thenagin The SOA Arsenal Metaphor

All:

Then:
http://briefingsdirect.blogspot.com/2007/03/briefingsdirect-soa-insights-analysts.html

Again:

Dana raised that metaphor in his opening remarks on this particular podcast, which was recorded on Friday January 26 of this year. That word has made me giggle since Morrissey brit-punned on it in the title to one of his early solo albums. Do a quick Google to giggle along with the master of mope.

Won’t go any further down--or up--that dirty boulevard of metaphorical elaboration. As for the podcast, we discussed three very substantial topics: best-of-breed SOA suites, master data management (MDM), and the “new enterprise architect.” Other panelists included Messrs. Gardner, Garone, McKendrick, Baer, and Macehiter.

Re best-of-breed SOA suites, here’s what I said then (and said more or less the same yesterday, August 3 2007, to Jon Brodkin of Network World, so it’s interesting to see that my fundamental perspective hasn’t altered significantly over the past half-year…or maybe I’m stuck in my ways…you decide):

“Kobielus: …. Over time, we’ve all been seeing this notion of a SOA suite take root in the industry’s productization of their various features, functions, and applications. Now, the big guys -- SAP, Oracle, Microsoft, webMethods, for that matter lots of software vendors -- are saying, ‘Hey, we provide a bigger, 'badder' SOA suite than the next guy.’ That raises an alarm bell in my mind, or it’s an anomaly or oxymoron, because when you think of SOA, you think of loose coupling and virtualization of application functionality across a heterogeneous environment. Isn’t this notion of a SOA suite from a single vendor getting us back into the monolithic days of yore?

This thought came to me when I was reading a Wall Street Journal article earlier in the week about SAP, “SAP Trails Nimble Start-Ups As Software Market Matures.” There was one paragraph in there that just jumped out at me. They said, ‘Some argue that SAP's slump highlights a broader shift under way in business software, in which startup companies wield an advantage over established titans. Under this traditional business model companies buy large, costly packages of software from SAP and Oracle to help them run their back-office functions and so forth, but as the business software industry matures, many companies already have the big software pieces they need, and feel little urgency to replace them.’

So, clearly SAP is then sort of a driver in the SOA suite arena for few years with NetWeaver. Is the notion of SOA suite an oxymoron? Are there best-of-breed-suites? There are also best-of-breed SOA components, and I’m not sure that the notion of a suite, an integrated suite is really what companies are looking for from SOA. They want best-of-breed components with the assurance, of course, that those components are implementing the full range of SOA standards for heterogeneous interoperability. So, I’m taking issue with this notion of a ‘best-of-breed’ suite.”

Of course, I’m hyperguilty of using the term “best-of-breed” all the time in my coverage of the Data Management space. Here’s where I should declare how I construe it, and why I feel it adds value to my discussions of “who’s on first (second, third, fourth, ….nth) in BI, DW, DBMS, DI, DQ, MDM, CPM, CEP/ESP, EII, ETL, GRC, etc.,” so that I can make my peace with it in the sphere of “SOA suites.” Essentially, a “best-of-breed” (let’s call it “BOB” for short) vendor, solution, or product is not “the best” one on the market, but rather one that, for some well-defined market segment, satisfies some weighted/composite metric of a) functional breadth/depth, b) installed base/adoption, c) maturity/stability, d) integration/sophistication/evolution, and e) price/TCO. Fundamentally, BOB is a “shortlisting” criterion: it refers to one or more strategic vendor/supplier/providers in a particular segment that offer enterprise-grade, robust solutions and are worthy of deeper consideration, investigation, and evaluation by enterprise IT.

That said, I agree with the following observations by my fellow panelists that morning:

“Macehiter: ….We have to recognize that organizations increasingly are looking to rationalize their supply strategy. So, they’re increasingly looking to deal with a smaller number of vendors and suppliers, which is, in part, driving the move toward larger vendors attempting to offer a suite or portfolio of product capabilities that can help organizations manage the lifecycle of an SOA initiative….Companies are putting together a bunch of products under a common brand, whether it’s Oracle Fusion, SAP NetWeaver, or under the IBM WebSphere brand. [It’s important to consider whether the products under these brands actually] are well integrated and that they have a common management environment, common configuration environment, and common policy definition environment.”

”Garone: All of us on this podcast today know that the debate over best-of-breed versus integrated-stack approach has been going for many years in a variety of scenarios and contexts, and it hasn’t stopped. I don’t really like the word "suite." It reeks more of marketing than functionality. [What customers want is] an open environment where they can pick and choose and not be tied to one vendor, what overrides all this is a desire to get things done quickly, efficiently. They want a way in which they don’t have to be concerned about integrating a lot of products and what that entails, and having potentially an unreliable environment. What that points to is working toward one vendor. End users will do that even in the short term by choosing someone that they know they can grow with in the future.”

