Monday, July 13, 2009

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.

[1] Tenets are also referred to as “Principles” by many. I prefer to reserve the term “Principles” for the meta-category of tenets about tenets.