- Jerry Larivee 

Justice Potter Stewart said that he couldn’t define pornography, but “I know it when I see it”.  I often feel the same about the term “enterprise transformation”.  Not that there haven’t been many attempts at defining transformation; I just feel that most fall short of addressing the vernacular use of the word.  Particular they don’t address just what is it about transformational projects that make them harder than any other large project.  Nor do they help identify when “transformation” is required.

So let me posit a different term: inertia.  Often when we use the term “transformation” what we are really talking about is significant or sudden change in inertia.  Consequently the role of Enterprise Architecture can be defined in terms of how it is used to manage inertia in an enterprise.

Transformation Overcomes Inertia

Enterprises develop inertia over time.  And just as inertia keeps a gyroscope from changing direction, inertia stops enterprises from changing themselves.  Transformation is about overcoming inertia to change direction.

Inertia is not always a bad thing.  Inertia can be very valuable in keeping an enterprise on track. When we talk about institutionalizing change we are talking about creating inertia that will keep the enterprise from reverting back to its old ways.  In this case inertia is the gyroscope that keeps the organization moving in the right direction.  It guides future decisions as processes and systems are updated.

Thus not all change is a change in direction.  Some change may be a course correction or a detour around a temporary obstacle.  Some change may be simply to keep going the same way but more efficiently or faster.  These changes may nor require a change in inertia at all, or may require only minor changes in inertia.

However, when a change in direction is significant or sudden inertia will become a major obstacle to change.  This requires an effort of Herculean proportions; this requires transformation.

Types of Bad Inertia

• Organizational Inertia – This is about people resisting change.
• Managers and executives resist change when they fear they will lose power because of it.
• Employees resist change when they fear they will lose their job because of it.
• But mostly people fear change because they lack confidence in the portability of their existing skill set and their own ability to adapt or learn new skills
• Financial Inertia – This is about the cost of change. Pre-existing investments in capital and resources make change expensive:
• We just built that factory last year.
• We just implementation that system.
• We’re still depreciating that expense.
• Process Inertia - The “we always do it that way” syndrome.
• System Inertia - We do it that way because that the only way the system supports and the system is too hard to change.

Strategy Sets the Course, Execution is the Journey

When we talk about direction for an enterprise we are talking about strategy.  Strategy does not simply specify a straight line direction; strategy defines a course from where we currently are to where we want to go.

Execution is how we translate strategy into action.  When strategy and execution are aligned the enterprise moves smoothly along the course laid out in the strategy.  Over time strategy changes and execution must change with it, but if inertia has built up and is not properly accounted for strategy and execution can drift out of alignment.  The problem is not that we don’t know we need to change direction; the problem is we can’t change direction as easily as expected.

Take the example of a car driving on an icy road.  If the road suddenly curves the driver will see it and know that he/she must change direction to match the curve.  So he/she turns the wheel of the car, but the ice on the road has robbed the tires of the traction required to execute that turn; the car continues to go straight.  The driver continues to turn the wheel for the expectation is that turning the wheel will cause the car to turn.  Finally the tires may summon enough traction to execute a turn, but at this point the driver may have over turned the wheel and the car turns more than required.  Anyone who has lived and driven in a cold winter climate knows how this story ends.

Unfortunately unlike the driver of the car on the icy road, it is not as easy to recognize when the enterprise has failed to change direction as desired.  Often times the enterprise fails to respond to even what are considered minor changes in strategy. This failure to respond may go unnoticed as may the next change in strategy and the next.  Left unattended the misalignment between strategy and execution grows over time.  Worse yet as execution deviates from strategy making strategy changes become harder because the assumed starting point may not be correct.

Back to the analogy of the car on the icy road; since the normal feedback associated with turning the wheel is not available, the driver turns the wheel randomly until he/she is no longer certain in which direction the wheels are pointing.  This is an enterprise skidding out of control.

The Role of EA in Avoiding the Car Wreck

It’s popular to talk about Enterprise Architecture as aligning business and IT.  Like “transformation” that has always struck me as too vague.  I prefer to talk about EA as aligning execution to strategy.

So if we define transformation either in terms of change to strategy or re-alignment of execution to strategy, the role of EA in transformation becomes one or more of the following:

1. Avoiding misalignment of strategy and architecture in the first place.
2. Recognizing when there is misalignment between strategy and architecture.
3. Identifying specific misalignment between execution and strategy.
4. Root cause analysis in the misalignment of execution and strategy.
5. Designing new modes of execution that align with strategy.
6. Identifying and minimizing the potential for creating bad inertia in the execution of strategy, in particular avoiding System Inertia, one of the most common and troublesome forms of inertia.

Posted by Jerry Larivee at 05:23 PM | Permalink | Comments (0) | TrackBacks (0)

As a participant of many discussions on Enterprise Architecture – the most insightful I had the opportunity to take part in as a member of the Open Group Architecture Forum – I found that attempting  to define terms like “Enterprise Architecture” or “Business Architecture” tends not to result in conclusion. While part of these divergencies are due to different contexts of the participants, most of them seem to stem from the ambiguous semantics associated both with the construct of a compound in English language, as well as with the ambiguous use of the word “architecture”[1].

In the following, I try to evaluate the semantic dimensions of “architecture” compounds – as a framework for structuring discussions, and facilitating communication. Subsequent postings will evaluate divergent interpretations of terms commonly used in the context of enterprise architecture, and provide recommendations how to handle these interpretations in interactions between architects.

Please contribute your own views on how the word architecture is used. It will be extremely interesting to gather additional aspects of the term.

Kind Regards

Thomas Obitz - Principal Architect

Composing “Architecture”

Within the IT community, the term “architecture” traditionally is used in one of three ways: One is as a characterization of an object (the “architecture” of a cathedral), the second is to describe the process of designing these architectures[2].  The third meaning – the profession of the architect – today is derived from the second[3].

In the characterizing context, an XYZ architecture can be (without claiming completeness)
·         the architecture of an XYZ (Enterprise Architecture - Architecture of an Enterprise)
·         an architecture for an XYZ (Enterprise Architecture - Architecture for an Enterprise)
·         an architecture describing the XYZ aspects of something (Information Architecture - Architecture describing the information assets of an Enterprise)
·         an architecture describing the aspects of “something” which are relevant for (constructing) an XYZ (Information System Architecture)
·         an architecture consisting of XYZs (Process Architecture - Architectural description consisting of process models)
·         an architecture in the state XYZ (Target Architecture)
As an art, we find “XYZ architecture” as
·         architecture using an XYZ approach (Enterprise Architecture – doing architecture using Enterprise Architectual approaches, even for a smaller unit than an enterprise, or for a government)

Architecture of an XYZ (constitutional)

 ISO 1471 talks about the “architecture of software intensive systems”, which was usually abreviated into “software architecture”. This straightforward interpretation has been transferred to the field of Enterprise Architecture only recently. The “Architecture of an Enterprise” therefore may describe the relevant aspects of an enterprise, the way an organization is structured, how its departments interact, and how they generate value.

Architecture for an XYZ (demarcational)

 The terms “Enterprise Architecture”, “Departmental Architecture” or “Line of Business Architecture” can be used to describe the scope an architecture is relevant to. An “industry architecture” is an architecture not of, but relevant to a specific industry. If used in this way, “Enterprise Architecture” does not explain what aspects it describes, but just that it applies to the enterprise as a whole. This missing description, however, can be inserted between the two terms: An Enterprise IT architecture describes the IT landscape for the enterprise, an Enterprise Data Architecture its data assets.

Architecture describing the XYZ aspects of something (projective)

 “Enterprise Business Architecture” can be used to describe the business aspects of an organization, i.e. the aspects related to achiving its vision and purpose. Enterprise Information Architecture describes the information related aspects of an organization, including their relationship to other architectures.
This use of XYZ architecture focuses on the aspects of architecture related to a specific concern. It therefore comprises the projection of architecture to a viewpoint or set of viewpoints, and hence is highly dependent on stakeholder concerns.

Architecture describing the aspects of “something” which are relevant for (constructing) an XYZ (contextualized)

 When John Zachman wrote his famous paper “A framework for Information Systems Architecture”[4], he spoke about much more than just information systems. His framework considers the context in which an organization builds such systems, and which influence their gestalt.
It is common to perform such contextualization in many compositions of the term architecture, and this approach can be considered as an extension of the constitutional use of the compound.

