Most Software systems are developed by corporations to gain parity with, or advantage over, competitors. These systems are either intended for sale as products or to be used internally but in both cases they are supposed to produce positive business results for the corporation that uses them. As anyone who has ever been involved in the development of software systems will know they often fail to produce a return on investment and sometimes fail to produce any benefit at all. This failure to achieve business value stems partly from difficultly system designers have in tracking the changing relationships between Policy, Strategy, and the Architecture they are responsible for designing.

System Architecture, and the Standards and Procedures that system designers are responsible for defining are the technical equivalent to Business Strategy, and Business Processes respectively. While they are equivalent they are not equal. Policy has precedence over Strategy and Strategy has precedence over Architecture, finally, Standards, Processes, and Procedures should follow.

The following sections attempt to define these concepts and show the relationships between them. Much of this essay, such as the ranking of Policy, Strategy, and Tactics is based on Basil Liddell Hart’s theories of military Strategy explained in his book Strategy. The purpose of these definitions is not to shed any new light on business strategy; the definitions of corporate and business strategy presented here are admittedly simplistic. Instead the purpose is to provide a framework for a discussion of the relationship between enterprise architecture, system architecture and corporate and business strategy and show how successful architecture must be derived from and driven by strategy.

Corporate Policy

Policy is defined by the Shorter Oxford English Dictionary as:

A course of action or principle adopted or proposed by a government, party, individual etc; any course of action adopted as advantageous or expedient.

Corporate Policy can be thought of as a promise to take a specific course of action or follow specific principles and thereby deliver defined business results. The executives of a company make promises of this sort to their investors over the short (3-6 months), medium (6-12 months), and long (12-18 months) term. Executives are usually held accountable by their investors for delivery of the short-term results that they claimed their policy would produce. Investors also want to see reasonable progress toward longer-term results. The results specified by a Corporate Policy are usually defined in terms of metrics that matter to investors, increased profitability, revenue, or sales etc. But investors care about more than just delivery of results. They care about the executive’s ability to deliver those results in the predicted way. Executives who cannot execute their stated Corporate Policy but somehow mange to deliver the results anyway are unpredictable and therefore a risky investment.

To summarize, a Corporate Policy commits a business to achieving tangible results in a specific timeframe by taking a specific approach.

To be convincing to investors the executives must not only publicly define their Corporate Policy they must also reveal some part of the Corporate Strategy that supports the policy. They must do this without giving away competitive advantage. Walking the line between convincing investors that the chosen policy is supported by a solid strategy while preserving competitive advantage and retaining as much room for maneuver as possible is the executive’s unenviable job.

Strategy

Strategy is defined by the Oxford English Dictionary as

The art or skill of careful planning towards an advantage or desired end; an instance of this, a stratagem.

In order to execute Corporate Policy and deliver the results executives have promised to investors companies must develop a Strategy. Strategy can be divided into two levels, Corporate Strategy, that encompasses the entire business, all its departments, lines of business and operations, and Business Strategy that deals with individual departments, initiatives, or lines of business. The names of these two levels are somewhat arbitrary, the important point is that there are two levels; one that encompasses the entire business or enterprise, and one that deals with individual initiatives and departments.

Corporate Strategy

Corporate Strategy can be thought of as Business Policy. This is a direct Parallel to Basil Liddell Harts claim that Grand Strategy can be thought of as Military Policy. The difference between Corporate Policy and Corporate Strategy would not matter too much if they were communicated to the same audience. However, while Corporate Policy is communicated externally and is primarily targeted at investors. Corporate Strategy is guarded to protect competitive advantage and is primarily intended for an internal audience. Corporate Strategy determines the way in which business will be conducted and the relative importance of all the stakeholders expectations; investors, customers and employees. At the same time Corporate Strategy must strike a balance between the goals of different business units within the corporation. Profit centers must be balanced against cost centers and the goals of individual departments must be aligned with stated Corporate Policy. Multiple initiatives must be evaluated and some chosen for immediate execution while others may need to be delayed. Investors care about Corporate Strategy. In particular they want it to clearly support Corporate Policy and be executed as planned. However they also understand that for competitive reasons it cannot be revealed to them completely.

Enterprise Architecture

