Is Strategy the Key Characteristic of SOA?

Loraine Lawson spoke with JP Morgenthal, the Tech Evangelist blogger and a Principal Architect, about why he thinks strategy might be the key characteristic of SOA. He explains that much of what we call SOA isn't - and why everything doesn't have to be called SOA to deliver value.

Lawson: I wanted to talk a little bit about your recent column, in which you explain why you're rethinking your position on the need to come to an agreement on what SOA means. You said that you're now open to viewing SOA as a strategy?
Morgenthal: Yes. SOA may be more strategy than an architecture piece.

Lawson: So, how did you define SOA previously?
Morgenthal: For me, and it still is to some degree, you talk about IT and business alignment. It’s using a service as a metaphor to model the business as a set of business functions.

There is a lot of misconception out there. I don’t know how, but somehow we created an army of people who think SOA is all about business process. It’s not. And your processes are not your services. Your services are your business functions. What function does your business do? If I’m a store, I sell goods. And that’s my business function. In order to do that business function, there are a number of things that I need to do internally.

Really, as a customer, do I care how many vendor relationships you need in order to have the products in stock that I’m interested in? No. If you don’t have the products, I’m going to go to a competitor. Your business function to me as a consumer is that I use goods and I buy goods from you. The things I care about are what kind of currency you accept in order for me to buy these goods, how easily I enter your establishment to find those goods, and how plentiful your stock is and your availability of those goods. That’s what I care about. That’s your business function, that’s your service, those are your operations.

Now, you're a consumer of vendor services because you need to get the goods into the store. So you're a vendor of trucking services, logistic services, wholesalers, manufacturers, right? So the store is a consumer, it’s a service chain, but people are confusing the entire service chain and the flow across the service chain with SOA. No. At the end of the day, you're modeling the retail outlet. It has four core operations, right? Those are the business functions.

You want to build the business process, you're going to do it across those four functions for that consumer, which is somebody coming in and buying goods. Who else are you satisfying? The rest of it is all mental-you-know-what.

So it’s a modeling of the business and the business function as a service. When I used to teach SOA, I’d say if you can’t think about how you would do it with a pen, paper and a filing cabinet, then you're not in the right place. You should be able to design any business function using those tools. Then you worry about how to automate.

Lawson: What has changed for you in terms of how you viewed it before and what you view differently now?
Morgenthal: What I’m seeing is that there is still a large group of people who think they're doing SOA, who in my opinion are not and don’t understand why they're not and I address one of them on your site around the New York State government SOA case study.

You're just never going to win these people over. As I wrote on another blog entry on another site, “It’s hip to do SOA even if you're not doing SOA.”

If you want to think you're doing it, great. Have a good time. You're not doing SOA. You're never getting the value of SOA. But you tell people that and they get very combative. It’s almost like taking food off their table, because if you're not doing SOA, then what the heck are you doing? It’s a dangerous position that we’ve created where everybody needs to slap SOA on their resume to get a job these days, which is ridiculous. It’s become something of a useless term.

But for the people who are doing or are attempting to do SOA and have been doing it for two to three years, have invested some money there, have run against some walls and maybe even had a couple of failures - what I’m noticing in those areas is that they're transforming into some sort of methodology that is helping them to build systems faster.

Now, is that SOA? I don’t know. I don’t know that I’d still call what they're doing at the end SOA, but what I find interesting is that they finally got on a path that is leading to better response, being more agile, being more responsive in their own organization, if nothing more, from a systems development perspective - which they could have done with agile architecture and agile development practices if they adopted those and didn’t try to go after this big honking thing called SOA that nobody knows what it is. But they're getting there. Organically they're growing a methodology that fits their particular business, based on these concepts which really, at the end of the day, to them are nothing more than what we learned with distributed object computing back in ’95.

But hey, you know, some of us are ahead of the curve.

Lawson: What's missing in a lot of these implementations that keeps them from being SOA? I know some companies are just doing Web services. But what else is missing?
Morgenthal: They didn’t map the business boundaries properly. They didn’t map the service boundaries. They focused on utility service. What the heck is a utility service? It’s a software component. There’s no such thing as a utility service unless you're the electric company or the water company.

Lawson: Do you mean architecture is what’s missing?
Morgenthal: Understanding of the business is missing. You want to transform a business using SOA, you’ve got to understand and design services that align on the service boundaries. You’ve got to create the service boundaries properly. The service boundary for a retail outlet is on what we discussed earlier. It’s about how do I get into your store, how do I find goods, how do I pay for them. That’s all I care about. I’m a consumer.

Think about yourself as a consumer. IT people can’t put themselves in the mind of the consumer. They're only about being the provider and they take that and they screw that up.

Lawson: One question I had to sort of help me clarify something is what’s the difference between a business process and a business function? You’ve talked a lot about business function. I feel like I understand when you say that, but I don’t really understand what is meant when people say a business process.
Morgenthal: Well, a process is a series of stages, of steps, in which state is carried across. And that business process may be done within the confines of a single business function or it might require a couple of different business functions - like cross-business functions. So if I’m a store, moving the stuff from the back room out onto the shelves is a process. Moving the stuff from the truck into the storeroom and then identifying when to move from the store room onto the shelf, that’s another process.

Lawson: So is it that people are thinking too granular still?
Morgenthal: Yes. Granularity is a big issue with SOA. I think too many people doing SOA really just don’t know how to define service boundaries properly. They don’t understand the granularity issues, they don’t understand architecture.

And, like I wrote on your blog about the state of New York, kudos to you for improving your system. There’s nothing wrong with that. They take all the credit in the world for doing that, that’s phenomenal. More people need to do that. Just stop having to label it with SOA. There’s nothing wrong with component-based software to engineering and development. We’ve been doing it for years. It works great.

Not everything is a service. If you're not transforming the business into a service paradigm, if you're not thinking about what I do as a business, where are my business functions and where are my boundaries for my business function, you're not doing SOA.