Architecture consisting of XYZs (compositional)

 When talking about “Process Architecture”, we are by and large talking about a documentation set composed of process documents. A similar thinking is behind the (outdated) perception of data architecture as a corporate data model.

Architecture in the state XYZ (state)

 Using the terms “as is” or “target” architecture describes a state in the development of architecture.

Architecture using an XYZ approach (method)

Architecture organized in an XYZ fashion (organizational setup)

Federated architecture is a way of performing architecture activities in a specific organizational setup. It can be used both for architectural deliverables (where deliverables of a higher level are detailed at the next level) as well as for a way of doing architecture (with a defined distribution of responsibilities between layers).

Posted by Thomas Obitz at 10:24 AM | Permalink | Comments (0) | TrackBacks (0)

“Identify 10-12 [application] ‘architectures’ that are standard.  The challenge is to build a decision tree to drive the ideal architecture.

Q1: Are there any defined set of enterprise architectures?
Q2: Are there any decision analysis mechanism (like that for determining architecturally significant requirements in ATAM) already available?”

I’ve seen a few companies attempt to do similar although not quite this ambitiously.  Most organizations have started by identifying common architects that are already in use within the organization and generalizing them.  This has the decided benefit that the architects represent technology components already known to the organization and have proven implementations against use cases relevant to the organization.  I fear any effort to define a standard set of architectures outside the context of a well define problem domain (i.e. the environment of a given enterprise) would be too abstract to be practically applied within any given IT organization.

The second challenge is describing the architects in standard ways that are well understood by everyone using the architectures.  Here there are some good works to start with:

• The TOGAF Technical Reference Model defines a core taxonomy for describing the components and conceptual structure of an architecture.  http://www.opengroup.org/architecture/togaf9-doc/arch/chap43.html
• FEA (Federal Enterprise Architecture) defines a set of Reference Models for describing the important elements of architecture in consistent ways. http://www.whitehouse.gov/omb/e-gov/fea/
• There are several good catalogs of common enterprise architecture patterns:

• Fowler: Patterns of Enterprise Application Architecture” http://martinfowler.com/eaaCatalog/

• Hohpe & Woolf: “Enterprise Integration Patterns” http://www.eaipatterns.com/

The last part of the problem is even more challenging:  Given a problem how does one pick the appropriate architecture? 

Methods like ATAM are designed to evaluate a given architecture against a given set of requirements.  So using ATAM would require evaluating each standard architecture against the given requirement set and picking the one that fits the best; this would be impractical in the real world for more than two or three architecture.  I’m not sure that inverting the function is possible in a generalized way.  However, if as said before, one narrows the problem domain to a single enterprise and a sufficiently small set of architectures one may be able to define such a function.

The other challenge for picking an architecture based on any given problem is ensuring that the problem has been broken down appropriately first.  Most large enterprises have complex problems, but the successful solution is not an equally complex solution but rather a collection of simple solutions.  Each one of these solution components may map to a different standard architecture.  This componentizing of the solution also simplifies the process of matching problems to architectures since it means both simpler problems and simpler architectures.  Complexity is the enemy.

Another technique for managing the complexity is to divide the standard architectures into layers.  If one limit the problem domain to defining standard physical architects (disk, memory, CPU, networks, I/O, etc.) then this starts to sound a lot more doable.  This may not be the ultimate goal, but it's the start the first step in a layered approach that starts with defining standard physical architects, then standard application architectures, data architects, process architectures, security architecture, etc.  Thus the process of mapping a problem to a standard architecture would actually involve picking an appropriate architecture from each layer.  One may find that each layer has a relatively small set of standard architectures, but in combination the layered architectures represent dozens of complete architectures.  The FEA Reference Models sort of takes this approach.

So whereas the goal of defining standard architectures within an organization has many advantages not the least of which are: reduced technology complexity within the organization, increase reuse of both components and skill sets throughout the organization, decrease risk, and decrease cost.  Unless you happen to be the Federal government of the United States of America don’t look for general solution, focus on the problems in your organization and the tools already at your disposal to develop more specialized solutions that give more immediate benefit.  Where there is some effort, there is some success.

Posted by Jerry Larivee at 02:57 AM | Permalink | Comments (2) | TrackBacks (0)