The latest BriefingsDirect SOA Insights Edition podcast begins with the panel of analysts -- Steve Garone, Joe McKendrick, Tony Baer, and Jim Kobielus -- examining the metrics of business success for services oriented architecture (SOA). But the discussion takes on a soul-searching kind of direction -- a search for the soul of SOA.
The analogies and metaphors soon start flying: SOA is like an orchestra, a root system, a 30-mile wide fungus, an amoeba, a 1930s Hollywood movie studio, and perhaps a independent film built from a loosely coupled team. It's an intellectually wild, yet illuminating, ride.
Here are some excerpts:
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? I’ve listed the main reasons why people would want to do SOA, in terms of the advantages, and they basically break down to four major areas.Listen to the entire podcast, or read the full transcript for more on SOA ROI concepts.
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 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 lot of other initiatives on the table. They’re likely to be very forward-looking with their management ... Essentially what you have in these companies is an orchestra making a lot of beautiful music and SOA may be the horn section, but how do you measure the impact of SOA versus another type of implementation or another type of project?
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. In Northern Michigan, where I’m from, scientists have discovered the world’s largest organism as a mushroom or a fungus of some sort that spans 30, 40, or 50 square miles. They determined though DNA analysis that it's the exact same individual and has got the largest biomass in the world. In essence -- and it’s all underground pretty much. That’s what SOA is all about, essentially all the services in an SOA sort of share a common DNA.
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 ... 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.
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, its 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.