What is SOA or Service-Oriented Architecture?

(We still get this favorite question quite a lot, so our founder John Michelsen took some time to give his version of the basic "What is SOA?" answer for anyone who is wondering...)

We have been talking about this so long that it’s hard to imagine that many folks are probably still walking up to a blog like this and saying: ”What is this SOA to begin with?”

We can’t talk about SOA governance and test strategy before understanding what SOA actually is.

So this blog takes a step back and lets us make sure that we get a good solid understanding of what SOA actually means.

In order to do that, we are going to have a quick history lesson:

Most applications that we deal with or have dealt with in the past years were “BIG BOX” applications, i.e. very large monolithic applications that were integrated to and proprietary in custom ways as “one offs” every time.

For example, your order management and tracking system would have been either a custom-built application, or a package that you brought in -- it was built on it’s own set of technologies and had it’s own way of integrating to the rest of the network and you had to build on a “per integration” basis all of the different ways that you needed to integrate that solution with the rest of the business’s assets.

SOA is an attempt to solve some problems that this particular way of doing things created. Among the issues that were created is a very rigid infrastructure; they are very big applications that are not likely to change on a rapid basis. It sometimes creates long cycle times to make even minor changes. In fact, this is the single biggest reason we see businesses writing big checks to IT for SOA. They need more rapid change--either from competitive pressure, regulatory burden, new markets, etc.

Also, these “Big Box” applications, because of the proprietary and rigid ways you integrate, create very expensive integrations that make it harder to connect the business processes together and automate more. Instead you end up with silos of functionality and people in between those silos who trade the data back and forth -- very inefficient.

There are lots of ways we’ve tried to solve these problems in the past, SOA is the most recent and possibly the one that has the best shot at actually succeeding. We’ve seen some good success so far; we’re encouraged that it will continue. Okay, so it might continue but what is it that we’re talking about to begin with?

The answer is essentially the breaking apart of these BIG BOX applications into their component parts -- we call those Services. Instead of there being one large application that does all of the activities around a particular function (say order management and processing), instead there are individual services that are exposed as first-class citizens on the network: for inventory check, order status, order placement, canceling, all of the different things that you might do in an order management and placement application you’ll do as individual and discreet services. In so doing, you’re decoupling the monolithic rigidity problems that you had, and creating something more flexible and easy to maintain over time, which more rapidly can be changed on a smaller scale instead of a Big Bang application delivery.

One of the best side effects of this (in addition to the ability to evolve individual pieces faster than as one big whole) is the alignment of IT’s application resources to the business’s workplace. The reason for this is: Instead of having to tell the business how it’s going to be when they describe how they want to do business, you are able to make the services flow the way the business wants to transact.

That is a key fundamental way to take the wall out between these big applications (with having to have people in the middle) and instead more fully automate the business process. Once we have this in place and we’re succeeding on our vision, we can start to increase the level of automated coverage of the businesses processes and even give the power of programming to some extent to the business, because they can actually collaborate these services themselves instead of this having to be a custom application development project every time.

One more point, if we properly expose self-governing services and we expose those through a Business Process Modeling tool; we get closer to the business actually building the application. The IT side builds the services as the foundation to what the business needs to build.

So when you take the SOA path, you frequently are trying to get to a Business Process Modeling conclusion. That is, of course, one of the things that we do with our testing solution, in that we are doing everything we can to make it possible to test at the Business Process Modeling level.

So, that is a quick introduction to Service Oriented Architecture. This may be a “Back to the Future” blog for most of us -- but for those either new to the market or just curious —it’s certainly something that needs to get out there just as a reminder.

Thanks everyone. - John Michelsen