“McKendrick: … Now, Oracle is an interesting case. When I think of suites, I think Oracle demonstrates the best tendency in this area. In fact, they called their offering ‘The SOA Suite,’ and they include a number of components. I have spoken with some companies that have Oracle installations. Now, it should be noted that typically the customers for these suites are the installed base. The people who will be buying into the components of the Oracle SOA suite are companies that either have the Oracle applications, the E-Business suite or the Oracle database underneath. And, in most cases, they are buying into components of the suite.”

“Baer: ….. There is always going to be a tension between homogeneity and heterogeneity. For the customer, it’s going to be dictated obviously by what is already in place, basically as Joe [McKendrick] pointed out. If 60 percent of my functionality, or even say 30 or 40 percent of my functionality, is SAP, I’m likely to listen when SAP tells me about a NetWeaver Solution…..[The] fact is that at the infrastructural level, there is a desire to have consistency. I don’t want to have five security engines. I don’t want to have three different authentications, if possible. Obviously, we’re never going to get that one, centralized identity repository in the sky, but I want to at least have my management framework be as consistent as possible and to manage what will inevitably be, in most large organizations, a federation of different installed bases of different technologies.”

“Macehiter: …. We have to be careful to distinguish between the infrastructure that you require to enable SOA initiatives and what you’re trying to enable with that service-oriented initiative. Just because you want to have a loosely coupled component that you can combine in multiple ways to deliver business outcomes, doesn’t mean that the infrastructure that underpins that has to be similarly loosely coupled and based on the heterogeneous offerings from different vendors.”

And here was me, then, splitting the difference and attempting to sum up what seemed to be the consensus of the panel that morning (and, I assume, still):

“Kobielus: I agree -- I think that the notion of a best-of-breed SOA suite makes more sense from an enterprise customer’s point of view. Most enterprises want to standardize on a single vendor and a single stack for the SOA plumbing -- the registries and repositories and also the development tools. They want the flexibility to plug in the different application layer components from Oracle and SAP and others, that are SOA-enabled and that can work with that single-core-plumbing-stack from a single vendor.”

