The Holy Grail of Enterprise Architecture?

Wednesday, October 7, 2009 |

There's been several conversations in LinkedIn groups on existence of a list of Enterprise Architecture Guidelines. These questions have been asked from a Governance point of view (how does my organization assure that projects comply?), from a theoretical point of view (is it possible?), and even from a sharing the pain point of view (why is there such a resistance to following our guidelines?!) Of course, if such a list exists, it could be tremendously useful to quickly creating Enterprise Architecture programs. So it's an intriguing thought, but is it just that - an interesting thought exercise?

Theory first. My apologies in advance for mathematical hue of the response, but this question can best addressed by a branch of mathematics known as set theory.

Let's say such a list exists, then what are the attributes of these guidelines?

  • They would need to be almost infinitely customizable to account for every possible combination of organizational growth by every organization.

  • They would have to address all business/public verticals, multiple business operating models, all business outcomes (good, bad, and ugly)

  • They would have to somehow tie all organizational processes and services to the business outcomes - arguable one of the more important roles of EA.

  • And that's just a start.
I did, however, say 'almost infinite' - which is by definition, discrete. While each organization is unique, there is a discrete number of organizations. Their growth patterns and responses to challenges are even more standardized thanks to normalization. So mathematically, a set of guidelines that accounts for all these variations must be discrete.

That's the theory, now reality: while discrete in nature, a list of possible guidelines would still have large enough cardinality to be unusable. And that's before we start considering unique organizational circumstances. Anyone can quote from the gospel of best practices on how to build pure software. Unfortunately, purity is not equivalent to good business - "perfection is the enemy of good" goes the quote. Yes, it can be easy to slip down the slippery slope of "good enough" to bad outcomes, but managing that risk is the job of any oversight organization such as Enterprise Architecture. Here are a couple of practical examples of where best intentions can lead:

  • Reduce the number of non-core business processes that perform the same or similar functionality as a method for reducing cost.
    • Hard to argue with this as a guideline, especially in current economic times, right? However, process optimization has been a fertile field for both tremendous success and catastrophic failure. If the organization is comfortable with the price point of existing operations, why would it want to disturb what already works when it has 31% chance of success? I understand that these operations may be messy. They may not be elegant at all. They might even involve Excel spreadsheets and Access databases and email-based workflow. They do have a tremendous advantage over any project proposal: they work today.
  • Reduce the number of unique data structures passed between systems
    • Believe it or not, sometimes this is not desired. Anyone who's been in Data Management space for any period of time knows that it's nice if everyone needed the same data all the time. Trouble is, it never happens. Different perspectives require different information at different times. There is nothing neat and predictable about how business uses data. Hardly anyone is willing to wait an additional week for their information to be presented in standardized format when decisions are needed right now.
  • Loose coupling of systems and process
    • This is one of the pillars of Service Oriented Approach. But much to the dismay of the adherents of SOA Grand Unified Theory, value of SOA and even its applicability are heavily dependent on business operating models. So the real question is: how much loose coupling is enough? Are there, in fact organizations where loose coupling is a bad idea from a business perspective? There are plenty of examples where this guideline could introduce too much organizational complexity, or too much risk against the asset portfolio.
I'm not just trying to be a contrarian here. What these examples should highlight, however, is that Enterprise Architecture Guidelines are entirely beholden to many things - business goals, business models, business operational models, stakeholder perspectives, among others. Trying to assemble a list of such guidelines is difficult at best because a lot of them will be contradictory. What it resembles most is a decision tree with each organization's 'as is' and 'to be' states as inputs. Without that, at worst, this exercise can become a hunt for "Holy Grail" of Enterprise Architecture. So rather than concentrating on compilation of such a list, I would advise focusing more on the process by which such a list could be compiled for a given organization. We often hear that right level of "granularity" is crucial when it comes to good systems design. Since an organization is just a system of systems, shouldn't that principle be applied in this case?

Aleks

4 comments:

Jack Bush said...

This sounds an awful lot like the search for better software development techniques, dating back to the 1970's. That theoretical work resulted in a number of marginally useful improvements. Perhaps SAAS will some day reduce all software to a finite set of robust, customizable modules. For now, most development is still done the old fashioned way, guided by skill, experience and principles from the likes of "The Elements of Programming Style" by Kernighan and Plauger.

Maybe the EA field can avoid some of the detours taken in the software development world by sticking to principles and not wasting too much time looking for the grail.

Robert said...

That's a bit more time, effort and costly research than I would have gone into, but hopefully it'll work out for them.

Chris Bird said...

A liitle phrase slipped into this post - perhaps unnoticed by others...."but managing that risk is the job of any oversight organization such as Enterprise Architecture..."

The implication of this statement is that EA is an oversight organization. If that is so, then I think it bodes poorly for EA. Governance is almsot always seen as barrier to innovation. Whether true or not is a subject for a different post.

I would hope that EA is on the value creation side of the fence, not simply pigeon-holed as a governance organization

Unknown said...

Chris -

Excellent point. Oversight is just one of the major responsibilities of EA, not THE responsibility of EA. I'm also going to take your suggestion on a separate post of whether governance is truly a bottleneck - as it is so often perceived.

AAB