Determining SOA’s Maturity Level

How mature is service-oriented architecture? In asking that question, it’s important to make the distinction between the best-of-breed approach, where one picks and chooses various components within one’s own SOA arsenal, or a more complete suite, a holistic full-feature set with the benefits, trade-offs and detriments of each of these approaches.

Data management also comes into play. Increasingly, companies that have had mergers and acquisitions encounter varying views of data, sometimes 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 does one manage this so that data can be used in a clean and productive way across all services?

Finally, as SOA matures, the field demands a growing set of skills. Where are we headed in terms of the necessary skill sets companies are going to need in order to accomplish the promise of SOA?

To answer these questions, I sat down with independent industry analyst Steve Garone, research consultant Joe McKendrick, onStrategies Principal Tony Baer, Current Analysis Principal Analyst Jim Kobielus and Macehiter Ward-Dutton Research Director Neil Macehiter.

Listen to the discussion (43:11 minutes).

Here are some excerpts:

On Best-of-Breed vs. SOA Suites

Jim Kobielus: We’ve all been seeing this notion of an 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 an SOA suite from a single vendor getting us back into the monolithic days of yore?

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.

Dana Gardner: Shouldn’t the vision of SOA allow us to have it both ways? If you have a culture and mindset in an organization, maybe it’s because of your legacy. Maybe it’s because of how you operate and the value you’ve perceived in past IT investments. Thus, you might want to remain with more of a single-vendor or an integrated-stack approach, but there might be other vendors without a legacy to drag along. The enterprise may want to take advantage of any innovation they can to be functionally heterogeneous and to explore and test open-source componentry as that becomes available. Shouldn’t SOA allow both of these approaches — and pretty much equally?

Neil Macehiter: We’ve done some detailed assessments of service infrastructure offerings from SAP, BEA, IBM, Oracle, Sun Microsystems and webMethods. If you actually dig under the covers, you will see that each of the components has its own policy definition approach. So, the way you configure policy within the orchestration engine is inconsistent with the way you do it within the security and identity management capabilities, and that challenge occurs within suites. That’s going to be compounded as you look across different components. That introduces risk into the deployment. It reduces the visibility of the end-to-end deployment. It’s those factors that are going to be important, as well as whether a communication and brokerage capability can integrate with the registry and repository

Kobielus: 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.

Gardner: Perhaps the tension here is between what aspects of SOA should be centralized, repeatable, simplified and consolidated, and which ones should not. It’s not really a matter of SOA homogeneous or SOA heterogeneous. In moving toward SOA, should you say, “Listen, this is going to be common throughout. Let’s reuse this. Let’s manage our policy as centrally as possible.

“We might say the same for other federated and directory services. We might say the same for our tooling, so that we don’t have myriad tools and approaches from our developers. On the other hand, we want to have great flexibility and loosely coupled benefits, when it comes to which services, be they internal or external, be they traditional nature or more of a ‘software as a service’ nature that we can easily incorporate and then manage those as process.”

Steve Garone: Frankly, from the end-user perspective, the message ought to be that the whole notion of SOA, as it relates to loose coupling, is really focused on the services and the applications that you’re going to deliver. That doesn’t imply or even suggest that your infrastructure cannot be based on an integrated stack or software that’s designed to work well together. It allows you to work with a single vendor, and to be very efficient about how you both develop, deploy and maintain and manage your environment.

Tony Baer: We can’t decompose it down to the age-old argument of best-of-breed versus integrated stack. 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. 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.

On the other hand, if I’m in a sector that does not lend itself to package solutions, I will more than likely tend to take a best-of-breed approach — especially if I do a lot of homegrown development, because my business is so unique. There will always be that creative tension there. That being said, 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.

On Master Data Management

Macehiter: Data has always been treated as a second class citizen, and that it has been the product of applications which have then been subsequently analyzed. More organizations are recognizing this need to treat data as a peer, and deliver access to information, whether it’s structured or unstructured, as a service, which can be incorporated as needed into business process.

IBM was quick to identify this when they sold the information as a service strategy. And Oracle, surprisingly, given where they have come from, has actually not really enunciated data services, vision and platform. Although I did notice something on the Oracle Technology Network a couple of weeks ago, where they are just starting to talk about Oracle Data Integrator, based on an acquisition they made of a company called Sunopsis.

Kobielus: Master data management (MDM) revolves around how you share, reuse and enable maximum interoperability of your core master reference data, your single version-of-truth information, which is maintained in data warehouses and various operational data stores, and so forth. Enterprise information integration (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.

Macehiter: The infrastructure could be common, but the information assets that you’re accessing will be in heterogeneous repositories accessed in a number of different ways. This is exactly what IBM is doing with its offerings around information-as-a-service, and BEA as well. It’s having the equivalent of application adapters by applying them to information assets and then exposing those through a service interface, so it’s virtualized and transparent: where the information is, how it’s stored and what format it’s in.

On the Need for Qualified SOA Architects

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 McKendrick: 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.

… 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.

Macehiter: 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.

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.

Gardner: This is going to be demanding. You can get Oracle-certified, you can get Microsoft-certified, IBM-certified. Where do you go to become SOA architect-certified?

Click here for more podcasts.