Edited transcript of BriefingsDirect[TM/SM] podcast with Dana Gardner, recorded June 5, 2007.
Listen to the podcast here. Sponsor: WSO2.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to a sponsored BriefingsDirect podcast. Today, a discussion about an energized entrant into the open-source Web services stack and Services Oriented Architecture (SOA) infrastructure field.
We’ll be talking to WSO2. They’ve been putting together a talented team with backing from Intel Capital to create a robust, lightweight and purely services- and standards-based stack and infrastructure offerings.
With us today to discuss their approach and philosophy to open-source and Web services support -- as well as a new product from WSO2 in the enterprise service bus (ESB) market -- is Paul Fremantle, vice president of technology at WSO2. Welcome to the show, Paul.
Paul Fremantle: Hi, Dana, nice to meet you.
Gardner: Glad you could be with us. Also joining us, a senior analyst from ZapThink, Ron Schmelzer. Welcome to the show, Ron.
Ron Schmelzer: Thank you for having me, Dana.
Gardner: Ron, you cover the field of SOA very closely. You’ve seen how both the commercial and open-source approaches have been churning over the past months and years. I wonder if we could just start the discussion with a level-set about open source and SOA.
I’ve been impressed with the fact that SOA is creating early-on an environment, in which open-source products are, in a sense, defining feature sets and approaches. In the past, we saw commercial products establish niches and define infrastructure areas that then became areas that open-source products might pursue.
Do you agree with that? Do you think that there is something new and different going on with open source and SOA?
Schmelzer: Well, there’s certainly a role for commercial software vendors, which are obviously having a huge impact on the space. It’s very hard to ignore what IBM, BEA, Microsoft, Oracle, Sun, SAP, and all those guys are doing in the space, as well as legions of smaller vendors and niche-focused vendors who are commercial.
One of the things that makes SOA different from CRM, ERP, or even traditional enterprise-application integration is that SOA is architecture. It’s a style, an approach, or a methodology for building loosely coupled, composable services that meet the needs of the businesses. So it doesn’t really demand a particular technology stack.
As a matter of fact, people can implement SOA using a very wide variety of technologies, which they probably already own. There are a lot of case studies on SOA for legacy and mainframe implementations.
So there is a significant role for open source to play in this market, given that one of the major roles that open source plays in general in IT is as an equalizing or commoditizing force for various technologies that have already made their way, and where people already understand the technology's capabilities or requirements. Open source has, to a certain extent, made that technology a lot more accessible.
Of course, the other part of open source is that it has rapidly accelerated the pace of software development through much more iterative, short-development cycles, [and] some large vendors simply can't keep up with that pace. So there is a certain role for that.
Gardner: SOA, by definition, is inclusive and supports heterogeneity, and those also are foundational notions for open source.
Let’s go to Paul Fremantle. First, give us a little bit of background for those listeners who aren't familiar with WSO2. Give us a quick rundown on the company. You’ve come from a background of standards development and a long heritage at IBM Research and product support. Tell us the story of WSO2.
Fremantle: Certainly. WSO2 was founded in August 2005. The three founders were myself, Sanjiva Weerawarana, and Davanum Srinivas. We’d all worked very much on the Web services stack.
Sanjiva was one of the leads on all the standards on Web services at IBM, and his name is on many of the documents.
I was one of the product development leads at IBM where I integrated the first SOAP support into the WebSphere platform. I built a key component of some of the WebSphere features known as the Web Services Invocation Framework, which was used heavily in the BPEL orchestrator and other parts of the stack, and which had a lot of influence on the SCA and JBI specifications. Also, I led the team that built IBM’s Web Services Gateway, and was one of the key members of the ESB development team there. So we had a very strong background.
The third partner, Davanum Srinivas, was in the CIO's office at Computer Associates and was very involved in Computer Associates' Web services stack. The other thing that tied us all together was that we all had a strong involvement at Apache Foundation.
Gardner: You’ve developed a philosophy of approaching this from a "pure" perspective. That’s to say, you don’t have a legacy to support or preserve. You’ve looked for a clean, simple, lightweight, REST-full approach, supporting AJAX-based Web applications. How did you switch from a commercial and proprietary mentality? And what drove you to this current philosophy that you’re supporting?
Fremantle: One of the things you see again and again in the computer industry is that people get to a point where they layer technologies on top of each other, and then it just gets too heavyweight. The benefits of reusing that old stuff are outweighed by the disadvantages. And the point at which that happens depends on the technology.
We were very involved in open standards and in writing and implementing the specifications, but many of those implementations were layered on top of the Java EE enterprise runtime. We found that there was a whole new middleware based on XML and self-describing messages based on simple HTTP communications that didn’t need the existing EJB/Servlet runtime -- that didn’t need to have all those existing layers.
So our philosophy when founding the company was to look at stuff afresh, and to build things with the simplest, most-lightweight combination possible. We tried to target users' requirements, rather than target an existing code base and legacy solution than we might have if we were working for a large company.
Our motivation was to do exactly what’s needed. There is a little synergy there with most open-source projects. Open-source projects tend to be small, componentized, and to try and solve specific needs. They work best when there is that lightweight aspect to them.
Gardner: Yet, at the same time, you’re being ambitious. You’re integrating widely with your stack, integrating to Microsoft .NET and the Windows Communications Foundation, formerly Indigo, with also full connectivity to the Java EE environment, even back to CICS, SAP, other Web services standards, and IBM WebSphere. It seems like you want to be neutral as well.
Fremantle: Certainly. This comes back to what Ron was just saying, which is that SOA is about working with everyone equally. It’s not about having a proprietary stack. As we talk about an ESB approach, you will see that one of our key tenets is that we’re not layering interoperability at the edges as adapters onto our stack, which is what you see a lot of people doing. We’re building interoperability into the heart of all our code. So naturally we want to have as wide an interoperability as possible.
We also think there is a critical mass here -- that we need to be ambitious. We need to cover not just the Java platform but also the C, Perl, and PHP -- the full gamut of platforms. SOA is not just a Java story. It’s really a cross-platform, cross-technology standard.
Gardner: Many of us are familiar with blogging and we know what can happen in the comments fields when we post things. I want to get this upfront right away. Many times when I blog around open source and SOA and how they relate to one another, there’s inevitably the comment about, "Well, how do you make a living at this? There are an awful lot of resources being devoted to something that is not your intellectual property."
Let’s go right to that and address your business model, and perhaps the role that systems integrators and support will play in how this is driven successfully into the market.
Fremantle: Absolutely. First, we’re a completely open-source company. We do everything under the Apache license. We don’t have any kind of "gotchas," different versions, relicensing and so forth. Our revenue stream is made out of our support to customers, selling support contracts, and providing a highly professional, enterprise-class support for both the Apache open source [Synapse ESB, for example] offerings and our own products.
Secondly, it’s made out of services and training, consultancy training, and custom development.
Finally, we also have partnerships, mostly with other technology companies who embed our technology and also with system integrators and ISVs who then use our technology to build solutions for their customers.
Having worked in a highly commercial proprietary software development shop, we know that support, services, and getting code that works is actually what really counts in the software industry.
Gardner: That’s the long-term play. You look to lose some revenues upfront on licensing, but [rely instead] on what’s going to sustain the company over time. It's that long tail, if you will, of support and maintenance.
Fremantle: Absolutely, and I see the software industry moving in this direction. What you used to see was that companies would put together a kind of magic package, which was intellectual property, plus support, plus training, plus everything. And somehow they’d value all of this at some astronomical figure.
You’d see middleware sales of multimillion dollars. What we’re saying is that the software industry can’t maintain those levels of cost. Better value, open-source software is the way to go. Obviously, open-source companies have to make money, both for our own livelihoods and also because the users of open source need that commercial infrastructure there to make sure this works for them in the long term.
Gardner: Another thing that you are taking advantage of is globalization. You have a distributed company. You’re taking advantage of development resources where they are, rather than where you’d like them to be, and you’re using Apache and open source as the governance over this development process. Tell us quickly a little bit about what that means in terms of efficiency and depth.
Fremantle: Well this is a very interesting story because we're a company that has offices in the U.S., here in Europe where I'm located, and also in Sri Lanka. These locations all actually came out of a growth of open-source developers in Sri Lanka. So in many ways I feel like I’m the outsourced guy because I’m the European offshoot for a bunch of smart developers based in Sri Lanka who are really driving the direction and the quality of this product. It’s not your traditional outsourcing operation at all, it’s very much globalization.
We found that the open-source model that Apache pioneered with open mailing lists, open-source code repositories, and free and open exchange of ideas on the mailing list, have shown us a way of operating a loosely coupled and distributed development team that actually works in practice. That means that I can participate in projects with people based in the U.S. and in Sri Lanka through that structure and process. That works just as effectively as when I used to work with my development team all located in the same office.
Gardner: We’ve mentioned how you are very ambitious in your scope. You’re looking for a full Web services stack. You’re producing an application server. You’re going to be introducing a mashup server. But today we’re going to focus on the ESB product that you’re going to be demonstrating and supporting for real in June.
Let’s go to Ron at ZapThink. Ron, the role and definition of ESB have been points of contention, and yet most folks that are pursuing the support of an SOA activities infrastructure market have some sort of an ESB approach. Why don’t you give us a level-set, if you could, on the state of the ESB market, why it’s essential for SOA development and maturity, and what you think is the proper functionality -- or perhaps your philosophy around ESBs?
Schmelzer: The place to start is that an ESB is actually not specifically necessary for an SOA. However, there are a lot of things that people require of their SOA infrastructure that a lot of vendors, who are pushing ESB products, are selling. The challenge of the market is that you can't really take any two ESB products, as you did J2EE application servers, and compare them to each other and see a very large overlap of functionality.
What you will find is that a lot of the ESB vendors are basically taking the infrastructure technology they had prior to the SOA wave and have applied Web-services technology or perhaps business process composition on top of that to run services, which is what people are looking for.
If I have a service, I need to be able to execute it reliably. I need to be able to secure it, manage it, govern it, and deal with the metadata. That’s what people really need from an SOA infrastructure -- all that capability. How do I reliably run, secure, and manage those services so that the loose coupling that I am looking for actually can exist?
To that extent, the ESB is really a catchphrase or a catchall for a wide variety of SOA infrastructures. If we look at the capabilities of the WSO2 ESB, it’s providing a lot of that SOA infrastructure capability. I don’t know if we’re ever going to get to a point in this industry where there will be a standardization of the ESB term. There are just too many forces in the industry that would basically try to own that term and not really make that happen.
Gardner: Let’s switch over to Paul again. You have described your offerings as middleware for Web services. In a sense, you’re starting from the perspective of this not being in a distributed-object environment, but more in an XML and semantic environment. Tell us what your requirements were as you started approaching this ESB project?
Fremantle: Actually it’s interesting listening to Ron, because what we were aiming to do was exactly what Ron says, which is not focus on what various players call their ESB technology, but instead on the requirements that someone needs for their SOA. Those are exactly the things that Ron talked about: managing your interactions, being able to turn on and off security and reliable messaging, being able to manage the quality of service that the message has as it flows across the network, being able to bridge between some mismatches, and managing connectivity.
For example, maybe I have a lightweight AJAX interface, but I already have a SOAP backend. How can I switch between that REST-like XML or HTTP interface and the SOAP interface? How can I switch between an existing JMS network and a .NET Windows Communication Foundation, SOAP reliable messaging, secure endpoint?
Then, finally, there's some level of transformation that often needs to go on the network, and that’s typically what we would call low-level transformation -- things like version management, switching namespaces on XML messages, or switching some XML formats.
Those are the kind of things that we saw a real need for. We took a kind of a different vision of what an ESB was from many of the vendors. A lot of the other vendors in the marketplace had some existing technology. They either had a JMS engine, and they said, "Okay, we’re going to rebrand our JMS engine as an ESB." They had a traditional message-oriented middleware product. Or in the case of JBI, they say well, "We’ve got a JVM. So, what’s the bus? It’s a JVM."
We took a much broader view to say that the bus is really all of your XML, HTTP, and JMS -- all of your communications -- and it encompasses a variety of clients and servers and different endpoints. So what do you need in that space? You need a very smart and simple mediator that can fit in, without disturbing those existing systems, and add those levels of management, connectivity, and virtualization that I was just talking about. That was really our plan and our approach to this space.
Gardner: What would the message be to developers? You’ve created a developer portal associated with your website for your company. As developers are scratching their heads and trying to determine what they want to do with SOA and how they want to produce services, what is it about your ESB that might be of interest to developers vis-à-vis some of the alternatives?
Fremantle: The first thing that’s of interest about our ESB to developers is that it’s very, very quick to get going. It’s the sort of thing that I think developers like. There is a 30MB download. You download it, you unzip it onto your hard drive, and you switch into the bin directory and start it up. You point your Web browser at it and you can start configuring and managing it straightaway.
The second thing is that it can add some instant value, even in a very simple scenario. Some things you can do very quickly. For example, you can interpose it as an HTTP proxy, so you don’t even have to recode any of your clients to start using it.
You can turn tracing on and off selectively. For example, perhaps you have a production environment and 99 percent of the time everything is working fine. But every once in a while you get an error and you need to help figure out what that problem is. You can have the system running, switch on trace, capture traces of the failure case, and then switch it off without having to bring anything down or redirect any messages, and so forth. You can instantly get some monitoring and management capabilities, without having to do much coding.
Finally, you can start to use it to do some of the things that are quite tricky. For example, one of the common cases that customers ask us for comes when they have an old Axis 1.x runtime, or a .NET 2.0 runtime. This runtime doesn’t support the latest WS-ReliableMessaging or WS-Security standards, and they need to enable that to talk to a partner. One of the things you can do very simply with the ESB is switch on those capabilities. So some of those capabilities that have a reputation for being complex are now just checkbox items with the ESB. Those are some things that I think would appeal to developers about this product.
Gardner: Do you expect that the arrival of this code under the Apache license, you’re calling it ESB 1.0, is going to be used by the developers primarily as a test-and-design environment, a learning experience that will then lead to operational use, or do you see this as an operational alternative as well, right from the get-go?
Fremantle: We really see this as an operational environment. Although this is a 1.0 product for us, the core runtime of this has been in development in Apache for about 18 months. We’ve done extensive performance tests on this engine. We're really, really pleased with the performance results.
For example, one of the things we’ve done is load it up with thousands of concurrent connections to simulate the scenario where you have a sudden spike and load that your backend can’t take care of. It doesn’t drop connections, even when you load it with thousands of concurrent TCP connections.
Similarly, we’ve done performance tests of how much overhead this adds to the path. For a standard 1K in, 1K out request-response message, you can add the ESB into that with an extra network hop now, and we add less than a third of a millisecond overhead.
We’ve done tests against one of the market-leader ESB products out there, and we’re twice as fast at doing XSLT processing. So we’ve really done a lot of heavy-duty testing on this. We think it’s up and ready for production use, despite the fact it’s just a 1.0 release.
Gardner: Ron, I suppose these days we’re seeing a lot more multiple ESBs in enterprise and hosting environments. Do you think we’re getting overcrowded now that we have another ESB? There are many other open-source ESBs: IONA/LogicBlaze CXF, MuleSource, and also Apache ServiceMix, and Apache ActiveMQ. For folks out there who are in this operational production environment, how do they start making sense of this?
Schmelzer: Well, I would say "vive la difference." It’s completely unreasonable to expect that an enterprise is ever going to be able to standardize on one technology stack for anything. We wouldn’t need SOA at all, if companies were truly homogenous. The reason why SOA has such appeal is because there’s this continued heterogeneity. Look at all the legacy mainframe technologies that exist. Part of the reason they exist is because they continue to provide value.
The fact that there are so many new technologies in the market, open source and commercial, providing value for runtime for SOA, goes to show that companies are still looking for best of breed. No two companies really have a similar environment, either a runtime execution environment or a distributed environment. Some companies are highly centralized and some companies have divisions distributed all over the world, and in parts of the world where bandwidth and processing power are still factors and budget is a factor.
In those environments we’re going to continue to see heterogeneity. A central organization might be able to invest in one kind of SOA infrastructure technology, but their branches, divisions, and departments may invest in something else. It's the power of SOA to abstract those differences so that they’re not so visible.
If there’s one thing that we can hope for from SOA it's that it really and truly enables that loose coupling, because if we’re going to continuously try to fight this battle of heterogeneity being a problem for IT, I don’t think we’ve really gotten anywhere with SOA.
Gardner: What now of loosely coupling, but across multiple ESBs? Is that going to require some way of federating among those ESBs or would it be an uber-ESB on top of them that you will use? What sort of scenarios do you expect?
Schmelzer: That’s a touchy subject. I believe the middleware-for-middleware approach is fundamentally the wrong approach. We’re seeing some companies saying, "Hey, put our ESB on top of your ESB," or "Let’s get some sort of magic integration middleware that basically integrates ESBs." That’s the old school, tightly coupled approach of managing heterogeneity.
I thought that the promise of Web services and SOA was that we could expose loosely coupled service interfaces, so that the infrastructure that runs those services doesn’t matter. The idea that you would need proprietary integration middleware to integrate other integration middleware is, in an SOA concept, a ludicrous thought. We should be able to architect our services so that the infrastructure matters less than it used to.
That being said, we do need infrastructure to run those services. Everything that WSO2 is doing is facilitating the running, execution, and, of course, management of intra-service communication, where you’re trying to manage some of that heterogeneity. A lot of stuff they were talking about in mediating protocols, and all that, is specifically to isolate services from having to worry about the runtime environment. Trying to overlay a heavy proprietary integration middleware stack on top of what is primarily another integration middleware stack is fueling the problem more than providing a solution.
Fremantle: Can I add something to that?
Gardner: Certainly.
Fremantle: I have to agree with Ron. I don’t think that the answer here is to have multiple proprietary ESBs and then some kind of uber-ESB between them. One of the things we tried to address, both in the Apache open source [Synapse] and in our own product, was making this product something that was really invisible to the rest of the world. You can almost think of our ESB as being a smart network router. You can have multiple versions of these around the network.
One thing we’ve done is to allow the ESB to run off of a set of metadata and configurations that’s remotely managed. It could be in a registry, it could be in an SVN repository, or it could be on a Website or a file system. Multiple brokers can fit in the network and communicate with each other, but they could also communicate with completely different systems.
This comes back to what I was saying earlier. To us, your ESB is the totality of all your different networking and service-oriented systems, whether they’re .NET, Axis 2, WSO2 application servers, or ESB nodes. It’s really about using open standards and open metadata -- things like WSDLs, XML schemas, URLs -- as your foundation of integration, which means that you don’t really end up with this problem of multiple ESBs that don’t communicate. You end up with a single fabric that’s completely based on standards, and you happen to have some useful management endpoints within that fabric.
Gardner: Both you and Ron have mentioned that word "management," and we discussed earlier how you have a lot of ambition in terms of the scope of your development activities. Yet you’re also very interested in partnering, as I understand it, and that would include areas for management, and registry/repository. Can you give us a little bit of your philosophy about how this fabric would work, using both your approach as a fairly robust and complete stack, and also partnering with other componentry?
Fremantle: Absolutely. First, we have built internal registry and repository into the ESB, but it’s our first step in this and what we’ve built in is a pluggable interface that allows us to talk to other registries and repositories out in the network. Because we work off a lot of those standard metadata types, such as Web service policy documents, Web service description language documents, HTTPs, URLs and so forth, we can really work in a very open manner.
At the moment, the kind of interface we use to talk to our remote registry is just an HTTP interface, but there is no reason why, if we get the demand, we wouldn’t write to an UDDI interface. It's just that none of our customers have asked us for that today.
We also see the Web service management and governance space as becoming very important here. At the moment, in the Web service management space there's a bit of a problem, which is that there are two competing standards. There's been some work to merge them, but that hasn’t been completed yet.
So, what we offer in our ESB is some simple, so-called REST-based interfaces to get at management information that customers can utilize in the same SOA manner that they utilized in the other services to help manage and monitor their service interactions.
As the Web services management standards start to tighten up a bit, we certainly expect to partner with other companies who provide WS-Management consoles to allow people to manage their network through our interfaces.
We also offer a very lightweight AJAX-based GUI that comes with the product, and which allows you to monitor, manage, and control your service interactions across the network.
Because all of our code is built on these open standards and open interfaces, once again this a heterogeneous story. This is the beauty of open sources. Although as a company, WSO2 is trying to provide to our customers the most useful components that we see, those components naturally and inherently interoperate with other vendors' software, other open-source projects, and other components.
Gardner: Given this flexible use-it-in-many-ways and enter-the-market-in-many-ways approach, I wonder if we could look a little higher up from a business abstraction point of view. What will systems integrators look to as they pick best of breed, and as they pick a stack, and as they factor how to manage what’s on-site in the organizations they’re working with?
I suspect that you want to be a very good partner to these integrators, as they inject SOA activities into the way that they produce code, services, and applications -- and then also take that into the enterprises that they’re working with.
How do you see this whole systems integrator movement toward SOA shaking out, and how do you make yourselves appealing to them?
Schmelzer: SOA offers an interesting opportunity for systems integrators. They formed a large part of their business, at least in the late 1990s and early part of this decade, doing a lot of the heavy lifting of integration, actually making systems work together, facilitating the systems, implementing enterprise applications, and things like that. SOA gives these folks more of an opportunity to focus on the business than they had before and provide a higher margin of services around business process.
[SOA] allows these system integrators to focus on things like building shared services and business services that reflect the business needs, and focus on governance, policy, and enterprise architecture, which is a missing skill set for most enterprises.
Actually this gives systems integrators a good opportunity to let the opportunity of focusing on the business exceed the opportunity of focusing just on implementation and infrastructure, which is migrating overseas anyway. So there are some unique opportunities here for systems integrators with regard to SOA.
Gardner: How about that, Paul? Throwing more warm bodies at the problem probably wasn’t a good idea to begin with. Now you can’t even get the warm bodies in many cases. The goal should be to work smart not hard, I suppose. How do you take that message to the integrators?
Fremantle: We’ve had a lot of interest from system integrators. We formed some partnerships with some of them, and we’re ongoing with that process. What we found attractive to system integrators is that they now are looking much more for simple, lightweight components that work straight out of the box -- rather than large complex solutions.
Part of that is exactly what Ron’s talking about. These guys haven’t got huge amounts of time, so they need something that they can get on with and be productive with instantly. That’s the first thing.
The second thing that system integrators look for is extensibility and flexibility. One of the things system integrators want to do is to add value over the core products or components that they find. We’ve been very careful with the ESB and also in the Apache projects that we work on to create the right plug points.
It’s very simple to extend our ESB just using simple scripting language. For example, you can use JavaScript, Groovy, and Ruby -- those sorts of languages. If you use Ruby or JavaScript, there are native XML language constructs that are called REXML and E4X that you can use inside your code to do really simple, high-quality XML transformations or manipulations. That’s the first level of integration.
The second level is to jump into Java and actually write Java classes. That can be very productive and a way that you can extend the ESB with custom functions.
Then there's actually a third level of that. You can write your own plug-in to our XML configuration language. So you can effectively take your component and raise it up to be a first-class part of the ESB and its configuration model. That means now there can be a third-party set of add-ons to the ESB that start to add value.
We see those two things as being very attractive to the system integrators. First, ease of use -- get it started quickly -- and second gain the ability to extend it, to add extra value, and to build up a catalog of reusable components that makes their jobs easier.
Gardner: I would think that those same attributes would be of interest to companies that want to position themselves within an ecology or some sort of a supply chain, where they’re creating services that will be consumed among partners. Therefore, those same attributes that would be of interest to a systems integrator would be appealing to those enterprises that are seeking a role other than just creating their own applications and services, but rather to become a center of gravity for a larger business process or ecology.
Fremantle: Absolutely.
Gardner: We’re about out of time. This has been a very interesting discussion. We’ve been talking about the advent of new open-source products and code being orchestrated by WSO2. We’ve been talking with Paul Fremantle, the vice president of technology at WSO2. Thank you for your time, Paul. It was very engaging.
Fremantle: Thank you, Dana. It has been a great conversation and it has been a pleasure talking to you.
Gardner: We’ve also been joined by Ron Schmelzer, a senior analyst at ZapThink. We appreciate your insights, Ron.
Schmelzer: Glad to be here. Thank you for having me.
Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You’ve been listening to a sponsored BriefingsDirect podcast on WSO2, open source, SOA, and the arrival of the WSO2 ESB 1.0 product in June 2007. Thanks for joining us.
Listen to the podcast here. Sponsor: WSO2.
Transcript of Dana Gardner’s BriefingsDirect podcast on open source Web services stacks and WSO2's latest ESB. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Thursday, June 14, 2007
Friday, June 08, 2007
BriefingsDirect SOA Insights Analysts on Defining the New Role of 'SOA Architect'
Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition podcast, recorded March 23, 2007.
Listen to the podcast here. If you'd like to learn more about BriefingsDirect B2B informational podcasts, or to become a sponsor of this or other B2B podcasts, contact Interarbor Solutions at 603-528-2435.
Dana Gardner: Hello and welcome to the latest BriefingsDirect SOA Insights Edition, Vol. 15. This is a weekly discussion and dissection of service-oriented architecture (SOA) related news and events with a panel of industry analysts and guests. I'm your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions, ZDNet software strategies blogger and Redmond Developer News Magazine columnist.
Our panel this week consists of Jim Kobielus. He’s a principal analyst at Current Analysis. Welcome to the show, Jim.
Jim Kobielus: Hi, Dana. Hi, everybody.
Gardner: Also joining us from the U.K., Neil Macehiter. He's a research director at Macehiter Ward-Dutton. Welcome, Neil.
Neil Macehiter: Hi, Dana. Hi, everyone.
Gardner: Also joining us today we have Steve Nunn. He's the vice president and COO of The Open Group. Welcome to the show, Steve.
Steve Nunn: Thanks very much, Dana, and good morning, everyone.
Gardner: Also joining us is John Bell, an enterprise architect at Marriott International. Hello, John.
John Bell: Hello.
Gardner: We're going to be discussing the role and concept of what’s becoming defined as the "SOA Architect." This is a different role, as we’re finding out, than the enterprise architect, but certainly seems to be part of an evolution of the role of architect within the enterprise and within IT in general.
We’ve invited a representative from The Open Group, in this case Steve Nunn, to join us, because The Open Group has taken some steps to try to define the role of the SOA architect, has created some certification around that role, and is trying to get in front of this role in terms of what will be required in the marketplace. That is, to try to encourage more people to step up and understand this role and to certify themselves, so that the progress and maturity of SOA practices can continue and not face a human resources crunch.
So, with that, why don’t we hand it off to you, Steve? Why don’t you tell us a little bit more about what The Open Group is doing and why?
Nunn: Thanks, Dana. The Open Group and its members have been working in the architecture space for over a decade now, primarily developing something called The Open Group Architecture Framework (TOGAF), but, as you’ve mentioned, we're running certification programs in two specific areas. One is in relation to TOGAF, but perhaps more relevant to this discussion is our IT Architect Certification (ITAC) program.
I guess that sets a caveat at the outset. The terminology around what type of architect it might be -- IT architect, enterprise architect, SOA architect -- is still very much settling down as a topic of debate in its own right, but our program that I can talk about is the IT Architect Certification Program, which is a broad skills- and experience-based program. It's aimed at creating a vendor-neutral program by which individuals can be certified. It provides them with a transferable qualification in the industry, and it enables employers to know that if they prefer recruiting certified individuals, they would be getting somebody who has been through an accreditation process.
Briefly, the process would be that a resume is compiled, which can be quite extensive, up to 52 pages in some cases.
Gardner: Wow!
Nunn: Yeah and then there’s a peer review by a panel of three certified architects themselves who would probe a little on the resume, ask questions of the candidate, and conclude whether or not that individual meets the conformance requirements.
Gardner: Is this process already up and running, or is it something you're still pulling together in terms of how you want to approach it?
Nunn: No, this is up and running. We launched this in July 2005, and as of today, we have just a shade under 2,000 individuals from all sorts of companies and all over the world who are certified under this program.
Gardner: This is the SOA Architect Certification?
Nunn: This is actually what we call ITAC, the IT Architect Certification.
Gardner: I see.
Nunn: It has several levels and covers various disciplines. The SOA-specific part of it is one that we are still working on. We have various horizontal levels under this program. The conformance requirements for meeting those levels have been agreed upon. There’s an entry level and a higher level. We are working on the highest level right now, but what’s also going on is work on the individual aspects of that certification, of which SOA is one. What we’re quite proud of in this program is the conformance requirements for the overall program, and what we're now focusing on are the conformance requirements for the individual disciplines.
Gardner: Perhaps this is a good time to go around the room, so to speak, and see if we’re in some agreement that an SOA architect is fundamentally different from an enterprise architect and why? Why don’t we start with you Jim Kobielus. Do you see these as significantly different roles?
Kobielus: Not really. You have to be an IT architect to be an SOA architect. It seems to me that an SOA architect, or that discipline, is a subset of the overall enterprise architect. I would like to know precisely what other disciplines or practices that one needs to be certified in to be a SOA architect, versus just an overall enterprise architect, I’m still unclear on that.
Gardner: When we hand it back to you, Steve, one of the helpful concepts for me in understanding this was the notion of the "city planner" or "town planner" role. The analogy is that an SOA architect needs to like a city planner, looking at all the resources and infrastructure and how the entire community comes together, managing constituencies and political relationships, whereas an IT architect might have a smaller role. Can you expand on that a little bit?
Bell: Actually, an enterprise architect from my perspective would have the view of the town planner. When they’re looking at the entire city, they're looking at how the various neighborhoods, how the various business zones, etc., fit into that city. The SOA architect, from my point of view, is really more interested in, "Hey, how does that underlying infrastructure allow different neighborhoods to communicate with each other and exchange messages? How are health services delivered across neighborhoods?"
So, it’s more interested in, "Okay, I’ve got a firehouse. Can the fire truck get to the house before it burns down?" The vision of the SOA architect is more associated with the communications pieces within the community.
Gardner: So, the hierarchy might be that the enterprise architect is in the town planner role, the more holistic, oversight uber-architect role, and then a subset of that is making sure that the communication channels between and among these different facets of resources and functionality are behaving well and conforming to what needs to happen.
Bell: Conforming to the standards so that they’ve got a consistent set of standards for exchanging information, those kinds of things.
Gardner: Okay. Neil Macehiter, what you make of this?
Macehiter: In that that classification of the difference between enterprise architecture and the SOA architect, it sounds to me that the premise is that the SOA architect is focused primarily on the plumbing. From a bottom-up perspective, the challenge that many SOA architects face is more around understanding what the services are that need to be delivered in a business-meaningful way, not just about communication and plumbing. It’s also about understanding the high-level, business-meaningful services.
There is a business strategy, there are business processes and priorities, and there are the services we need at a business level. Then, there's a handoff to what’s currently defined as the SOA architect, who will actually define how those services are deployed in technology terms. So, the distinction is quite blurred. A service-oriented approach is one of the methodologies and the approaches that you can utilize to deliver or to support an enterprise architecture initiative. So, I still find a distinction difficult.
Kobielus: I second what Neil’s saying. I’m uncomfortable with just reducing SOA to the plumbing. In the three-layer stack that I carry in my head, the plumbing level is the enterprise service bus, and then SOA refers to development and reuse practices within the development organization to enable maximum sharing and reuse. Then, there’s the layer above that, which is the applications, services and data -- the business processes.
I’ll put enterprise architecture at that very top layer, concerned with the end-to-end set of resources: app services, data, etc. The SOA architect would be the middle layer of the development and reusing. The layer below that, the enterprise service bus (ESB) or whatever, I call that "IT architect" in the sense that it's the infrastructure architect.
Bell: And to be fair, I didn’t mean to imply that the SOA was limited to the plumbing. My intent was saying that the enterprise architect has a much broader spectrum and scope that they have to deal with than your SOA architect has to deal with. Putting it into that city paradigm, you kind of limit it as to how to describe some of the roles. I try to clarify that by saying it’s not just how they communicate, it’s things like, "Hey, where’s the fire station? Do you have a fire station? Where’s your police station? Where are your schools? Where are all those pieces that are providing services to that community and are they adequate for providing the services to their community?" That’s a subset of what a city planner has to do but it’s still an important city-planning kind of function.
Gardner: John, you’re in the trenches, you’re an enterprise architect in a large global concern. How do you see this hierarchy and is this really the right discussion that we’re having?
Bell: My view is that the enterprise architect is at the top of the hierarchy, and at some place, working with the enterprise architect is an SOA architect, and their focus is on, "What are the services that are being delivered, how am I delivering them? What’s the infrastructure I am using to deliver it? Do I need – using that town model -- a police station? Do I need a fire station? Do I need a school? Do I need a museum? And, if I do, how do I get that service out to the community or to the entire city, not just an individual neighborhood?"
So, from my perspective, using a city planner paradigm, the role of the SOA architect, is identifying what are the services that need to be available to the city and how to deliver those services out to the city.
Gardner: Back to you, Steve Nunn. It seems to me that there needs to be a fair amount of flexibility, enterprise by enterprise, and circumstance by circumstance, as to how this SOA architect role pans out. How much standardization and methodological consistency can we bring to something that, in fact, will probably be dealing with huge variability from organization to organization?
Nunn: Something that we’ve had to address in putting the program together is that there are huge differences. Even taking the frameworks that might be used in implementing an enterprise architecture, there are huge differences among organizations. Some organizations are required to use a certain framework. Our approach is not to specify exactly how enterprise architecture or SOA architecture is done in the certification program, but more about the experience of the individual who's implementing it.
It doesn’t seek to define a particular way of implementing the architecture, but is more about the skills and experience of the individuals who are playing that role inside an organization. They could be part of a team in larger organizations, or could be one person in a much smaller organization who is playing this role. The whole idea of raising the value of the architects of various titles in the organization is what we are seeking to achieve with our efforts in the certification program. It’s about raising the standards of that role, and getting people to understand that it’s a valuable role and, apart from anything else, it should be compensated as such.
Macehiter: Dana, could I chip in with a quick question there?
Gardner: Certainly.
Macehiter: It’s about the approach and the experience, rather than framework, and I agree completely with that. Given that the SOA discipline is currently within the IT architect certification, to what extent do you look at the approach and experience in terms of the interface to the business, business understanding, or collaboration with the business? I think that key elements of the SOA architect role are skill and capability, as well as the more IT-oriented skills and capabilities.
Nunn: Well, that's not so different between SOA and enterprise architecture. I’d say exactly the same about the enterprise architect -- that ability to translate the business need into the systems underlying or delivering the needs of the business. It’s something the enterprise architect absolutely needs to have, and that’s why we think there’s a special set of individuals who play this role. So, there isn’t really a difference in that respect between the SOA architect and the enterprise architect.
Kobielus: I like what you do. Thinking about the whole notion of certification, there are two ways to go about it. One approach that you can easily take -- and this is the way it’s usually perceived -- is when you are certifying a CPA, you’re certifying somebody as a skilled in an established and knowledgeful body of practice, be it law, medicine, whatever. But when there’s no consensus body of practice that everybody agrees upon -- for example SOA, which is still evolving -- a certification in that regard is more like when somebody is applying to college. You’ve got to send in your transcripts, write essays, and you also might have to go and do an interview in the admissions office. They look you over and say, "Oh, this is a smart person. Yeah."
So, they consider the sum total of everything you’ve done and who you are in certifying that. They say, "Yes, you’re good enough to be admitted into this college," and then proceed from there. That’s sounds like what you’re doing. You’re certifying the competency of a particular individual in this general field called a enterprise architect (EA) or a SOA architecture.
Nunn: That’s right, Jim, and it’s not a bad analogy at all. It's about assessing the individual. It’s a relatively young discipline in its own right. One of the things that we look at in a conformance requirement is the role that those individuals have played in the projects that they have been involved in, and whether they had been in a lead role or support role, or a combination of the two, but it certainly is about the individual, rather than the specific approach that they take or any particular body of knowledge.
Macehiter: Just one other quick comment on this, if I may. The other dimension for this, I think, is rather than thinking about the role, thinking about SOA as an approach. Then, thinking about how that approach applies to different types of architect. What I mean by this is that a lot of the emphasis and focus on SOA today has been around application development and integration, when, in fact, there’s a broader perspective that really extends across more traditional IT architecture and other disciplines, for example, a service-oriented approach to infrastructure architecture and the service-oriented approach to the operations and operational management of IT.
So, there are two dimensions that a body such as The Open Group might want to think about. One is the role of a service-oriented architect, and the second is how service orientation impacts other architecture disciplines and other IT functions or operation capabilities. If we don’t do that, we risk driving SOA into a particular stovepipe focused on application development and integration, and aren't thinking about it more broadly as an approach that it is an enabler of whatever the enterprise architects are driving out.
Gardner: Thanks, Neil. I suppose, too, that the role of the SOA architect will shift, as the maturity of SOA principles and methods evolves inside of an organization. They might have to start out a bit more focused on application development and deployment issues, move up toward being mindful of the business issues, and then move up more toward being the communications conduit between the fire house and the police station, for example. Does that make sense?
Macehiter: Absolutely. It’s about gradually extending through the life cycle.
Gardner: One of the reasons we are discussing this is that we’ve seen some warnings from analysts and others saying that we are moving toward SOA, but we really might find ourselves without the people with the background and abilities to move this. So, we’re worried a little bit about a dearth of qualified people, which might, in fact, stifle the progress here for SOA.
Do you see that is the case, Steve Nunn? Do you have any sense of numbers and what the demand is going to be? The second part of the question is, if there aren’t enough people, aren’t these roles going to fall upon the enterprise architect anyway?
Nunn: Dana, what we’re hearing is there aren’t enough enterprise architects to start with. So, I think it’s a given, therefore, that the SOA specialists are in short supply too. We’re hearing from our members that if they spot a good enterprise architect or somebody they think has potential for that, then they try and grab them. They’re pretty few and far between right now in terms of folks with experience.
Obviously, there are other folks that we just talked about with the college analogy who might well be groomed into that role in the future. So, certainly there is a shortage right now. That's what we are hearing from our membership. I don’t have specifics on numbers, but the message we hear is that demand is out-stripping supply right now.
Macehiter: This is not new. We’ve been through this with every major technology advance or discipline advance. You used the word "potential" there. I think there are individuals within organizations that have the potential to fulfill that role. Part of the benefit of this certification approach, providing conformance and definitions of what constitutes the role, is that it will help organizations identify the individuals within that company that have that potential, even if they don’t have the 50-page resume that demonstrates that they have been there and done it, because the key element in a service-oriented approach, and an enterprise architect more broadly, is an understanding of the business.
If you’ve got individuals within the organization that understand how the business works, have been around, and know the right individuals to talk to, that that can be of much benefit in terms of enabling effective EA and SOA, as can be going outside, finding someone from a different vertical market or different industry, and bringing them in because they’ve done six SOA projects elsewhere.
Gardner: Thanks Neil. Let’s take that point back to John Bell. Now, as an enterprise architect with Marriott International, I assume that you’re going to be in the position of having to hire or find SOA architects in this climate of scarcity. Where do you think these people will come from and what kind of backgrounds would you look for?
Bell: I think what we are going to have to do -- fortunately or unfortunately, however you look at it -- is end up training our own people. A lot of it goes back to what was just said about having to have an understanding of the business. You have to know the people in the business. You have to understand what the business of the business is. You have to have a lot of domain knowledge in order to create an effective SOA environment.
Because of that, when you pull somebody from outside, they may understand the technology, but they have to come up and learn the business, which is harder to train than somebody who has a general technology background, but knows the business pretty well, because he has been working in the business. Marriott happens to be a company that retains employees for years and years on end. So, in our IT department we have people who may already have 5, 10, 15 years of experience working directly in the business. And we can’t afford to lose that.
Gardner: Do you find that a developer is a fast-track path to SOA architect or a business analyst, even though it makes great sense to have someone with longevity in your organization? Is there particular type of role that they would have played that seems to conform to this need for SOA process management and evangelism?
Bell: In our experience, we are finding developers, as they move through their technology career path, since they have been developing within the context of the business, if they take that broader view, they understand the basis for the SOA architecture that’s installed in this particular company. They tend to make a good SOA architects with the proper training, and sometimes that training isn’t the technology training; it’s the people training -- teaching them how to conduct interviews, how to talk to people, how to get information from people, particularly in a company like Marriott where the business is not technically oriented.
Kobielus: This is all very good, but it doesn’t address the need that many companies have which is, "Hey, we need to hire people straight out of college who have some background in architecture, and where are we going to find these people and how are they going to get certified?"
Everything I'm hearing says that, an EA or a SOA architect is somebody who has experience and, by definition, somebody right out of college doesn’t have experience. So, is this the kind of thing that we can actually train in school or does somebody have to be in their career for 5, 10, 15 years before they’ve been steeped enough in all of this architectural infrastructural development and integration stuff to the point where they can be certified?
Bell: I’m also an adjunct faculty member at Towson State University, and this is an issue that we’re dealing with at the university level so that the university can provide the skills that the local businesses in the Baltimore area need. So, at the graduate school level, we are looking at what we offer in the way of architecture courses that take architecture from an enterprise or SOA perspective, so that we can enable our students who are finishing graduate school to be more and better prepared as they enter their new job market.
Gardner: These are excellent points. Steve, you and I discussed, when we spoke about some of these issues a month or so ago, that you were also trying to encourage universities to create the curriculum and the definition of these jobs. Can you fill in our listeners a little bit on what you’ve seen?
Nunn: That’s right, Dana. Something The Open Group launched at the end of January this year was the Association of Open Group Enterprise Architects (AOGEA), which really is -- the analogy here is the one somebody used earlier with attorneys or CPAs -- to do for enterprise architects what the Bar Association, for example, would do for attorneys, all joking aside. I think one of the things that we’re trying to do is partner with various types of organization in creating this community and this professional association.
One of those groups is the academic community, so we are putting out feelers to various universities to explore the possibility of getting enterprise architecture on the curriculum. There is one university that we are aware of where there is actually a TOGAF module in some of their courses. Obviously, changing a curriculum is a multi-year project, or multi-year plan. It’s not going to happen overnight, but in the interim, one of the categories of membership for the association is students.
So, those who are on a course of some description inside the university or even working in a job and doing part-time study, can join the association, be part of the community, get the information that’s available there, be on the news groups, maybe take part in the local chapter, or whatever they want to do to start building up some experience.
I had somebody come up to me a couple of weeks ago, after a talk I gave, and said, "This is exactly what I’ve been looking for, because in my organization I’m quite junior and the people above me really aren’t that interested in enterprise architecture, and certainly not SOA, but they won’t listen to me because I’m too junior. So, I need to get some experience or immerse myself in this field. Some kind of virtual community that allows people to do that is going to be a great help to me."
So, that’s one of the thing we’re trying to do. There are various membership categories, and student is just one of those.
Gardner: Now, it does seem that we have a climate of opportunity here. There’s the track for developer to move above that role and embrace more business understanding in domain expertise, and that would be a track. We’re looking at more universities preparing people for these types of roles. We’re probably going to find, again, variety within organizations in terms of business analysts or non-tech people coming into this role, because it requires influencing and consensus building, and so forth.
Usually, in markets, when there’s opportunity and there’s scarcity -- and these are probably well-paying jobs -- we would expect for the supply and demand to even out at some point. For those in the field like yourself, John Bell, am I overly optimistic that this supply and demand is going to mesh, or are we looking at something a bit more serious in terms of the next three to five years where there’s going to be a serious deficit of talent?
Bell: I think that the supply and demand will eventually mesh, but there may be a gap in the next year or two. I don’t know if it will carry out for three to five years.
Gardner: Well, thank you very much. Let’s move on to our next subject of the day.
In March an announcement came from the consortium of large IT vendors including SAP, IBM, Oracle, BEA, and Cisco. They have formed a series of proposed standards, the Service Component Architecture (SCA) specification and the Service Data Objects (SDO) spec. We are not quite at the standards level, but that seems to be the goal, to take this approach through OASIS, which is the organization that’s overseeing the Web services specifications and standards, WSDL, UDDI and SOAP and so forth and all the WS-* specifications.
It seems that the vendors have stepped up and said, "Listen, we need a level of standardization. We are going to do some heavy lifting, create some specifications, and then we are going to hand them off to the standard organization." This strikes me as an important juncture in the maturity and real-world applicability of SOA, and I wanted to test that hypothesis on Jim Kobielus.
Kobielus: Yeah, it’s very important. It’s clear that the SOA paradigm requires ever more high-level abstractions to enable easy development of very complex, orchestrated, end-to-end services. The SCA and SDO specifications – the initiative has been being going on for a couple of years – have come a long way and they’ve got pretty significant support throughout the industry. Microsoft is one of the few important holdouts. It's not only the high-level abstraction for developing competence services, but also, especially, in my area, the SDO, the high-level abstraction for working with heterogeneous data. I see the SDO, in itself, becoming potentially the standard industry framework for what’s called the semantic layer for any data integration.
So, I’m very keen on the potential for SDO, for example, within the business intelligence space, the data warehousing, and the enterprise, information, integration space. The fact that now OASIS will be taking over ongoing development of SDO, puts it on a very important fast track. Hopefully, we’ll get some of the business intelligence (BI) vendors like Business Objects and Cognos behind it. That’s one of my fond hopes.
Gardner: Jim, you’re tracking the data management side on this quite deeply. Do you think that SDO has the potential to become the ODBC/JDBC of SOA in terms of what those things enabled and empowered for distributed architecture?
Kobielus: It’s quite likely, because it’s leveraging the whole WS-* stack and the whole notion of semantic web that’s been kicking around for long time. Tim Berners-Lee keeps this going. It’s really a utopia of interoperability, where the semantic layer is the resource description layer for describing metadata. If you look at the so called semantic web’s specifications like OWL, RDF and a few others, they have not achieved takeoff velocity in the data management world. I can count on one hand the number of the BI or data warehousing vendors that are implementing OWL, for example. The semantic web has not really gotten any traction with standards or specifications where it counts.
With SDO, I still don’t see significant traction yet in the whole BI space, but the fact is that every BI vendor is SOA-focused and enabled and getting ever more so. That’s one of the clear gaps I’ve been seeing in the whole enterprise information integration (EII) side of it all in terms of distributed master data management (MDM). Every vendor, including Business Objects and the others, have their own semantic layer. That’s what Business Objects calls it.
As yet, there is no federated semantic layer specifications, but customers are asking for federation of say, Business Objects, Teradata, Microsoft, Oracle, and I believe that at some point BI and EII will converge around a common set of standards. I’m getting further and deeper into SDO, and it really looks like this is a strong potential framework for them all to work together going forward.
Gardner: A framework for a common and federated metadata approach, is it not?
Kobielus: Yeah, exactly.
Gardner: Now, the politics here struck me as a little bit interesting. Ed Cobb of BEA, who was on the call describing the movement of these specifications to OASIS, said that he hopes that this does for SOA what J2EE did for n-tier in distributed computing, which is to create a climate of growth with application server vendors coming together and ISVs building applications that take advantage of these. That sort of exploded during the mid- and late-1990s into what is now a predominant architecture for enterprise applications, as well as large Web commerce and online commerce types of applications.
Neil Macehiter, what do you make of the politics here? If J2EE did for distributed computing what they hope this does for SOA, why aren't SDO and SCA going into the Java process?
Macehiter: You've hit the nail on the head there. I think there are a couple of issues here. First is, if it went into the Java Community Process (JCP), you’re talking about SOA based on purely Java. As my colleague put it at the time, it’s like a three-legged dog running in a race. If you’ve only got Java, then you’re not really addressing one of the core propositions of SOA -- that it is about heterogeneous interoperability, with services based on multiple languages.
Gardner: What happened to "write once, run anywhere?" Wasn’t that heterogeneity and interoperability?
Macehiter: One programming language, and that’s the distinction. The SCA and the SDO are multi-program, multi-language.
Gardner: So, an abstraction above Java their pointers will make sense?
Macehiter: Yeah. Actually, the second point is that, in part, the creation of SCA and SDO was motivated by the frustration with the J2EE process. Enterprise JavaBeans (EJBs) and things like that never really took off. Some of the lightweight programming frameworks, Spring and Hibernate, were just taking great chunks out of J2EE in terms of deployment.
Then there was a significant amount of discontent among the Java community around the support for Web services, which is clearly one of the key enablers of SOA. Those three things, plus what Microsoft was doing with the Windows Communication Foundation (WCF), and the work they’ve been doing around it, caused the big J2EE players to think, "Well, actually we need to do something different." That was the motivation.
Gardner: I suppose it’s water over the dam at this point, but perhaps if the J2EE and a variety of Java framework specifications had moved into a standards organization like OASIS five years ago or so, the SOA specifications and the Java specifications could find themselves in the same organization. That seems now not to be the case.
On the other hand, if Microsoft has been the holdout in terms of embracing SDO and SCA, and is focusing more on .NET Framework -- but OASIS was a place where Microsoft felt comfortable going when it came to working with folks like IBM on the Web services standards -- do you think that this might move the hearts and minds of Redmond, Washington toward a bit more SOA compatibility and the programmatic approach to SOA, rather than just the interoperability approach?
Macehiter: My gut feeling is "no." And the reason is that Microsoft has collaborated with the likes of IBM, BEA and others, its historical competitors, up to a certain level up the stack. But the level at which SCA and SDO are operating is at the level where Microsoft has a massive investment, and a significant proportion of its business has been driven out of this at the programming model level.
So, I think it would take a lot for Microsoft to move to support SCA and SDO within the composition framework that they have, which is fundamentally around Visual Studio. Whether we are talking about BizTalk or Sharepoint or Office, it’s all around that programming model, which is tied into WCF and Windows Workflow Foundation. So, I just think the battle line is drawn at that level.
Gardner: What we are facing is perhaps an important decision within enterprises and service providers, software-as-a-service (SaaS) providers, and ISVs as to which role you perceive for .NET playing in Microsoft’s tools and process runtimes. Are they a subset of SOA, or are they in fact the master -- and the rest of the SOA componentry is the slave?
That would be one way of looking at it. The other would be that .NET should be just another spoke in the hub of all SOAs. Jim Kobielus, do you think we are going to be facing this sort of a face-off between the role of Microsoft as the hub or the spoke?
Kobielus: I think Microsoft has gotten much more open to being just one spoke. But I wouldn't use the hub vs. spoke analogy here. They’ve become more comfortable with the notion that they’re just one node in a vast mesh on the Internet in terms of Web services and SOA. So I don’t see Microsoft in face-off mode in the SOA world, or where SCA or SDO are concerned. A couple of years ago it might have been different, but it has changed.
Gardner: How about in terms of the role of their communications, their ESB, WCF (the former Indigo) and the role of BizTalk? It seems as if they are happy to be a spoke on one level, but they’d also like to be where business process is coded and logic is instantiated, and therefore become "the place" where SOA is driven, the dashboard from which SOA is driven.
Kobielus: Well, pretty much every BPM vendor wants to be that hub, that business-process hub, and Microsoft is not alone. Companies like TIBCO with ActiveMatrix, are interesting, because basically what it is doing is it is virtualizing the app server or the integration server, so you can run your .NET logic and your J2EE logic, and so forth in different containers on the same platform. That kind of architecture is more where the industry is going. In that case, TIBCO necessarily isn’t trying to be the one and only integration and logic hub out there. It is simply trying to be the hub of all hubs, but one of the hub of many hubs federated to each other.
Gardner: Is it that you don’t agree with Neil then, that if Microsoft is a bit more ecumenical on this, would we expect them to embrace SCA and SDO? Is that what you expect?
Kobielus: It’s a relative thing -- getting ecumenical. They get ecumenical when they are good and ready, like they’re doing right now in the identity space, with this whole notion of user-centric identities. It’s taken them a couple of years of sitting back, watching things like OpenID and Higgins develop. And then finally they make a token offering that says, “Okay, we’ll implement OpenID in the next generation of the Vista Card Space."
And, once again, my sense is they’re going to wait quite a period of time, at least a year, before they make any public pronouncements on the extent to which they are going to work with OASIS on SCA and SDO. It’s just their nature, and they are going to pursue their proprietary approach, as long as it holds out, and as long anybody will implement it.
Macehiter: I’m not suggesting that this a face-off. What I am suggesting really is that it comes down to the point of control that an organization or vendor has. Microsoft does not want to be denigrated to the plumbing, even if that’s interoperable plumbing. The point you raised about TIBCO with ActiveMatrix is that it’s actually using the SCA programming model in order to provide this abstraction.
So, ultimately in that environment who’s controlling it? TIBCO is becoming the master, and it will be the same in an IBM environment. SCA may be under the hood, but ultimately there will be a point of control that IBM wants to wrest for its process server for its development tools, and that’s what Microsoft wants to do. The challenge is that SCA and SDO are trying to do the same thing as Windows Communication Foundation and Microsoft tooling around .NET and SOA.
Gardner: To wrap up, it seems that it's not a face-off, but perhaps there are, as Jim points out, a lot of vendors who would like to be that over uber-dashboard, point of control. Some are BPEL-focused and others are taking different tacks. SCA seems to be playing a role for many of them, and Microsoft would like to play that role as well -- but perhaps thinks that it has an advantage through the way it’s architected up to this point. The market will, I suppose, determine who the ultimate winner is.
Macehiter: I think a lot will depend how quickly the tooling comes out around SCA and SDO, as an alternative to Visual Studio.
Bell: The other piece too is, as Microsoft tends to build those kinds of capabilities in as part of the operating system, other vendors tend to create them as standalone products and infrastructure pieces. If you are a small company, having it built into the operating system is a value to you, but in large, heterogeneous environments that can be costly to you. So, that’s always been used by Microsoft. If you look at CORBA versus COM and DCOM, it’s the same story.
Macehiter: Absolutely.
Gardner: You’ve been listening to yet another BriefingsDirect SOA Insights Edition, Vol. 15, for the week of March 19, 2007. We’ve been joined by Jim Kobielus, principal analyst at Current Analysis. Neil Macehiter, a research director at Macehiter Ward-Dutton. Steve Nunn, the vice president and COO of The Open Group, and John Bell, enterprise architect at Marriott International.
I'm your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions. Thanks everyone, and thanks for listening.
Listen to the podcast here. If any of our listeners are interested in learning more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, please fill free to contact Interarbor Solutions at 603-528-2435.
Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 15. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Listen to the podcast here. If you'd like to learn more about BriefingsDirect B2B informational podcasts, or to become a sponsor of this or other B2B podcasts, contact Interarbor Solutions at 603-528-2435.
Dana Gardner: Hello and welcome to the latest BriefingsDirect SOA Insights Edition, Vol. 15. This is a weekly discussion and dissection of service-oriented architecture (SOA) related news and events with a panel of industry analysts and guests. I'm your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions, ZDNet software strategies blogger and Redmond Developer News Magazine columnist.
Our panel this week consists of Jim Kobielus. He’s a principal analyst at Current Analysis. Welcome to the show, Jim.
Jim Kobielus: Hi, Dana. Hi, everybody.
Gardner: Also joining us from the U.K., Neil Macehiter. He's a research director at Macehiter Ward-Dutton. Welcome, Neil.
Neil Macehiter: Hi, Dana. Hi, everyone.
Gardner: Also joining us today we have Steve Nunn. He's the vice president and COO of The Open Group. Welcome to the show, Steve.
Steve Nunn: Thanks very much, Dana, and good morning, everyone.
Gardner: Also joining us is John Bell, an enterprise architect at Marriott International. Hello, John.
John Bell: Hello.
Gardner: We're going to be discussing the role and concept of what’s becoming defined as the "SOA Architect." This is a different role, as we’re finding out, than the enterprise architect, but certainly seems to be part of an evolution of the role of architect within the enterprise and within IT in general.
We’ve invited a representative from The Open Group, in this case Steve Nunn, to join us, because The Open Group has taken some steps to try to define the role of the SOA architect, has created some certification around that role, and is trying to get in front of this role in terms of what will be required in the marketplace. That is, to try to encourage more people to step up and understand this role and to certify themselves, so that the progress and maturity of SOA practices can continue and not face a human resources crunch.
So, with that, why don’t we hand it off to you, Steve? Why don’t you tell us a little bit more about what The Open Group is doing and why?
Nunn: Thanks, Dana. The Open Group and its members have been working in the architecture space for over a decade now, primarily developing something called The Open Group Architecture Framework (TOGAF), but, as you’ve mentioned, we're running certification programs in two specific areas. One is in relation to TOGAF, but perhaps more relevant to this discussion is our IT Architect Certification (ITAC) program.
I guess that sets a caveat at the outset. The terminology around what type of architect it might be -- IT architect, enterprise architect, SOA architect -- is still very much settling down as a topic of debate in its own right, but our program that I can talk about is the IT Architect Certification Program, which is a broad skills- and experience-based program. It's aimed at creating a vendor-neutral program by which individuals can be certified. It provides them with a transferable qualification in the industry, and it enables employers to know that if they prefer recruiting certified individuals, they would be getting somebody who has been through an accreditation process.
Briefly, the process would be that a resume is compiled, which can be quite extensive, up to 52 pages in some cases.
Gardner: Wow!
Nunn: Yeah and then there’s a peer review by a panel of three certified architects themselves who would probe a little on the resume, ask questions of the candidate, and conclude whether or not that individual meets the conformance requirements.
Gardner: Is this process already up and running, or is it something you're still pulling together in terms of how you want to approach it?
Nunn: No, this is up and running. We launched this in July 2005, and as of today, we have just a shade under 2,000 individuals from all sorts of companies and all over the world who are certified under this program.
Gardner: This is the SOA Architect Certification?
Nunn: This is actually what we call ITAC, the IT Architect Certification.
Gardner: I see.
Nunn: It has several levels and covers various disciplines. The SOA-specific part of it is one that we are still working on. We have various horizontal levels under this program. The conformance requirements for meeting those levels have been agreed upon. There’s an entry level and a higher level. We are working on the highest level right now, but what’s also going on is work on the individual aspects of that certification, of which SOA is one. What we’re quite proud of in this program is the conformance requirements for the overall program, and what we're now focusing on are the conformance requirements for the individual disciplines.
Gardner: Perhaps this is a good time to go around the room, so to speak, and see if we’re in some agreement that an SOA architect is fundamentally different from an enterprise architect and why? Why don’t we start with you Jim Kobielus. Do you see these as significantly different roles?
Kobielus: Not really. You have to be an IT architect to be an SOA architect. It seems to me that an SOA architect, or that discipline, is a subset of the overall enterprise architect. I would like to know precisely what other disciplines or practices that one needs to be certified in to be a SOA architect, versus just an overall enterprise architect, I’m still unclear on that.
Gardner: When we hand it back to you, Steve, one of the helpful concepts for me in understanding this was the notion of the "city planner" or "town planner" role. The analogy is that an SOA architect needs to like a city planner, looking at all the resources and infrastructure and how the entire community comes together, managing constituencies and political relationships, whereas an IT architect might have a smaller role. Can you expand on that a little bit?
Bell: Actually, an enterprise architect from my perspective would have the view of the town planner. When they’re looking at the entire city, they're looking at how the various neighborhoods, how the various business zones, etc., fit into that city. The SOA architect, from my point of view, is really more interested in, "Hey, how does that underlying infrastructure allow different neighborhoods to communicate with each other and exchange messages? How are health services delivered across neighborhoods?"
So, it’s more interested in, "Okay, I’ve got a firehouse. Can the fire truck get to the house before it burns down?" The vision of the SOA architect is more associated with the communications pieces within the community.
Gardner: So, the hierarchy might be that the enterprise architect is in the town planner role, the more holistic, oversight uber-architect role, and then a subset of that is making sure that the communication channels between and among these different facets of resources and functionality are behaving well and conforming to what needs to happen.
Bell: Conforming to the standards so that they’ve got a consistent set of standards for exchanging information, those kinds of things.
Gardner: Okay. Neil Macehiter, what you make of this?
Macehiter: In that that classification of the difference between enterprise architecture and the SOA architect, it sounds to me that the premise is that the SOA architect is focused primarily on the plumbing. From a bottom-up perspective, the challenge that many SOA architects face is more around understanding what the services are that need to be delivered in a business-meaningful way, not just about communication and plumbing. It’s also about understanding the high-level, business-meaningful services.
There is a business strategy, there are business processes and priorities, and there are the services we need at a business level. Then, there's a handoff to what’s currently defined as the SOA architect, who will actually define how those services are deployed in technology terms. So, the distinction is quite blurred. A service-oriented approach is one of the methodologies and the approaches that you can utilize to deliver or to support an enterprise architecture initiative. So, I still find a distinction difficult.
Kobielus: I second what Neil’s saying. I’m uncomfortable with just reducing SOA to the plumbing. In the three-layer stack that I carry in my head, the plumbing level is the enterprise service bus, and then SOA refers to development and reuse practices within the development organization to enable maximum sharing and reuse. Then, there’s the layer above that, which is the applications, services and data -- the business processes.
I’ll put enterprise architecture at that very top layer, concerned with the end-to-end set of resources: app services, data, etc. The SOA architect would be the middle layer of the development and reusing. The layer below that, the enterprise service bus (ESB) or whatever, I call that "IT architect" in the sense that it's the infrastructure architect.
Bell: And to be fair, I didn’t mean to imply that the SOA was limited to the plumbing. My intent was saying that the enterprise architect has a much broader spectrum and scope that they have to deal with than your SOA architect has to deal with. Putting it into that city paradigm, you kind of limit it as to how to describe some of the roles. I try to clarify that by saying it’s not just how they communicate, it’s things like, "Hey, where’s the fire station? Do you have a fire station? Where’s your police station? Where are your schools? Where are all those pieces that are providing services to that community and are they adequate for providing the services to their community?" That’s a subset of what a city planner has to do but it’s still an important city-planning kind of function.
Gardner: John, you’re in the trenches, you’re an enterprise architect in a large global concern. How do you see this hierarchy and is this really the right discussion that we’re having?
Bell: My view is that the enterprise architect is at the top of the hierarchy, and at some place, working with the enterprise architect is an SOA architect, and their focus is on, "What are the services that are being delivered, how am I delivering them? What’s the infrastructure I am using to deliver it? Do I need – using that town model -- a police station? Do I need a fire station? Do I need a school? Do I need a museum? And, if I do, how do I get that service out to the community or to the entire city, not just an individual neighborhood?"
So, from my perspective, using a city planner paradigm, the role of the SOA architect, is identifying what are the services that need to be available to the city and how to deliver those services out to the city.
Gardner: Back to you, Steve Nunn. It seems to me that there needs to be a fair amount of flexibility, enterprise by enterprise, and circumstance by circumstance, as to how this SOA architect role pans out. How much standardization and methodological consistency can we bring to something that, in fact, will probably be dealing with huge variability from organization to organization?
Nunn: Something that we’ve had to address in putting the program together is that there are huge differences. Even taking the frameworks that might be used in implementing an enterprise architecture, there are huge differences among organizations. Some organizations are required to use a certain framework. Our approach is not to specify exactly how enterprise architecture or SOA architecture is done in the certification program, but more about the experience of the individual who's implementing it.
It doesn’t seek to define a particular way of implementing the architecture, but is more about the skills and experience of the individuals who are playing that role inside an organization. They could be part of a team in larger organizations, or could be one person in a much smaller organization who is playing this role. The whole idea of raising the value of the architects of various titles in the organization is what we are seeking to achieve with our efforts in the certification program. It’s about raising the standards of that role, and getting people to understand that it’s a valuable role and, apart from anything else, it should be compensated as such.
Macehiter: Dana, could I chip in with a quick question there?
Gardner: Certainly.
Macehiter: It’s about the approach and the experience, rather than framework, and I agree completely with that. Given that the SOA discipline is currently within the IT architect certification, to what extent do you look at the approach and experience in terms of the interface to the business, business understanding, or collaboration with the business? I think that key elements of the SOA architect role are skill and capability, as well as the more IT-oriented skills and capabilities.
Nunn: Well, that's not so different between SOA and enterprise architecture. I’d say exactly the same about the enterprise architect -- that ability to translate the business need into the systems underlying or delivering the needs of the business. It’s something the enterprise architect absolutely needs to have, and that’s why we think there’s a special set of individuals who play this role. So, there isn’t really a difference in that respect between the SOA architect and the enterprise architect.
Kobielus: I like what you do. Thinking about the whole notion of certification, there are two ways to go about it. One approach that you can easily take -- and this is the way it’s usually perceived -- is when you are certifying a CPA, you’re certifying somebody as a skilled in an established and knowledgeful body of practice, be it law, medicine, whatever. But when there’s no consensus body of practice that everybody agrees upon -- for example SOA, which is still evolving -- a certification in that regard is more like when somebody is applying to college. You’ve got to send in your transcripts, write essays, and you also might have to go and do an interview in the admissions office. They look you over and say, "Oh, this is a smart person. Yeah."
So, they consider the sum total of everything you’ve done and who you are in certifying that. They say, "Yes, you’re good enough to be admitted into this college," and then proceed from there. That’s sounds like what you’re doing. You’re certifying the competency of a particular individual in this general field called a enterprise architect (EA) or a SOA architecture.
Nunn: That’s right, Jim, and it’s not a bad analogy at all. It's about assessing the individual. It’s a relatively young discipline in its own right. One of the things that we look at in a conformance requirement is the role that those individuals have played in the projects that they have been involved in, and whether they had been in a lead role or support role, or a combination of the two, but it certainly is about the individual, rather than the specific approach that they take or any particular body of knowledge.
Macehiter: Just one other quick comment on this, if I may. The other dimension for this, I think, is rather than thinking about the role, thinking about SOA as an approach. Then, thinking about how that approach applies to different types of architect. What I mean by this is that a lot of the emphasis and focus on SOA today has been around application development and integration, when, in fact, there’s a broader perspective that really extends across more traditional IT architecture and other disciplines, for example, a service-oriented approach to infrastructure architecture and the service-oriented approach to the operations and operational management of IT.
So, there are two dimensions that a body such as The Open Group might want to think about. One is the role of a service-oriented architect, and the second is how service orientation impacts other architecture disciplines and other IT functions or operation capabilities. If we don’t do that, we risk driving SOA into a particular stovepipe focused on application development and integration, and aren't thinking about it more broadly as an approach that it is an enabler of whatever the enterprise architects are driving out.
Gardner: Thanks, Neil. I suppose, too, that the role of the SOA architect will shift, as the maturity of SOA principles and methods evolves inside of an organization. They might have to start out a bit more focused on application development and deployment issues, move up toward being mindful of the business issues, and then move up more toward being the communications conduit between the fire house and the police station, for example. Does that make sense?
Macehiter: Absolutely. It’s about gradually extending through the life cycle.
Gardner: One of the reasons we are discussing this is that we’ve seen some warnings from analysts and others saying that we are moving toward SOA, but we really might find ourselves without the people with the background and abilities to move this. So, we’re worried a little bit about a dearth of qualified people, which might, in fact, stifle the progress here for SOA.
Do you see that is the case, Steve Nunn? Do you have any sense of numbers and what the demand is going to be? The second part of the question is, if there aren’t enough people, aren’t these roles going to fall upon the enterprise architect anyway?
Nunn: Dana, what we’re hearing is there aren’t enough enterprise architects to start with. So, I think it’s a given, therefore, that the SOA specialists are in short supply too. We’re hearing from our members that if they spot a good enterprise architect or somebody they think has potential for that, then they try and grab them. They’re pretty few and far between right now in terms of folks with experience.
Obviously, there are other folks that we just talked about with the college analogy who might well be groomed into that role in the future. So, certainly there is a shortage right now. That's what we are hearing from our membership. I don’t have specifics on numbers, but the message we hear is that demand is out-stripping supply right now.
Macehiter: This is not new. We’ve been through this with every major technology advance or discipline advance. You used the word "potential" there. I think there are individuals within organizations that have the potential to fulfill that role. Part of the benefit of this certification approach, providing conformance and definitions of what constitutes the role, is that it will help organizations identify the individuals within that company that have that potential, even if they don’t have the 50-page resume that demonstrates that they have been there and done it, because the key element in a service-oriented approach, and an enterprise architect more broadly, is an understanding of the business.
If you’ve got individuals within the organization that understand how the business works, have been around, and know the right individuals to talk to, that that can be of much benefit in terms of enabling effective EA and SOA, as can be going outside, finding someone from a different vertical market or different industry, and bringing them in because they’ve done six SOA projects elsewhere.
Gardner: Thanks Neil. Let’s take that point back to John Bell. Now, as an enterprise architect with Marriott International, I assume that you’re going to be in the position of having to hire or find SOA architects in this climate of scarcity. Where do you think these people will come from and what kind of backgrounds would you look for?
Bell: I think what we are going to have to do -- fortunately or unfortunately, however you look at it -- is end up training our own people. A lot of it goes back to what was just said about having to have an understanding of the business. You have to know the people in the business. You have to understand what the business of the business is. You have to have a lot of domain knowledge in order to create an effective SOA environment.
Because of that, when you pull somebody from outside, they may understand the technology, but they have to come up and learn the business, which is harder to train than somebody who has a general technology background, but knows the business pretty well, because he has been working in the business. Marriott happens to be a company that retains employees for years and years on end. So, in our IT department we have people who may already have 5, 10, 15 years of experience working directly in the business. And we can’t afford to lose that.
Gardner: Do you find that a developer is a fast-track path to SOA architect or a business analyst, even though it makes great sense to have someone with longevity in your organization? Is there particular type of role that they would have played that seems to conform to this need for SOA process management and evangelism?
Bell: In our experience, we are finding developers, as they move through their technology career path, since they have been developing within the context of the business, if they take that broader view, they understand the basis for the SOA architecture that’s installed in this particular company. They tend to make a good SOA architects with the proper training, and sometimes that training isn’t the technology training; it’s the people training -- teaching them how to conduct interviews, how to talk to people, how to get information from people, particularly in a company like Marriott where the business is not technically oriented.
Kobielus: This is all very good, but it doesn’t address the need that many companies have which is, "Hey, we need to hire people straight out of college who have some background in architecture, and where are we going to find these people and how are they going to get certified?"
Everything I'm hearing says that, an EA or a SOA architect is somebody who has experience and, by definition, somebody right out of college doesn’t have experience. So, is this the kind of thing that we can actually train in school or does somebody have to be in their career for 5, 10, 15 years before they’ve been steeped enough in all of this architectural infrastructural development and integration stuff to the point where they can be certified?
Bell: I’m also an adjunct faculty member at Towson State University, and this is an issue that we’re dealing with at the university level so that the university can provide the skills that the local businesses in the Baltimore area need. So, at the graduate school level, we are looking at what we offer in the way of architecture courses that take architecture from an enterprise or SOA perspective, so that we can enable our students who are finishing graduate school to be more and better prepared as they enter their new job market.
Gardner: These are excellent points. Steve, you and I discussed, when we spoke about some of these issues a month or so ago, that you were also trying to encourage universities to create the curriculum and the definition of these jobs. Can you fill in our listeners a little bit on what you’ve seen?
Nunn: That’s right, Dana. Something The Open Group launched at the end of January this year was the Association of Open Group Enterprise Architects (AOGEA), which really is -- the analogy here is the one somebody used earlier with attorneys or CPAs -- to do for enterprise architects what the Bar Association, for example, would do for attorneys, all joking aside. I think one of the things that we’re trying to do is partner with various types of organization in creating this community and this professional association.
One of those groups is the academic community, so we are putting out feelers to various universities to explore the possibility of getting enterprise architecture on the curriculum. There is one university that we are aware of where there is actually a TOGAF module in some of their courses. Obviously, changing a curriculum is a multi-year project, or multi-year plan. It’s not going to happen overnight, but in the interim, one of the categories of membership for the association is students.
So, those who are on a course of some description inside the university or even working in a job and doing part-time study, can join the association, be part of the community, get the information that’s available there, be on the news groups, maybe take part in the local chapter, or whatever they want to do to start building up some experience.
I had somebody come up to me a couple of weeks ago, after a talk I gave, and said, "This is exactly what I’ve been looking for, because in my organization I’m quite junior and the people above me really aren’t that interested in enterprise architecture, and certainly not SOA, but they won’t listen to me because I’m too junior. So, I need to get some experience or immerse myself in this field. Some kind of virtual community that allows people to do that is going to be a great help to me."
So, that’s one of the thing we’re trying to do. There are various membership categories, and student is just one of those.
Gardner: Now, it does seem that we have a climate of opportunity here. There’s the track for developer to move above that role and embrace more business understanding in domain expertise, and that would be a track. We’re looking at more universities preparing people for these types of roles. We’re probably going to find, again, variety within organizations in terms of business analysts or non-tech people coming into this role, because it requires influencing and consensus building, and so forth.
Usually, in markets, when there’s opportunity and there’s scarcity -- and these are probably well-paying jobs -- we would expect for the supply and demand to even out at some point. For those in the field like yourself, John Bell, am I overly optimistic that this supply and demand is going to mesh, or are we looking at something a bit more serious in terms of the next three to five years where there’s going to be a serious deficit of talent?
Bell: I think that the supply and demand will eventually mesh, but there may be a gap in the next year or two. I don’t know if it will carry out for three to five years.
Gardner: Well, thank you very much. Let’s move on to our next subject of the day.
In March an announcement came from the consortium of large IT vendors including SAP, IBM, Oracle, BEA, and Cisco. They have formed a series of proposed standards, the Service Component Architecture (SCA) specification and the Service Data Objects (SDO) spec. We are not quite at the standards level, but that seems to be the goal, to take this approach through OASIS, which is the organization that’s overseeing the Web services specifications and standards, WSDL, UDDI and SOAP and so forth and all the WS-* specifications.
It seems that the vendors have stepped up and said, "Listen, we need a level of standardization. We are going to do some heavy lifting, create some specifications, and then we are going to hand them off to the standard organization." This strikes me as an important juncture in the maturity and real-world applicability of SOA, and I wanted to test that hypothesis on Jim Kobielus.
Kobielus: Yeah, it’s very important. It’s clear that the SOA paradigm requires ever more high-level abstractions to enable easy development of very complex, orchestrated, end-to-end services. The SCA and SDO specifications – the initiative has been being going on for a couple of years – have come a long way and they’ve got pretty significant support throughout the industry. Microsoft is one of the few important holdouts. It's not only the high-level abstraction for developing competence services, but also, especially, in my area, the SDO, the high-level abstraction for working with heterogeneous data. I see the SDO, in itself, becoming potentially the standard industry framework for what’s called the semantic layer for any data integration.
So, I’m very keen on the potential for SDO, for example, within the business intelligence space, the data warehousing, and the enterprise, information, integration space. The fact that now OASIS will be taking over ongoing development of SDO, puts it on a very important fast track. Hopefully, we’ll get some of the business intelligence (BI) vendors like Business Objects and Cognos behind it. That’s one of my fond hopes.
Gardner: Jim, you’re tracking the data management side on this quite deeply. Do you think that SDO has the potential to become the ODBC/JDBC of SOA in terms of what those things enabled and empowered for distributed architecture?
Kobielus: It’s quite likely, because it’s leveraging the whole WS-* stack and the whole notion of semantic web that’s been kicking around for long time. Tim Berners-Lee keeps this going. It’s really a utopia of interoperability, where the semantic layer is the resource description layer for describing metadata. If you look at the so called semantic web’s specifications like OWL, RDF and a few others, they have not achieved takeoff velocity in the data management world. I can count on one hand the number of the BI or data warehousing vendors that are implementing OWL, for example. The semantic web has not really gotten any traction with standards or specifications where it counts.
With SDO, I still don’t see significant traction yet in the whole BI space, but the fact is that every BI vendor is SOA-focused and enabled and getting ever more so. That’s one of the clear gaps I’ve been seeing in the whole enterprise information integration (EII) side of it all in terms of distributed master data management (MDM). Every vendor, including Business Objects and the others, have their own semantic layer. That’s what Business Objects calls it.
As yet, there is no federated semantic layer specifications, but customers are asking for federation of say, Business Objects, Teradata, Microsoft, Oracle, and I believe that at some point BI and EII will converge around a common set of standards. I’m getting further and deeper into SDO, and it really looks like this is a strong potential framework for them all to work together going forward.
Gardner: A framework for a common and federated metadata approach, is it not?
Kobielus: Yeah, exactly.
Gardner: Now, the politics here struck me as a little bit interesting. Ed Cobb of BEA, who was on the call describing the movement of these specifications to OASIS, said that he hopes that this does for SOA what J2EE did for n-tier in distributed computing, which is to create a climate of growth with application server vendors coming together and ISVs building applications that take advantage of these. That sort of exploded during the mid- and late-1990s into what is now a predominant architecture for enterprise applications, as well as large Web commerce and online commerce types of applications.
Neil Macehiter, what do you make of the politics here? If J2EE did for distributed computing what they hope this does for SOA, why aren't SDO and SCA going into the Java process?
Macehiter: You've hit the nail on the head there. I think there are a couple of issues here. First is, if it went into the Java Community Process (JCP), you’re talking about SOA based on purely Java. As my colleague put it at the time, it’s like a three-legged dog running in a race. If you’ve only got Java, then you’re not really addressing one of the core propositions of SOA -- that it is about heterogeneous interoperability, with services based on multiple languages.
Gardner: What happened to "write once, run anywhere?" Wasn’t that heterogeneity and interoperability?
Macehiter: One programming language, and that’s the distinction. The SCA and the SDO are multi-program, multi-language.
Gardner: So, an abstraction above Java their pointers will make sense?
Macehiter: Yeah. Actually, the second point is that, in part, the creation of SCA and SDO was motivated by the frustration with the J2EE process. Enterprise JavaBeans (EJBs) and things like that never really took off. Some of the lightweight programming frameworks, Spring and Hibernate, were just taking great chunks out of J2EE in terms of deployment.
Then there was a significant amount of discontent among the Java community around the support for Web services, which is clearly one of the key enablers of SOA. Those three things, plus what Microsoft was doing with the Windows Communication Foundation (WCF), and the work they’ve been doing around it, caused the big J2EE players to think, "Well, actually we need to do something different." That was the motivation.
Gardner: I suppose it’s water over the dam at this point, but perhaps if the J2EE and a variety of Java framework specifications had moved into a standards organization like OASIS five years ago or so, the SOA specifications and the Java specifications could find themselves in the same organization. That seems now not to be the case.
On the other hand, if Microsoft has been the holdout in terms of embracing SDO and SCA, and is focusing more on .NET Framework -- but OASIS was a place where Microsoft felt comfortable going when it came to working with folks like IBM on the Web services standards -- do you think that this might move the hearts and minds of Redmond, Washington toward a bit more SOA compatibility and the programmatic approach to SOA, rather than just the interoperability approach?
Macehiter: My gut feeling is "no." And the reason is that Microsoft has collaborated with the likes of IBM, BEA and others, its historical competitors, up to a certain level up the stack. But the level at which SCA and SDO are operating is at the level where Microsoft has a massive investment, and a significant proportion of its business has been driven out of this at the programming model level.
So, I think it would take a lot for Microsoft to move to support SCA and SDO within the composition framework that they have, which is fundamentally around Visual Studio. Whether we are talking about BizTalk or Sharepoint or Office, it’s all around that programming model, which is tied into WCF and Windows Workflow Foundation. So, I just think the battle line is drawn at that level.
Gardner: What we are facing is perhaps an important decision within enterprises and service providers, software-as-a-service (SaaS) providers, and ISVs as to which role you perceive for .NET playing in Microsoft’s tools and process runtimes. Are they a subset of SOA, or are they in fact the master -- and the rest of the SOA componentry is the slave?
That would be one way of looking at it. The other would be that .NET should be just another spoke in the hub of all SOAs. Jim Kobielus, do you think we are going to be facing this sort of a face-off between the role of Microsoft as the hub or the spoke?
Kobielus: I think Microsoft has gotten much more open to being just one spoke. But I wouldn't use the hub vs. spoke analogy here. They’ve become more comfortable with the notion that they’re just one node in a vast mesh on the Internet in terms of Web services and SOA. So I don’t see Microsoft in face-off mode in the SOA world, or where SCA or SDO are concerned. A couple of years ago it might have been different, but it has changed.
Gardner: How about in terms of the role of their communications, their ESB, WCF (the former Indigo) and the role of BizTalk? It seems as if they are happy to be a spoke on one level, but they’d also like to be where business process is coded and logic is instantiated, and therefore become "the place" where SOA is driven, the dashboard from which SOA is driven.
Kobielus: Well, pretty much every BPM vendor wants to be that hub, that business-process hub, and Microsoft is not alone. Companies like TIBCO with ActiveMatrix, are interesting, because basically what it is doing is it is virtualizing the app server or the integration server, so you can run your .NET logic and your J2EE logic, and so forth in different containers on the same platform. That kind of architecture is more where the industry is going. In that case, TIBCO necessarily isn’t trying to be the one and only integration and logic hub out there. It is simply trying to be the hub of all hubs, but one of the hub of many hubs federated to each other.
Gardner: Is it that you don’t agree with Neil then, that if Microsoft is a bit more ecumenical on this, would we expect them to embrace SCA and SDO? Is that what you expect?
Kobielus: It’s a relative thing -- getting ecumenical. They get ecumenical when they are good and ready, like they’re doing right now in the identity space, with this whole notion of user-centric identities. It’s taken them a couple of years of sitting back, watching things like OpenID and Higgins develop. And then finally they make a token offering that says, “Okay, we’ll implement OpenID in the next generation of the Vista Card Space."
And, once again, my sense is they’re going to wait quite a period of time, at least a year, before they make any public pronouncements on the extent to which they are going to work with OASIS on SCA and SDO. It’s just their nature, and they are going to pursue their proprietary approach, as long as it holds out, and as long anybody will implement it.
Macehiter: I’m not suggesting that this a face-off. What I am suggesting really is that it comes down to the point of control that an organization or vendor has. Microsoft does not want to be denigrated to the plumbing, even if that’s interoperable plumbing. The point you raised about TIBCO with ActiveMatrix is that it’s actually using the SCA programming model in order to provide this abstraction.
So, ultimately in that environment who’s controlling it? TIBCO is becoming the master, and it will be the same in an IBM environment. SCA may be under the hood, but ultimately there will be a point of control that IBM wants to wrest for its process server for its development tools, and that’s what Microsoft wants to do. The challenge is that SCA and SDO are trying to do the same thing as Windows Communication Foundation and Microsoft tooling around .NET and SOA.
Gardner: To wrap up, it seems that it's not a face-off, but perhaps there are, as Jim points out, a lot of vendors who would like to be that over uber-dashboard, point of control. Some are BPEL-focused and others are taking different tacks. SCA seems to be playing a role for many of them, and Microsoft would like to play that role as well -- but perhaps thinks that it has an advantage through the way it’s architected up to this point. The market will, I suppose, determine who the ultimate winner is.
Macehiter: I think a lot will depend how quickly the tooling comes out around SCA and SDO, as an alternative to Visual Studio.
Bell: The other piece too is, as Microsoft tends to build those kinds of capabilities in as part of the operating system, other vendors tend to create them as standalone products and infrastructure pieces. If you are a small company, having it built into the operating system is a value to you, but in large, heterogeneous environments that can be costly to you. So, that’s always been used by Microsoft. If you look at CORBA versus COM and DCOM, it’s the same story.
Macehiter: Absolutely.
Gardner: You’ve been listening to yet another BriefingsDirect SOA Insights Edition, Vol. 15, for the week of March 19, 2007. We’ve been joined by Jim Kobielus, principal analyst at Current Analysis. Neil Macehiter, a research director at Macehiter Ward-Dutton. Steve Nunn, the vice president and COO of The Open Group, and John Bell, enterprise architect at Marriott International.
I'm your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions. Thanks everyone, and thanks for listening.
Listen to the podcast here. If any of our listeners are interested in learning more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, please fill free to contact Interarbor Solutions at 603-528-2435.
Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 15. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Thursday, May 24, 2007
BriefingsDirect SOA Insights Analysts on the SOA Consortium's Formation and Goals with OMG CEO Richard Soley
Edited transcript of weekly BriefingsDirect[TM/SM] SOA Insights Edition, recorded March 9, 2007.
Listen to the podcast here. If you'd like to learn more about BriefingsDirect B2B informational podcasts, or to become a sponsor of this or other B2B podcasts, contact Interarbor Solutions at 603-528-2435.
Dana Gardner: Hello, and welcome to the latest BriefingsDirect SOA Insights Edition, Vol. 14. This is a weekly discussion and dissection of Service Oriented Architecture (SOA) related news and events with the panel of industry analysts and guests. I am your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions, ZDNet software strategies blogger and Redmond Developer News Magazine columnist.
Our panel this week consists of show regular, Steve Garone. Steve is a former IDC group vice president, founder of the AlignIT Group, and an independent industry analyst. Welcome to the show again, Steve.
Steve Garone: Hi, Dana. Great to be here.
Gardner: Also joining us is Joe McKendrick. He is a research consultant, columnist at Database Trends and a blogger at ZDNet and ebizQ. Thanks for coming, Joe.
Joe McKendrick: Good morning, Dana.
Gardner: Also, we have Tony Baer. He is a principal at onStrategies, and blogger at Sandhill.com and ebizQ. Thanks for joining, Tony.
Tony Baer: Hi, Dana.
Gardner: Also joining us, Jim Kobielus. Jim is a principal analyst at Current Analysis. Welcome again to the show.
Jim Kobielus: Hi, everybody.
Gardner: Our guest this week is Dr. Richard Soley, the chairman and CEO of the Object Management Group (OMG). Welcome back to the show, Richard.
Richard Soley: Well, thanks for the invitation. I am happy to be here.
Gardner: We're going to be digging into a few items this week, principally to discuss the new SOA Consortium. We are going to learn more about what's going on with that. It’s an interesting approach, combining end-user organizations and enterprises along with vendors to promote adoption and, I suppose, further definition of the scope of SOA.
We’ll also be discussing some of the events at EclipseCon, wrapping up for the week of March 5, 2007.
Gardner: First for those of our listeners who are not familiar with the greater details of OMG, why don’t you give us the elevator pitch, Richard, on OMG, its mission, and where it’s headed?
Soley: Sure, the Object Management Group is an 18-year-old consortium of software users and vendors, academics, and a growing number of government institutions focused on delivering standards to make interoperability and portability a reality. We were founded in 1989 focused on object technology, later grew into distributed object technology, and were best known for the first few years for our Common Object Request Broker Architecture (CORBA).
In 1997, we moved in two new directions; one being the adoption of a unified modeling language with the clever name, Unified Modeling Language (UML), and also into vertical markets -- originally healthcare, finance, telecommunications, and manufacturing, although we are now in about 25 different markets, everything from robotics to regulatory compliance.
In 2000, we actually leveraged that modeling technology and made it the base technology for all of the efforts that we have under way. So, we defined business models and software models, and, in some cases, even hardware models and process models.
The next big leap came in 2005, when we merged with Business Process Management Initiative (BPMI.org), so that now all of the modeling languages from meta modeling languages like Meta-Object Facility (MOF), to business modeling languages like Business Process Modeling Notation (BPMN), to software modeling languages like UML, and systems engineering languages like SysML are all in one place. That’s been our focus, but looked at from another dimension, what my staff is really good at is getting competitors to agree on things.
We have been doing that at OMG for 18 years with, at this time, between 500 and 600 member companies. We were approached by a group of 11 companies to create a community around SOA, an advocacy group, not a standards group, which is why it’s separate from OMG. We strongly believe that SOA isn’t a technology at all, but rather an approach to achieve business agility. It’s not a technology, but rather a business strategy.
Gardner: Well, it certainly seems to fit in well with the heritage and the direction that OMG has taken. This is really an industry development that’s ready-made for many of the values that you bring to the table.
Soley: I appreciate that and I think that’s fair. But it’s important to understand that this is not a standards organization. There are plenty of organizations focused on SOA standards and, in fact, OMG is one of them. Let’s get this straight upfront -- we are going to pronounce it SOA (So-wah) from now on, because, otherwise you can’t say, "SOA what?"
Our SOA group at OMG has been focused on modeling SOA, modeling for software assurance, and modeling for software producibility, and so forth. At the other end of the spectrum, you have organizations like W3C and OASIS that are doing a great job designing the protocols and languages at the pipe level -- how do we connect the systems together?
That hasn’t been our primary focus in over a decade, so we are not in that space, but the advocacy group is exactly that. It’s an advocacy group. How do we help the CIO? And, we call this "Corner Office SOA." How do we help the CIO get the news across to the rest of the C-suite that this is not a technology but a business strategy, and a business strategy that can deliver agility and a better bottom line?
Second, "Ground Floor SOA." How do we help the enterprise architect, the domain architect, the data architect get the word across to his alter ego in the line of business that this is a business strategy and not a technology and it’s something he needs to pay attention to?
Gardner: Back on Feb. 12, the SOA Consortium announced its formation of this advocacy group, and it’s quite a nice mix of organizations. You’ve got such enterprises as Avis, Bank of America, CellExchange, WebEx -- I suppose WebEx [now part of Cisco] is a vendor, but probably could be both -- and then we’ve also got some very large influential vendors, BEA, Cisco, IBM, SAP and HP.
Tell us a little bit about what the goal of this organization is -- combining, I guess, the constituencies of the end-user issues and vendor issues. You’ve had some of these closed-door summits over the last several weeks to come up with a charter. Tell us what you can about what took place at these events and what is shaping up as the charter, given you’re straddling the fence between the user and vendor organizations.
Soley: It’s important first of all to note the mix of users and vendors. We are currently running 3-to-1 end-users to vendors, and that’s because the focus is on this advocacy activity. It’s not on whose SOA infrastructure we should buy and "Our Web service is cool," or any of those questions. I am guessing that we are actually going to be more like 5-to-1 or 10-to-1 end-users to vendors eventually, but, as you can see, on Feb. 12 four vendors stepped up to the plate to fund it and get it off the ground. They were BEA, Cisco, IBM, and SAP. As an old consortium hand, I listed those in alphabetical order.
You also saw, as you said, some very dedicated end-users who have ideas about how to get the idea across to the lines of business that this is not a technology play, but a business agility play. Some you didn’t mention, for example Wells Fargo, and, of course, Object Management Group ourselves are a member, as well as the Integration Consortium. So, that’s another differentiator from OMG, which is about half end-users and half vendors. We expect that the SOA Consortium is going to weighted toward end-users, although there will be a couple of sponsors joining.
Gardner: So, with this predominance of users, what do they say? What do they want your organization do for them?
Soley: Number one, they want to be truly vendor neutral. Over the last two years, there have been various alliances of vendors saying, "We have created this" – their usual common phrase is -- "SOA alliance to help our customers understand the products in the SOA space." That’s wonderful. That’s all well and good. That’s how the industry works.
But you notice that there are always one or two vendors and one or two of their top customers. This is four major vendor-sponsors, a couple of more that are participating and might be sponsors later, and a lot more end-users, because what they are looking for is understanding the business strategy, not trying to decide which product to buy to "SOAfy" their infrastructure. That’s a very important differentiator.
They are not building reference models. They are sharing case studies. For example, our enterprise architects and our community of practice is showing case studies of success stories and, more importantly, failure stories, best practices, what works, what doesn’t work? We have even had sessions on how to influence project managers and product managers in the line of business to understand business strategies in general, rather than think of us as “the guy who fixes my Treo.”
We received a lot of feedback from CIOs and CTOs during the [early] summits that said this is very important. We had a Fortune 100 CIO who came into the New York summit. This person is CIO of a multi-billion dollar travel organization, and the opening gambit that we heard was, “Look, this is just a technology play, and if one of my technology guys hadn’t told me I had to be here, I wouldn’t be here. I’ve already told the CEO that SOA is a technical thing, and we’ll take care of it.”
At the end of the summit, this particular CIO stayed an extra half hour and said, “The most important thing I learned is that I can now understand how I can position this as -- rather than a technology play -- a business agility play. That will support the efforts that I am making to make our business processes understood, to write them down in a way that’s reusable and discoverable, and in a way that I can make them more efficient. And, I am going to go back to the CEO and say it’s not a technology play.”
[Editor's note: More news has come from the SOA Consortium since this podcast recording.]
Gardner: Well, this gentleman obviously had not been listening to our podcast series. Let’s go to the panel.
Steve Garone, we’ve talked about advocacy and evangelism, and the intersection of the business and technology values around it for quite sometime now, and we’ve mentioned that politics is an important aspect of this cultural shift. Do you think an advocacy group like this is a good thing for the politics, in terms of getting people on the same page? And, what would you pose as some of the necessary ingredients for success for an activity like this?
Garone: It’s a great question, Dana. First of all, Richard, that sounded like a great case study, and certainly makes the case that this group is going in the right direction. The issues that seem to surface come from two directions. One, and I know, Richard, from some of the information I’ve seen in this alliance, that you guys have considered this, is that many organizations that have gone through some SOA activities up to this point. These have focused primarily, and in some cases exclusively, on cost saving and not business agility. Getting that message across I think is a very important issue, in terms of getting acceleration around SOA adoption.
Obviously, it's very important to convince the higher-ups within an organization that this is something that they can benefit from, from a business standpoint. One of the key issues also is that there tends to be sort of a push-pull, or a lack of communication and understanding, between the business functions within an organization, and that, from the line of business standpoint, can certainly benefit business agility and the IT folks. Of course, there's been a lot of activity around tools, standards, and technologies to help bridge that gap, but I think it’s still a pretty important issue. So, those are the major areas that I would look at, and it sounds like you guys are addressing them to some extent.
Soley: The first is a very important issue for us, and second is a really tough one to get past. IT has traditionally focused in most organizations on what are the right tools to achieve what lines of business are telling us we need to achieve. Sure, there are going to be tools and there are going to be technologies and there are going to be frameworks to help you implement the SOA strategy, but it’s the other way around. It’s "What is it we need to achieve?" And, what we need to achieve is fairly easy to explain, right? What we need to achieve is capturing business processes, so that we can find them, so that we can make them more efficient, and so that we can reuse them -- and this is nothing new.
What’s new here is the message that we are not just talking about workflow. We are not just talking about processes that can be automated. We are talking about any of the processes, especially customer-facing, but any value-chain processes within the organization that we might want to reuse.
Gardner: I'd like to encourage any of the analysts to kick in with their questions. I'd just like to start off with a quick one. Richard, one of the things we come up against a lot, when we talk to our guests and we examine some of the events that are unfolding, is complexity.
People are baffled in that there’s just so much, and the more you dig down, it seems daunting. It seems difficult to manage things horizontally, and therefore you relegate it to projects and pilot types of affairs. Is there anything that you expect to be doing through an advocacy role, inasmuch as you understand and are participating in this, that can deal with helping people manage the complexity issues for SOA?
Soley: You know, that’s a great point. I would like to answer in two different dimensions. First, as you can see, we are making top-down advocacy the core of what we do. If you start with your developers and try to work your way up, you are not going to change the way that company thinks about business process, and you are not going to have an effect on business agility. So, that’s why we're having the CIO Summits. And we will be continuing to do those.
Starting in June we are planning on doing them quarterly with a small number of CIOs and CTOs, government agencies, large corporations, as well as non-governmental organizations (NGOs). We actually had an NGO participate in our San Francisco event. We'll use those events not only to make sure we stay on track, but also to get the word out about what we are trying to do here, which is a top-down focus on business process and business agility.
By the way, that’s working. The participants at the events we had were very enthusiastic about the consortium. There was active participation throughout the sessions. In fact there was so much interaction that the round table discussion, which was supposed to be after the presentation, was embedded within SOA Consortium presentation at every stop. So, that’s one, and I’ve lost the thread for the second. I should have written it down.
Gardner: That it was kind of complex.
Soley: Yes, there is complexity involved in capturing the business processes in a way that makes them reusable and discoverable and to make them more efficient, but you always are going to have that complexity, and the question is, "Where is the complexity best spent? Is it best spent upfront, so that I’ve got a description of the process that I can reuse, find, and make more efficient, or is it best spent by the people trying to implement the process, looking at an ambiguous description of a process, in, at best English, and trying to figure out every single time, what in the world it means?"
I would rather do that once, capture it upfront in a rigorous fashion, rigorous both from the standpoint of how it’s captured a formal language, but also the way that it’s captured, having the methodology in place -- spend that extra money upfront and have the savings every time the process is carried out and reused.
Gardner: Anyone else out there have some questions for Richard?
Kobielus: There’s definitely a value for an advocacy organization like this to spread best practices regarding SOA and SOA deployment and management. You mentioned that one of the functions of these – for lack of better term, dog and pony shows -- meetings in various cities is for the CIOs to share both the success stories and the failure stories regarding SOA deployment. How eager are CIOs to share their failures and their screw ups in implementing SOA?
Soley: You saw how carefully I didn’t mention even the gender of the CIO who made that comment in New York. I will admit there was one time we had to turn off the tape recorder, which we were using just to have notes so we can get the quotes right later on. They are willing to share. We find this at the level of CIOs and CTOs, as well as at the level of enterprise architects. They are willing to share failure studies, if they have the safety and security of knowing they are not going to be quoted, it’s not going to be on their performance reviews, and they know that others in the room are going to do the same.
Listening to one of these stories, actually it was in San Francisco, gave me an instant flash to my kids high school in Lexington, Mass. It blew me away the first time I saw this. There's an enormous board in one of the major cafeterias. It’s labeled "The Board of Rejection," and all the kids post their rejection letters up there, and I thought, "My God. I never could have done that 30 years ago, when I was graduating high school."
But kids write notes on them and say, "They don’t know what they missed," and "You’ll get accepted somewhere else." And, they really help each other out. I think they all understand that failure stories are just as important as success stories. In fact, more important, because it’s very difficult to justify cost savings. It’s far easier to justify increased revenue. So, they do it and I will admit that the enterprise architect level folks do it more readily.
Kobielus: Which leads me to another question, I am looking at the initial membership of the SOA Consortium and I don’t see any consultants or a professional services firms.
Soley: Yes, systems integrators (SIs).
Kobielus: Those are the folks who see the broadest range of SOA implementations, successes and failures and they themselves quite often are a key component of those successes and failures. Why don’t you have the SIs involved in the consortium?
Soley: That’s a great question. In the three weeks since we’ve been live; you are only the second person to think of that. So, well done. In fact, amazingly, the entire idea for these summits was from one of the big four, a very active person who has been participating in all of the meetings. Unfortunately, their entire management restructured the day the membership agreement was supposed to be signed. So, we are talking to all of them obviously, and, in fact, unsurprisingly, IBM is participating from two different parts of the house, and one of them being, whatever IBM Global Services is called -- today is Friday, so it must have a new name.
I expect to be able to make an announcement about another major one in the next couple of weeks. We are talking to all of them. Come along to a meeting. Maybe you will see the one that I am talking about, but I really shouldn’t mention them until they can get their own processes back in order and get involved. It was really depressing to have this gentleman come to all the meetings, actually lay out the entire structure, idea, and plan for the CIO Summits and then not be able to participate in them.
Kobielus: I'll bet it was frustrating.
Soley: It was very extremely frustrating for me and I think intensely frustrating for him.
Gardner: Seeing these individuals participating in the sharing back and forth of stories, methodologies, and lessons learned, sounds a little bit conceptually like an open-source project. I didn’t see in the initial release any mention of some of these SOA open-source projects involved, whether it’s SOA Tools Project within Eclipse, or Tuscany within Apache, or some of the success in the field, such as ServiceMix. Is there a role for open-source projects within this consortium?
Soley: I'm going to go out on a limb here. Didn’t I say SOA is not a technology? When I hear "SOA tool," or "SOA development tool," or "SOA testing tool," I have to wrap my mind around that, because SOA is not a technology. It’s a business strategy.
So, I think what you really mean is "tools for implementing processes that are defined using the SOA approach." These are tools for testing implementations of processes that are defined using a SOA approach. If what we're talking about is business strategy, then software is an implementation technology. It’s not the strategy, right?
Gardner: Well, they still have a relationship?
Soley: Yes. So, let’s look at any of those. Commercial products, by the way, are no different. They implement processes that are defined by a methodology that’s part of your SOA strategy, or maybe they help you implement the methodology itself. There are tools to do that as well, and some of those are going to be open source and some are going to be commercial. There is definitely room for participation, and these vendors that have put money into the creation of the SOA Consortium obviously want to sell products and services. The good news, however, from the point of view of the end-users is that the purpose of the organization is not to help them decide what product to buy.
I will tell you, sitting around the table, enterprise architects share experiences of which products have worked for them and which haven’t, and I have seen marketing reps from our vendor participants scribbling down notes, because they want to sell more product -- and more power to them. I'm a capitalist. But whether it’s open source or commercial, software is an enabler, software is an implementation technology, but it’s not a business strategy.
Garone: I wanted to follow up on Dana’s question, because I was thinking in the background as you were talking about what the Consortium is actually doing and who is participating. Given its charter, what's in it for the vendors and how they are participating, if, in fact, this is not about generating standards that all the vendors can leverage, and it’s not about selling product, which of course it shouldn’t be and it isn’t?
I am sure that they get value out of being there, out of being in front of CIO’s and other end-users, out of taking notes, as you said, learning where their products are selling and where they aren’t. But I'm interested in the mechanics of how they participate, what they bring to the table, and how they interact with the CIOs in a way that brings them benefit?
Soley: First of all, I should mention that at the summits none of the vendors were allowed. In fact, none of the members were allowed. They were run as focus groups, because we wanted the CIO-level executives to be able to talk completely openly about their case studies, their success stories and failure studies as well. And, we wanted their honest feedback on the organization. So, no one else was in the room, except for the executives that were able to come and two OMG staffers, including me and Brenda Michelson from Elemental Links, who is the consultant who put together the vision-mission strategy goals and tactics document. She then presented that to these executives and then ran focus groups to get results and is now finalizing those documents, which we call the core documents about the organization.
The vendors have been in the room at all the other meetings, of course, and they have their own SOA strategies to implement and their own business processes that interest them, but there’s money coming from marketing departments and they want to get out in front of these users and say, "Look. We are leaders in this field, we understand how to implement an SOA, we have tools to help you with the implementation of your architecture, and we have run-time executables to manage the implementation."
Those go from anything such business-process description languages as BPMN to capture business processes, SOA governance product for keeping track of what processes you have, and making sure they follow the corporate rules and implementation of technologies.
It's no surprise that IBM mentions WebSphere, and that BEA mentions WebLogic and AquaLogic, and so forth. The group from Cisco, for example, the AON group, is all about capturing SOA and implementing it on your network. The group from SAP is changing completely the way that they implement their own products and integrate them with the other products they find in their customers, to be able to say to their customer base, "Look, we are leaders in SOA and one of the proof points is that we took sponsorship positions in the consortium."
Gardner: You know, Richard, one of the problems that we have encountered in the field around SOA is that it’s hard to measure success. There are long-term and soft-types of implications, and I suppose that the same could be said for something like this consortium. How do you measure the success of what you’re doing and have you put any milestones out there for what you'd like to attain?
Soley: That's an extremely good point, and actually one that came up at every single one of the executive summit events. We worked on that for a long time and came up with the loosey-goosey measure of self‑identification.
So, the overall goal, which you see on our Website, is 75 percent of the global 1,000 self identify SOA successes by 2010. There is an asterisk that mentions that we are also talking 50 percent of medium‑sized businesses and 50 percent of major government agencies. Because we couldn’t pull some measure of success off the shelf, we went with self identification, and at every single one of the summits we were told, "No, you are going to have to try harder. You’re going to have to deliver some metrics of success."
I don’t have any for you today, but I can tell you that that is something that we got very clear direction on from the CIOs and CTOs who participated in the summits. Also, they wanted us to look specifically, for example, at connections between SOA and Lean, Six Sigma, and ITIL best practices, all of which have metrics of maturity and success.
Gardner: Any other questions?
Kobielus: I think the industry is looking at the SOA Consortium or OMG to be a third-party certifier -- maybe that’s overstating your mission -- of enterprises' success or lack thereof in implementing SOA. So, it’s the extent to which you are going to be mapping these SOA best practices back to such recognized frameworks as ITIL, Six Sigma, and so forth that would be essentially what the industry is looking for you guys to do -- to catalyze that kind of mapping.
Soley: Yes, that’s a very good point, and, Dana, I thought you said that I wasn’t going to be get any hard questions.
Gardner: Sorry.
Soley: The SOA Consortium is looking to not only OMG, but other standards consortia, to deliver standards, mappings, and validation endorsement certifications where appropriate. In fact, it’s in the mission statement that the SOA Consortium is not a standards organization, but it will deliver requirements to standards organizations and where we were talking about modeling things, those requirements would be handed to OMG.
One of the 10 largest banks in the world sent an executive to one of our meetings, and this person said, that all they care about in terms of metrics of success are Lean and Six Sigma, so we're going to need to connect SOA to that world in order to be successful at that bank. I think that’s part of it, but there’s more than that. There are going to be metrics that are not yet in the stack when you fly through the ITIL, Six Sigma and Lean documents.
OMG, as it happens is moving into the direction of maturity models anyway. We are just starting work on a business-process maturity model. You may have read about it. It’s not a standard yet, but it was just starting. What were talking about is a maturity model for business process adoption that measures organizations and their ability to capture business processes. That’s very strongly related to SOA, but again, that’s a standard and belongs in OMG and not in the SOA Consortium.
Kobielus: One last question. Are you developing a maturity model for master data management (MDM)?
Soley: First of all, the SOA Consortium wouldn’t be delivering any maturity models at all. OMG has never delivered maturity models before, although we’ve expanded many times over our history, which is frankly why I am still there. This is a new area for us. We have to learn not only how to deliver the standard that specifies business process maturity, but how to deliver that, which means how to certify people, so that they can certify organizations at the five different maturity model levels that we are contemplating. So, no, we have never delivered any other maturity models and although there are lots on the books as potentials, let’s wait for 2008 to see what develops.
McKendrick: You talk about the SOA Consortium, and there’s a lot of discussion about business process management (BPM) and SOA. Obviously, these two areas need to converge as we go forward. As I have heard and seen, though, over the years, especially in recent years, that the BPM professionals and the IT or the SOA professionals tend to be in two different camps and kind of follow their own separate sets of disciplines. It would seem a challenge from the perspective of the SOA Consortium in bringing these two camps together. Do you see that as a challenge?
Soley: You bet, but that’s one of the results that we learned during the events. We are very worried about that. Obviously, I strongly believe that BPM -- and now I am not talking about technology, just managing business processes -- is a key part of the SOA business agility message. I also believe that BPM technology, like our own BPMN standard, implemented by 40 some vendors, is a great way to capture business processes. But, we have been worried since day one that you’ve got your business process owners, your Six Sigma experts, and business process offices in companies, and they seem to be different from the IT definition of BPM.
One of the things that we heard in every event from all the participants is that the CIO and CTO participants did not artificially separate SOA and BPM by the underlying technology. They see business processes and services tied to a cohesive enterprise architecture foundation as a major message of SOA. That message has been received at the high level, and what we have to do is help the C-suite, get the message down into the lines of business and down into the IT organization, that a business process viewed as a methodology by business process improvement office and business process viewed as a business process notation in the IT departments are the same thing, and they ought to be working together more closely.
Gardner: Great. Well, thank you, Richard. Obviously, there are so many constituencies involved inside of organizations, and then also involving their communities, and there are vendors that are herding the cats, as it were, toward SOA as a worthwhile, important, and difficult activity.
Soley: Yeah, no problem, though. These are cool cats.
Gardner: I wish you well. Moving on to our second subject, I just came back from EclipseCon in Santa Clara, Calif. [in March] and there were few announcements there I would like to go over quickly. Tony, you wrote about the Oracle move with its Java Persistence API. Tell us very quickly about that.
Baer: Well, it’s been an interesting strategy, because the fact is that Eclipse was initially known for IDEs, and Oracle with JDeveloper is one of the few major Java players, outside of Sun, who is not migrating its IDE to Eclipse.
In the past year or so, Oracle has been involved in a number of Eclipse projects. I think putting its feet in the water. What’s interesting is that they are now ramping up to board level by saying, "No, we are not going to IDE. We are going to instead work on Java persistence and essentially they are trying to coalesce it around top tier, which is their implementation of the Java Persistence API.
It’s actually the update of what is essentially about a 10-year-old product, and what the interesting thing is not so much what Oracle is doing, but it’s more reflection of Eclipse saying, "We’re more than about IDEs."
Gardner: This is runtime material, right?
Baer: Exactly, and that begs the question that I have asked the Eclipse folks as well. If you’re not just IDEs, which is what we’ve associated you with, what are you? What is your mission, and where do you draw the bounds on it? Their answer to that was, "Well, we didn’t initially form ourselves to develop an IDE. It was the idea of trying to be a proof of concept to show that you can have an extensible framework to this plug-in model."
Gardner: Around OSGi?
Baer: Well, OSGi came later. They initially tried their own plug-in model and realized, "Why are we re-inventing wheel?" OSGi just happens to work. The whole rest of the field just discovered OSGi, kind of by chance, in the same way that all the AJAX folks discovered you can use Java Script, XML and a whole bunch of other stuff together and get rich clients on the Web.
That was not the original intent of OSGi. It was supposed to be basically a home box, which would essentially Java-enable your toaster or refrigerator, and we can see how far that’s gone. But, what we have found is that it’s actually a very effective, hot-swappable component model. So, that’s what Eclipse has really capitalized on, and they are seeing that as being some of their proofs of concept to say, "Now, let’s see how far we can take this."
Gardner: I had two take-a-ways, one was that this seems like mission creep for Eclipse, that they are getting more into runtime, and not just on the client with their rich-client platform, but now, increasingly on the server. The second thing was this. Oracle, as a major vendor is going to be driving a lot of the innovation around this project. The proposed project under Eclipse has moved the project in the sense out of GlassFish and around the Java community, and they will keep it as a Java reference implementation. But the innovation will be happening at Eclipse. And then any of the changes will only then move downstream into Java.
So, my take-a-way was: one, mission creep for Eclipse into runtime, but secondarily some diminishment of the role of the Java environment for innovation. Anybody have reaction to that?
Kobielus: Actually before everybody else jumps in, I just want to top that. You have mission-creep for Eclipse, and it sounds like you could also say "mission accomplished" for IBM, because I think one of the original goals in getting Eclipse going was to essentially move the center of gravity in the Java world away from Sun.
Gardner: That seems to be happening, doesn’t it? Richard, what do you think of that?
Soley: This goes back to the conversation we were informally having at the beginning of the call, about mission creep and expansion of Eclipse goals, and where the organization goes. I think there’s sufficient demand in all of these areas, that some organization has got to get their arms around it and deliver. As long as that delivery happens, I think it’s the right thing for the user base.
Gardner: I'm not sure I understand.
Soley: Whether it’s commercial or open source -- and you hear me say "whether it’s commercial or open source" a lot -- you need product that delivers against a user requirement. My response in this was something I was saying earlier to Tony’s note this morning about results of EclipseCon is that expansion of mission is perfectly fine as long as you continue to deliver on each of the elements of that mission.
Gardner: Well, one thing I can tell you as an observation is that this is a very energetic environment. A lot of developers that had the feel of what Java 1.0 was about seven or eight years ago, and many, many vendors that I speak to, recognize that the Eclipse community is a force to go with and not to ignore. Many of them are creating plug-ins -- be they commercial or open source -- in order to ride the marketing machine that the Eclipse involvement has become. So, this is something that’s got a lot of momentum, and at a time, as I think Tony pointed, out that Java is losing momentum?
Soley: You can’t have both of those at the same time, right? A big message of Eclipse is the Java message. Eclipse supports other programming languages as well, but the success of Eclipse is the continued success of Java. So, let’s be fair.
Kobielus: One thing we have to distinguish is Java versus the Java community process. I think that’s really what they’ve meant.
Soley: Okay, fair enough.
Gardner: Where did the innovation take place? Is that kind of the point?
Soley: The open-source model has proven to be a very successful one in the Java community.
Gardner: Well thank you everyone for joining, we’ve had an interesting discussion, and again I want to wish the SOA Consortium well, and OMG as a participant in that. I guess you’re taking a leadership role in this Consortium. Is that fair?
Soley: I am the executive director of the consortium, yes.
Gardner: Well, thanks everyone. We’ve been talking again about SOA, your SOA Insights Edition, Volume 14; our guest has been Dr. Richard Soley, chairman and CEO of OMG. Thanks for coming, Richard.
Soley: No, thank you for arranging. It was a pleasure, Dana.
Gardner: Also joining have been Steve Garone, Joe McKendrick, Tony Baer, Jim Kobielus -- thanks everyone for joining. I am your host and moderator, Dana Gardner. Thanks for listening.
Listen to the podcast here. If any of our listeners are interested in learning more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, please fill free to contact Interarbor Solutions at 603-528-2435.
Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 14. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Listen to the podcast here. If you'd like to learn more about BriefingsDirect B2B informational podcasts, or to become a sponsor of this or other B2B podcasts, contact Interarbor Solutions at 603-528-2435.
Dana Gardner: Hello, and welcome to the latest BriefingsDirect SOA Insights Edition, Vol. 14. This is a weekly discussion and dissection of Service Oriented Architecture (SOA) related news and events with the panel of industry analysts and guests. I am your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions, ZDNet software strategies blogger and Redmond Developer News Magazine columnist.
Our panel this week consists of show regular, Steve Garone. Steve is a former IDC group vice president, founder of the AlignIT Group, and an independent industry analyst. Welcome to the show again, Steve.
Steve Garone: Hi, Dana. Great to be here.
Gardner: Also joining us is Joe McKendrick. He is a research consultant, columnist at Database Trends and a blogger at ZDNet and ebizQ. Thanks for coming, Joe.
Joe McKendrick: Good morning, Dana.
Gardner: Also, we have Tony Baer. He is a principal at onStrategies, and blogger at Sandhill.com and ebizQ. Thanks for joining, Tony.
Tony Baer: Hi, Dana.
Gardner: Also joining us, Jim Kobielus. Jim is a principal analyst at Current Analysis. Welcome again to the show.
Jim Kobielus: Hi, everybody.
Gardner: Our guest this week is Dr. Richard Soley, the chairman and CEO of the Object Management Group (OMG). Welcome back to the show, Richard.
Richard Soley: Well, thanks for the invitation. I am happy to be here.
Gardner: We're going to be digging into a few items this week, principally to discuss the new SOA Consortium. We are going to learn more about what's going on with that. It’s an interesting approach, combining end-user organizations and enterprises along with vendors to promote adoption and, I suppose, further definition of the scope of SOA.
We’ll also be discussing some of the events at EclipseCon, wrapping up for the week of March 5, 2007.
Gardner: First for those of our listeners who are not familiar with the greater details of OMG, why don’t you give us the elevator pitch, Richard, on OMG, its mission, and where it’s headed?
Soley: Sure, the Object Management Group is an 18-year-old consortium of software users and vendors, academics, and a growing number of government institutions focused on delivering standards to make interoperability and portability a reality. We were founded in 1989 focused on object technology, later grew into distributed object technology, and were best known for the first few years for our Common Object Request Broker Architecture (CORBA).
In 1997, we moved in two new directions; one being the adoption of a unified modeling language with the clever name, Unified Modeling Language (UML), and also into vertical markets -- originally healthcare, finance, telecommunications, and manufacturing, although we are now in about 25 different markets, everything from robotics to regulatory compliance.
In 2000, we actually leveraged that modeling technology and made it the base technology for all of the efforts that we have under way. So, we defined business models and software models, and, in some cases, even hardware models and process models.
The next big leap came in 2005, when we merged with Business Process Management Initiative (BPMI.org), so that now all of the modeling languages from meta modeling languages like Meta-Object Facility (MOF), to business modeling languages like Business Process Modeling Notation (BPMN), to software modeling languages like UML, and systems engineering languages like SysML are all in one place. That’s been our focus, but looked at from another dimension, what my staff is really good at is getting competitors to agree on things.
We have been doing that at OMG for 18 years with, at this time, between 500 and 600 member companies. We were approached by a group of 11 companies to create a community around SOA, an advocacy group, not a standards group, which is why it’s separate from OMG. We strongly believe that SOA isn’t a technology at all, but rather an approach to achieve business agility. It’s not a technology, but rather a business strategy.
Gardner: Well, it certainly seems to fit in well with the heritage and the direction that OMG has taken. This is really an industry development that’s ready-made for many of the values that you bring to the table.
Soley: I appreciate that and I think that’s fair. But it’s important to understand that this is not a standards organization. There are plenty of organizations focused on SOA standards and, in fact, OMG is one of them. Let’s get this straight upfront -- we are going to pronounce it SOA (So-wah) from now on, because, otherwise you can’t say, "SOA what?"
Our SOA group at OMG has been focused on modeling SOA, modeling for software assurance, and modeling for software producibility, and so forth. At the other end of the spectrum, you have organizations like W3C and OASIS that are doing a great job designing the protocols and languages at the pipe level -- how do we connect the systems together?
That hasn’t been our primary focus in over a decade, so we are not in that space, but the advocacy group is exactly that. It’s an advocacy group. How do we help the CIO? And, we call this "Corner Office SOA." How do we help the CIO get the news across to the rest of the C-suite that this is not a technology but a business strategy, and a business strategy that can deliver agility and a better bottom line?
Second, "Ground Floor SOA." How do we help the enterprise architect, the domain architect, the data architect get the word across to his alter ego in the line of business that this is a business strategy and not a technology and it’s something he needs to pay attention to?
Gardner: Back on Feb. 12, the SOA Consortium announced its formation of this advocacy group, and it’s quite a nice mix of organizations. You’ve got such enterprises as Avis, Bank of America, CellExchange, WebEx -- I suppose WebEx [now part of Cisco] is a vendor, but probably could be both -- and then we’ve also got some very large influential vendors, BEA, Cisco, IBM, SAP and HP.
Tell us a little bit about what the goal of this organization is -- combining, I guess, the constituencies of the end-user issues and vendor issues. You’ve had some of these closed-door summits over the last several weeks to come up with a charter. Tell us what you can about what took place at these events and what is shaping up as the charter, given you’re straddling the fence between the user and vendor organizations.
Soley: It’s important first of all to note the mix of users and vendors. We are currently running 3-to-1 end-users to vendors, and that’s because the focus is on this advocacy activity. It’s not on whose SOA infrastructure we should buy and "Our Web service is cool," or any of those questions. I am guessing that we are actually going to be more like 5-to-1 or 10-to-1 end-users to vendors eventually, but, as you can see, on Feb. 12 four vendors stepped up to the plate to fund it and get it off the ground. They were BEA, Cisco, IBM, and SAP. As an old consortium hand, I listed those in alphabetical order.
You also saw, as you said, some very dedicated end-users who have ideas about how to get the idea across to the lines of business that this is not a technology play, but a business agility play. Some you didn’t mention, for example Wells Fargo, and, of course, Object Management Group ourselves are a member, as well as the Integration Consortium. So, that’s another differentiator from OMG, which is about half end-users and half vendors. We expect that the SOA Consortium is going to weighted toward end-users, although there will be a couple of sponsors joining.
Gardner: So, with this predominance of users, what do they say? What do they want your organization do for them?
Soley: Number one, they want to be truly vendor neutral. Over the last two years, there have been various alliances of vendors saying, "We have created this" – their usual common phrase is -- "SOA alliance to help our customers understand the products in the SOA space." That’s wonderful. That’s all well and good. That’s how the industry works.
But you notice that there are always one or two vendors and one or two of their top customers. This is four major vendor-sponsors, a couple of more that are participating and might be sponsors later, and a lot more end-users, because what they are looking for is understanding the business strategy, not trying to decide which product to buy to "SOAfy" their infrastructure. That’s a very important differentiator.
They are not building reference models. They are sharing case studies. For example, our enterprise architects and our community of practice is showing case studies of success stories and, more importantly, failure stories, best practices, what works, what doesn’t work? We have even had sessions on how to influence project managers and product managers in the line of business to understand business strategies in general, rather than think of us as “the guy who fixes my Treo.”
We received a lot of feedback from CIOs and CTOs during the [early] summits that said this is very important. We had a Fortune 100 CIO who came into the New York summit. This person is CIO of a multi-billion dollar travel organization, and the opening gambit that we heard was, “Look, this is just a technology play, and if one of my technology guys hadn’t told me I had to be here, I wouldn’t be here. I’ve already told the CEO that SOA is a technical thing, and we’ll take care of it.”
At the end of the summit, this particular CIO stayed an extra half hour and said, “The most important thing I learned is that I can now understand how I can position this as -- rather than a technology play -- a business agility play. That will support the efforts that I am making to make our business processes understood, to write them down in a way that’s reusable and discoverable, and in a way that I can make them more efficient. And, I am going to go back to the CEO and say it’s not a technology play.”
[Editor's note: More news has come from the SOA Consortium since this podcast recording.]
Gardner: Well, this gentleman obviously had not been listening to our podcast series. Let’s go to the panel.
Steve Garone, we’ve talked about advocacy and evangelism, and the intersection of the business and technology values around it for quite sometime now, and we’ve mentioned that politics is an important aspect of this cultural shift. Do you think an advocacy group like this is a good thing for the politics, in terms of getting people on the same page? And, what would you pose as some of the necessary ingredients for success for an activity like this?
Garone: It’s a great question, Dana. First of all, Richard, that sounded like a great case study, and certainly makes the case that this group is going in the right direction. The issues that seem to surface come from two directions. One, and I know, Richard, from some of the information I’ve seen in this alliance, that you guys have considered this, is that many organizations that have gone through some SOA activities up to this point. These have focused primarily, and in some cases exclusively, on cost saving and not business agility. Getting that message across I think is a very important issue, in terms of getting acceleration around SOA adoption.
Obviously, it's very important to convince the higher-ups within an organization that this is something that they can benefit from, from a business standpoint. One of the key issues also is that there tends to be sort of a push-pull, or a lack of communication and understanding, between the business functions within an organization, and that, from the line of business standpoint, can certainly benefit business agility and the IT folks. Of course, there's been a lot of activity around tools, standards, and technologies to help bridge that gap, but I think it’s still a pretty important issue. So, those are the major areas that I would look at, and it sounds like you guys are addressing them to some extent.
Soley: The first is a very important issue for us, and second is a really tough one to get past. IT has traditionally focused in most organizations on what are the right tools to achieve what lines of business are telling us we need to achieve. Sure, there are going to be tools and there are going to be technologies and there are going to be frameworks to help you implement the SOA strategy, but it’s the other way around. It’s "What is it we need to achieve?" And, what we need to achieve is fairly easy to explain, right? What we need to achieve is capturing business processes, so that we can find them, so that we can make them more efficient, and so that we can reuse them -- and this is nothing new.
What’s new here is the message that we are not just talking about workflow. We are not just talking about processes that can be automated. We are talking about any of the processes, especially customer-facing, but any value-chain processes within the organization that we might want to reuse.
Gardner: I'd like to encourage any of the analysts to kick in with their questions. I'd just like to start off with a quick one. Richard, one of the things we come up against a lot, when we talk to our guests and we examine some of the events that are unfolding, is complexity.
People are baffled in that there’s just so much, and the more you dig down, it seems daunting. It seems difficult to manage things horizontally, and therefore you relegate it to projects and pilot types of affairs. Is there anything that you expect to be doing through an advocacy role, inasmuch as you understand and are participating in this, that can deal with helping people manage the complexity issues for SOA?
Soley: You know, that’s a great point. I would like to answer in two different dimensions. First, as you can see, we are making top-down advocacy the core of what we do. If you start with your developers and try to work your way up, you are not going to change the way that company thinks about business process, and you are not going to have an effect on business agility. So, that’s why we're having the CIO Summits. And we will be continuing to do those.
Starting in June we are planning on doing them quarterly with a small number of CIOs and CTOs, government agencies, large corporations, as well as non-governmental organizations (NGOs). We actually had an NGO participate in our San Francisco event. We'll use those events not only to make sure we stay on track, but also to get the word out about what we are trying to do here, which is a top-down focus on business process and business agility.
By the way, that’s working. The participants at the events we had were very enthusiastic about the consortium. There was active participation throughout the sessions. In fact there was so much interaction that the round table discussion, which was supposed to be after the presentation, was embedded within SOA Consortium presentation at every stop. So, that’s one, and I’ve lost the thread for the second. I should have written it down.
Gardner: That it was kind of complex.
Soley: Yes, there is complexity involved in capturing the business processes in a way that makes them reusable and discoverable and to make them more efficient, but you always are going to have that complexity, and the question is, "Where is the complexity best spent? Is it best spent upfront, so that I’ve got a description of the process that I can reuse, find, and make more efficient, or is it best spent by the people trying to implement the process, looking at an ambiguous description of a process, in, at best English, and trying to figure out every single time, what in the world it means?"
I would rather do that once, capture it upfront in a rigorous fashion, rigorous both from the standpoint of how it’s captured a formal language, but also the way that it’s captured, having the methodology in place -- spend that extra money upfront and have the savings every time the process is carried out and reused.
Gardner: Anyone else out there have some questions for Richard?
Kobielus: There’s definitely a value for an advocacy organization like this to spread best practices regarding SOA and SOA deployment and management. You mentioned that one of the functions of these – for lack of better term, dog and pony shows -- meetings in various cities is for the CIOs to share both the success stories and the failure stories regarding SOA deployment. How eager are CIOs to share their failures and their screw ups in implementing SOA?
Soley: You saw how carefully I didn’t mention even the gender of the CIO who made that comment in New York. I will admit there was one time we had to turn off the tape recorder, which we were using just to have notes so we can get the quotes right later on. They are willing to share. We find this at the level of CIOs and CTOs, as well as at the level of enterprise architects. They are willing to share failure studies, if they have the safety and security of knowing they are not going to be quoted, it’s not going to be on their performance reviews, and they know that others in the room are going to do the same.
Listening to one of these stories, actually it was in San Francisco, gave me an instant flash to my kids high school in Lexington, Mass. It blew me away the first time I saw this. There's an enormous board in one of the major cafeterias. It’s labeled "The Board of Rejection," and all the kids post their rejection letters up there, and I thought, "My God. I never could have done that 30 years ago, when I was graduating high school."
But kids write notes on them and say, "They don’t know what they missed," and "You’ll get accepted somewhere else." And, they really help each other out. I think they all understand that failure stories are just as important as success stories. In fact, more important, because it’s very difficult to justify cost savings. It’s far easier to justify increased revenue. So, they do it and I will admit that the enterprise architect level folks do it more readily.
Kobielus: Which leads me to another question, I am looking at the initial membership of the SOA Consortium and I don’t see any consultants or a professional services firms.
Soley: Yes, systems integrators (SIs).
Kobielus: Those are the folks who see the broadest range of SOA implementations, successes and failures and they themselves quite often are a key component of those successes and failures. Why don’t you have the SIs involved in the consortium?
Soley: That’s a great question. In the three weeks since we’ve been live; you are only the second person to think of that. So, well done. In fact, amazingly, the entire idea for these summits was from one of the big four, a very active person who has been participating in all of the meetings. Unfortunately, their entire management restructured the day the membership agreement was supposed to be signed. So, we are talking to all of them obviously, and, in fact, unsurprisingly, IBM is participating from two different parts of the house, and one of them being, whatever IBM Global Services is called -- today is Friday, so it must have a new name.
I expect to be able to make an announcement about another major one in the next couple of weeks. We are talking to all of them. Come along to a meeting. Maybe you will see the one that I am talking about, but I really shouldn’t mention them until they can get their own processes back in order and get involved. It was really depressing to have this gentleman come to all the meetings, actually lay out the entire structure, idea, and plan for the CIO Summits and then not be able to participate in them.
Kobielus: I'll bet it was frustrating.
Soley: It was very extremely frustrating for me and I think intensely frustrating for him.
Gardner: Seeing these individuals participating in the sharing back and forth of stories, methodologies, and lessons learned, sounds a little bit conceptually like an open-source project. I didn’t see in the initial release any mention of some of these SOA open-source projects involved, whether it’s SOA Tools Project within Eclipse, or Tuscany within Apache, or some of the success in the field, such as ServiceMix. Is there a role for open-source projects within this consortium?
Soley: I'm going to go out on a limb here. Didn’t I say SOA is not a technology? When I hear "SOA tool," or "SOA development tool," or "SOA testing tool," I have to wrap my mind around that, because SOA is not a technology. It’s a business strategy.
So, I think what you really mean is "tools for implementing processes that are defined using the SOA approach." These are tools for testing implementations of processes that are defined using a SOA approach. If what we're talking about is business strategy, then software is an implementation technology. It’s not the strategy, right?
Gardner: Well, they still have a relationship?
Soley: Yes. So, let’s look at any of those. Commercial products, by the way, are no different. They implement processes that are defined by a methodology that’s part of your SOA strategy, or maybe they help you implement the methodology itself. There are tools to do that as well, and some of those are going to be open source and some are going to be commercial. There is definitely room for participation, and these vendors that have put money into the creation of the SOA Consortium obviously want to sell products and services. The good news, however, from the point of view of the end-users is that the purpose of the organization is not to help them decide what product to buy.
I will tell you, sitting around the table, enterprise architects share experiences of which products have worked for them and which haven’t, and I have seen marketing reps from our vendor participants scribbling down notes, because they want to sell more product -- and more power to them. I'm a capitalist. But whether it’s open source or commercial, software is an enabler, software is an implementation technology, but it’s not a business strategy.
Garone: I wanted to follow up on Dana’s question, because I was thinking in the background as you were talking about what the Consortium is actually doing and who is participating. Given its charter, what's in it for the vendors and how they are participating, if, in fact, this is not about generating standards that all the vendors can leverage, and it’s not about selling product, which of course it shouldn’t be and it isn’t?
I am sure that they get value out of being there, out of being in front of CIO’s and other end-users, out of taking notes, as you said, learning where their products are selling and where they aren’t. But I'm interested in the mechanics of how they participate, what they bring to the table, and how they interact with the CIOs in a way that brings them benefit?
Soley: First of all, I should mention that at the summits none of the vendors were allowed. In fact, none of the members were allowed. They were run as focus groups, because we wanted the CIO-level executives to be able to talk completely openly about their case studies, their success stories and failure studies as well. And, we wanted their honest feedback on the organization. So, no one else was in the room, except for the executives that were able to come and two OMG staffers, including me and Brenda Michelson from Elemental Links, who is the consultant who put together the vision-mission strategy goals and tactics document. She then presented that to these executives and then ran focus groups to get results and is now finalizing those documents, which we call the core documents about the organization.
The vendors have been in the room at all the other meetings, of course, and they have their own SOA strategies to implement and their own business processes that interest them, but there’s money coming from marketing departments and they want to get out in front of these users and say, "Look. We are leaders in this field, we understand how to implement an SOA, we have tools to help you with the implementation of your architecture, and we have run-time executables to manage the implementation."
Those go from anything such business-process description languages as BPMN to capture business processes, SOA governance product for keeping track of what processes you have, and making sure they follow the corporate rules and implementation of technologies.
It's no surprise that IBM mentions WebSphere, and that BEA mentions WebLogic and AquaLogic, and so forth. The group from Cisco, for example, the AON group, is all about capturing SOA and implementing it on your network. The group from SAP is changing completely the way that they implement their own products and integrate them with the other products they find in their customers, to be able to say to their customer base, "Look, we are leaders in SOA and one of the proof points is that we took sponsorship positions in the consortium."
Gardner: You know, Richard, one of the problems that we have encountered in the field around SOA is that it’s hard to measure success. There are long-term and soft-types of implications, and I suppose that the same could be said for something like this consortium. How do you measure the success of what you’re doing and have you put any milestones out there for what you'd like to attain?
Soley: That's an extremely good point, and actually one that came up at every single one of the executive summit events. We worked on that for a long time and came up with the loosey-goosey measure of self‑identification.
So, the overall goal, which you see on our Website, is 75 percent of the global 1,000 self identify SOA successes by 2010. There is an asterisk that mentions that we are also talking 50 percent of medium‑sized businesses and 50 percent of major government agencies. Because we couldn’t pull some measure of success off the shelf, we went with self identification, and at every single one of the summits we were told, "No, you are going to have to try harder. You’re going to have to deliver some metrics of success."
I don’t have any for you today, but I can tell you that that is something that we got very clear direction on from the CIOs and CTOs who participated in the summits. Also, they wanted us to look specifically, for example, at connections between SOA and Lean, Six Sigma, and ITIL best practices, all of which have metrics of maturity and success.
Gardner: Any other questions?
Kobielus: I think the industry is looking at the SOA Consortium or OMG to be a third-party certifier -- maybe that’s overstating your mission -- of enterprises' success or lack thereof in implementing SOA. So, it’s the extent to which you are going to be mapping these SOA best practices back to such recognized frameworks as ITIL, Six Sigma, and so forth that would be essentially what the industry is looking for you guys to do -- to catalyze that kind of mapping.
Soley: Yes, that’s a very good point, and, Dana, I thought you said that I wasn’t going to be get any hard questions.
Gardner: Sorry.
Soley: The SOA Consortium is looking to not only OMG, but other standards consortia, to deliver standards, mappings, and validation endorsement certifications where appropriate. In fact, it’s in the mission statement that the SOA Consortium is not a standards organization, but it will deliver requirements to standards organizations and where we were talking about modeling things, those requirements would be handed to OMG.
One of the 10 largest banks in the world sent an executive to one of our meetings, and this person said, that all they care about in terms of metrics of success are Lean and Six Sigma, so we're going to need to connect SOA to that world in order to be successful at that bank. I think that’s part of it, but there’s more than that. There are going to be metrics that are not yet in the stack when you fly through the ITIL, Six Sigma and Lean documents.
OMG, as it happens is moving into the direction of maturity models anyway. We are just starting work on a business-process maturity model. You may have read about it. It’s not a standard yet, but it was just starting. What were talking about is a maturity model for business process adoption that measures organizations and their ability to capture business processes. That’s very strongly related to SOA, but again, that’s a standard and belongs in OMG and not in the SOA Consortium.
Kobielus: One last question. Are you developing a maturity model for master data management (MDM)?
Soley: First of all, the SOA Consortium wouldn’t be delivering any maturity models at all. OMG has never delivered maturity models before, although we’ve expanded many times over our history, which is frankly why I am still there. This is a new area for us. We have to learn not only how to deliver the standard that specifies business process maturity, but how to deliver that, which means how to certify people, so that they can certify organizations at the five different maturity model levels that we are contemplating. So, no, we have never delivered any other maturity models and although there are lots on the books as potentials, let’s wait for 2008 to see what develops.
McKendrick: You talk about the SOA Consortium, and there’s a lot of discussion about business process management (BPM) and SOA. Obviously, these two areas need to converge as we go forward. As I have heard and seen, though, over the years, especially in recent years, that the BPM professionals and the IT or the SOA professionals tend to be in two different camps and kind of follow their own separate sets of disciplines. It would seem a challenge from the perspective of the SOA Consortium in bringing these two camps together. Do you see that as a challenge?
Soley: You bet, but that’s one of the results that we learned during the events. We are very worried about that. Obviously, I strongly believe that BPM -- and now I am not talking about technology, just managing business processes -- is a key part of the SOA business agility message. I also believe that BPM technology, like our own BPMN standard, implemented by 40 some vendors, is a great way to capture business processes. But, we have been worried since day one that you’ve got your business process owners, your Six Sigma experts, and business process offices in companies, and they seem to be different from the IT definition of BPM.
One of the things that we heard in every event from all the participants is that the CIO and CTO participants did not artificially separate SOA and BPM by the underlying technology. They see business processes and services tied to a cohesive enterprise architecture foundation as a major message of SOA. That message has been received at the high level, and what we have to do is help the C-suite, get the message down into the lines of business and down into the IT organization, that a business process viewed as a methodology by business process improvement office and business process viewed as a business process notation in the IT departments are the same thing, and they ought to be working together more closely.
Gardner: Great. Well, thank you, Richard. Obviously, there are so many constituencies involved inside of organizations, and then also involving their communities, and there are vendors that are herding the cats, as it were, toward SOA as a worthwhile, important, and difficult activity.
Soley: Yeah, no problem, though. These are cool cats.
Gardner: I wish you well. Moving on to our second subject, I just came back from EclipseCon in Santa Clara, Calif. [in March] and there were few announcements there I would like to go over quickly. Tony, you wrote about the Oracle move with its Java Persistence API. Tell us very quickly about that.
Baer: Well, it’s been an interesting strategy, because the fact is that Eclipse was initially known for IDEs, and Oracle with JDeveloper is one of the few major Java players, outside of Sun, who is not migrating its IDE to Eclipse.
In the past year or so, Oracle has been involved in a number of Eclipse projects. I think putting its feet in the water. What’s interesting is that they are now ramping up to board level by saying, "No, we are not going to IDE. We are going to instead work on Java persistence and essentially they are trying to coalesce it around top tier, which is their implementation of the Java Persistence API.
It’s actually the update of what is essentially about a 10-year-old product, and what the interesting thing is not so much what Oracle is doing, but it’s more reflection of Eclipse saying, "We’re more than about IDEs."
Gardner: This is runtime material, right?
Baer: Exactly, and that begs the question that I have asked the Eclipse folks as well. If you’re not just IDEs, which is what we’ve associated you with, what are you? What is your mission, and where do you draw the bounds on it? Their answer to that was, "Well, we didn’t initially form ourselves to develop an IDE. It was the idea of trying to be a proof of concept to show that you can have an extensible framework to this plug-in model."
Gardner: Around OSGi?
Baer: Well, OSGi came later. They initially tried their own plug-in model and realized, "Why are we re-inventing wheel?" OSGi just happens to work. The whole rest of the field just discovered OSGi, kind of by chance, in the same way that all the AJAX folks discovered you can use Java Script, XML and a whole bunch of other stuff together and get rich clients on the Web.
That was not the original intent of OSGi. It was supposed to be basically a home box, which would essentially Java-enable your toaster or refrigerator, and we can see how far that’s gone. But, what we have found is that it’s actually a very effective, hot-swappable component model. So, that’s what Eclipse has really capitalized on, and they are seeing that as being some of their proofs of concept to say, "Now, let’s see how far we can take this."
Gardner: I had two take-a-ways, one was that this seems like mission creep for Eclipse, that they are getting more into runtime, and not just on the client with their rich-client platform, but now, increasingly on the server. The second thing was this. Oracle, as a major vendor is going to be driving a lot of the innovation around this project. The proposed project under Eclipse has moved the project in the sense out of GlassFish and around the Java community, and they will keep it as a Java reference implementation. But the innovation will be happening at Eclipse. And then any of the changes will only then move downstream into Java.
So, my take-a-way was: one, mission creep for Eclipse into runtime, but secondarily some diminishment of the role of the Java environment for innovation. Anybody have reaction to that?
Kobielus: Actually before everybody else jumps in, I just want to top that. You have mission-creep for Eclipse, and it sounds like you could also say "mission accomplished" for IBM, because I think one of the original goals in getting Eclipse going was to essentially move the center of gravity in the Java world away from Sun.
Gardner: That seems to be happening, doesn’t it? Richard, what do you think of that?
Soley: This goes back to the conversation we were informally having at the beginning of the call, about mission creep and expansion of Eclipse goals, and where the organization goes. I think there’s sufficient demand in all of these areas, that some organization has got to get their arms around it and deliver. As long as that delivery happens, I think it’s the right thing for the user base.
Gardner: I'm not sure I understand.
Soley: Whether it’s commercial or open source -- and you hear me say "whether it’s commercial or open source" a lot -- you need product that delivers against a user requirement. My response in this was something I was saying earlier to Tony’s note this morning about results of EclipseCon is that expansion of mission is perfectly fine as long as you continue to deliver on each of the elements of that mission.
Gardner: Well, one thing I can tell you as an observation is that this is a very energetic environment. A lot of developers that had the feel of what Java 1.0 was about seven or eight years ago, and many, many vendors that I speak to, recognize that the Eclipse community is a force to go with and not to ignore. Many of them are creating plug-ins -- be they commercial or open source -- in order to ride the marketing machine that the Eclipse involvement has become. So, this is something that’s got a lot of momentum, and at a time, as I think Tony pointed, out that Java is losing momentum?
Soley: You can’t have both of those at the same time, right? A big message of Eclipse is the Java message. Eclipse supports other programming languages as well, but the success of Eclipse is the continued success of Java. So, let’s be fair.
Kobielus: One thing we have to distinguish is Java versus the Java community process. I think that’s really what they’ve meant.
Soley: Okay, fair enough.
Gardner: Where did the innovation take place? Is that kind of the point?
Soley: The open-source model has proven to be a very successful one in the Java community.
Gardner: Well thank you everyone for joining, we’ve had an interesting discussion, and again I want to wish the SOA Consortium well, and OMG as a participant in that. I guess you’re taking a leadership role in this Consortium. Is that fair?
Soley: I am the executive director of the consortium, yes.
Gardner: Well, thanks everyone. We’ve been talking again about SOA, your SOA Insights Edition, Volume 14; our guest has been Dr. Richard Soley, chairman and CEO of OMG. Thanks for coming, Richard.
Soley: No, thank you for arranging. It was a pleasure, Dana.
Gardner: Also joining have been Steve Garone, Joe McKendrick, Tony Baer, Jim Kobielus -- thanks everyone for joining. I am your host and moderator, Dana Gardner. Thanks for listening.
Listen to the podcast here. If any of our listeners are interested in learning more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, please fill free to contact Interarbor Solutions at 603-528-2435.
Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 14. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.
Subscribe to:
Posts (Atom)