Enterprise Architecture is a specialized form of corporate strategy. As has already been said, in today’s business world many organizations seek to gain competitive advantage by developing custom information technology solutions or installing and integrating packages. These solutions are built to achieve specific business results. When many such solutions exist within a single organization conflicts and incompatibilities inevitable occur and complexity increases which leads to increased maintenance costs. While good Enterprise Architecture can provide benefits such as clarity and reduced integration costs it is essential for the architect to accept that enterprise architecture is necessarily subservient to corporate strategy. The consequences of this can be frustrating. For example; if corporate strategy mandates rapid growth, there may never be a good time to replace that archaic database or the completely outdated middleware. Much of the frustration felt by architects stems from the fact that they must consider the longer term, 2 to 5 years, while corporate policy and strategy rarely consider anything beyond 18 months.

Enterprise Architecture can be thought of as technology policy. An Enterprise Architect must define the standard approaches, tools and procedures for the integration of multiple systems and various technologies across the organization. The factors that drive enterprise architecture decisions often have less to do with the relative merits of the available technology options and more to do with resource constraints and risk mitigation. For example DB2 may cost less to own and be slightly more efficient in operation than Oracle but the large number of developers in the job market with skills in Oracle may swing the decision in Oracle’s favor. These decisions can sometimes seem completely arbitrary to the technologists that have to live with them. I was recently asked which platform, J2EE or .net, supported the highest developer productivity. I explained that it was not uncommon to find a 25-fold difference in productivity between a “good” programmer and a “bad” programmer. The difference between a J2EE and .net platform is nowhere near that. So the real concern should be ensuring that the hiring process retains “good” programmers. The next consideration should be selecting a development platform that would be around for a reasonable length of time and provide an easy upgrade path when, and if, it comes time to move on. Finally the relative productivity levels supported by the two platforms could be considered but by this point it really doesn’t matter that much. They both work fairly well!

The main driving factor in many enterprise architecture decisions is the risk that a selected technology or approach may become obsolete. Enterprise architectures are, by their nature, intended to endure for a considerable length of time, 2 to 5 years, is common. This is easily long enough for technologies, companies, design patterns and methodologies, to become obsolete. As a result enterprise architectures tend to be conservative. Betting the entire enterprise on a technology or approach that becomes obsolete after 1 year does nothing to enhance the Architects future employment prospects. It is here that the goal of the Architect and the software infrastructure and package vendors differ the most. The vendor wants to lock-in the client forever. The architect wants to select a package or technology that does the required job and can be most easily retired if it becomes obsolete. Alternatively they may buy into the fallacy that they can avoid having to replace anything altogether by going with a large well respected, stable company. Millions of dollars are spent each year on marketing by major infrastructure vendors to obscure 2 basic facts; no company in this industry can guarantee it’s stability over 18 months let alone 5 years, and their products are designed to lock-in customers not to reduce the cost and difficulty of switching.

Business Strategy

Business strategy is focused on the execution of specific initiatives and projects. The purpose of any strategy is not to overcome problems but to avoid them. The perfect strategy brings about the desired result with the minimum expended effort. A sound business strategy addresses both the means by which the objective will be achieved and the resources that will execute the plan and achieve the goal.

The psychological aspect of strategy must not be underestimated. Corporate and Business Strategies are executed by people, if these people believe in the strategies they are executing then they are more likely to succeed. Strategy is not a matter of mathematics it is more than geometry likewise enterprise and system architectures are much more than mere engineering artifacts. They are also manifestos, statements of principle, and often, common belief. There is nothing worse for moral than a hollow strategy that no one believes in! And nothing more inspiring than a well articulated strategy that aligns peoples desires.

System Architecture

I have described elsewhere the attributes of a good system architecture. Here I want to discuss the relationship between System Architecture and the Business Strategy it supports. Unlike Enterprise Architecture, System Architecture is highly focused. A System Architecture is the blue print for a system that will achieve specific business objectives that will in-tern contribute to achieving a defined business goal. System Architecture is therefore subservient to Business Strategy, since strategy defines the goal. However System Architecture is the most significant factor in the medium to long-term success of any system. The appearance of short-term success can be achieved with weak architecture but the costs are high and the solution temporary at best. Implementing a working system may allow the designers to declare victory and move on but this does not mean the goal has been achieved or that it ever will be.

The following quotes (from chapter 20 – The concentrated essence of Strategy and Tactics, from Basil Liddell Hart’s book Strategy) cover the cross-over between Business Strategy and System Architecture.

