Anne Thomas Manes is one of the most influential figures in
Web services today. She's a research director with Burton Group as well as a prolific speaker,
writer, and blogger on the important topics around SOA and Web services. Manes recently co-authored
a concise report on "The State of SOA". This interview covers the findings and recommendations from
that report, as well as why SOA is very much alive and well.
In your report you say some organizations have not realized the promise of their SOA initiatives, and one key reason is they didn't focus on architecture. Can you explain?
Anne Thomas Manes: Architecture is really hard. People are comfortable doing things the way they've always done them, particularly design patterns inside application systems. I don't think many organizations adopted new design patterns to build loosely coupled services, so they didn't get spectacular results of reduced costs and increased agility. To get that you have to go back and look at what prevents it in the first place, and in 95% of cases it's the application architecture that gets in the way and makes it expensive to manage and maintain the applications. You have to fix the architecture.
And yet there have been a lot of SOA initiatives. Are they successful?
Manes: I still assert that very few organizations have been successful with SOA. Plenty have built successful applications using SOA technology. The use of SOA technology at this point is pervasive. They're not the creaky old integration brokers. They've upgraded to ESBs. They're not using proprietary protocols but the web services stack. There's a small benefit in migrating to this next level of interoperable middleware; but one successful implementation of an application does not make SOA.
As you go through the design of a system, [you need to] make sure you're following core principles of service orientation, encapsulation, loose coupling. But how do you implement something, making sure there are reduced dependencies? That's where design patterns come into play. The big challenge is you've got seasoned object-oriented developers who understand object-oriented design patterns and don't realize the design pattern they're used to using is inappropriate in a loosely coupled world.
Another key aspect is service modeling. How do we determine what should be a service and how much goes into a service? To some degree you can use some patterns, but service modeling is an art a lot of people don't have much experience with. What processes do you go through to make sure you're building the right services? But more fundamentally, it's about training. Do people know what principles/patterns are, and do they know how to do modeling?
What about cultural issues?
Manes: What [we've been] talking about is core design, the engineering aspect. To design a good service-oriented system you have to have those core engineering capabilities in the organization. But then the question is whether the organization facilitates that. Lots of organizations, the vast majority, are not set up to support the creation of shared services. There are big problems with funding models. They're not designed to support the notion of shared services.
Is SOA the future?
I don't know how else to fix the problem. The problem is a lot of organizations are not willing to make an investment in architecture, but if you want to increase agility and decrease costs, you have to fix the application portfolio. Application portfolio management and a rigorous decommissioning of application systems is a great way to fix the problem, but you have to replace them with something else. If you've got 10 applications that manage customer information, you just can't get rid of 9. The way to fix it is to create a service that manages customer information that can support all 10 of the use cases.
My position on SOA is the reason you're doing it is to increase agility and decrease resources. You have to treat the source of the problem, which is redundancy and monolithic tightly coupled systems that are hard to manage and maintain. The way to reduce costs, make [apps] easier to manage and maintain, reduce redundancy and make [information] easier to access is all accomplished via SOA. I don't know any other way to accomplish that. If you want to support cloud, mashups, mobile, then you'd better be doing service orientation.
That said, I have to ask about your 2009 report called "SOA is Dead; Long Live Services" that sparked a lot of controversy. What was your intent?
I said it's not really dead; it's called "services." [Ed. Note: In her blog post on this topic, Manes wrote: "Although the word 'SOA' is dead, the requirement for service-oriented architecture is stronger than ever.] The point was you can't sell SOA to the business, because you failed to deliver on the promise of SOA. It was 2009 when there was belt tightening, and they're not interested in spending another $5 to $10 million on SOA. The point I was making is you can't go to the business and say I need more money if you're not demonstrating value. Stop talking about SOA and just do it. You need to start applying the [SOA] principles in every project you're working on; adopt this discipline, not technology.
There were an awful lot of people who never read beyond the first half of the title, and they took it as an intention to abandon SOA, which was not my intention. And lots of people interpreted it as you just can't call it SOA. The vendors really hated me, but if they had been smart they would've embraced the idea, because it's not just technology, but design and architecture. Vendors don't like to tell clients that SOA is hard.
A number of people said my blog post was best thing that happened to SOA, that it was a wakeup call to the industry. Three years ago the most common question I got from clients was what ESB should I buy? I'd say what makes you say that? They'd say this is what the vendor told us or what the analyst said. An ESB is a piece of technology to integrate your system, but it doesn't give you SOA. What are you doing to rearchitect? Look at it from an application portfolio perspective.
This was first published in October 2010