Then: http://briefingsdirect.blogspot.com/2007/01/transcript-of-briefingsdirect-soa.html
Again:
It’s (sometimes, often, not always) nice to have an exact transcript of my words on a particular occasion. And also good to have the precise words of whoever came immediately before me, and who set me up. Because in retrospect we all tend (or maybe just I tend) to maintain a self-centric memory of an occasion, abstracting away the inconvenient fact that other people were there and that they, not me, were the more important players in that little vignette.
My first SOA Insights was on Friday, January 5 of this year. It was with Dana, Steve Garone, Joe McKendrick, and Tony Baer (none of whom I knew before then, but all of whom impressed me with being more deserving of the “leading SOA analyst” title than myself….no, not false modesty….I’m an SOA analyst, all right, but my coverage area has shifted since my Burton Group years away from the application infrastructure focus of most of these folks toward data management…under which SOA is an important theme, but which takes me in different directions from the others…such as Semantic Web…which explains in why I felt inclined to throw that topic into the panel in April…and, of course, explains that just-finished ten-week blogthread).
Anyway, back to the podcast on January 5. Dana usually, a day or two before the event, e-mails the participants a sketchy list of possible topics he’ll bring up, and he did that week. His number one topic was the “ROI of SOA”—a first-podcast topic that, fortunately for me, was like lobbing a clean fastball through the sweet spot of my strike zone—I had published an article on that very topic in Network World in October 2005, and I had my print-out of the original manuscript, including a symbolic SOA mesh-like drawing I was inordinately proud of, in front of me as I spoke to the world that January morning.
I already had my remarks mapped out in my head when Dana turned virtually toward me to set me up. In the following excerpt from the transcript of that podcast, notice that Dana lead in with a “root system” metaphor, which I wasn’t expecting. Notice how I then, in a eureka moment of which I’m also inordinately proud, morphed Dana’s metaphor into another metaphor—SOA as fungus--that has since that time struck a responsive chord with a bunch of folks across cyberspace (as gleaned through my daily reading and occasional self-Googling):
************************************
“
”Let’s go over to Jim. Jim, if SOA is important, almost like a root system that cuts across a number of different trees that are growing, is it even worthwhile measuring it, or should people just be smart enough to recognize that this is the right thing to do?
”Kobielus: That’s an interesting metaphor there -- SOA as a root system. My visual image of SOA is a very complex hyper-mesh. In other words, like a root system, where you have tendrils going hither and yon, the tendrils being simply interactions among services and client.
”It’s very worthwhile to measure the ROI of SOA as a paradigm or an approach for enabling and for maximizing the sharing and reuse and interoperability of distributed resources across your network. You make an investment as an organization, as an enterprise, and in this approach you want to know whether you’re investing your funds and your resources wisely. 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? We’ll never get there, but in any given organization, 100 percent reuse, service reuse, first and foremost is a consolidation topic. What that means is, if you do SOA right, you’re doing much more with much less.
”You’re able to consolidate redundant silos of application functionality and data throughout the organization. You’re able to consolidate fewer software licenses and servers, with the associated translation and cost savings and capital on operating budgets, fewer redundant software components and so forth. The need for fewer programming groups, as we can consolidate that as well.
”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.
”So, once again, getting back to your root-system-and-tree metaphor, 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 [
”
Kobielus: I think they probably already believe that!”
************************************
Boy, am I glad we didn’t deep-end on that metaphor: it can quickly lead to some disparaging, distracting, downright dirty connotations. Later on in that session, we all morphed together into an SOA-as-movie-studio metaphor (by way of Dana morphing fungus to amoeba, and then amoeba to plumbing, and then plumbing to architecture, and then architecture to soundstage, and then soundstage to movie studio—I’m too impatient to get to the point of this new blogpost—does anybody care enough to go back to the transcript and double-check the sequence of images?..you don’t?...don’t worry…hold on, gotta give Tony Baer credit for taking it to the movie studio metaphor, which is where I picked up developing it further then, and will do so “again” presently).
First, here’s me “then”:
************************************
“Kobielus: I’m going to take this movie industry metaphor out of the realm of metaphor into the actuality of, teams becoming very SOA-focused in terms of the actual production ... A mashup is reusing existing components of service -- content -- whatever into new vehicles or new compositions. If you look at the content that’s being developed out there in the IT world, more of it's getting built through various types of mashups, which is very much an instantiation of the SOA paradigm into a different world -- not the software world so much as the normal cultural world that we all inhabit.”
************************************
Now, me now:
This feeds nicely into how I approach SOA as the principal analyst for data management at Current Analysis. Fundamentally, as I’ve told many people on many occasions over the past few years:
- SOA is a paradigm for maximizing the reuse, sharing, and interoperability of precious resources over distributed fabrics.
- For any organization, one of the most precious resources is the master data—the official, single-version-of-truth, recordkeeping data--on which they run the business.
- Consequently, the life-cycle governance of that master data—and of the distributed services for extracting, transforming, and loading; for profiling, cleansing, and enhancing; for consolidating, controlling, and versioning; for accessing, distributing, delivering, and mashing up that master data—is one of the most critical applications of SOA in the corporate world.
- Hence, master data management (MDM) is SOA in the sphere of data management—lifecycle governance of that sprawling fungus, amoeba, aquifer, grotto, or whatever called SOA—governance of the master data, of all of the myriad, sundry, and sordid means by which it all gets mashed up—and acquires meaning, either at the source through careful composition—or in the intermediate re-interpretations or recontextualizations—or the emergent process by which meaning blurs, distorts, or opaques through progressive deconstruction or regressive decomposition somewhere across that universal producinogenic fungus….
- For that’s what fungi do, here on this earth….
They decompose and consume every last sentient thing.
Jim