• Adjusts your end to your means. In determining your object [goal], clear sight and cool calculation should prevail. It is folly “to bite off more than you can chew”, and a beginning of [business/technology] wisdom is a sense of what is possible. So learn to face facts while still preserving faith: there will be ample need for faith- the faith that can achieve the apparently impossible- when the action begins. Confidence is like the current in a battery avoid exhausting it in a vain effort and remember that your own continued confidence will be of no avail if the cells of your battery, the [people] on which you depend, have been run down.
• Keep your object always in mind, while adapting the plan to circumstance. Realize that there are more ways than one of gaining the objective, but take heed that every objective should bear on the object. And in considering possible objectives weigh their possibility of attainment with their service to the object if attained to wander down a side-track is bad, but to reach a dead end is worse.
• Take a line of operation which offers alternative objectives. Liddell Hart sees this as a way to place your opponent on the horns of a dilemma. In the absence of an opponent it is a good risk mitigation tactic. If one option will not work the other is still open.
• Exploit the line of least resistance - so long as it can lead you to any objective which would contribute to your underlying object.
• Ensure that both plan and resources are flexible and adaptable to change. Your plan should foresee and provide for a next step in case of success or failure, or partial success which is the most common case. Your disposition should be such as to allow this exploitation or adaptation in the shortest possible time

Tactics are extremely important but are outside the scope of this essay. Briefly, the purpose of an Strategy is to minimize expended effort while the purpose of Tactics – Business processes, procedures and standards is to define the most efficient or appropriate method for expending effort when the need arises.

Schematic diagram showing the relationship between Policy, Strategy, and Architecture

Understanding how a System Architecture supports it’s Business Strategy within the framework of an Enterprise Architecture and how these in turn support Corporate Strategy and ultimately Corporate Policy is essential if systems are to deliver business value. This is not easy and is one reason why so many systems fail to deliver business value. The difficulty stems form the ever-changing business environment that forces continuous changes in goals and objectives. Making the goals and objectives explicit and then tracking them as they change is the only way to keep up with the game. But that is the topic for another time.

Just because you can make a decision or solve a problem does not mean you should. There are times when it’s better to delay until the last possible moment, others when its best to go half way and stop, and of course times when action must be taken immediately. Recognizing the best way to handle any given situation is fundamental when handling large numbers of problems. Recently I’ve been working with a client on defining a change management process for a large system and have been thinking about these issues.

Not all problems are equal some are more urgent that others. In large systems problems can spawn other problems and often have complex relationships with each other. It is usually possible to draw a hierarchy of problems, more fundamental problems rise to the top, and less severe symptomatic problems fall to the bottom. Choosing whether to resolve a problem or ignore it depends on its relative urgency and degree of subservience within the problem hierarchy. These issues have little to do with the problem itself, they are outside the scope of the problem and are more correctly thought of as the meta-problem or problem context. Understanding the context of a problem is vitally important. The same problem in different contexts may have radically different solutions.

This process flow diagram shows a generic problem resolution process. For this discussion the important features are the parallelization of problem definition and problem context definition and the separation of candidate solution evaluation and candidate solution selection.

Parallelization of Problem Context Definition and Problem Definition

By understanding the context of a problem it is possible to make decisions about its resolution without actually understanding much about the problem itself. The two primary pieces of information needed to understand a problems context are its relative urgency and the degree to which it is subservient to other problems. An isolated problem that is unrelated to any other problem can only be resolved by a direct attack. Whereas a problem that is merely a symptom of some deeper, more fundamental problem can be resolved either by a direct attack or by resolving the more fundamental problem.

Keeping your Options Open

Retaining the option to solve a problem using any candidate solution for as long as possible has significant advantages. Most importantly the ability to learn from mistakes and hard won experience is preserved. If the opportunity arises solutions to more fundamental problems can be implemented instead, thus reducing total costs and wasted effort while increasing quality. And resources can be committed to more urgent problems if the relative urgency changes or new urgent problems arise.

Although tempting, there is often no pressing need to select a candidate solution. In the absence of such a pressing need it is better to wait. Large systems are typically dynamic, new problems occur all the time and existing problems morph as more is learned about them. In such an environment retaining the ability to change your mind for as long as possible is highly desirable since a better overall solution may be discovered. If however a candidate solution has been selected then decisions can and should be made on the assumption that the selected candidate solution will be implemented. It is my experience that too many system designers select candidate solutions when there is no pressing need. This boxes the designer in, reducing thier options and forces them along paths that may reduce overall quality unnecessarily.

This table recommends an approach for solution definition and development based on an evaluation of a problems context in two dimensions; relative urgency, and degree of likely subservience to other problems.

	Low Urgency	Medium Urgency	High Urgency
