« Business Enhancement and Constructive Innovation | Main | The Structure is the Strategy »

August 25, 2005

Alignment, Configuration, and Enterprise Architecture

According to Telelogic/Popkin, the brand leader in enterprise architecture management solutions, "BUSINESS MODELING enables you to realize an advantage over your competitors. By accurately knowing how your business runs, you can enforce efficient processes, and change not-so-efficient processes to make your company more cost-effective and adaptable to change than your competitors."

What that modeling includes and offers is very well explained in numerous publications and studies, such as Yogesh Malhotra's specific but introductory 1996 paper, Enterprise Architecture: An Overview. And after a few of those descriptions have rolled by, the thought that jumps to mind is not "what is business-IT alignment" but instead "why didn't architecture already do that trick?"

One answer to this question is that the business management team responds primarily to what it knows how to measure. In this case, that was a barrier. The speed and cost of business impacts from architectural practice are more evident in a contrast to architectural alternatives than they are from comparison of current period activity to previous time periods of equal length. Because financial accounting has dominated management culture for so long, that accounting mode of period-over-period measurement and response was naturally but mistakenly applied to architecture, giving unusable results.

Different architectures are like different game plans; we know that both can play on the same field, and for long stretches of time neither one may establish superiority in terms of the score. But game in, game out, the always immediate prospect is that one plan is more likely to offer up the game-breaker than the other; and the longterm prospect is that one plan is more likely to win more games than is the other.

Another answer to the question of architecture's delayed impact comes from the now familiar Tim Russert quote, "The older I get, the smarter my father seems to get." How is this an answer? Well, the quote attests to the fact that youngsters don't have the wisdom of their parents, and not having it, the youngster's naivete makes the father's wisdom invisible. Only experience allows the youngster to begin to recognize what the father already knew. Businesses have lost a lot of their naivete in the last four years, as global and scientific forces have brought many different game plans onto their field more frequently and persistently, exposing the weaknesses in the business model. Suddenly, the design-level flaws that architects had always wisely strived to prevent and repair are surface wounds that the business responds to with a proper urgency and respect.

So why is this response -- in particular the flavor called business-IT alignment -- most often invoked by names other than "architecture"?

Here, the answer is an apparent phenomenon that is just not obvious. The answer is that the business experience has to go through stages of maturation, and at different stages, the architectural issue tends to have a different driver or focus, and thus a different name.

We can track this maturation in a maturity matrix. Not to be confused with hierarchical "maturity models", the maturity matrix for the business finds it positioned within classic x,y coordinates of architecture -- functionality and reliability, or here, competency and responsibility.

In the maturity matrix, a business could at any point in time be:
- in the upper left quadrant (multi-competent, less responsible)
- the upper right quadrant (multi-competent, more responsible)
- the lower left quadrant (uni-competent, less responsible)
- or the lower right quadrant (uni-competent,more responsible).

The reason for that point of view is that companies often add functions to their existing arsenal, only to find themselves overwhelmed by the resulting complexity or by being stretched too thin in support obligations.

More typical, though, is a linear or trend-type view. In the historical pattern of 1999 to now, issues such as supply-side economics, hypercompetition and regulation have followed each other on a trajectory that tracks enterprise adaptation to the changing business landscape. In the maturing adaptation on that trajectory, the business goes respectively from getting to be really good at what it does, to being really good at more than one thing, to being able to manage the intricacy of its means for being good at more than one thing.

Correspondingly, one step in this maturation concerned itself mainly with process efficiency, which drove a focus on the supporting assets and therefore BPR and asset management.

A following step concerned itself mainly with innovation, which drove a focus on the supporting infrastructure and therefore e-business transformation and change management.

Now currently the concern is with control of the functional complexity, which drives a focus on accountability and governance, or performance risk management.

A logical next step will be portfolio strategy management, as the business learns to be more than one kind of business simultaneously.

By calling these episodes "steps", we suggest that in some strong sense there is progress being made. The notion here is that the mastery of enterprise architecture is incrementally achieved as the operating environment increasingly demands it. The fittest survive -- not because they "picked the right architecture", but because they have the ability to manage an architecture comprehensively, so that an advantageous architecture could be effective for them.

With related I.T. issues, progress comes along in like manner. Attention to the mounting volume and diversity of assets and resources has been progressing from inventory to investments to configuration and deployment -- while attention to proliferating functions has been progressing from selection to integration to policies and orchestration.

As a result, business intelligence is necessary for analyzing the underlying elements appearing in newer perspectives on business processing models. The need for this intelligence is stimulating new automation dedicated to logical information services such as CMDBs (configuration management databases) and simulation -- emphasizing the management arts of What Could Be over those of What Should Have Been.

For a closer look at this business intelligence see the article "The Conceptual Basis of Configuration Management Data", here at Archestra.

Posted by Malcolm Ryder at August 25, 2005 12:00 AM

Trackback Pings

TrackBack URL for this entry:
http://www.malcolmryder.com/cgi-bin/mt-tb.cgi/114

Comments

Post a comment