Envisioning the Many Levels of Architectural Enlightenment

by Mike Rosen, Director, Cutter Consortium Enterprise Architecture Practice

When I teach architecture courses, one of the things that I try to convey to the class is the different levels of complexity/interconnectedness/theory that exist within architecture. It is not the goal of the course to make people experts at metamodels, but it is important for an architect to understand that architecture is founded on architecture of its own. I was recently discussing this with a fellow architect, who also happens to be a Buddhist and who compared this to the different levels of awareness -- or enlightenment -- for which a Buddhist strives. I wouldn''t try to compare architecture to a system of spiritual belief, but there is something about the increasing levels of awareness that an organization and individual architects reach as they conduct their journey.

At first, people and organizations are starting from a level of architectural ignorance. This is where they don't know what architecture is, why they would need it, or how to use it. Sometimes we call this "unconscious incompetence," or where you "don't know what you don't know."

At some point, organizations reach a level of complexity that can no longer be ignored. They begin to understand that they can no longer just build single projects in isolation. There is a need to consolidate, simplify, and rationalize infrastructure. There is a need for commonality across applications -- both at a technical level in terms of security (single sign-on, compliance, etc.) and at a business level in terms of common information (customer, products, etc.). At this point, a level of initial awareness is being reached. There is an understanding that architecture is necessary, but limited understanding of what it is or how to do it. We might call this level "conscious incompetence," or where we're starting to know about all the things we don't know.

At this level, the architectures that are produced are generally conceptual. I don't mean in terms of the classic levels of abstractions (conceptual, logical, physical). Rather, that architecture mostly exists to convey concepts. The architecture that is produced is generally in the form of drawings (Visio seems to be the most popular). There is little commonality among different architectures developed by different people, and little or no formal underpinning to them. However, at least architecture is being created and applied.

After some time, if architecture has demonstrated some success, architectural alignment can begin to be achieved. Alignment can occur in many forms: alignment between systems and common infrastructure, alignment between IT systems and business goals, and so on. To enable and manage the alignment, an organizational structure emerges, such as an architecture group or program with some form of governance. An increased understanding of architectural concerns manifests itself in the creation of business, information, application, and technology perspectives. The organization starts to see the big picture. Perhaps an IT inventory is created.

At this point, the architecture itself is more mature and reaches the level of what I call formal architecture or "architecture as specification." Architecture has moved beyond simply conveying concepts in drawings to where it is used to specify designs, implementations, and standards. In addition to the conceptual drawings and the standards documents, we start to see architecture take the form of reference models and to use patterns as a way of specifying the commonality across systems. An architecture repository might be established. Some commonality exists between the different architectures that are created, but, in general, standards, reference models, and patterns are applied to systems, not to the architecture itself. Today, this is the level of awareness that I see in a few of the better organizations. Yet there is still more to architecture.

Eventually, architecture can become integrated and actionable. There is a formal link between the different architectural perspectives (business, information, application, technology). This allows for traceability from business requirements to systems as well as impact analysis from systems back up to business objectives. Metrics are in place to measure architectural impact. Architectural artifacts themselves are based on patterns and reference architectures. Tools can implement and enforce architecture. Model-driven development is common across the organization. In general, architects are aware of the underlying formalisms but may not completely understand them. Quality, time-to-market, reuse, flexibility, and extensibility are all improved.

This level of maturity requires meta-architecture -- the architecture of architecture, where formal underlying concepts tie everything together. Consistency across architecture is achieved because all the architectural artifacts conform to formal metamodels. Integration between perspectives is based on relationships between metamodels. Different levels of abstraction are defined, and formal transformations between them are automated. Tractability and impact analysis are based on relationships at the metadata level, which are implemented in standards-based repositories.

But wait, there's more. How do we achieve consistency and integration across our reference architectures and metamodels? Part of the meta-architecture is the underlying formalism of the meta-metamodel. Ouch! My head hurts! Only a few people, if any, need to understand architecture at this level, but it does exist, and it is part of the formalism and theory of architecture.

I recently had a conversation with someone fresh out of graduate school with a master's degree in computer science. I asked him what they had studied in terms of enterprise architecture, and he said, "Nothing, they only studied theory." Somebody needs to be enlightened.

I welcome your comments on this issue of the Cutter Edge and encourage you to send your insights on the market in general to me at mrosen@cutter.com.

-- Mike Rosen, Director, Enterprise Architecture Practice