BriefingsDirect SOA Insights Edition, vol. 3: Gardner, Garone, Ward-Dutton and Pendleton on SOA, open source, and making the business case for SOA
Read a transcript of the podcast.
Welcome to the latest BriefingsDirect SOA Insights Edition, a weekly discussion and dissection of Service Oriented Architecture (SOA) and related news and events with a panel of independent IT industry analysts and guests. Yours truly, Dana Gardner, principal analyst at Interarbor Solutions, is your host and moderator.
BriefingsDirect SOA Insights Edition brings a new focus to the SOA thought leadership field by assembling noted independent IT industry analysts and guests to investigate the trends and news of the week. Take the content via this blog and excerpts, by listening to the podcast, and/or by perusing the full transcript of the discussion.
This week's panel consists of Steve Garone, a former program vice president at IDC and founder of the AlignIT Group, Neil Ward-Dutton, a research director at Macehiter Ward-Dutton, and Jeff Pendleton, a former IT executive who has filled many roles, at BEA, HP and other firms. The topics are the relationship between SOA and open source as well as a lively discussion on what SOA needs to be better accepted by business leaders.
Among the more intriguing issues of the day is the intersection of SOA and open source. There are 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. The panelists rate the important of SOA and open source as a tag-team.
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.
How should 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? The panel sees the business case as essential, but not necessarily by calling it SOA. Where's Steve Jobs when you need him?
Here are some excerpts from Gardner, Garone, Pendleton and Ward-Dutton in this probing show:
On open source and SOA:
... 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.
... 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.
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.
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.
... 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.
On ways to make SOA better appreciated:
... 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 incorporation, 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.
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.
... 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.
... Risk reduction is a pretty good message around SOA -- that you can reduce your risk going backward in time, if you will; 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?
Let’s look at this lineage of IT 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 by the way 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 approach. 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 a freedom, and apply it in some better way to what services on your terms is all about?
... 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.
Listen to the podcast, or read the full transcript for more on this week's SOA news and analysis.