Tag Archives: complexity

Next generation of Enterprise Architecture

Early this morning, while glancing through the latest tweets on my iphone, I was attracted by last post from Richard Veryard on slideshare:


Good slideshow though, but since I felt that it is going a bit in many different directions, I felt that I had to react on this one, directly on my blog to reflect my own thoughts regarding: How should we deal with enterprise architecture in big companies? Richard starts his slideshow by exposing 2 historical views of Enterprise Architecture: the “Simplify and Unify” view and the “Differentiate and Integrate” view. Structuring the begining of his presentation through this split, Richard starts quickly to mention ancient approaches such as “Information Engineering” structure versus the well-known “Zachman framework“. then, he also mentions the different trends / challenges the EA is facing to… But, finally, what is the main stand-point that comes out of this presentation? To be honest, I miss a bit Richard’s stand point at the end of the presentation. So here is mine (stand-point):

My point is…

I would say that, in general, I try to learn from history and experimented people such as John Zachman and Roger Session, but at the same time, I don’t want to follow them blind. I think times change and EA has to change as well (even quicker).
To me, such approach as Zachman’s framework, which is a 198x’s vestige (see my article: Top Four Enterprise Architecture Methodologies) or trying to simplify the IS way too much, when if fact we, as Enterprise Architect must admit/deal with this complexity (up to a certain point). We (EntArch) have to make this complexity manageable and introduce enough flexibility in it to better support the business objectives.  Not saying, as I mentionned earlier that we should forget the previous frameworks or structures, but more to know them, understand their points, why they raised when they did and look at today trends/issues to make our own opinions.

Then, let’s re-invent the wheel again will you tell me… No, sorry I am not this kind. I looked for a real EA methodology for a while before finding one that suit the best to my personnal beliefs. To me, the Praxeme methodology is the EA methodology that suits the best to my personal perception of what the EA should be/do.

There I think that Praxeme is fully supporting the EA challenges Richard is pinpointing. (see fig. 1)

My Conclusion

I would quote Richard when Richard writes:
“Not suppressing complexity but managing complexity”

This is exactly what I am trying to do when practising EA. EA should not be done for the “beauty of the move”, but for the whole-of-the-enterprise sake and benefit. To add to Richard’s presentation, I would say that in order to “manage the company IS complexity and support business objectives“, we need both the theory and the practice. There,  it’s time to mention Emmanuel Kant that is underneath the Praxeme’s approach:

Theory without practice is useless; Practice without theory is blind.

Let’s come back to the title: “Next generation of Enterprise Architecture”. To me the next generation of Enterprise Architecture and as a consequence: Enterprise Architects :D, where I expect from myself to be a key player ( 😉 french humor) is based on a true Business approach. We, as Enterprise Architects, have to get our key business decision makers to understand the value of spending money on EA to gain money on the maintenance (IT costs), reduce the project failure rate… stop re-doing project to achieve the same goals without succeeding each time.

Once your top management is convinced, then it is time to go to work. Start from the semantic level to keep the flexibility in the whole enterprise system. Break the silos, avoid hard-coded business rules that have lead us to where historic companies are entangled in today. Complex and frozen Information System that is not anymore able to support the always moving targets of our companies, neither the economical volatilities that we are currently facing or the increasing competition (to mention a few…). Our companies have no choice to evoluate or die. This is pure evolution theory.

  • If you are lucky and work for companies like Google or Apple, then you have not much to achieve in the first hand (convinced your management), mainly because the top management is already convinced and they have trusted the vision I described above. In addition, they didn’t have to manage the complexity coming from all the heritage of ages (usually called “Legacy”).
  • In case you’re not working for Google or Apple, then you are even more lucky! Look at all the interesting job you have in front of you! I use to quote Booker T. Washington when saying:

“You measure the size of the accomplishment by the obstacles you had to overcome to reach your goals.”

So, let’s go to work!

Agile and Complex projects

Catching up with my posts… Here is the trigger of this post: an interesting twitter discussion with my #entarch fellow: @RSessions
mcgoverntheorymcgoverntheory: Most #CIO dont know how to deal with issues in #Agile projects. Troubled projects lead to a backlash against #agile approaches. Endless loop 12:17pm, Nov 01 from Web
RSessionsRSessions: @mcgoverntheory Agile methodology methodology doesn’t scale to complex projects. 12:37pm, Nov 01
enectouxenectoux: @rsessions Don’t agree. It all depends of the scale of the project and awareness of project members.
RSessionsRSessions: @enectoux The scale of the project is what I mean by it doesn’t scale to complex projects.
enectouxenectoux: @rsessions lol, ok then I agree :o) But “complex” is not equal to “large”, isn’t it? To me, a complex project can be a small ones as well and the #Agile issue is more related to scale (large /small) than complex
RSessionsRSessions: @enectoux But I believe Agile can be applied to large projects once we get their complexity under control.
enectoux: @RSessions Well, this time I fully agree.

@RSessions is much more knowledgeable about managing complexity as I pretend to be. If you are interested, you will find lot of interesting thoughts and information at his website: http://www.objectwatch.com/

My intention here is to dig a bit more into this “complexity thing related to Agile”. Basically, if we look at Agile’s manifesto, here are some of the main principles underlie in it (short extract):

  • Customer satisfaction by rapid delivery of useful software
  • Welcome changing requirements, even late in development.
  • Simplicity
  • Regular adaptation to changing circumstances
So, if we look at these principles, some of them will be very difficult to argue with when it comes to manage complex projects through Agile. Take the principle “simplicity” for instance 😉 or on the other hand, other principles like “adaptation to changing circumstances” are more in favor of managing the complexity.
My point is that we cannot state that Agile doesn’t scale to complex projects. It is all about how you can deal with complexity. How much you (as the project leader or project member) can deal with a complex situation. Are you afraid of complexity or are you comfortable with it? If you are comfortable with it, then Agile methodology can help you to manage your complex project, parallelizing activities, having short development loops, enabling you to validate your “still fuzzy” concepts by testing them towards reality quickly than if you were in a “not Agile way of working”. Agile methodology is, to me, very powerful. But, like any powerful tool, it has to be handled with care. It is very easy to get trapped when using Agile and then, blame the method. I’ve seen and I see it many times. Among the principles I mentioned above, two are missing in this list (but not missing in the full list):
Close, daily cooperation between businesspeople and developers” and “Projects are built around motivated individuals, who should be trusted“. these two might look obvious, but they are to me the fundamental ones. Without trust between IT and business in a Agile project, there is no way to make it a success. As enterprise architect, one of our challenge is to achieve “Business and IT alignment“.
There is many ways to try to achieve this alignment, but I think that one of the best one, when the trust is lacking, is to re-establish this trust by succeeding a complex project using Agile methodology. Then you prove what you prone  as “alignment of Business and IT” has a value for both and for the enterprise.
I have many examples of such projects, at different sizes. Some have failed and some have succeeded. But let’s me ask you about you’re experience. Try to remember, any good personal experience of using Agile methodology in a complex project and making it a success?