Searching for the Soul of SOA

SOA is like an orchestra, a root system, a 30-mile wide fungus, an amoeba, a 1930s Hollywood movie studio and perhaps an independent film built from a loosely coupled team. It’s an intellectually wild, yet illuminating, ride.

Recently, I sat down with a panel of analysts — independent industry analyst Steve Garone, research consultant Joe McKendrick, onStrategies Principal Tony Baer, and Current Analysis Principal Analyst Jim Kobielus — examining the metrics of business success for service oriented architecture.

The discussion takes on a soul-searching kind of direction — a search for the soul of SOA.

Listen to the discussion (44:53 minutes).

Here are some excerpts:

Steve Garone: One of the challenges that organizations face in doing SOA and then trying to determine their ROI — for want of a better way to put it — isn’t unique to SOA. It’s really a function of various other types of IT-related activities as well. How do you actually quantify what your ROI is, given the advantages of using an SOA approach?

Joe McKendrick: The companies that are most likely implementing, or are implementing, SOA are probably the companies that don’t really need SOA as much. The companies that really could use SOA in their operations are likely not to be the ones implementing. It’s kind of a paradox.

The reason (for) that is the companies that have the management vision, the support to roll out and move an SOA project forward — providing top management support, for example — are likely to have (a) lot of other initiatives on the table. They’re likely to be very forward-looking with their management.

Jim Kobielus: When I think of SOA’s ROI, I think of two numbers, and those numbers are 100 and zero. As we know, SOA focuses on how you maximize the sharing and reuse of services, of application functionality and resources. In other words, how do you enable a 100 percent reuse as a nirvana?

… So 100 percent reuse is the nirvana. The zero comes in the sense that, if you’re doing SOA right, the marginal cost of billing the next application drops pretty close to zero. You’re able to reuse everything that’s already been built. You do not have to reinvent the wheel. So, basically, a 100 percent reuse means zero marginal cost of building the next application. Of course, as I said, you enable that vision through consolidation, both in software and hardware, and in programming teams, and so forth.

SOA becomes this ubiquitous root system from which new sprigs can pop up, without needing to lay down their own root system. Rather they are simply branches on a huge underground system.

Tony Baer: If there is one benefit that SOA delivers, it’s that the value becomes the service rather than the plumbing. If you think about the way we’ve traditionally developed functionality or integrated systems, we’ve had to spend inordinate amounts of time in the plumbing and maintaining it.

SOA theoretically, if it’s done right, standardizes the plumbing, makes everything declarative, so you take out the guess work. The result is that if you look at outsourcing, SOA separates the plumbing from the service. Therefore, what is probably ideal for outsourcing would be the plumbing, because that’s where the value is and that’s not where IT organizations should be spinning their wheels.

The value is in the — and this will sound a little clich-ish — intellectual property, which is represented by the actual service. That’s the service that delivers the actual business logic. It’s the way a company does business. The way a company does business is not the way it puts together its SOA plumbing. That should be standard.

Jim Kobielus: On the issue of outsourcing, the only thing that the company should never consider outsourcing in terms of core competencies is the core competency of making money and delivering value. Everything else is fair game, and I think what everybody is saying here is that they agree with that. SOA — or much of what we think of as SOA — revolves round the plumbing, the protocols, the application servers, the middleware fabric, etc., that all is fair game for outsourcing.

The notion of the classic studio system for Hollywood was there between the ’20s and the ’50s, and then it gradually gave way to more independent producers. Now, you’ve got all these indies everywhere. What I’m getting at is that the governance of any given movie production project, how it’s done, the best practice for that particular industry, continues to evolve from generation to generation.

Likewise in the IT world. If you look at the life cycle of governance of the creation of any application or functionality, of the whole software is on the life cycle, that paradigm continues to evolve from generation to generation, with new platforms, new tools, and so forth. So, it’s one of those things where now you’ve got to look at the structure of the SOA governance environment.

You’ve got roles that are specific to the plan, specific to the development stage, roles that are specific to the deployment and optimization stages and so on. What I’m getting at, then, is that I think the movie studio analogy is very interesting, because it focuses on the core of governance as a workflow over a life cycle involving various roles, and those roles continue to munge into each other and get broken off from each other.

Click here for more podcasts.