A minute or two later, Dana moved the discussion toward one of my core focus areas at Current Analysis: master data management (MDM). I don’t recall if I’ve laid out my MDM/SOA framework in this blog before (I assume that I have…so, in a Morrissey vein, stop me stop me stop me, stop me if you think that you’ve heard this one before…or just fast-forward past the following bullets:

• SOA is a paradigm that focuses on maximizing reuse, sharing, and interoperability of valuable enterprise resources over distributed networking fabrics.
• Master, official, reference, scrubbed, corrected, standardized, normalized single-version-of-truth recordkeeping data is one of the most valuable/indispensable enterprise resources.
• MDM refers to the ecosystem of repositories, solutions, applications, components, tools, workflows, roles, rules, etc, that support lifecycle governance of master data sets, so that this “gospel” data can be maximally reused, shared, interchanged, etc in BI, CPM, BPM, ERP, CPM, and other applications throughout the enterprise, supply chain, etc.

That said, Dana framed the MDM-as-SOA discussion quite well that chilly late-Jan morning:

“Gardner: “We [he and Ash Kulkarni of Informatica] had a really long, interesting discussion about the role of data, master data, and metadata when it comes to moving toward SOA. We really shouldn’t lose track of the fact that as you move to applications as services, and you go loosely coupled, and you adopt more reuse across development with common frameworks, and use rich internet application interfaces -- what about the data? The data has to be managed as well. Increasingly, companies that have had mergers and acquisitions, or have just gotten myriad applications with varying views of something as specific as a customer identity -- there might be 10 or 15 different views of a customer, as defined by a variety of different applications. How do you manage that? And when you think about the progression of the data, it seems to me that if not in actuality, in a virtual sense, you want to become centralized with your data so that data can be used in a clean and impactful or productive way across all of your services.”

Then I uttered a short version of the MDM-as-SOA framework that I just now bulletized/expanded in this post a moment ago. Not going to excerpt that here, but I do want to re-present the following excerpt from I uttered then, in which I pointed out that MDM need not be implemented in a centralized fashion (departing from Dana had just stated or implied), but, rather, could leverage enterprise information integration (EII)—aka “data federation”—fabrics for unified governance of decentralized master data sets (this is an extremely important point in the MDM Maturity Model upon which I’m basing my growing body of vendor-specific MDM Solution Assessments for Current Analysis):

“Kobielus: ….[T]here are a lot of enterprise information integration (EII) vendors out there. EII revolves around really federated MDM, where you keep the data in its source repository, and then provide a virtualized access layer. This allows your business intelligence and other applications to access that data through a common object or model and a common set of access schemas -- wherever that data might reside -- but facilitated through a virtualized access layer. That’s very much EII as implemented by Business Objects, BEA, [IBM, Sybase, Composite Software, Red Hat/Jboss/MetaMatrix] and many other vendors, and is very much the approach for federated MDM.”

After we’d explored that theme for a few minutes more, then we moved into a discussion of the “new enterprise architect,” re the career path for SOA developers, integrators, analysts, etc. Here’s how Dana framed discussion on that topic, which was proposed by Joe McKendrick:

“Gardner: ….”There are a burgeoning number of critical skill sets that need to be applied to SOA. We’ve talked about data, whether it’s cleansing, transforming, virtualizing and approaching some sort of a MDM capability. We have talked about development and process, BPEL. We talked about infrastructure. There is the management, the architectural overview, and what’s our philosophy. It seems like we’re going to need a lot of very skilled people who are both generalists, as well as highly specific and technical. Because for SOA to work, a bunch of people who are highly specific -- but don’t share the same vision or have a general sense of the strategy -- probably won’t fare too well.”

Joe’s take on the topic:

“McKendrick: [Ron Schmelzer of ZapThink] is sounding the alarm bells that the folks that we need to drive SOA forward in the enterprise is this class of enterprise architects and enlightened architects, if you will. There are a lot of SOA projects everybody is interested in. Everybody’s kind of ginned up about SOA now, and we’ve been hearing about it. Enterprises really want to begin to either pilot or move SOA past the pilot stage, and 2007 should be a big year. Schmelzer feels there may not be enough architects who can take this high-level view and drive this process forward. Now, it’s interesting, but when I posted this on my blog, I got lot of feedback that perhaps architects are not the only ones who can really lead this effort. There are plenty of developers out there, high-level developers, who can also contribute to the process and interact with the business. The key behind this argument is that you need folks who know what’s going on technically, but can interact with the business. It can be a rare skill to have both.”

My two-cents on it, pointing out that such IT skills deficits are usually short-lived, as smart people quickly get the requisite training, or rise to the challenge, in order to seize these money- and career-making opportunities while they last:

“Kobielus: … Not to get reminiscent or anything, but 10 years ago, when we started seeing Java ramp up, we saw a lag there as well. A lot of organizations were really hungry for Java developers, and the universities came through with more focus on it, but later than probably most organizations wanted. What will happen here is that while this ramp-up goes on, we might see a lot of new business and new interest in service organizations that can provide the professional services required to get people through it.”

You can read the full transcript for the panel’s foreshortened discussion of this topic (we were near the end of the allotted 45 minutes and were trying to wrap it up gracefully). The highlight for me was Neil Macehiter’s take:

“Macehiter: “… the key skills that are required [revolve] around being able to interface with the business. One of the skills and attributes that you also need as a SOA architect is really this ability to balance supporting short-term business outcomes but keeping an eye on the longer-term objectives in terms of gaining high quality and maximizing IT value. That’s an equally difficult skill because too often architecture historically has been focused on quite discrete initiatives or infrastructure. I’m thinking about server architecture or network architecture rather than this broader perspective. There are skills occurring from such things as Oasis and what they are trying to do around things like SOA blueprints.”

All of which gives me a sweet seg-way into the core of my chat yesterday [once again, Fri Aug 3 2007—a week in which Dana didn’t convene the podcast panel] with Jon Brodkin of Network World, who was interviewing analysts, enterprise architects, practitioners, and so forth for a piece he’s writing on 5 tips for making SOA be “about the business,” or something to that effect. Over the half-hour or so that we spoke, I cobbled together the following 5 bulleted tips (I’m paraphrasing myself, since I generated them on the fly and didn’t write them down till now):

1) Banish the phrase “SOA” from your business vocabulary, and only speak in terms of the business metrics, benefits, ROI, etc from implementation of the principles associated with this approach.

2) Boil down SOA’s business metrics/benefits/ROI to the fewest number of actionable words (e.g., agility, modernization, consolidation, rationalization, simplification, optimization, rightsourcing) that can be used to justify/explain SOA-related projects to all business and IT stakeholders.

3) Establish an internal SOA planning/governance practice, under a broader business and IT governance umbrella, that can evaluate, approve, and authorize new SOA-related development/integration/infrastructure proposals for feasibility/ROI per clear corporate-standard metrics.

4) Implement a runtime SOA governance infrastructure/operations to ensure that the end-to-end fabric/ESB/app-infrastructure continuously complies with corporate business policies, SLAs, etc.

5) Provide all SOA governance participants/stakeholders—business analysts, enterprise architects, IT developers, operational personnel, etc.—with a common visual modeling/management framework to catalyze and maintain a consistent, consensus view of the shared environment on all levels, from high business level through drilldown to low-level “plumbing” details, per the needs of each stakeholder.

Or something to that effect. I’m curious to see if/how Jon quotes me in his article, or just paraphrases some segment of the thoughtstream.

Then again, it’s good to have this blog so that I can paraphrase myself, and thereby nail this stuff conceptually to my personal persistent arsenal. And you, all you enterprise architects out there, you’re more than welcome to stick these SOA business-oriented bulletpoints in your arsenals.

Jim