Last week, Anne Thomas Manes, a research director with the Burton Group, explained why she wrote SOA's obituary and discussed the benefits of doing SOA right . This week, Manes explains what it takes to really do service-oriented architecture and what companies should be doing instead of integration.
Lawson: It doesn't seem like you're really advocating moving away from the ideas of SOA.
Manes: Oh, absolutely not. One of the responses (to the SOA obituary) in a blog post said that the reason people claim things are dead is because they're bored and it's not exciting enough anymore. No, I'm just really tired of banging my head against the wall because I've been telling people that they need to do architecture, but instead of doing architecture, they do integration and they're not actually re-architecting their systems.
"Any time somebody has to switch from one application to another application in order to get a single process done, that's really dumb. Any time somebody has to write something down on paper so that they can go to the next screen and put it in, that's really dumb. Any time that a human has to copy or paste, any time a human has to actually get up and go do something that is not through the computer, well, why is my automation not working here?"
Lawson: My feeling is that there is not a lot of guts for re-architecting right now. Maybe it's resources, will, ability - I don't know-but it seems people aren't willing to completely redo everything.
Manes: I agree with you, and obviously you're not going to re-architect your entire portfolio in a matter of months, right? But what you do is establish your priorities.
I typically say that your SOA initiatives begin with application rationalization. The first thing you have to do is take a look at your application portfolio and rationalize it. Determine what are the applications that I have that actually provide significant value to my business, which applications and how much do each of these applications cost. The applications that provide very little value to the business, but cost an awful lot, are the ones that you want to start getting rid of.
The other aspect of that is to actually understand where you've got duplicative application systems out there. It's like, okay, I've got 10 different applications out here to do billing and why is it that 10 of my applications do billing? Why don't I have one billing service instead of 10 applications that do billing in a different way?
Scheduling is another great example. Lots and lots of applications need to do scheduling. Well, why is it that you have a different scheduler in every single one of these applications? Why don't you have a common scheduling service and whenever an application needs to do scheduling, it calls that scheduling service?
And that's the reason why I keep insisting SOA is much more in the realm of enterprise architecture than it is in individual application architecture. If I'm only doing SOA at an individual application level, what's the difference between SOA and 3-tier or end-tier client/server applications?
If I'm still focused on building this one application that does everything from soup to nuts and I'm not looking at opportunities to externalize a bunch of capabilities from my application and put them into a shared service that other applications can use, then I'm really not doing SOA. I'm still building monolithic applications where this one application may be distributed but it's still a monolithic application. It's solving one end-to-end process and I'm not actually sharing this across any other systems.
Lawson: That brings up a question. You talk about all of these different systems that do the same thing or have some of the same functionality. There is a lot of talk about integrating those because not only are they separate but they often don't even talk to each other. Instead of talking about integrating systems or applications, what should people be talking about doing?
Manes: That is fundamental. That's hard. There aren't too many organizations that are really willing to go do that. That's one of the reasons why I recommend going through the application rationalization process, because that application rationalization will give you an incredibly solid business case to say, "I need to decommission these applications."
You walk into your average large enterprise and it typically has more than 500 applications. In fact, it often has more than 1,000 applications. But, if you actually do an analysis of what it is that this business needs to do and the capabilities that the application software has to support for the business, it usually comes in at somewhere under 50.
Why do I have 500 applications to do 50 things? It's because every single business unit says, "I'm special and the thing that those guys over there are doing - well, it's kind of close to what I do but it's not exactly what I do so I need my own version of it."
Why is it that an organization has thousands of databases often containing almost identical information but it's not semantically compatible? That's because everybody says, "No, no, I have to have my own copy of the data." No, you don't. You might need your own view of the data, but you should not have your own copy of the data.
Having all of this duplication and redundancy in the applications and data architecture is the primary thing that impedes agility. That's because every time you create a new application, you've got to connect it to these other applications. And if all those applications, instead of being monolithic things, were services that implemented a set of capabilities that were much more readily accessible from other things, then integration wouldn't be a problem anymore. You wouldn't have to build all this extra stuff to make this thing talk to that thing.