Planning a Service-Oriented Architecture

belisarius ^ | February 3, 2004 | Roger Sessions

[stainlessbanner]

In my last article I gave an introduction to service-oriented architectures (SOAs) [1]. In this issue, I'm going to discuss a little about how to approach the process of planning for an SOA implementation, primarily from a management perspective.

The starting point for implementing an SOA is with the systems you have today. After all, SOAs are not about replacing systems, they are about getting those systems to interoperate. They are also about getting your systems to collaborate with those of your commerce partners, but that is a secondary and longer term goal. Initially, we are primarily focusing on interoperating.

So where are your systems today? You probably have nothing approaching an SOA. In fact, if you are the typical IT organization, you probably have something that looks a lot like a very big pile of IT spaghetti.

If you are the typical enterprise CTO, you are responsible for managing a herd of unruly and ungainly business applications, each developed without any regard whatsoever to the needs its fellow applications, each using its own version of data storage, each built on its own long-forgotten standard, each with its own hardware and software requirements, and each with its own lineage, some so ancient that nobody knows exactly where they came from or, in some cases, even why you are running them.

If you are the typical CTO, the chances are that you can't even name all of your mission critical applications, never mind figure out how to make them interoperate. They say herding cats is difficult? You know better. You would trade your job for that of cat herder any day!

So how do you migrate from a spaghetti-oriented architecture to a service-oriented architecture? The answer to this question comes from a surprising source. It doesn't come from IT theorists, or from business schools, or from some expensive consulting organization. The answer to this question comes from one of the most unlikely sources I can think of: an unassuming retired Air Force Colonel who was trying to understand not how to build SOAs, but how to win dogfights.

A dogfight is a one-on-one battle between two planes, each trying to shoot the other down before it is itself shot down. You can see why an Air Force Colonel might be interested in winning them.

But what does this have to do with building SOAs? Before I relate dogfighting to building SOAs, let's see what this Colonel discovered.

Colonel John Boyd [2] was interested not just in any dogfights, but specifically in dogfights between MiG-15s and F-86s. As an ex-pilot and accomplished aircraft designer, Boyd knew both planes very well. He knew the MiG-15 was a better aircraft than the F-86. The MiG-15 could climb faster than the F-86. The MiG-15 could turn faster than the F-86. The MiG-15 had better distance visibility.

The F-86 had two points in its favor. First, it had better side visibility. While the MiG-15 pilot could see further in front, the F-86 pilot could see slightly more on the sides. Second, the F-86 had a hydraulic flight control. The MiG-15 had a manual flight control.

The standing assumption on the part of airline designers was that maneuverability was the key component of winning dogfights. Clearly, the MiG-15, with its faster turning and climbing ability, could outmaneuver the F-86.

There was just one problem with all this. Even though the MiG-15 was considered a superior aircraft by aircraft designers, the F-86 was favored by pilots. The reason it was favored was simple: in one-on-one dogfights with MiG-15s, the F-86 won nine times out of ten.

This problem fascinated Boyd. Why would an aircraft that had inferior maneuverability consistently win in dogfights?

In order to solve this anomaly, Boyd needed to understand how pilots actually operate in a dogfight. Boyd had an advantage here. He was not only a pilot, but one of the best dogfighters in history. He therefore had some first-hand knowledge of this subject.

Let's consider a pilot involved in a dogfight, say Pete. Boyd proposed that Pete's dogfight consists of four stages. In the first stage, Pete is observing the state of the world around him, including the enemy plane. In the second stage, Pete orients himself with respect to that state. In the third stage, Pete decides on an appropriate action. In the fourth stage, Pete acts.

So Pete first observes, then orients, then decides, then acts. Boyd called this sequence OODA (observe, orient, decide, act).

But, and here is a critical fact, Pete doesn't just do this once. He does this over and over again. In fact, Pete is constantly looping through this sequence of OODA. And, of course, so is his opponent. So who will win? Pete? Or the anti-Pete? If Pete is flying the F-86, we know he will probably win. But why?

It would seem that the anti-Pete flying the MiG-15 would be better at OODAing than Pete. The anti-Pete can see further, so he can presumably observe better. He can also turn and climb faster, so he can presumably act faster. Yet Pete wins.

Could it be that Pete wins because he can see more on the sides? Not according to Boyd, who believed that the side vision difference was insignificant. Myself, never having been in either a MiG-15 or an F-86, I will have to trust him on this.

Boyd decided that the primary determinant to winning dogfights was not observing, orienting, deciding, or acting better. The primary determinant to winning dogfights was how quickly one could execute the overall OODA loop.

This is a bit easier to see if we lay out a hypothetical dogfight. Let's say that it takes either Pete or anti-Pete 500 milliseconds to go through each stage of the OODA loop. Let's further say that it takes the anti-Pete an additional 500 milliseconds to go from one stage to the other while Pete can transition from stage to stage in 300 milliseconds. Let's further assume that each stage is executed with equal effectiveness by both Pete and anti-Pete. Here is how the dogfight traverses, millisecond by millisecond.

0 milliseconds: Pete and anti-Pete start observing the state of the world. Let's call this state W1.

500 milliseconds: Pete and anti-Pete have completed their observation. Both start transitioning to stage 2: Orientation.

800 milliseconds: Pete has completed the transition to stage 2 and starts actually orienting himself to W1.

1000 milliseconds: anti-Pete has completed the transition to stage 2 and starts orienting himself to W1.

1300 milliseconds: Pete has completed the orientation of himself to W1 and starts the transition to stage 3: Deciding.

1500 milliseconds: anti-Pete has completed the orientation to W1 and starts the transition to stage 3: Deciding.

