IT Transformation with SOA

On the Creation of Tenets and Standards

You have defined the technology strategy and the architecture scope. On the table sits a clear architecture model and on the wall you have a nice poster with architecture reference framework that will serve as a coherent beacon throughout the effort. What’s next?

Four decades ago, men set foot on the Moon. The beginning of that incredible journey was promulgated in this mission statement by JFK: "This nation should dedicate itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to Earth."

This is one of the best examples of a mission statement that you will find anywhere. It is succinct, clear, and comprehensive (I especially like the bit “…and returning him safely to Earth”—very thoughtful.) What was not clear was what would follow next. It wasn’t obvious at first that NASA would be the agency responsible for the mission (the Air Force wanted the gig), and then there was the question of who would make a good astronaut (the idea to use circus performers, divers, and mountain climbers was first considered, but disposed of in favor of test pilots). Then there were the questions of the type of technology to be used and the project governance (using myriads of contractors working under a common NASA governance was the one chosen). The number of decisions and choices that had to be taken was staggering.

As with the Moon mission, to reach the sky you must first touch the ground. Even at Level I, the architecture must move into the “where-the-wheels-touch-the-road” area. Work may start as abstract and conceptual, but eventually it has to reach the point where it is necessary to explicitly articulate the specific rules, tenets and preferred standards that will constitute “the practical canon” of the architecture. This canon will help clarify the preferred approach and will serve as a lighthouse for dispute resolution purposes. As covered earlier, the US Constitution is a perfect example of Tenets and Standards defined to make possible America’s “mission” as represented by the Declaration of Independence (the part where we are all entitled to pursue happiness?)

When applied to systems architecture, you’ll need to start defining concrete approaches. For example, it’s all very well to pursue a distributed processing model, but will you use the suite provided by a specific vendor? And if so, which one? Or, will you prefer to play the integration game and select amongst best-of-breed solutions. If so, which ones and under what criteria?

You’ll need to define tenets.

The dictionary definition of tenet is this: a principle, belief, or doctrine generally held to be true; especially one held in common by members of an organization, movement, or profession. In our context, the tenets should be mapped within the end-to-end architecture model and should represent a summary of the consensus and direction of specific strategic choices.

Tenets[1] should be documented in such a way as to provide broad exposure to the technology principles without being buried in dense documents. Tenets can be categorized, and sometimes should be prioritized in the case (hopefully rare) where two tenets result in contradictory directions.

There are different types of tenets:

· Category I Tenets represent clear-cut best practices that apply to all projects. These are the tenets that are core to the project and therefore the ones that you need to worry about first.

· Category II Tenets tend to revolve around the “technology context”, or industry, and are usually a more detailed specification of process and technology choices.

· Category III Tenets represent choices made at a departmental level. These are options that have a narrower scope and therefore their selections can be more a matter of individual or department preference. That is to say, given a set of feasible options, you simply choose those that you believe are the most appropriate to your company.

Just to state the obvious, Category II Tenets should not violate Category I Tenets, and Category III Tenets should conform to Category II Tenets.

The formulation of tenets is as much a key to the entire transformation project as is the framing of a constitutional convention. After all, it is here that you define the rules that will serve as the de-facto guide for all future decisions regarding the project; so let me cover a bit of the “how” you can accomplish this step.

First, if you have not yet defined clear governance for an architecture group, you should do so now.

At this point in the process, the core architecture team should be relatively small; formed of a few senior individuals able to cover the span of knowledge needed for the transformation (systems, applications, data, SOA, etc.) Most importantly, this core team should be tasked to facilitate the elaboration of tenets and standards.

The next question is what specific role you and the architecture team will take vis-à-vis the tenet and standard decision-making. Here are some ways you can arrive at them:

1. Moses Coming Down from the Mountain. Here you and your architecture team go to a retreat, hash out the Category I Tenets and return wearing long white robes to announce your “commandments” to the rest of the technology areas. In my experience, this style only makes sense in two scenarios:

· A project has been so delayed that any more debate or analysis-paralysis will place its success in jeopardy. A strong “do now-ask questions later” stance is required.

· The great majority of the technology team is formed by external resources and therefore not emotionally committed to the project

Otherwise, I recommend not following this approach, unless you wish to disenfranchise the very people whose support you’ll need in the grueling months and years ahead. You would also risk losing the benefit of the insights and opinions of the rest of the technology team.

2. Edicts from the Benevolent Dictator. First let me state I believe the term “benevolent dictator” to be an oxymoron. The Benevolent Dictator approach is a softer form than the Moses style because it at least allows the voicing of opinions of all key technical members through the means of a Technology Steering Board. You will then be able to assess all the opinions and decide upon the chosen tenet. If this process was truly unbiased and resulted in a decision that properly accounted for the strength of an argument favoring one tenet over another then this method would actually be ideal. In truth, it is almost impossible to remove the natural biases of the decision-makers. You risk alienating the rest of the technology members if they perceive the entire exercise as just playing lip service—an exercise on futility.

3. The Democratic Caucus. Here you debate and ultimately decide the preferred tenet, based either on consensus or outright vote. Obviously, you will need to allocate extra time to allow for the very heated debates to follow; plus secure the assistance of HR and a good therapist to deal with the aftermath of bruised egos! In principle, this process may work under some circumstances but it also has its issues if you are facing an organizational structure that comes already fragmented into groups. Let’s face it, the chances that you will get a consensus between mainframe people and people who dabble with Java is not very high.

4. The Grass-Roots Convergence. Why even bother with a process? Let people decide themselves! After all the Internet emerged with approaches and standards that eventually replaced those of established vendors. I believe this approach is actually effective in small start-ups and in those situations where you have a highly involved and well-experienced base. I am afraid that it might not lead itself to being effective in the more cavernous world of large enterprises where the process can lead to anarchy if not well structured.

So what’s best? My own view is that Category I Tenets should generally be chosen via the Benevolent Dictator form, if only because of the wide span and strategic importance they represent. Also, Category I Tenets should closely adhere to the strategic objectives already defined for the project. You can’t expect the entire technology base to have all the information needed to make well-informed decisions (maybe you are privy to information regarding a secret acquisition of a company that uses a certain technology, but which can’t be shared). In any case, I advise against the Moses approach so as not to shut down the chance to learn valuable insights from the team.

I suggest that for Category II Tenets you try the Democratic Caucus approach, with the proviso that if no decision is forthcoming after a healthy degree of debate that you retain your Benevolent Dictator prerogative. This should ensure a decent amount of compromise as your team surely will not want you to make the final decision!

If at all possible, to the extent that Category I or II tenets leave room for flexibility (as they should), it is worthwhile to allow the base team to recommend specific departmental Category III tenets. Obviously, you will need to oversee that the Category III decisions do not deviate from higher level tenets.

A final point, during this phase it would also be wise to establish the process and principles under which tenets will be enforced and revised. Your entire team should be well aware that the establishment of tenets and standards is a serious matter and that its ultimate outcome will be the reduction of stresses resulting from byzantine arguments and the focus gained by the shared understanding of the environment.

So, what are these Category I, II, and III Tenets I have been talking about? Next I will be covering some examples.

Labels: Architecture, Methodology, Principles, Process, SOA, Standards, Tenets

posted by IT Transformation with SOA @ 2:48 PM

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.

Labels: Architecture, IT, Levels, Methodology, Model, Scope, Services, SOA, Strategy, Technology

posted by IT Transformation with SOA @ 4:05 PM