I have been thinking a lot about enterprise architecture recently (an occupational hazard I must deal with on a daily basis). I got to thinking about how, over the years, I have noticed a distinct pattern underlying EAI projects that work out well. No, I don't mean SOA or Open APIs or protocol independence or any of those IT-shaped things. The pattern is at a different level. It goes like this...

I am plunging headfirst into a new EAI project. Worse case it is in a domain I know little about. When this happens I need to engage in an intense bout of vertical learning curve climbing. Without knowing the lingo I will not have enough of a shared vocabulary to engage in conversation with the domain experts.

Once vocabulary is out of the way, pictures start to form in my head about the "as is" situation. The resultant picture of existing IT systems is always messy, always complex. No surprise there because these projects generally are initiated by senior management seeing the correlation between messy complexity and cost and thus resolving to do something about it.

Now comes the job of staring long and hard at the complex behavior of the existing IT systems and comparing that complexity with the complexity of the real world. In other words, identifying complexity that is inherent to the problem (I cannot do anything about that) and separating it from complexity that can be removed with the aid of some architecture &038; design work[1].

Gradually - this can take days, months or even years depending on the size of the project - the apparent chaotic complexity of the real world begins to yield up patterns of behavior. It is a bit like watching complex traffic flows: of cars, animals or people, it matters not. At first, it can seem chaotic beyond words but then, slowly you see the patterns. What at first appears random and non-deterministic gradually becomes non-random and deterministic.

At this point, real progress can be made. The job of an enterprise architecture is to identify and then leverage the patterns. The complexity of the real world is the "acceptance test" the architecture needs to pass. Can the architectural model successfully exhibit the required complexity of the real world? Can it do so by strategic use of the identified key patterns and combinations of those patterns?

The patterns I am talking about here are the software equivalent of moving parts in an engine. A standard engineering mantra is to keep the total number of moving parts as small as possible. I find the same concept works well in enterprise architecture - with a twist. For me, the real trick is to find a set of key patterns and ensure that they can be combined together in a myriad of ways to yield what appears to be "complex" behavior but which under the hood, is not truly complex at all.

I call this combinatorical architecture. The essence of it is boiling down problem domain chaos into the pseudo-chaos exhibiting by a combinatorical explosion of key patterns joined together in different ways. When it works, the chaos of the real world will only appear truly complex if you cannot see the pattern combinations underneath. Once you see the pattern combinations, the complexity melts away and the underlying simplicity is revealed...

It is those delicious moments - when the simplicity of pattern combinatorics replaces unruly complexity - that make enterprise architecture such a rewarding activity.

[1]
http://seanmcgrath.blogspot.com/2003_07_20_seanmcgrath_archive.html#105923521456343257#105923521456343257

ITworld.com

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine