Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition, recorded Oct. 20, 2006.
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 Dana Gardner at 603-528-2435.
Dana Gardner: Hello and welcome to the latest Briefings Direct SOA Insights Edition, a weekly discussion and dissection of services oriented architecture- (SOA)-related news and events, with a panel of independent IT Industry analysts and guests. I’m your host and moderator, Dana Gardner, principal analyst at Interarbor Solutions. This week, the week of October 16, 2006, our SOA panel includes Steve Garone. Steve is an independent industry analyst, a founder of the AlignIT Group, and a former vice president at IDC. Welcome again to the show, Steve.
Steve Garone: Thanks, Dana. It's great to be here, and I’m looking forward to some spirited discussion.
Gardner: It’s always spirited on SOA, and no one agrees on anything, right? Also joining us for the first time -- and welcome -- is Neil Ward-Dutton, a research director at Macehiter Ward-Dutton, an IT analysis and consulting firm based in the U.K. Hi, Neil.
Neil Ward-Dutton: Hello, Dana, thanks for having me on.
Gardner: My pleasure. Also joining us as a guest is Jeff Pendleton, a former IT executive who has filled many roles, at BEA, HP and other firms. Welcome to the show, Jeff.
Jeff Pendleton: Thank you, Dana. Pleasure to be here.
Gardner: Thanks. Give us a brief rundown of your background, Jeff, so people can appreciate where you’re coming from.
Pendleton: Well, I’m pretty much a jack-of-all-trades. I spent 16 years at HP, alternating between IT, marketing, and operations management. So I got a pretty good, 360-degree view of HP, and how it approaches the world. I made a run at a startup, spending a year in the garage, working on a SOA appliance startup with a bunch of really smart guys from Cisco, just before Cisco announced their whole Application-Oriented Networking (AON) initiative.
So I played around with that. I picked absolutely the wrong time to try to launch a startup, in 2000-2001. Then I moved over to BEA about four and a half years ago and ran their IT group, ran their education services division. And then I moved over and began a role as a BEA SOA community development evangelist, and also ran the product marketing group -- the whole AquaLogic, WebLogic, and Tuxedo product marketing function.
Gardner: And you’re not affiliated with any particular vendor at this time?
Pendleton: No, I left BEA at the end of May to really look at SOA from a different vantage point.
Gardner: The first major topic of discussion is the convergence of SOA and open source. This is an interesting development. We have a number of different projects in incubation and being supported by a variety of different contributors, including some of the largest vendors in SOA and software infrastructure. These projects run the gamut from approaches to tools into runtime governance, enterprise service bus (ESB), and even the possibility of some frameworks. These include some complete frameworks, stacks for SOA within an open source environment, as well as promoting and developing a commercial open source business model, a variety of which we’ve seen emerge in the past several years.
We’re also going to discuss this week the topic of SOA and market evangelism, and that’s primarily why Jeff is here. The idea is that SOA is a concept, a methodology, a paradigm shift in the latest approach to IT, computing and applications. But the fact remains that there is no one entity that represents or sells SOA as a concept. SOA is being brought to market piecemeal, through standardization efforts, through commercial products, from a variety of perspectives -- not always with a lot of user input, or at least evident user input. And, so we want to discuss this whole notion of how SOA should emerge in the market -- whose responsibility is it to define it and promote it.
Let's get to the news around open source. I attended, just over a month ago, the EclipseWorld Conference in Cambridge, Mass., and talked with a number of folks here, including IONA Technologies, and IBM, as well as Eclipse Foundation, about a variety of different activities that are now under way, several of which are in Apache incubation.
So there’s not a whole lot of publicly available information about these activities, but let me just give you a quick rundown to demonstrate the breadth of what’s going on. IONA has an Artix commercial ESB, and they spun off an open source project from there called Celtix, maybe two years ago. They have now taken Celtix into the Apache Software Foundation, and joined it with Codehaus XFire, an open source Java SOAP framework, to create a new initiative, CeltiXFire (CXF).
CeltiXFire is aimed at providing an open source services framework, and it's going to join a number of other SOA-oriented open source projects, including the Eclipse SOA tools platform project. Also in Apache incubation is Yoko, a CORBA initiative. Also in Apache incubation is Tuscany, a services component architecture (SCA) initiative, and also Qpid, a message broker project that aims to define protocols -- in a sense take up where Java Message Service (JMS) leaves off.
So, there’s the possibility here of a rather robust and ecology-driven SOA infrastructure stack, that could play a role as an entire SOA approach for some enterprises, ISVs, and software as a service (SaaS) providers. Or bits and pieces of this could be cherry picked -- particularly, I imagine, from the tools perspective -- and used in conjunction with other commercial SOA products.
Let's take a quick level-set on this. How seriously should we take these open source SOA projects? Why don’t we begin with you, Neil?
Ward-Dutton: We should take them pretty seriously as people who look at the market. I think for too long the industry, the IT industry, and this community has not really looked hard enough at open source and freely offered technology products. It's time that we really should take them very seriously.
It’s interesting to think a bit about the distinction between open-source and free, and how much that matters to people, particularly to what you might call end-customers. Certainly, if you’re going to expand the definition to include free, but not necessarily completely open source, today you could just look at Sun Microsystems and what’s now called the Sun Java Composite Application Platform Suite (CAPS), which is basically SeeBeyond's old portfolio.
It's been reengineered to a degree to support SOA, and there’s a hell of a lot stuff in there, which is available at no cost whatsoever. As usual with the open source model, if you want paid support or enterprise support, you have to pay for that, but you can get the software for free. So, it's not just about Eclipse or Apache incubator software projects, it's also about the really big gorillas of the industry taking big steps toward making stuff freely available.
I don’t see why that should appear strange because this is all infrastructure. It's all boxes and wires, just plumbing, and increasingly that is commodity technology. We’ll get on in a bit to talk about the softer issues around SOA, and I think that’s where the real competitive differentiation, and the real challenge, actually come -- working out some of the more business-focused issues, and some of the more methodology-focused, and quality-focused issues.
Gardner: One of the things that I find interesting about the emergence of SOA, and the emergence of open-source SOA, is that this is happening very early in the development of SOA. We saw other open-source products, perhaps Linux, come a number of years after Unix and Windows were quite mature. And some people would even claim that there was some reengineering involved. Also the open source Apache Web Server followed the Netscape Web Server and Microsoft IIS Web server and became very prominent in the market, and so, again open source followed the commercial lead. What I think might be different here is that open source has an opportunity to lead the commercial vendors when it comes to SOA. Does that make any sense, Steve?
Garone: Yes, it does. I think what you’re saying makes a lot of sense, although I think it’s less of an issue in terms of the connection between open source and SOA, and more an issue of the timing of SOA. The reality is that open source, in the case of SOA, was around for a fairly long period of time. Whereas in the other examples you gave it wasn’t. So, you naturally expect the open source community to kind of jump on this new initiative, as it will with other new initiatives as they come along.
I agree with everything Neil said. I think it’s important to take this very seriously, which does not unfortunately imply that everything at this particular point in time has stabilized. One of the things that one likes to see when you talk about technologies and issues that are “open” is that standards bodies are sort of leading the way, and we see a lot of that. But, what ultimately happens, or what happens along the way, is that you get competition even on that level.
You see organizations like ObjectWeb and Apache, and others, going off and doing their own thing. In similar areas, some are supersets of others. But that introduces a level of confusion to the end-user. We hope that eventually that will shake out, but I don’t think in the case of SOA it has done so as yet. One interesting example of that, by the way, is the example you brought up of IONA and Celtix. Now, Celtix originally was hosted by ObjectWeb. I think one of the factors in that choice was the fact that IONA is a European company, and ObjectWeb is already active in Europe.
But now, what they’ve essentially done is move that technology, in the context that we talked about earlier, over to Apache Foundation. So, even in the case of one particular vendor, there wasn’t a lot of clarity over the last year or two in terms of where that technology would reside, and who would be leading the charge from the standard’s body point of view.
Gardner: Jeff, let’s go over to you. It seems to me another opportunity with open source is that the users, large enterprises -- something along the lines of General Electric, Ford Motor Co., General Motors, and Boeing -- can come in and say, "Listen, we want a seat at the table too. And we want to have a say in how these technologies evolve." So first, do you take these open source projects seriously, and is there something new and different here, where we are able to get end-user input, and an open source approach to some technologies that have not yet matured?
Pendleton: I spent the last couple of years at BEA, really looking at open source, first as a threat, and then one day realizing, as a lot of vendors have realized, that open source is actually a stimulus for change within these large enterprise software and hardware companies. When you’re sitting in the middle of these software companies you have these machines that you have to keep running, whether it's your maintenance streams, or your product streams, or what have you. And it’s very, very difficult to change those things without some sort of a very severe external catalyst.
So from my perspective, open source is innovating and causing innovation that the vendors are at first reluctantly but then wholeheartedly beginning to accept because they really don’t have much choice. But as I’ve talked to CIOs through the briefing center at BEA, what I‘ve noticed is there is a real fear -- and almost a deer-in-the-headlights phenomenon that’s occurring -- because there’s so much open source and there’s so much change.
What these folks are worried about is, first, they’re still a little bit in the woodshed from the last big, exciting IT wave. Second, they’re worried about the complexity of what they’re currently managing, and the complexity of all of these new ideas and standards that are coming out. To a certain extent open source is really having probably as much, if not more, impact on the vendor community to catalyze change there than it is in terms of really having a dramatic impact across the board in a lot of these enterprise companies. I think they’re selectively picking up open source components. But I think that, if anything, it's adding to just the churn out there. It’s an interesting dynamic, but as far as SOA goes, I agree open source really has been, arguably, a SOA poster child for years.
Gardner: In what sense?
Pendleton: Well, by the fact that we‘re talking about a lot of independent components that are really attacking very specific aspects of the plumbing of IT, doing it in a collaborative way, bringing the best minds together, and really providing a loosely coupled set of capabilities that then theoretically can be woven by architects and developers into a richer platform. I think that to a certain extent open source has been living the SOA loosely coupled federated approach for years.
Gardner: I suppose the only way that you could manage open source approaches is to divide things into small manageable chunks, and then develop those chunks in a way that they can be, at least to a large extent, dropped, like a LEGO piece, into an existing or heterogeneous environment.
Pendleton: What’s really cool about it is that you are able to draw people with passion and with a certain level of expertise into that specific LEGO, and so you get a much richer service offering. Then you look at the vendors, and they take that and blend it into their capability over time. So you really start to get those composite effects when you blend what’s happening in the standards world with what’s happening in the vendor world.
Gardner: Do you think we can take this another step further, which is to say that we might not even be at this level with SOA as we define it if open source were not such a major trend at this time? Would we still be looking at monolithic SOA stacks from specific vendors?
Pendleton: Are you asking if the movement toward a comprehensive stack for SOA would not be as far along without open source?
Gardner: Well, SOA has loosely coupled parts that use messaging and a variety of technologies across boundaries for purposes of integration and process refinement, and publish-and-subscribe capabilities. Would we even be at this point, in this openness, if open source as a trend were not an accelerant or a catalyst to promote that?
Pendleton: Having lived through a multi-billion dollar experiment at HP, I would say the reason e-services -- as a vision for the industry -- didn’t succeed back in the mid- to late-1990s was because we only had within our portfolio the existing monolithic, tightly integrated capabilities. There were no standards. I was trying to build basically an SOA, a billion-dollar SOA prototype, with no standards, no open source, really a very narrow gene pool to work with. What we ended building was another monolithic stack from a very poor source of ingredients.
So, yes, I absolutely agree that open source has in many cases created a richer gene pool for us to create the next wave of IT.
Garone: I would agree with that to a limit. I don’t think you needed open source to be able to move in the direction of openness and interoperability to the level that’s required for SOA. What I think open source might have done is sort of held back the tendency of vendors to add their own little hooks, and their own little proprietary extensions and so on that often take open standards and industry standards and make them a little more difficult to work with in terms of putting together a solution with components from a lot of different areas.
Gardner: Perhaps this is a three- or a four-leg stool, and SOA is the top of the stool. The legs that are supporting it over time, and we need all of them there, would be open source, open standards, and the move toward distributed Java computing over the last 10 years. Perhaps a fourth standard or pillar on this would be this notion of the extended enterprise. If we didn’t have the need for all of these things, or they weren’t in place, then perhaps SOA would not be as we know it. Does anyone want to react to that?
Ward-Dutton: I’ve been kind of scratching my head for a couple of minutes, so I’m glad you mentioned the last leg there, Dana, because I was going to jump in and say that there has to be a need for it as well. Maybe when you said "extended enterprise" computing, that captures that. Certainly SOA would not be here if people didn’t actually need it, and that’s actually the biggest hurdle that we collectively have to help people get over. It’s not primarily a technology question anymore. It’s actually convincing people that SOA is a good thing to do.
Gardner: It’s about the business.
Ward-Dutton: That’s exactly right. It’s about explaining why a SOA-approach to delivering IT capabilities is really a sensible thing do, given challenges: connecting organizations together, dealing with transparency, and compliance initiatives, becoming more effective -- that kind of cross-departmental business processing.
Gardner: That makes for a very nice natural segue into the next major discussion point today, which is this notion of evangelizing and educating on SOA. But before we go there, I want to ask one more question on open source in SOA.
I’ve heard several people theorize that the number and complexity, as Jeff pointed out, of the open source projects and componentry are going to be a bit overwhelming for your average enterprise. Therefore they predict a consolidation, and we’ve already seen that with the Codehaus and the IONA Celtix combination.
So what’s going to be the right balance between this componentization within an open-source environment of SOA and the need for simplicity, and a bit more integration and unification around a common approach, or at least a common methodology that might give you some choices among the components you choose or use? What do you think the market will require for this balance? And I will go to you first, Steve.
Garone: Well, that’s a really good question. And it’s a good question because it’s an interesting one for decision-makers. It’s also a very difficult one to answer.
For me, the criteria are not going to be so much: To what degree do we componentize versus have a more integrated approach for some application domains. To me the real issue is how do you transition an organization? Neil used the words "make the business case," and it’s a good thing to do.
It's also important to make the case that SOA is not a bad thing to do. And where that manifests itself is in: "What do I have installed today, and how do I best leverage that within the context of a SOA-based environment." To me, the answer is not so much how many components I use, how granular are they, and how much variety I have, but rather, "Can I make new application logic that I build within a SOA context componentize, and so on? Do I make that work well with what I already use, and what I already have installed, from the standpoint of applications, especially enterprise applications?"
Gardner: How about you, Neil? What’s your position on the proper balance between open source componentization in SOA, and an open source integrated stack approach?
Ward-Dutton: I think the best way to answer that question is to think about supply chains, about the delivery of software as a supply chain. The degree of componentization that makes sense depends on where you sit in that supply chain.
The degree of componentization we have historically had and what we are experiencing now is the reflection of two things. First off: The main people who are actually doing something with this stuff aren’t end-users, but they are really getting in there and making things happen. They’re still actually within the supply chain. They’re not at the end -- that’s one.
The other is that where it is an end-user situation that’s occurring where those people are playing, those are very leading-edge adopters of technology. And so there’s a high degree of tolerance for a high degree of componentization of these things. As the market matures I would fully expect to see much lower tolerance for that, and a much greater interest in aggregated offerings.
So you look at what SpikeSource does, for example, or you look at the announcement from Novell a couple of days ago around integrated stacks of Novell technology, IBM technology, open source, closed source. As you get into segments and scenarios, which are less leading edge, they actually want the reassurance that comes with bundling, and that comes with aggregation and comes with, "Don’t tell me about the details, just tell me it works."
It’s a question of maturity, of where you sit in the software supply chain. To a degree we're kind of dancing on the head of a pin, because -- don’t forget -- this is open source. Although there is a consumer predisposition to a certain level of granularity, actually it doesn’t really matter. Because within a project if someone wants -- metaphorically speaking -- to break something up within an aggregation they can absolutely do that because it's open. So, they can break something apart and mess about with it that way.
Gardner: Right. I would like to answer my own question through a little slightly different lens or focus, and that is around the politics, or the power politics, within infrastructure decisions. If I were an enterprise I might look to bring in open source components for those which I view as most likely to be a lock-in type of a technology. I might be more comfortable going with a commercial vendor on parts that I think will remain in some competition, and that I might be able to pick and choose among different commercial vendors as well as open-source components.
But for something perhaps like an ESB or a data-services approach or framework, and certainly from a tools perspective, I might be more inclined to go open source so that I can avoid lock-in and provide myself with a reduction of risk moving into the future, a future which I have very little insight into. Can you react at all to that, Jeff?
Pendleton: Well, that comes from a position where the architect is a key decision maker within the IT community. In organizations where architecture matters that makes a lot of sense. But my experience is that there’s kind of this interesting politic within IT communities where a lot of the open source decisions are still being made by what I call the "fighter jocks" that are in the development organizations.
To a certain extent they are bringing open source in because it makes their job a little easier, but also because it's cool. It's interesting to look at the political dynamic that’s happening right now within IT to figure out how to break that architecture-vs.-developer struggle that’s going on. So when you talk about bringing in choke-holds and things like that, it makes a lot of sense when the architects are in charge. But it’s a different kind of flavor when the development organization, which is being sponsored by a powerful line-of-business team, is really trying to drive an innovative piece of applications. I don’t argue your point so much as I think its only 50 percent of the equation. I think that a lot of the open source is coming in because it’s cool.
Gardner: Does a SOA by definition require a bit more coordination, communication, and harmony between the development teams and the architects -- and even the operators?
Pendleton: Architecture, and I mean the "A" in SOA, is really the defining element -- and the disruptive element. In my opinion that is going to really define the enterprise of the 21st century. And I’m not just talking about IT architecture. So, absolutely! I’m just pointing out that I think we don’t really have strong architecture in most corporations today.
Gardner: So people are often still thinking tactically about different parts of this but not holistically from a strategic overview?
Pendleton: When you talk about not wanting to get locked in it's generally something that’s more applied to vendor lock-in, traditional vendor lock-in, and it's generally more of a decision that’s being made by the CIO for very pragmatic reasons. But when it comes to open source there’s still a fair amount of the old West cowboy activities going on in most IT organizations.
Garone: If I could just jump in and add something briefly. That’s a great point Jeff, and in fact in my experience, especially over the last year or two, SOA within organizations has typically been done on a small scale, a pilot project and so on, which would be initiated in many cases by the development community by establishing a set of technologies. Maybe it's an ESB, maybe it's an application server, or open source in the situation we’re talking about here.
Then, when it comes time to expand this, when you have success, you want to expand it throughout the organization, and only then do the architects get involved. Now, you’ve got a technology and a basis of experience in a particular technology and there’s an incentive to some extent to stick with that. I think that’s really where what you’re saying comes into play.
Gardner: Well that makes another natural segue into our next discussion point. And that’s about how we evangelize and educate the concept of SOA as strategic, as architecture, as a long-term approach, when we’re still stuck in kind of a tactical decision-making process, and we have a variety of different vendors, and open source projects approach to componentry on the tactical level.
Let's start with you, Jeff. Perhaps you can explain some of your thoughts about evangelizing SOA and why you’re heading in that direction, both as defining the problem and then perhaps we can all think about some solutions.
Pendleton: Okay, as I mentioned early on I’ve been suffering from schizophrenia for a number of years, in the sense that I would be on the IT side really trying to drive application development. Then I’d jump over to the general management side. It was always amazing how my perspective on IT would change, depending on which hat I was wearing.
In one case, as IT, I was trying to bang the table saying, "We can really add competitive advantage here," and then moving over to the other side and looking at IT as an inhibitor and a road-block to achieving my quarterly numbers, and IT as something that was very, very expensive, and very risky.
So when I looked at SOA and talked to a lot of customers we were all in agreement that SOA was very, very disruptive, and in fact probably will be the defining element of the 21st-century enterprise. But for some reason we weren’t able to bring that message to the line-of-business guy, who still had this parochial, or somewhat skeptical, view of IT. They just weren’t hearing and understanding the potential.
So this summer we brought a bunch of folks together from some of the fiercest competitors, from some of the largest companies, to start talking about what is it about SOA that really is going to the define the 21st-century organization. I’m not sure we have the answer yet, but one of the things that we’ve noticed is that the vendor community is preaching to the choir for the most part. They’re talking about the power of SOA to folks who kind of understand the potential of SOA.
But when you go to the people that really need to see IT as strategic again we’re delivering messages like "agility," "flexibility," "adaptive," "liquid," which are like motherhood and apple pie. The real challenge is telling what it is about SOA that's so disruptive because I’m not sure line-of-business guys are going to care about SOA any more than they cared about client-server during the second wave.
What is it that is so disruptive? It’s not the LEGO approach per se because when I was at HP -- talk about a LEGO company; every LEGO was completely autonomous -- it was a cat-herding exercise. Loosely coupled was the HP way, and that didn’t work. Then you go to these large monoliths, where they have very much a top-down driven execution, and that doesn’t work.
So, what is it, and how do we start to make the potential of SOA a practical and pragmatic strategy? ... Make it something that IT people can bring to the business, so that the business people can say, "I get it, and what’s more, I can measure it, and I can see how it’s going to affect the various financial statements."
That’s what the industry is struggling with -- to break out of this preaching-to-the-choir marketing and really being able to take these very generalized notions of agility and LEGO-like use and translate them into something that’s consistent with what we saw with the second wave of IT, where we were talking about quality and the customer, and the notion of process core-competencies. We need things that business people can get their heads wrapped around, that are aspirational enough but also practical enough that they can execute over a couple of years.
Gardner: Let’s go to Neil. What sort of terminology do you think is required in order to bring to those line-of-business folks a business case for this fundamentally different IT approach?
Ward-Dutton: The challenge is that it's very difficult to say one thing that’s going to suit everyone, because SOA is kind of both everything and nothing. It's like dancing on a head of a pin.
Garone: Well, that message isn't going to work.
Ward-Dutton: Yeah, exactly.
Gardner: Well, that is the message right now.
Ward-Dutton: SOA, by itself, isn’t really anything. It’s just a way of thinking. It doesn’t do anything. You apply that way of thinking to a problem.
Just take a step back. The fundamental challenge we have today is that looking through five decades of “IT innovation” we’ve ended up in a situation where no one really knows where to go because the level of complexity in systems is so high, the level of brittleness is so high. Businesses change and changing requirements is very rapid.
The number of stake-holders involved in anything to do with IT is ridiculous. It’s a kind of locking up of the very gears that should help business and IT work together. And the reason we’ve got here is that business and IT together have kind of sleepwalked toward this situation because they didn’t have the ability to generate consensus between themselves that a short-term view had to be balanced with a long-term view.
You have to do both. What we have with SOA is a catalyst to start doing that. There are reasons and there are methods for actually keeping the short-term at the front of our minds, but also keeping the long-term in the picture at the same time. That comes back to be idea about architecture, but fundamentally it has to tied into the short-term because you can’t make something real that is about a "big" vision. People don’t buy it.
Even with business process re-engineering in the 1990s, it didn’t really work that well for everyone because they couldn’t sustain that level of commitment. There are a few poster children but it didn’t really happen broadly. So there have to be short-term tactical hooks, but at same time a much longer-term broader-value message just sits behinds it. And that’s the challenge we all face with SOA, because when you’re looking at the tactical side the message that an IT shop has to give to its “business customers” is absolutely tailored to that particular business situation.
That’s what I mean when I say SOA is everything and nothing. You can’t have one set of messages that works for both the long-term and the short-term story, and that works for everyone. Does that make sense?
Gardner: Yes, it certainly emphasizes the challenge.
Ward-Dutton: It didn’t give us your answer, of course.
Gardner: Well, you probably wouldn’t give it to us on this show, if you had it -- right? That’s probably a pretty valuable piece of information.
Steve, you and I have talked in the past about how risk reduction is a pretty good message around SOA -- that you can reduce your risk going backward in time, that you can leverage your investments and you can modernize and you can continue to deliver applications and services and data as people have been accustomed to.
But you can also reduce your risk moving forward, either into the foreseeable future where you know that you’re going to have certain requirements and a certain approach of agility, and you can reduce time-to-completion, and higher quality, and take advantage of a wider variety of services, and perhaps embark on some general reuse and object oriented principles. But you might reduce your risk even going beyond that into things you can’t predict and understand, or know yet.
But risk reduction is still also rather nebulous, and it's not something you can take to line-of-business people and say, "We’re going to reduce your risk. Can you double our IT budget?" Do you have any other thoughts here about the proper message that can be both tactical, strategic, IT, and business?
Garone: Wow! First of all, that was a great synopsis of the benefits and advantages of SOA. I think it’s right on. We’ve been talking here about the long-term versus the short-term, the tactical versus strategic and everything you just said, Dana, sort of plays into that.
To me the messaging, really the gap in the messaging, manifests itself in what you’re actually saying versus what you can actually demonstrate. It's the story versus the evidence. There’s no magic here. Vendors have for a very long time gone out to their prospects and customers with potentially very impactful and very interesting studies and case-studies that demonstrate ideally within their particular type of business how this technology has been used to create real advantages in terms of not only costs, but also in terms of business value and increasing the ability to do business more efficiently and so on.
To me that’s really the key. The messages are there, but the question is how do you demonstrate to a particular customer that this will work for them? For me, the only real way to do that is for vendors to work very, very closely with customers to make it happen for them in individual cases, and then bring that story to the rest of their customers.
Gardner: I think that sounds a little bit like a rehash of what we’ve been through for the last five years. After the dot-com bust, after the telecom bust, after the contraction in IT spending, everything was about ROI and TCO. And it sounds to me like you’re still trying to do an ROI-TCO cost-benefit analysis approach to SOA.
Garone: Certainly that's part of it but I wasn’t implying that it's all you need to do. Again, there are distinct advantages in terms of all the "... ilities" that you just went through that we recognize unto themselves, but may not be very effective to a business manager. If you then demonstrate those "... ilities" with real examples -- how it was done within their industry -- I think that can have a very positive effect. And, it’s not just restricted to numbers.
In fact I would make the case that not only should one not restrict yourself to that, but it maybe impossible to do anyway. A lot of the end users I know don’t really want that kind of information presented to people who are their potential competitors. Whereas in a qualitative sense they like the PR associated with being able to say we’ve done a really good job at this.
Gardner: Let’s get back to you, Jeff. Obviously we still need to work on the message. What about the messenger? We don’t seem to have a figurehead for SOA, like we’ve had in some cases in the past. We certainly had Linus Torvalds for Linux. We’ve had Larry Ellison for databases. We’ve had Bill Gates for client/server. Do we need a better messenger, in addition to a better message for SOA?
Pendleton: Well, I think there’s two sides to the coin. One is the messenger to the IT community, and then the messenger -- or messengers -- to the business community. The client/server, despite Bill Gates's evangelical power, was not what really catalyzed that wave. I don’t think line-of-business people bought client/server. They bought some higher level of abstraction. They were buying into the total quality movement. They were into this whole notion of core competency -- really understand your processes, and which ones add value, and which ones don’t ...
Ward-Dutton: ... And freedom.
Pendleton: Yeah. Go talk to SAP about taking over the processes that really don’t add value. That catalyzed the whole ERP wave, which catalyzed the client/server. There was this very interesting dynamic that met in the middle. What we don’t have right now are those inspirational, aspirational, definitional messages that define the enterprise of the 21st century.
Gardner: So we need a sort of a passion, and also a spiritual level to the drive to SOA?
Pendleton: Yeah, the Tom Peters way -- and that may be out of vogue. People may be very skeptical. But having watched HP spend billions of dollars executing strategies and then looking at the ROI after-the-fact, or looking at the ROI to justify a decision that had already been made, I think that we don’t yet have those agility strategies that will then drive the conversation with IT: When the executives ask, "So how are we’re going to do this?" and then IT says, "Well, it’s all about architecture, and look at what we’re doing with SOA." Somehow we need to marry what’s going on in the IT community with something equivalent in the business community.
Gardner: So, a complete narrative that brings in the tactical and strategic, and crosses the chasm between IT and business?
Pendleton: Yes, look at business intelligence. You can argue that it was catalyzed by Sarbanes-Oxley and all of the regulation, but the reality is that most corner-office executives really find out what’s happening in their business through interrogating their managers, and their managers' Excel spreadsheets.
How many guys are going to bed at night really wondering if they know what’s going on in their organization? The whole compliance-regulation thing has made it more powerful, but even without that as these corporations have gotten larger and more global it’s very uncomfortable to understand you don’t really have control. You’ve got this powerful enterprise with a lot of capability, and they want to know: "How do I bring that together, and bring a better offering to my customers, a richer offering? How do I get a bigger share of the wallet, taking advantage of my total enterprise?"
Gardner: Well you know who I need to invite on this show -- and I’ll go ahead and do it, but I’m not going to hold my breath -- Steve Jobs.
Pendleton: Absolutely. Everybody keeps coming back to that guy.
Gardner: If we could apply his genius of creating passion and drive around IT for its own sake -- never mind for these larger issues of strategy and ROI and TCO, which he usually doesn’t go to -- if we could get Steve to put his special sauce on SOA that might help a lot.
Pendleton: I bet he’d never even talk about SOA. I bet he’d never ever mention it, because that’s not what business people are buying. That just happens to be there to enable it but they’re buying something else, and that’s where we’re having the problem.
Ward-Dutton: Dana, it’s interesting the examples you gave when you were talking about evangelists. They were all really technical examples. Remember the point that -- I think it was Jeff -- made about people not buying client/server. I talked to people. Those guys were buying freedom. They were buying freedom from the shackles of the mainframe, which was something that was very closed, very powerful, and [freedom from that] held a lot of promise. A lot of people were very excited by it.
Gardner: It was mysterious. You never knew what was going on behind those glass doors.
Ward-Dutton: Right, and there was no way in hell you were ever going to get close to it. It was reserved because it was very, very expensive. In the mainframe era people bought dependability, efficiency, and accuracy because it was all about very high volume and very reliable transaction processing.
So that’s what people bought. They bought a tool to help them automate things that had to be done quickly and by rote, very, very dependably. In client/server, they bought freedom. They bought the freedom to use what was a radically different model of IT to devolve power and responsibility to individual lines of business. So it didn’t have to depend on those weirdoes sitting in the data center.
With e-commerce they bought into a promise of global markets, and the ability to radically change business models. SOA gives us all of those things, but the problem is that the IT community has created its pitch, as they would say over here. They’ve cried wolf too many times over their promises. Why should they believe us now?
The problem is that SOA actually does all those things. It helps organizations by aligning IT and business more closely. It helps organizations become more service-oriented and componentized, which enables organizations to more quickly adapt to new business conditions, enter new markets, compete globally, and do all that kind of stuff. It helps them be rock solid and dependable in how they get hold of information, so they know where they are. If you don’t know where you are, you can’t innovate.
Gardner: Let’s look at this lineage of freedom. We had the freedom of the PC, which then bled over into the freedom of client/server, which then bled over into the freedom of the web, which then bled over into web services, and is now bleeding over into SOA.
So, it's all about individual empowerment and freedom, which comes at a very auspicious time because this "echo boom," that is to say, the children of the baby-boom generation, are now thinking quite a bit differently. They like independence. They do not like a top-down approaches. They do not like to be told how to do things. They like to explore on their own, as evidenced by such things as Web 2.0 and social networking, and MySpace.
To appeal to this younger, echo-boom generation, we need to encourage that level of exploration on your own terms, individual approaches, not a cookie-cutter kind of methodology, but a kind of a messy, creative-chaos approach. So, do we take this continuation of freedom, and apply it in some better way to what services on your terms is all about? Jeff?
Pendleton: Well, freedom is great but when you have to hit your numbers every quarter, when you’re signing up for a two-year plan, you need to have confidence that you’re ultimately going to execute on a portfolio of strategies that execute against those management-by-objectives (MBOs). The MBO is what drives line-of-business guys.
I think that you'd want freedom to invest and enable some percentage of your strategy, but at the end of the day we’re kind of handcuffed by this need to hit our numbers every quarter and every year. I’m not sure how that’s actually going to manifest over time, but the last thing I would want to do is have more cowboys in my IT organization.
What I’d like to try to figure out is how to have a blueprint, and a strong architecture team ... imagine if you were building a corporate headquarters. You probably wouldn’t want to do that with just a free-wheeling set of cement layers and plumbers, and what have you. You’d probably want to have a really rich architecture and blueprint.
Ward-Dutton: It's about who has the freedom, isn’t it?
Gardner: But wait. I read about this guy, Frank Gehry, who builds buildings that look like they were put together by creative chaos, but are actually highly architected in order to make that possible.
Pendleton: But are there a thousand developers involved in actually building that blueprint. He draws the picture, and then he works with sub contractors and contractors to execute on that.
Gardner: Do you think this is a valid metaphor for SOA, a Frank Gehry-type architecture?
Pendleton: Absolutely! Positively! I was looking at a picture of a rabbit warren. I don’t know if you’ve ever seen one of those, but you take a bunch of rabbits and you put them on a 100-acre field, and basically you build the enterprise of the 20th century. It's just holes going everywhere. They just dig, dig, dig. It's kind of is a picture of what the architecture of most enterprises look like. We don’t have the same type of pride and passion going into the internal architecture and workings of the enterprises that we do going into the corporate headquarters.
Gardner: That very interesting, isn’t it? Perhaps from the IT architecture perspective we've got a Frank Gehry-looking application that actually is as messy inside as it is outside. But what we really want is to have an elegant creation that’s beautiful on the outside and the inside.
Ward-Dutton: It’s about the right freedom for the right people. You can’t build a creation in enterprise IT because change is too constant. So you can’t build something. You can’t build anything. All you can do is build scaffolding.
Gardner: You can build an architectural approach, right?
Ward-Dutton: Right. A great approach to architecture is to partition a business and to partition IT up into domains which have different qualities. Some of them will be very stable, and very predictable. And for those you can actually optimize for those things you may not use a SOA approach.
In certain areas, particularly around the edge of the organization, where you want to connect with customers, with partners, with suppliers -- where you really want to innovate in terms of how you build products and services, that's for SOA. Actually, you don’t want to build a building. You don’t even want to build an open-plant building, where you can move partitions and cubicles around, although that’s better.
What you actually want to build is foundations and scaffoldings, so that prefabricated chunks can be pulled together very, very quickly, and torn down very quickly. That’s not about building a building, it’s about building the tools to build and tear down bits of buildings very, very quickly. And in some places you want to do that and in some places you don’t. It’s about balancing the two.
Pendleton: Sounds like a Hollywood sound stage.
Ward-Dutton: For some bits of a business, absolutely. Not every thing.
Gardner: All right, gentlemen, I’m afraid we’re going to have to leave it there. We’re out of time, and obviously this is a very interesting subject that we’ll be revisiting over and over again. And perhaps we’ll get closer to how to best conceptualize, and go to market and provide messaging for SOA.
So I’d like to thank our guests, Steve Garone and Neil Ward-Dutton, as well as Jeff Pendleton. I’ve been your host Dana Gardner, principal analyst at Interarbor Solutions. You’ve been listening to a weekly Briefings Direct SOA Insights Edition. Come back and listen again next week. Thanks everyone.
I would also like to point out to our listeners that if you'd like to learn more about BriefingsDirect B2B informational podcasts or to become a sponsor of this or other B2B podcasts, feel free to contact me, Dana Gardner, at 603-528-2435.
Listen to the podcast here.
Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 3. Copyright Interarbor Solutions, LLC, 2005-2006. All rights reserved.