Getting Back to the Business Value of SOA

Loraine Lawson spoke with Dr. Chris Harding, head of The Open Group’s SOA Working Group, and the primary author of “The SOA Sourcebook,” which distills the work of the Open Group on SOA. Harding explains why IT hasn't managed to shift SOA from a programming concept to an architectural concept that supports business functions.

Lawson: You mentioned that SOA lends itself to an organic approach to enterprise architecture. What do you mean?
Harding: The term organic architecture was coined in the terms of buildings architecture by Frank Lloyd Wright long ago. This is a different use of that term in the sense of enterprise and IT architecture. Organic architecture is an architectural approach that regards the enterprise as an organism and focuses on the principles by which that organism develops, rather than attempting to define a particular state at a particular point in time of that organism. Rather than painting a picture of a tree, it is defining the tree's DNA - the principles by which that tree will evolve and develop.

Lawson: So practically speaking, how does that change how you do architecture in IT?
Harding: Well, it means that your focus is on the principles and the governance. You're not only going to have a governance regimen that looks at the processes, service and solution lifecycle and portfolio management, and defines how those processes are done, and defines how you check those processes are done correctly, and how you do appeals and exceptions and so on. You also look at how the governance process is working, and whether the governance process itself needs modification. In the context of the architecture, you're looking not only at what are the systems that are going to be in place when the architecture is delivered, but also at how those systems are going to evolve.

In the case of SOA, you're not coming out with a picture of the enterprise as it is and will be. You're coming out with, “Here is where you're starting from and this is how you go on from there. Here is your architecture, and it has these services in it, and you're going to add to those services, you're going to put in new ones, you're going to revise them and these are the kinds of ways you're going to go about it - but in doing so you will maintain the standards and principles that everything conforms to.”

That has always been a way of doing architecture. If you look at the IEEE 1471 definition of architecture, it talks about the principles by which the architecture evolves, but I think it is something which is becoming emphasized more as we go on, and which SOA lends itself to particularly.

Lawson: You felt like the concept of SOA hasn’t shifted from just a programming concept to an IT architecture or business operation concept, so one of the key themes of the book is how to evaluate SOA features in business terms. What is IT doing wrong in this regard and how can they evaluate SOA features in business terms?
Harding: A lot of the problem with SOA is how it's been introduced. It's very much been something that a set of vendors had been behind, and there is nothing wrong with that, but of course they desire to sell their products. So you have messages coming from them saying, “SOA is wonderful and here is our enterprise service bus, which is something you can use to implement SOA.” You come out of that with the feeling, even if they didn’t say it absolutely, that all you need to do is buy an enterprise service bus and you have SOA. Of course, it's not like that and buying an enterprise service bus - or a service registry, or an event processor or adopting an event-driven approach - may or may not solve your problem.

What you have to do is to look at the problem that you have. You shouldn't start by saying, "We're going to do SOA." You start with, "I have a reason by which our business needs to change and the IT supporting it needs to change." Then you look at why it needs to change, and how it needs to change, and when you do that, you think in terms of services. This is adopting the SOA approach - and you can then think about what other kinds of things you can do when you have services.

You can have messaging and a service bus which sends the messages, you can put on an event processor and add event-driven capabilities. You can do business activity monitoring. You can do any of those things, but you shouldn’t do them automatically. You should look at what those things buy you in business terms, and how they relate to what you actually need. That's what I mean by evaluating SOA features in business terms.

Lawson: I think part of the problem IT has with SOA and moving it to those business concepts, is that people do define services differently and disagree over what constitutes a service. So in the book, how is a service defined?
Harding: I actually think there is a fundamental agreement on the base of characteristics of what a service is, although there may be variations to that. A service has a provider and consumers, and has a description. An enterprise service is an activity the enterprise does that delivers value to consumers and that is provided by the enterprise.

Now, when you get into software services, you can have different kinds of standards. You could say, “In my SOA, services will be implemented by BPEL,” for example. You can say, “In my SOA, services will have WSDL descriptions.” But in both cases, you're using the same kinds of concepts of service, and that's also the same concept of service that the business people have for a service that might be provided by people, rather than by IT.

There are a number of standards organizations active in SOA. We're actually in discussion with people from the OMG and people from OASIS, both of which have concepts of standard frameworks for SOA. We differ heatedly on the phrasing of what the definition of a service should be, but we agree that we have fundamentally the same concept of what a service actually is.

Lawson: What do you think are the misconceptions about services that might be holding back broader SOA implementations?
Harding: I think the misconceptions are not so much about services as about SOA. The A in SOA stands for “architecture.” There are architectural frameworks around that give guidance on how to do architecture. They are quite comprehensive and there are actually a lot of things that you have to do.

It often happens that some new technique comes along on the horizon and people say, “Ah, here is a magic silver bullet. I do not have to do all that hard work anymore of finding out what the concerns are, finding out who my stakeholders are and what they're worried about and thinking about, how to describe the system to them so that we can resolve those concerns. We'll do it with SOA (or whatever it happens to be) and it will all be alright."

And, of course, it isn’t, because no architectural style will do for you the work of answering those basic questions. It’s like saying, "Okay, we’ve got a wonderful new architectural style for building houses. We'll build them with timber frame," for example. That's fine, but it won't work if you don't ask your clients the basic questions, like: “What are you going to use your house for? How many rooms does it have to have? Do you like open-plan living or do you need a separate dining room and kitchen?”

The problem with SOA, I think, has been that people have been caught up with the newness of the technique and forgotten to go back to the basics of how to apply it. Yes, it is a good technique and, yes, a timber frame is a good way of building houses. But the house you build is not going to be any good if you haven’t done the basics of talking to the people involved and finding out what kind of timber frame house they want. And the same applies to finding out what kind of SOA you need to provide.