The Architecture Process
The progression of the architecture definition process begins at stratospheric heights, moving all the way down to the ground in what is hopefully a smooth-landing implementation rather than an uncontrolled crash. All architecture definition processes should follow a top-down progression. As discussed earlier, this progression is grouped into levels: Level I representing the most abstract steps, and Level III dealing with the detailed design and engineering.
The objective of the Level I process is to develop a conceptual architecture model that properly mirrors the business process it is meant to solve. In order to be meaningful, this model must offer an end-to-end view of the defined scope; so the first Level I task is to define the scope of the architecture.
At this point in the process it is fine if the model is suitably high-level, otherwise you could trade-off coverage for specificity (to abuse the cliché: you could fail to see the forest for the trees). At this early stage you should resist the impulse to over-define the solution. I say this fully aware that a common criticism of architecture is that, due to its abstract nature, it is can become too ethereal and impossible to implement. The alternative, however, is to fail to develop the most flexible solution in an attempt to tackle detailed implementation concerns such as performance or operability. Remember, God was allegedly able to create the universe in six days and then be so satisfied with the results that he could rest on the seventh day (I still contend He missed out on quality assurance). You on the other hand, have to take the more humble view that, in all likelihood, the solution you define will not be perfect initially. Your focus should be one of flexibility. Architectures defined under the pressure of parochial concerns often end up being the opposite: stilted and monolithic.
A composer represents a symphony in a musical score and a building architect conveys her vision through the use of a mock-up. Likewise, a good IT architecture model should be fashioned in a manner that business people can relate to. As a high level construct, the architecture model does not need to depict all the elements needed for a proper technology solution, but it should serve as the basis from which the detailed technology components emanate. The visual representation of the architecture model is known as the Architecture Reference Framework. Creation of a powerful framework as a communications tool is a key ingredient to the success of the architectural process.
Last in Level I list, you will need to provide the bridge between the abstractness of the architecture model and the reality of the technology design. This bridge is provided by the definition of tenets and standards.
For example, the United States of America was formed as a federated republic with three independent powers to ensure checks-and-balances. This arrangement represents the architecture model created by America’s founding fathers. The Constitution describes the standards that define the workings of this model, and the Bill of Rights represents the tenets.
Like the Constitution, which can be amended according to Article V, the standards can be further refined into a more detailed form as the architecture development steps are followed. Standards should not be seen as an inflexible mantra never to be deviated from, but they do provide a foundation against which to measure technology decisions.
Now, like the Constitution, which seems like a nuisance at times to politicians, architectures are sometimes seen as an expensive burden in terms of performance and practicality. The reason for this is that oftentimes, people attempt to reify[1] the architecture as opposed to instantiating it[2]. Attempts to reify the architecture by trying to implement architectures in a too-literal a fashion will usually result in contrived, inflexible systems. Instead, the architecture model, tenets, and standards should be seen as a kind of Rosetta stone for the purpose of translating the more ethereal architecture concepts into more concrete, practical implementations.
I present the view that architecture processes should be driven from a Top-Down perspective. There is, amazingly, a school of thought out there that proposes the idea that a successful implementation can serve as a baseline pattern for a new architecture. This bottom-up view is most commonly espoused by some extreme proponents of Agile methodologies who have forgotten that methodology’s forte is in applying quick development and implementation processes; not in the creation of comprehensive, repeatable frameworks. A detailed implementation, no matter how well executed, cannot constitute a true architecture because it is an implementation; one that intrinsically lacks an appropriate level of abstraction. In the end, “architecture solutions” derived by trying to generalize a successful implementation end up being so narrowly defined that the best one can hope for is to use them as the proverbial hammer, turning everything into a nail.
Moving downwards from the Space Shuttle-height Level I, the Commercial Jet Level II architecture deals with the current and target architecture models that map to specific business functions.
A drum-roll here!
We have finally arrived at the technology level that ultimately corresponds to the domain of Service Oriented Architecture! In Level II we deal with the various methodologies and processes needed to define the services’ ontology and the enterprise design for the entire SOA fabric. Later on, I will expand on this level (after all, we are dealing with IT Transformation with SOA!).
There’s no arguing the fact that the architecture should ultimately deal with practical details, it’s just that the mapping to reality is more of an engineering exercise; not an architectural one. Call it semantics, but Level III is actually a stage dealing with the engineering and detail designs in which the architecture principles are correlated with specific technology elements and pragmatic tenets; not to wash-out the principles, but to apply them. Practical trade-offs can be made here to ensure the system will perform under real-life situations. Engineering in Level III is when and where you can and should address all questions of performance, practical scalability, and operability; not before. Hopefully, your great work at defining flexible architecture principles during the Level I and II steps will make this engineering effort easier.
Engineering in this sense is the art of translating the architecture patterns into real world solutions that take into account well-known practical implementation constraints. As such, the definition of the Level III architecture is more about the practice of engineering .
Remember this key dictum:
Architect for Flexibility, Engineer for Performance.
The engineering and implementation processes are responsible for instantiating the abstract architecture into a concrete form. Level I and Level II Architecture may have defined the need for a glass ceiling in the structure, but the engineering process will decide the thickness and brand of that glass ceiling. The strategic engineering role will seek further reuse of common solutions (e.g. use same glass manufacturer for all glass ceilings), without infringing on the overall architecture guidelines. Architecture is all about doing your best; engineering is all about doing what’s best.
Next week, we'll go on how to define the Architecture Scope. The very first Level I activity.
[1] The Webster’s Collegiate dictionary defines reification as, "to regard (something abstract) as a material thing." People who assume a flag “is” the country are reifying the abstract symbol of a flag. An Architecture that depicts a logical system as being completely modular should not be reified as an implementation that demands each module be run in its own computer.
Labels: Architecture, IT, Levels, Methodology, Model, Scope, Services, SOA, Strategy, Technology
posted by IT Transformation with SOA @ 4:05 PM