High Subservience	Ignore the problem. It will go away when the more fundamental problem, to which this problem is subservient, is resolved.	Solve the more fundamental problem to which this problem is subservient.	Implement the easiest candidate solution available. Expect this temporary solution to be replaced when the more fundamental problem is resolved.
Medium Subservience	Solve the more fundamental problem to which this problem is subservient.	Evaluate candidate solutions then wait until the last moment before selecting one. Keep looking to solve a more fundamental problem while waiting.	Select a candidate solution but do not develop it until the last moment. Keep looking to solve a more fundamental problem while waiting.
Low Subservience	Select a solution but do not develop it until there is nothing more urgent to do or its urgency increases.	Select a candidate solution but do not develop it until the last moment. Retain the option to do something more important for as long as possible	Implement the cleanest candidate solution you can in the time available

Recently, I have been traveling to Washington D.C. via Washington Dulles International Airport and have begun to appreciate the fine architecture of the airport. Built between 1958 and 1966 by the engineering firm of Amman and Whitney the terminal building, control tower, and service buildings were designed by Architect Eero Saarinen who claimed it was “the best thing I have ever done.”

This was the first US airport designed for jets and so there was no precedent for Saarinen to follow. One of the most distinctive features of the airport was the lack of any building extensions onto the airfield for aircraft loading. Instead passengers traveled from the terminal to their planes, which could be waiting over a mile away, on strange vehicles called Mobile Lounges and Plane-Mates. Saarinen viewed these mobile lounges as an extension of the airport. They were mobile buildings that served as transportation. Apparently when the lounges were first introduced they had a bar onboard and it was possible to drink cocktails while being transported to your plane!

A Mobile Lounge

Mobile lounges were constructed by the Chrysler Corporation in association with the Budd Company. They are 54-foot long, 16-foot wide, 17 1/2-foot high, and were originally specified to carry 102 passengers, 71 of them seated, directly from the terminal to the aircraft on the ramp. This was intended to protect the passengers from weather, jet noise and blast, and also eliminate long walking distances. Passengers had to walk only 200 feet once they entered the terminal until they were seated in the lounge for the short trip directly to their aircraft.

A Plane-Mate

These vehicles are still in operation at the airport today. The Mobile Lounge / Plane-Mate system seems to work very well. It has allowed the airport to grow at phenomenal rates – just over 25% in 1999. I am curious why the system never caught on. It obviously works, but miles of terminal buildings with endless moving walkways leading to telescopic boarding ramps have become the norm – Why? The only thing I can think of is that the operation costs of a Mobile Lounge system are high and the benefits, like support for airport expansion, are long-term. As a result they may fair badly when compared with the moving walkway systems that I imagine are cheaper to operate if inflexible.

In 1999 the Airports Authority Board of Directors approved the concept for an underground rail system on the airport that will eventually replace the current Mobile Lounges. So, sadly the Mobile Lounges are on their way out. However if you want to see what the future looked like in the late 1950′s theres still time. And, if you’re really inspired, the Airport Authority is currently advertising for Mobile Lounge and Plane-mate operators, pay is between $14.95 and $19.41 an hour and the job description is bizarre to say the least!

In mating with aircraft, employs appropriate operating procedure in keeping with the characteristics of the aircraft (e.g., location of projecting fins and sensors), preferred policy of the particular airline and the structure of the lounge.

For some problems the challenge is not to identify the solution. The real challenge is working out how to put the solution in place. Anyone who has setup a theodolite will understand what I mean. The solution is simple to describe. Position a precision optical measuring device so that it is; perfectly level, at a reasonable height for operation and directly above a predefined mark. Sounds easy, but given a tripod and a theodolite most untrained surveyors will take hours and usually give up in frustration. The problem is that there are too many degrees of freedom in the system. Everything is interdependent. Make one small adjustment here and it knocks things way out of whack there!

The secret is to follow a procedure that is based on a strategy. There are many variations on the procedure, but they all rely on the same strategy. Establish an initial, sub-optimal, solution that is configured to allow for as much adjustment as possible. Adjust this preliminary configuration gradually refining the setup until it finally meets the requirements.

The following are the most succinct instructions I could find after brief search.

Setting Up the Tripod

(doing this correctly will save a lot of time and frustration in subsequent adjustments!!)

Extend the tripod legs to a proper length (around shoulder height), and set the tripod approximately over the marked survey point. The tripod head should be levelled (use horizontal objects as references), and each leg should make approximately a 70 angle with the ground. Feel free to lift the tripod and redo the above if necessary. Avoid having a tripod leg coming at you; that might cause some inconvenience.

