Archive for SOA

Is 2009 the Year for SOA?

I read a lot about Service Oriented Architectures (SOA) and most of the articles start off the same way: “Most companies fail and here are 10 reasons why they fail”. Personally, I would rather focus on “How to succeed at SOA without really trying”, but the truth of the matter is that most companies do fail at SOA and they fail for the same reason, which is that they treat SOA as another technology implementation project and it’s not

So if SOA is not about technology, then what is it? Before answering that vital question, it is useful to first look at why companies even bother with SOA. If we set the stage with a business context, I think some of this makes more sense.

Many companies, either through acquisition or through the independent actions of independent divisions produce a complex technology landscape of independent silos. This accretion process often happens haphazardly driven by expansion.

The first pressure on the architecture is usually for integration. In other words, as independent business units drive their respective technology silos forward, they invariably see features and functions in another silo that they want. They have the choice of either duplicating the function in their silo, or integrating with the existing technology silo which already has the feature / function. Depending on the ease of integration, different decisions may be made.

This brings us to the next pressure on the architecture, which is to provide agility or time-to-market. This is simply the ease of the business to react quickly to a market demand and put a new feature out quickly. Obviously, Agility and Integration are somewhat correlated, because if the infrastructure supports easy integration, then an existing feature may be cross-fertilized from one product to another relatively quickly.

But to truly get agility, software needs to release quickly. No matter what development methodology you employ and how many outsourced resources you have access to, the only tried and true way of getting software to release quickly is to have less of it and to have fewer integration points.

This drives you down the road to the final driver on the architecture, which is to increase leverage or reduce duplication. By separating out the technology that is common to and duplicated amongst all those technology silos and build them once, you gain leverage. By increasing leverage you also reduce the amount of money you spend on duplicated functions, theoretically allowing you to spend more on business differentiating functions.

This brings us to the three main benefits of a Service Oriented Architecture (SOA)

  1. Increase Agility – Providing improved time to market (By far the most important)
  2. Increase Leverage – Providing reduced overall cost and complexity of the technology
    landscape
  3. Increase Integration – Providing consistency and uniformity of feature sets between products at reduced cost

There are two side benefits of a well implemented SOA that are also worth mentioning:

  1. Improved Quality –Because there is less technology with fewer touch-points.
  2. Facilitated Removal of Legacy – Most companies have a difficult time removing legacy infrastructure and this legacy technology can be like an anchor weighing down the ability to innovate. An SOA with well-defined coarse grained service interfaces has fewer touch-points allowing legacy to be more easily migrated at the appropriate time.

You will notice that at no time in this entire discussion did I ever mention the words “Web Service” or “Enterprise Service Bus” and that there is nothing up my sleeve and at no time did my hands ever leave the end of my wrists. I point this out simply to confirm that for a service oriented architecture to succeed, the entire process of translating business initiatives into technology actions and operation must be adapted. Thinking it’s just implementing a few bits of technology is why most companies fail.
This is because the SOA technology really only provides integration. Integration, while certainly important is completely overwhelmed by the other two business drivers, which are: gaining time-to-market through agility and reducing cost through leverage. Technology alone cannot achieve these goals.

What is a Service Oriented Architecture?
Now that we have some business context for why companies need service oriented architecture, let’s be clear about what one is. Additional detail may be found in:
http://pro.iankoenig.com/docs/SOA-10GoldenRules.pdfTo quickly review, the technology landscape, particularly for large companies tends to evolve from technology silos. In these silos, there are generally large amounts of duplicated, overlapping and inconsistent technology choices and complex, arcane business processes that make products difficult to integrate, slow to migrate and costly to maintain.

Silo

As the above diagram attempts to show (grey areas representing interfaces and colored rectangles representing functional business logic), by moving to a Service Oriented architecture, removing duplication and integrating the shared services, we can gain agility, leverage and integration. Sounds great, doesn’t it?

A Service Oriented Architecture (SOA) is: a collection of shared services that communicate with each other and with consuming applications to minimize duplication of business logic across autonomous units.

A Service is: a coarse grained, self-contained, autonomous, single-instance, operational set of software modules that perform a well defined set of functions through well defined interfaces.
Services are independent of the applications using them, but inclusive of the computing platforms and all other resources necessary in order to operate. Services are re-used by being called through their exposed interfaces. They are scaled up/out to handle load (i.e. not through the creation of a new instance).

Once again, you may notice that the definitions of SOA and Service never mentioned the words “Web Service” or “Enterprise Service Bus (ESB)”. In fact, you can easily have an SOA with neither web services nor an ESB, just as you can have both an ESB and web services and not have an SOA.

So if a Service Oriented Architecture is not about technology, what is it about?
Well it is about technology, it’s just not only about technology. In fact the technology is the easy part. The hard part is: “making the next right decision”.

When you have an SOA, you have Services, but more to the point, you have “shared” services. While it is nice to share, in a big company it is also hard to share and this tends to be where you either succeed or fail.

Let me explain: When two applications require independent feature enhancements on the same shared service and they both need it urgently and immediately (when has that ever happened?), you have a decision to make. One business unit is generally going to get what they want (maybe) and the other is generally going to wait.

A company either succeeds or fails in its SOA strategy in making the correct decisions as to which products drive the architecture, which wait and which go ahead in a tactical manner.
I use a few rules of thumb when I am involved in these decisions.

  1. It is 2.5 times as costly to make something reusable as not (mostly due to support costs) so don’t do it unless it’s worth it.
  2. It is 7 times as costly to do something tactically as to wait, if you have to then undo it, redo it and clean up the mess. So while there are always tactical and strategic activities going on choose the right ones. Don’t just act because you are bored.

Another interesting issue that companies run into is the misallocation of resources. It goes something like this. Product development group asks service development group for a new feature. Service group is overloaded and cannot get to it right away. Product group says “My business unit is breathing down my neck, so I am being forced to do the wrong thing and act tactically”. Service Development Group says “Tell your business group to wait”. Meetings happen, revenue would be lost; the decision is made to act tactically. The technology sprawl gets worse.

My solution: If the product development group has the resource to do the work, then clearly the resource exists in the company to do the work. So they should “lend” the resource to the Service Development group for the duration of the project so that it is done correctly. The service groups own the responsibility for covering the extra cost of reusability and all is satisfied. All except for the tendency to say “Mine!”

Okay, maybe I am a bit naïve. Or maybe not.

Comments