1600 milliseconds: Pete has completed the transition and starts deciding what to do about W1.

2000 milliseconds: anti-Pete has completed the transition and starts deciding what to do about W1.

2100 milliseconds: Pete finishes deciding and starts the transition to stage 4: Acting.

2400 milliseconds: Pete finishes the transition and starts acting.

2500 milliseconds: anti-Pete finishes deciding and starts the transition to stage 4: acting.

2900 milliseconds: Pete finishes acting.

3000 milliseconds: anti-Pete finishes the transition and starts acting.

Notice that at 2900 milliseconds, Pete has completed stage 4 (acting). But when Pete finishes acting, the state of the world is no longer W1, but some new state, say W2, the delta between W1 and the effect of Pete's actions.

Unfortunately for anti-Pete, he is just starting his acting at 3000 milliseconds, 100 milliseconds after Pete has ended his acting. So anti-Pete is acting based on a world that looks like W1, whereas in fact Pete has just changed the world to W2. And, even worse, Pete has already started his next OODA loop and now has a head start over anti-Pete.

With each iteration of the loop, anti-Pete falls further and further behind Pete. He can never catch up. As long as each pilot iterates equally accurately, the one who iterates the fastest will be the one who wins the dogfight.

The next question Boyd asked is: why would the F-86 iterate faster? The reason, he concluded, was not the visibility differential. It was something that nobody had thought was particularly important. It was the hydraulic flight stick.

Without hydraulics, it took more physical energy to move the MiG-15 flight stick than it did the F-85 flight stick. Even though the MiG-15 would turn faster (or climb higher) once the stick was moved, the amount of energy it took to move the stick was greater for the MiG-15 pilot.

With each iteration, the MiG-15 pilot got a little more tired than the F-86 pilot. And as he got more tired, it took a little longer to complete his OODA loop. The MiG-15 pilot didn't lose because he got outfought. He lost because he got out-OODAed.

You are probably already getting the feeling that building an SOA is something like dogfighting. It is certainly competitive. We don't build SOAs for the fun of it; we build them to increase our organization's competitiveness. If the SOA doesn't increase our competitiveness, then we shouldn't be doing it.

Many consulting organizations help a company build an SOA by bringing in a large number of consultants who catalog every possible software system and then start building a mammoth SOA that will link them all together. This is a great approach for the consulting organizations. It is a very lucrative.

The irony is that not only is this approach extremely expensive, it is unlikely to succeed. It is the equivalent to trying to win a dogfight by building a plane that has perfect visibility.

Boyd teaches us that we win by iterating faster than our enemy, not by building a more expensive plane than our enemy. We will do better by implementing and deploying a small piece of the SOA, getting it right, showing its value, learning from the result, and then iterating on to the next piece.

I recently saw an example of Boyd's OODA loops in action in an SOA scenario. I was sitting in on an architectural presentation by a major manufacturing company (not one that I had mentored!). I'll call this company X, so as not to embarrass anybody.

The head architect of X was proudly showing how they were going to build their SOA. They had exhaustively analyzed their enterprise systems. They had exhaustively designed an SOA that would allow their myriad systems to interoperate. They had exhaustively built connections for many of their systems. Believe me, they exhausted me just explaining what they had done.

There was just one problem. They had made a fatal flaw in their basic architecture. They had forgotten to account for error conditions. When I asked about this, they mumbled something about "'dealing with this later after they get the basic architecture to work"'. Unfortunately, error handling is not something you "'add later"'. It is a basic part of the SOA.

Had X used an iterative approach to implementing their SOA architecture, they would have discovered their flaw early on when it could have been corrected relatively inexpensively. Now they had invested large amounts of money into a fundamentally flawed architecture. Fixing the problem at this point was going to be disruptive, expensive, and demoralizing. A likely result of the undertaking will be a management decision that SOAs are more trouble than they are worth.

The critical problem with X was not the lack of error handling. It was a lack of iteration. As Boyd proved, it is the constant iteration that gives us the ability to learn quickly and either build on our successes or contain our failures. Without iteration, there is no opportunity to learn, or at least, no opportunity to learn until it is too late.

My philosophy when doing an SOA architectural mentoring engagement is to encourage organizations to start with small projects that have high business value and that can be completed quickly. Then learn from the results and iterate to the next project.

With each iteration, the organization gains executive confidence in the SOA approach and technical proficiency. When problems occur (which they will), they can be fixed quickly and inexpensively. As knowledge is gained, each iteration becomes easier.

In other words, when you need to disentangle the IT spaghetti, do it a few strands at a time. Do it well. And then unravel the next few strands.

I'll discuss more details about what it takes to unravel a "'few strands of spaghetti"' in future articles. Suffice it to say that many of the stages of the iteration are non-technical.

But I will leave you with a hint. If you see somebody over your right wing, don't spend a lot of time figuring out if he is wearing a red scarf or a purple scarf. Don't ask his astrological sign. And don't bring in twenty highly paid consultants to analyze the best way to compensate for wind resistance. Just Dive!

This article is the result of some ongoing discussion between three people: myself, Stephen Fulcher, and John Cavnar-Johnson, so even though I (Roger Sessions) wrote this article, I'm going to sign it on behalf of all of us.

*

Roger Sessions, ObjectWatch
*

Stephen Fulcher, DeveloperLabs
*

John Cavnar-Johnson, DeveloperLabs

[1] What is a Service-Oriented Architecture? by Roger Sessions in The ObjectWatch Newsletter #45 available at www.objectwatch.com

[2] For an good introduction to John Boyd's work, see Genghis John in Proceedings of the U. S. Naval Institute July 1997, pp. 42-47 By Franklin C. Spinney available at www.d-n-i.net/fcs/comments/c199.htm