Carefully take the theodolite out of the carrying case, and remember how it was fitted in the box so that you know how to put it back later. Mount it on the tripod, and fasten the tripod screw. Make sure the tribrach base and the tripod head (both triangular) are parallel and share the same centroid to permit maximum translation in any direction, which will be needed later on. Remove the lens cap, put it back into the carrying case, and close the box.

Setting Up the Theodolite

1 Rough Centering

Secure the front tripod leg. Hold and move the two other legs to roughly center the theodolite by locating the ground mark via the optical plummet. Use your right foot placed near the mark as a guide; see Fig. 1. Secure the tripod legs when done.

2 Rough Levelling (use the circular bubble as the guide)

By adjusting the length of one tripod leg at a time while keeping the other two still, the circular bubble can be levelled without causing disturbance to the previously accomplished centering (check the optical plummet to see this is true).

3 Precise Levelling (use the plate bubble as the guide)

Rotate the theodolite until its plate bubble is parallel to any two footscrews (A and B), then adjust A and B to center the bubble. The left thumb rule applies as usual (bubble will travel in direction of left thumb). Now rotate the theodolite body by 90, and center the bubble with the third footscrew (C) only. Repeat this procedure for each 90 revolution of the instrument until the bubble is centered for all four positions. Now check the optical plummet: adjustment of the footscrews has probably disturbed the centering.

4 Precise Centering

Loosen the tripod screw, and slowly translate (do not rotate) the theodolite around until it is exactly centered over the survey point, then tighten the screw.

5 Repeat 3 and 4 until levelling and centering are both accomplished precisely.

Some generalized lessons can be drawn from this procedure. When faced with a complex problem that has an obvious solution always consider how the solution will be put in place. If the solution comprises many interdependent sub-components use a convergent, iterative optimization process. Put the part of the system with the largest scope for adjustment in place first and set all configuration parameters to the middle of their range before starting to make adjustments. Monitor the size of successive adjustments; they should get smaller as the procedure progresses. If they start to get larger at any point this is a danger sign. Don’t worry if early configuration is very imprecise

use your right foot as a mark

Make accommodations early in the process for flexibility that may be needed later.

Make sure the tribrach base and the tripod head (both triangular) are parallel and share the same centroid to permit maximum translation in any direction, which will be needed later on

Avoid having a tripod leg coming at you; that might cause some inconvenience [when using the theodolite].

Understand that the best procedure may be non-trivial and not obvious to the novice. Ask someone who has done it before how they did it and what they would do different next time. If you come across one of these situations beware, some things really are easier said than done.

5 Nines is a term used in the computer industry that refers to the 5 nines in 99.999%. This number is about the best odds manufacturers will give that one of their systems will be available at any given moment in time. Of course there are systems with higher availability but they tend to have very expensive multiple redundancy. 5 Nines is the best availability claimed for commercial system, and after all, 99.999% availability is pretty good. 5 Nines translates to a downtime of only 5 minutes a year.

While this makes for good marketing material it does not make very much sense even if it were possible. A typical user does not think in terms of availability. Instead they think in terms of system failure; how frequently it happens (reliability), and how long it takes them to recover afterwards (recoverability). All three factors must be taken into consideration when specifying desired system quality.

• Availability Probability of nominal operation
• Reliability Mean Time Between Failure (MTBF)
• Recoverability Mean Time To Recover (MTTR)

To illustrate the interaction of these three attributes consider a system with a high availability of 99.999%, a low reliability (MTBF of about 30 hours). The system fails every 30 hours but it is only unavailable for one second each time. There are about 300 failures in a year adding up to a total downtime of 5 minutes. As soon as the hardware returns from it’s one second absence the software starts an automatic recovery process. This is where the definition of MTTR becomes important. A hardware manufacturer will claim that the mean time to recover is less than a second. However while the hardware may be available the system it supports is going through a software recovery process. On a large database system this type of recovery could take up to 5 hours! From a user perspective the system is unavailable for normal use for 5 hours out of every 30 while it recovers. That is a mere 83.3% percieved availability.

This extreme case is not as unlikely as one might think. I once had to build an interface that linked two large systems connected to each other via a leased microwave telephone link. The phone company guaranteed a 1 hour downtime a year. 99.99% availability. What they neglected to tell us was that this downtime would be spread randomly throughout the year in fraction of a second increments. Eventually we worked out what was happening and tweaked our already fault tolerant system to accommodate the unexpectedly frequent failures. Fortunately our MTTR was negligible.

Availability, Reliability, and Recoverability are just three system quality attributes. There are many more. Picking just one to raise above all the others is nonsense, It is the way these attributes interact with each other that is really important.