BriefingsDirect SOA Insights Analysts on Software AG's Acquisition of webMethods, Web 2.0 and SOA, and SOA Hype Curves

Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition podcast, recorded April 6, 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, Volume 16, a weekly discussion and dissection of Services 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 blogger and Redmond Development News Magazine columnist.

Our panel this week, and it is the week of April 2, 2007, consists of Steve Garone, a former IDC group vice president, founder of the AlignIT Group, and an independent IT industry analyst. Welcome, 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. Welcome back, Joe.

Joe McKendrick: Good morning, Dana.

Gardner: Also joining us is Jim Kobielus. Jim is a principal analyst at Current Analysis. Welcome back Jim.

Jim Kobielus: Hey, Dana. Hey, everybody.

Gardner: And, Tony Baer, Tony is a principal at OnStrategies. Hey, Tony!

Tony Baer: Hey, Dana, how are you doing?

Gardner: Great, and joining us as a first-time guest is Todd Biske. Todd is enterprise architect with MomentumSI, an Austin, Texas-based consultancy. Welcome to the show, Todd.

Todd Biske: Thanks, Dana, thanks for letting me join.

Gardner: My pleasure. Because of the big news this week with mergers and acquisitions in the SOA space, we’re going to take that as our top topic. We’re going to look at the announced acquisition of webMethods by Germany’s Software AG. We’re also going to talk about the role of Web 2.0 and SOA and perhaps delve into the notion of using wikis for governance, control, and management of assets and process.

If we have time, we’re going to jump into a discussion about SOA hype. Is SOA over-hyped or under-hyped, and that might take an hour in itself just to get started.

The news this week came as a surprise to me, and I think to many. Germany’s Software AG, a company with database and tools assets, best known for legacy implementations, legacy support -- and perhaps moving more toward modernization and, therefore, SOA -- for about $550 million in cash has announced an agreement to purchase webMethods based in the U.S., in Virginia.

WebMethods itself has recently gone through a series of acquisitions, including, most recently, Infravio. Our regular listeners may recall that we had a vice president from webMethods, Miko Matsumura, on the show just recently. So, let’s go around the table a little bit and get the take. I suppose the big questions are: Is this a big deal or a little deal, and is it a good deal or a bad deal? Let’s start with you, Steve Garone?

Garone: Well, that’s interesting question you just asked. I think it’s a good deal. I'm sure it’s a good deal for webMethods from a financial standpoint and for the folks who are going to profit individually from the acquisition. It’s also a good deal from Software AG's standpoint, given its direction to move more strongly into SOA, which I don’t think -- based on what I’ve seen -- it’s been extremely successful at doing over the last three or four years.

Software AG, if we go back maybe three, four, or five years, went through a series of fairly significant announcements with integration products and database enhancements focused on XML, leading it more toward modernizing into the web services, and eventually SOA, world. My perception is that from a business standpoint it has not been extremely successful at that, particularly in the United States.

So, this move really amounts to an effort to get a lot of customers onboard, customers who are using the webMethods products and suites. As you mentioned, we’ve talked about it on this show before. The governance aspects that resulted from the Infravio acquisition are particularly important for Software AG in terms of acquiring a customer base in the United States.

Gardner: You mentioned the price paid. We should point out the 25 percent premium that is apparently going to be paid by Software AG for webMethods that would be over its publicly traded price before the announcement.

Tony Baer, you had an interesting point in your blog. You’ve mentioned that this price, of roughly $550 million is a third, or significantly less, than the $1.3 billion that webMethods had paid back in 1999 for Active. What’s your take on this? Was this something that was of economic expediency? It seems like it happened fairly quickly after the Infravio acquisition?

Baer: Well, I think that webMethods has been looking for an exit strategy for some time, because basically they're trying to build up their SOA platform story. The fact is that large corporate customers are going to be nervous with a $200 million company. They’re probably a lot more comfortable with a company that’s closer to one billion, if they're looking for a platform play.

In terms of the pricing discrepancies, that just reflects the absurd valuations we had during the dot-com period. That was a very interesting irony. I actually liked the point you raised in your blog, Dana, which is the challenge of integrating German companies with companies of some other regions, especially the U.S. German companies tend to be very deliberate. Take a look at Shai Agassi’s recent departure from SAP. He just didn’t want to wait another couple of years to become CEO or whatever the title is over there.

Gardner: "If" he was going to become CEO.

Baer: Very good point. German companies are very deliberate. I don’t think he had the patience for that. One thing I want to point out is more of a key performance indicator. Software AG had, up until now, a very heavily promoted alliance with Fujitsu. In the area of BPM, Fujitsu would resell Software AG’s service bus and Software AG would resell Fujitsu’s BPM. BPM also happens to be one of the highlights of the webMethods acquisition.

One of the challenges that will be before Software AG, and I think an indicator as to whether they are successfully getting the message out to their customers, is how they handle this transition with BPM. Obviously, having an internal product is going to be a lot more attractive than having to partner for it. In fact, Software AG’s CEO told me that in a quote. So, it will be interesting to see how they handle that.

Gardner: How about you, Jim Kobielus? Do you think that this is a sales and channel opportunity to reach the Asia-Pacific region through the Fujitsu alliance and take what was a complementary fit in terms of North America and European Union presence for these two companies? Is this a technology play for all of the above?

Kobielus: I am not really up on the Fujitsu alliance with Software AG. So, I won’t comment on that. It’s very much a geographic jigsaw puzzle coming together here. Clearly, Software AG is very big in Europe, and not so much in the U.S., in terms of integration in BPM.

It’s pretty clear that from a geographic standpoint it’s very complementary. Actually, it’s more complementary from a product standpoint than many have been there willing to give it credit for. Software AG, as you’ve indicated, Dana, is very strong on legacy modernization of the whole mainframe-based setup products for development, databases, and so forth.

WebMethods is very strong on integration, BPM, and the whole SOA stack registries. There is some redundancy with Software AG’s products, such as the whole Crossvision Suite, but I think that from a technological standpoint webMethods is stronger on BPM, the repository, and all of those SOA components than the company that’s acquiring it.

There definitely are a lot of synergies there. Also, webMethods is a bit more visionary than Software AG on the SOA front and has been for quite a while. In fact, webMethods almost coined the term "Web services" back in the late 1990s, and they had a pre-SOAP implementation or a protocol that presaged or foreshadowed SOAP and the whole WS suite that came along. I think webMethods is still a more dynamic company than Software AG in a variety of ways.

Gardner: Let me just pause you there for a second. So, you’re saying that webMethods is ahead of its time, and Software AG might be behind the times, and so together they are going to be on time?

Kobielus: That's right. Software AG is a little bit stodgy and maybe that has to do with its national background. The whole German-versus-American alliance thing is kind of interesting. So, it’s ironic that a big German and a smaller American company are hooking up right now and trying to make a real go of it on SOA.

Another big German and another American company are divorcing -- DaimlerChrysler, of course. They want to get rid of the German stockholders of DaimlerChrysler, who want to jettison the Chrysler side of it and send it packing its bags back to Detroit. They cited the cultural difference, the Germans did. It didn’t work out.

Gardner: Just as a quick aside, it seems that you can pick up Chrysler for $4.5 billion. That seems like a small change for such a big company. If I had a few more bucks, I might consider it.

Garone: Based on the last Chrysler car I owned, I don’t think it’s a cultural issue.

Gardner: You could sell the bricks in the factory and Chrysler would make that money back.

Kobielus: I was reading in one of the articles in the press that Software AG and webMethods cited a cultural match, and that's why it’s a good synergistic deal for those guys. We’ll wait and see.

Gardner: Just the fact that you bring it up means it’s probably somewhat different, right? Let’s go to Todd Biske. Todd, I really enjoy your blog. I think you have a view of SOA that’s much more pragmatic and practical than some of us tea-leaf readers. You tend to eschew the products and look more to the process and the issue of changing the way people behave. Does this merger and acquisition mean anything to you?

Biske: I always like to follow what's going on. The interesting thing that only time will tell is what you’ve got filling the technology gap. We’ve seen a lot of the recent mergers, even just webMethod acquiring and Infravio for the registry/repository and governance solutions, fill the gap.

Clearly, this isn’t a case of filling a technology gap. It's more about geographic issues. But the question from an end user point of view is, when you combine two medium-sized companies, will you get a new big player or will you just get another medium-sized company, maybe like DaimlerChrysler, and the message just gets kind of watered down for both?

I don’t know whether this acquisition will really make a lot of large enterprises see them in a different light or not, when they’re comparing them against the likes of IBM or Oracle. It certainly creates a potential to do so, and that increased customer base can go a long, long way. We’ll see where we windup with it.

Gardner: Your point is well taken. I see this as kind of a risky activity and I agree that this is one-plus-one-equals-two, or one-plus-one-equals-three. And hopefully now, one plus one plus equals 1.3 or 1.5.

In a sense, the whole SOA notion might be affected by this, because if these companies don’t succeed, and they can’t make a multiplier effect, they can’t show that the whole is greater than sum of the parts. You'd have to ask yourself why two companies that are focusing more and more of their products and processes and approaches on SOA couldn’t pull their companies together.

A failure could happen for a number of reasons. It could be culture, but gee ... SOA has to do with culture. Or it could be geography, and gee ... SOA is supposed to be appealing to multinational companies. And, it could be technology, but gosh ... I hope not, because the SOA technology is suppose to allow for mixing, matching, and elevating to a services level of assets, and data resources, and then to bring the people and process together around that.

Does anyone else share my view that this has a somewhat high level of risk, in that, if doesn’t succeed, it could besmirch SOA in general?

McKendrick: I don’t think it’s going to have a huge impact, at least initially, on either besmirching SOA or advancing SOA. It’s a great metaphor. Have you folks seen the movie, "The Pursuit of Happyness," with Will Smith? I’ve spoken with Software AG on a number of occasions over the past three years. When I look at them, I think of the young Chris Gardner out there trying to sell these bone density scanners to hospitals and doctors. He said in the movie that these scanners are slightly better than X-Rays, but cost three times as much.

That kind of reminds me of Software AG. Software AG has been working very hard over the years to try to sell their products. They had Adabas, EntireX, Tamino, and Bolero. They've been really working hard trying to push these products, which maybe are slightly better than other products in the market out there. I’m not sure if they’re priced three times as high, but they have to work hard, and they just haven't quite risen to that level.

Maybe buying webMethods will give them that final break -- the internship at Dean Witter that Chris Gardner had in the movie. This is their breakthrough into the market.

Also Software AG's focus has always been the legacy market. That's what they have been good at. They bought Sabratec a couple of years ago, which provided very good legacy integration tools for iSeries, AS400 mainframes and that’s always been their focus.

webMethods has played in this integration and legacy market as well. This is a huge, untapped frontier -- the legacy integration side of SOA. There are hundreds of thousands of legacy systems that have yet to be leveraged and exposed. In the long run, there is a lot of potential for Software AG to be well positioned.

Gardner: Well, there are a number of companies that are focusing on legacy. IBM is trying to cover its flank in terms of, "If anybody is going to put the mainframe out of business, it’s going to be us." So, there is certainly a lot of business, and perhaps even more so in Europe and in the type of customers that Software AG has.

I want to throw the question out again. Does anyone want to share my perception that this is a risky merger, given the geography, the culture, and the fact that the SOA is in a sense on trial?

Baer: One thing struck me about both companies, which I think also sort of ups the level of risk. Both companies have been going to their own form of legacy migration. Software AG is obvious, but webMethods is another clear case in point. WebMethods initially was a B2B company, and then it bought Active Software for $1.3 billion, and that was suppose to be webMethods’ future. Unfortunately, they bought an EAI company, just as the EAI market peaked. So, in that post-2000 era, or post-Y2K, where SOA started to emerge, they start to seem a bit of a legacy player.

Over the last five years, they’ve been essentially reinventing themselves from EAI to SOA. If there's any risk here, it’s that maybe webMethods is a company that's a lot more open to change, because it had no choice. It doesn't have the cash cushion of Software AG, but you’re talking about two companies that are trying to undergo transition. That ups the risk factor. On the other hand, it might also up the motivation, as long as Software AG’s cash cushion doesn’t make them both too complacent and, as you say, Dana, the cultural differences don’t get in the way. Those are some very big "ifs."

Garone: I tend to agree with Tony, although I think it has to be put into context of what webMethods has gone through and continues to go through. I don’t think it’s unusual amongst vendors in the EAI space. If you look at the collection of those vendors, webMethods has done a really good job, relatively speaking, and they have a ways to go as they all do.

The platform vendors have had that issue, too. IBM had to move each product toward a more SOA-centric model and has also done a very good job. The point is, I don’t think that’s particularly unusual. There is risk here, culturally and technologically, but I really don’t see this risk as being major enough to influence the adoption of SOA or the SOA space in general.

Gardner: Okay, fair enough.

Kobielus: I find it risky from Software AG’s standpoint. They’re acquiring another vendor whose own customers are not avidly acquiring their new product. What I mean by that is, back in 2002, webMethods had license revenues of about $120 million, and it’s dropped. Last year, it was $84 or $85 million in software license revenues. This doesn’t sound like a healthy software vendor, and, to some degree, it sounds like webMethods' own customers regard them as being a legacy vendor, away from which they’re trying to migrate. That’s just the surface impression I get.

Biske: I don’t think it’s going to impact adoption of SOA or cast that all in a negative light. Interestingly, looking at the other risk to webMethods and to Software AG, how would we’d be perceiving this, if it was in the reverse direction with webMethods acquiring Software AG or even if it was presented as a merger of equals, rather than an acquisition? The fact that you’ve got the German company acquiring the U.S. company, what does that mean for the existing U.S. customers of webMethods, and how are they going to perceive this, because there are some cultural issues that have made it difficult for Software AG to gain ground in the U.S. market.

Garone: That’s an interesting point. I really can’t address the issue of whether this is financially feasible or not, but my first reaction was, "Why isn't this in the other direction?" I perceive webMethods as being better positioned and in a better business position generally than Software AG is.

Gardner: Well, they have certainly shown their interest in expansion, but I don’t think their cash position would have allowed this.

Garone: Right, that’s probably true.

Gardner: So, the desire might have been there, but not the means, right? Now, what about the point about Infravio and the registry/repository? We heard quite a bit from Miko about governance and policy, running an IT organization, and perhaps even a larger take on the whole management of business in general. It was a very visionary discussion we had, and yet Software AG has its own repository.

I frankly don’t know enough about them to put them side by side and pick a winner, but it seems that if Infravio and governance was going to be the tail that wagged the webMethods’ dog, and that this acquisition may show you a little different future for the role of registry and repository. Any thoughts on that issue?

Baer: It depends on who is going to be driving the agenda there. An early indicator is that Software AG has said that they want to keep webMethods’ management in place. That’s kind of interesting, because usually a CEO of an acquired company exits fairly tactfully, if it’s a friendly takeover. We’ll approach the interesting inflection point about 8 to 12 months down the pike, when we see who's really driving the SOA strategy at the combined company. That’s basically going to be the telling point.

Gardner: Okay, thanks, Tony.

Garone: I think that’s correct. The real pessimists out there -- I’m not sure I’m one of them -- would look at this and say there’s no doubt that webMethods is going to drive the SOA strategy. Software AG, in terms of revenue, is highly reliant on Adabas maintenance at this point and it's going to continue that way until it figures out how to leverage what it got via the acquisition of webMethods in the SOA space. I’m not quite sure I’m there, but there are some elements to that that may ring true.

Gardner: Yeah, this smacks of a good sales and channel match-up, and they might run webMethods as a subsidiary for some time. Then there's also this balance-sheet issue, where Software AG has recurring revenue. It’s got an old cash cow to continue to milk, and that gives webMethods an opportunity to be funded and financed -- without the vagaries of a quarterly report to Wall Street -- to pursue the larger brass ring here, which is SOA.

Kobielus: Dana, I’ll make a one last point there. I agree with that with what you just said. Software AG is a cash cow in the same way, for example, SAP is living off the substantial legacy of a very well-entrenched set of products. My first reaction to the webMethods acquisition was how they finally put webMethods out of its misery. When I say misery, how long has it been? WebMethods is about 11 or 12 years old now, and it seems that for most of their history they have been in some financial trouble or shakiness. It’s just been one thing after another, and it’s like they don’t get a break.

Now, they seem to have a corporate parent that has a comfort pillow for them, some money to fund ongoing development, diversification, and so forth. Software AG pulled webMethods out of their misery and has given them a new lease on life.

Gardner: Thanks, Jim. Yeah, maybe then make them the R&D department in a sense, right? Okay, a final word on this issue to Joe McKendrick. Joe, this relates somewhat to our discussions from the past about best-of-breed versus integrated-stack-and-suite. Clearly, these companies think that bigger is better and more is better. Does this change your thinking on the best-of-breed versus integrated-suite issue at all?

McKendrick: Well, as we discussed in a previous podcast, the whole notion of an SOA suite runs counter to the SOA philosophy. SOA is especially about loosely coupling, and it doesn’t matter where the applications or the system resides. SOA should be independent of all that, and the idea of an SOA suite runs counter to that thinking. Nevertheless, we see lot of companies glomming onto each other, a lot of gelling taking place. This Software AG-webMethods merger is an example. Progress Software has been very astute in assembling a collection of companies that deal with different aspects of SOA. They want to compete with Oracles, and we saw that just recently with JBoss.

Gardner: SOA Software?

McKendrick: Yeah, right. SOA Software and JBoss. Their goal, their intention is to compete against these bigger guys, while servicing the smaller business market, of course.

Gardner: More of an ecology approach to how to bulk up.

McKendrick: Yeah, we’re going to see more of these alliances, more of these acquisitions and mergers.

On Web 2.0 and SOA ...

Gardner: Let’s move on to our second topic, which is this notion of Web 2.0 and SOA. Now, Web 2.0, of course, can be defined many ways in the market. Some people look at it as simply a rich Internet application interface approach. Others focus on the collaborative social networking aspects of it. Yet others look at Web 2.0 as simply going from an HTML and text page-driven Web to more of a process and semantic Web.

So, let’s just leave the Web 2.0 definition off the table and look at the issue of any of these new activities, whether it’s social networking or rich Internet application interfaces or whether it’s taking advantage of more semantics and BPEL as a process relating to Web activities instead of just as a publishing medium.

Let’s just say, "All of the above" for defining Web 2.0 and how this relates to SOA. I want to go first to Jim Kobielus, because in some emails this week you had some interesting thoughts. We’ve seen a few companies say, "Let’s leverage Web 2.0." We’ve seen Intel come out and say, "We’re going to corral a number of 'open-source' Web 2.0 functions." We’ve seen Cisco get involved with Web 2.0. We’ve seen BEA just announce an embrace of Web 2.0. Even IBM is tinkering with this, I’m sure.

So, there is something there, but let’s focus on this collaborative aspect and particularly in terms of governance. Annrai O’Toole at Cape Clear mentioned this to me probably about nine months ago that he looked at governance and at Web 2.0 and thought, "Gee, maybe wikis would be a good concept for how people manage their services." They could say, "I think the policy should be this, and I’m going to use it in this way, and you can pick and choose."

It's sort of an open source, open collaboration approach to policy and use of services and their agreements. I suppose provisioning rules would come about. You said, Jim, this is kind of a scary concept, that wikis seem to be anti-governance and that it could be a collaboration with no structure. Tell us a little bit about why you’re concerned?

Kobielus: Well, when I think of governance, like everybody I think of the capital "G," like Government, but governance has a broader concern. You often think about crack-the-whip, controls, and setting controls on how people interact and how policies are created? When I think about wikis, I think of the exact opposite. There are no controls. It’s basically a shared space to which everybody can post, everybody can overwrite, and everybody can erase everybody else’s comments.

Gardner: The wisdom of the crowd, right?

Kobielus: Well, okay, that’s a religious faith. Wiki seems like the wild, wild West. It’s a free-for-all as collaboration. That’s great. It’s definitely got a very valid role in many environments, like open-source initiatives where they are very peer oriented. Everybody is an equal, even-steven, participant. There is a high emphasis on collaboration, design, reciprocity, and all of that. So, when I think about the whole SOA governance space, both design-time governance and run-time governance, I think of wiki as in the design-time governance side, where you have teams of designers or business analysts and IT people sitting around the virtual table, trying to hash out policies.

Gardner: Requirements?

Kobielus: Requirements, policies, data designs, data hierarchies like with their master data management environment. Quite often these are creative processes involving teams of smart people who sit around a virtual table and hash out the overall design approach. Wikis and the whole Web 2.0 repertoire of collaborative tools can be very valuable in this upfront design, modeling, simulation, and shoot-the-breeze aspects that are critically necessary for design time. But runtime SOA governance really depends on clear-cut policies, designs, data definitions, and so forth that have been handed down by the policy gurus, and now are governing ongoing operations without ambiguity.

In that case, you don’t necessarily want any Joe Blow to be able to overwrite the policies and the business rules that are guiding the ongoing monitoring, management control, or security of your SOA.

Gardner: Yes. You said that they needed adult supervision, but I didn’t think that this would be open to anybody. I thought this would be open to the people who have impact, the architects and the line-of-business people perhaps. You're not going to open this up to anybody. There would be a directory and an provisioning, so that only those most close would have access.

Let’s go to the real world. Todd Biske, does it make sense to you? Should we be collaborating among the right people with the right access and privileges in how SOA governance is improved over time?

Biske: I don’t know that you really want a wiki-style collaboration for governance. I tend to agree with Jim that you can’t just open it up to the masses, and even if you look at collaborative environments, whether it’s the large open-source projects, or something like Wikipedia, there's some hierarchy that eventually was put in place, where certain people were allowed to do commits or were designated as senior editors.

So, you always wind up with some form of governance structure around that. The area where I think wikis are going to be important in the SOA space is in the service management lifecycle or service development lifecycle. You got companies that have to move to a service-provider model, whether it’s internally to internal consumers or externally. I have talked a lot about this in my blog.

If we compare that to traditional product management, for a long time it was really just one-way communication. The product marketers went out and said, "Here’s our product. Here are its features. Go and use it." They pushed it out to the market place, and the only response they got back was did people buy the product or not.

Over time, they recognized the need for much more collaboration with their end consumers on how to evolve that product, whether it was the formation of customer advisory boards or even leveraging the Internet and some of the technologies to establish a community around those products. The same thing can apply when adopting SOA.

If I am providing a service out to the rest of the enterprise, I am going to be interested in what the consumers of that have to say. If I am not listening to them, not establishing that bi-directional communication, eventually they are going to go somewhere else or they are going to build it on their own and put that redundancy back into the organization, which is the opposite of what we are trying to achieve.

Gardner: Okay. So social networking has a value here, but you wouldn’t want it necessarily hardwired into the way in which the technology actually operates?

Biske: Exactly.

Gardner: Okay, I can buy that. Does anyone else have any thoughts on this notion of wikis and collaboration as applied to SOA governance?

Garone: I don’t really have a lot to add. The two guys who just talked gave a great view of this particular question, and I agree with virtually all of it. After a while, it becomes something that a few key contributors, people who actually have the power, control, and knowledge, would be part of. I waxed philosophical in my head and asked, "Well, is it then still a wiki or is it in fact a collaborative tool among a set of decision-makers who, through policies themselves, are able to make changes or not?"

Gardner: I think you're right. The key word here is collaboration. I believe that IBM is going to be coming out soon with something called Jazz, which is a collaborative application lifecycle management approach. We are seeing more collaboration across different aspects of the whole development-to-deployment environment and we are looking for the tools to do that. Web 2.0 is perhaps stepping up and saying, "We have some tools that can be used in that way." Perhaps, it's not just a matter of dropping a wiki into the process, but something a bit more tailored to an aspect, but somehow availing all the participants of each others' wisdom in the process.

Kobielus: It’s like an open source project. You have a broad range of contributors, but only a handful of committers who can actually commit changes to the underlying code base. So, you might have a wiki that has potentially 3,000 different contributors, but ultimately there might be a moderator or two whose job it is to periodically weed out the nonsense, and crack the wiki whip to make sure that what’s actually been posted reflects the wisdom of the crowd of 3,000 people and not necessarily the vandalism of the few who decide to just disrupt the process.

Garone: And that’s a governance model in itself.

Gardner: Yeah, that’s right. It’s governance, and it relates back to what we’ve discussed in trying to find analogies in geo-politics for technology governance. You want the best of both. You want a federated approach, where they get grassroots input, but you also need command and control. So, it’s Jefferson and it’s Hamilton, right?

Kobielus: It’s Aaron Burr occasionally too. You’re going to follow the pistols.

Gardner: I heard an interesting analogy the other day. We talked about the chicken and the egg, and somebody said, "What about the rooster?"

Alright, let’s move on. Before we leave with Web 2.0, does anyone else have any inputs about the role of Web 2.0? As I said, it’s a very large subject, and then it evolves into Enterprise 2.0 issues, which have lot to do with software as a service and delivery of service. There is the mash-up notion of creating services and then compositing them, even if not with an application purpose or a process, which is letting people change their interfaces and drag and drop things.

We have seen some information from Google Maps this week that have lent more credence to this. I’ll just throw it out to the crowd, any other beauty tips or predictions for the future about where Web 2.0 and SOA come together or not?

Kobielus: Web 2.0 is really HOA, Human Oriented Architecture. It is pretty much giving human beings the tools to share what’s in their minds, to share their creativity with the big wide world. SOA, Service Oriented Architecture, is about sharing and reusing all matter of resources in a standardized way. HOA, the Web 2.0, is the most critical resource, and the most inexhaustible energy supply is human ingenuity and creativity.

Gardner: That’s like Cosmic 2.0. Woah!

Kobielus: Yeah, I have been known to get cosmic. People who have read my blog realize that I am a total space cadet.

Baer: Jim, I'll give you the award this morning for coining the best buzz words, like "Cracking the wiki whip" and "Human Oriented Architecture."

Gardner: Now, any other thoughts before we leave the Web 2.0 subject area?

McKendrick: This may be just a rumor, but I once heard that there was a company, an enterprise with several architectural teams, and these teams actually met face to face once a year to discuss things. That's just a rumor. I am not sure if it’s true.

Gardner: They had to leave their guns and knives at the door.

McKendrick: Exactly. So, Web 2.0 can only help the situation, help break down some of these walls.

On SOA and the Hype Curve ...

Gardner: Okay, let’s move on to our last subject of the day -- we only have a few more minutes -- but it’s the notion of hype. I just noticed, looking around some of the SOA information that was floating around the Web, we seem to be now in the, past-the-peak of the hype curve on SOA and are apparently, from what they say, approaching the "trough of disillusionment."

I took exception with that. I am not sure we’ve even hyped SOA sufficiently and that we are still ramping up on this one. Does anybody else agree with me that SOA is so large, so long-term, and crosses not into just technology but business in organizing behaviors and even redefining the corporation itself? My point is that we are not hyping SOA enough. Anybody agree or disagree?

Biske: I tend to agree with you that the communication isn’t hitting home and it’s not sinking in. I had a blog I know Joe picked up on at one point that talked about companies that are claiming success with SOA. I pointed out that a lot of these companies are the same ones that claim success with virtually every new technology adoption or business adoption, because their culture is well suited to that. There is still a lot of of companies that just don’t know how to do cultural change. It’s not an easy thing to do.

We hyped SOA a lot from the IT perspective, and a lot of the IT managers certainly may be growing tried of hearing about it, but haven't done anything to actually start that process of cultural change. Is it really adopted by the business side and do they understand what it means and how it can impact our business? If they aren't having those communications, we haven’t really changed anything, and that means they’re still open for that message to continue, and to increase.

Gardner: You are saying that managing change well is a core competency, will be an important aspect of any SOA activity, and perhaps SOA adoption could help companies improve the way that they manage change?

Biske: Absolutely. Back when I was working at an enterprise, I had somebody ask me, "How do I build this service so that it meets the enterprise needs?" And I said, "You don’t. You build it to what you know now, and you understand what your processes are going to need to be to change it in the future? Because it is going to change. Think from a change-first perspective, and how you want to manage that process, rather than stick it out there, not want to have it touch it for 10 years, and have it last forever."

Gardner: Well, not to change this subject, but who else agrees with Todd and me?

Garone: You used an expression earlier, "trough of disillusionment." Those words come easily, because they have been used before. That’s because we go through this cycle every time some disruptive technology comes along. The hype gets really high, and the adoption and the use of the technology lags behind, depending on a variety of factors.

I think the SOA hype is pretty high, but I think that it's difficult to sell to decision-makers due to two factors: 1) the degree to which cultural change needs to take place, and 2) as time has progressed through this decade so far we’ve seen greater caution in IT departments because of shrinking budgets. So, the hype is high, but it needs to be sustained longer with messaging that’s going to be more aligned with business goals, rather than technology.

Gardner: We seem to be in a cheap era when it comes to IT, and ironically it’s coming at a time when the Dow is flirting with a record high, even though it has been a bumpy road in the market for the past couple of months. We are still within a Curt Shilling breaking ball of the record, and companies are enjoying record levels of profit, record growth.

Many of them are sitting on record piles of cash. Capital around the world is still at very cheap level, taxes are at a record low in real terms and are dropping in many countries. If there’s any time to invest in IT for the future, this should be it? And yet we’re not seeing it.

Kobielus: Oh, it’s not inconsistent, Dana, with SOA not succeeding. In fact SOA, the model of SOA practically could be: Do more with less.

Gardner: Yeah, but you've got to spend something to allow for your older systems to be freed up and excise the services. That doesn’t come free.

Biske: One thing you have to be cautious with ... Just as we talked about that things change quickly, a number of businesses got burned in the dot-com boom when stock markets were also very high and revenues were increasing. They increased their IT spending, and then the bottom dropped out of it.

Gardner: But, here it’s 2007. It’s been seven years since this crash.

Baer: But, Dana, probably the major reasons -- and the big difference this time -- is that on the IT side there isn't the same sense of urgency. We don't have this Y2K thing staring us at the face, telling us that we must renovate all those legacy systems that are out there -- either renovate or replace. You don’t have the same drama in the headlines all the time. That’s dropped the sense of urgency.

Combine that with the fact that a lot of organizations felt that they got burned the last time they opened up the purse strings.

That’s probably a large part of the reason why you’re seeing much more deliberate spending. To that extent, it can be a positive force in terms of enforcing some discipline. On the other hand, if you want to do SOA right, do you need to invest upfront to do that planning and architecture? I'm not sure that IT organizations have gotten that message.

Gardner: Perhaps there’s more. We keep going back to the crash, but after the crash, we had a series of corporate scandals and meltdowns that really couldn’t be blamed on hyping IT. They had to do a lot more with malfeasance and neglect. We also had a period where we saw new laws and a different compliance atmosphere.

So it could be that companies are being run more by the accountants -- of, for, and by the accountants -- and therefore the vision around IT is not getting through to them, and the purse strings are not opening up. Is that possible?

Koblielus: You’re pretty much on the mark there. I was talking with one CIO about a year or so ago, after about the first year of Sarbanes-Oxley, and she said that the impact of SOX translates to shutting down IT for about 90 days out of the year, just so that they could just account for their tracks over the previous three quarters.

Gardner: Does anyone else concur that the accountants have run amok, and that the IT guys have very good rationales for spending, but they just can’t get the money?

McKendrick: One effect of the whole compliance scenario was that it gave vendors another hype factor. I'm going to try another buzz word. How about Hype-Oriented Architecture? HOA. Using Jim’s HOA for another purpose.

Kobielus: It’s better to have hype-oriented accounting.

McKendrick: Hype-oriented accounting? I think the whole compliance thing gave a boost to the IT industry in the early 2000s. What do we call this decade anyway, the 2000s?

Gardner: The oughts.

McKendrick: It gave the whole industry a boost at a time when things were kind of down with the IT recession. The whole compliance scenario helped business intelligence and the data-environment vendors who directly addressed the flow of financial information.

Gardner: I’d like to conduct an experiment. I think we should take an accountant out to lunch. Anyone who knows an accountant, take them out to lunch and tell them how great IT is and what SOA can do in terms of long-term efficiency and lower total costs. Bring in some of the other mega trends, such as software as a service, virtualization, and data master management. It behooves us all to educate the accounts on why IT is important, because I think they are suffering from a lack of understanding.

Better yet, take a chief financial officer out to lunch and then take the accountants out to lunch. This is the crowd we need to work on. We keep talking about trying to convince the CEO and the CIO, and I think we need to get right down into the bean counters' frontal lobes on SOA.

Biske: Not to move away from the accountants, but one group I hope will keep the hype going is this newly formed SOA Consortium that OMG is sponsoring. It's an advocacy group, not another standards body coming, into the mix. It would be great to start to see a message come from a collection of end-users that are seeing some success with this, rather than being pushed so strongly by the vendor community.

I think it’s a different type of hype. It is one that will be a bit more pragmatic. Hopefully it will continue the pace, and they’ll achieve the goals that they have set out for themselves. I don’t know if they have any accountants in the consortium, but maybe this will help them bring some in.

Gardner: Well, we'll invite them and try to give them a free membership. They should cotton to that, right?

McKendrick: Often, it’s the stuff going on in the consumer space that begins to leach into the enterprise. Any excitement going on in the consumer space, eventually translates into excitement within the walls of the corporation about a certain technology. We saw that with the PCs and we saw that with the Internet. If anything is going on out there in the consumer space right now, it is Web 2.0, going back to the Web 2.0 discussion.

Gardner: Oh, we know how profitable that is.

McKendrick: It's where the excitement is in the corporation that begins to drive the investment. To paraphrase Wall Street's Gordon Gecko, hype is good.

Gardner: Greed was good in the 1980s -- hype is good in "the oughts."

McKendrick: Because it raises that level of excitement, and that’s why you need to get the attention of the bean counters, the CIOs, and the CEOs, most importantly.

Gardner: Well, here’s the message. Take your hype to your accountants and your CFOs and then make them join the SOA Consortium. I am always tempted at the signoff period of our discussion to take a cue from the Car Talk guys and say, "You’ve wasted another completely good hour," but I am not going to do it

Koblielus: And don't drive like my brother

Gardner: And don’t implement your IT like my brother. We have been joined here once again on our SOA Insights Edition by Steve Garone. Thanks, Steve.

Garone: Thank you Dana. It has been a pleasure.

Gardner: Joe McKendrick.

McKendrick: Thanks, Dana. It is good to be here.

Gardner: Jim Kobielus.

Kobielus: Another pleasurable morning.

Gardner: Tony Baer.

Baer: Another hour not wasted.

Gardner: Our guest -- please come back again Todd; we enjoyed having you -- Todd Biske.

Biske: Thanks, this is a lot of fun. I hope to be back.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You have been listening to Volume 16 of BriefingsDirect, SOA Insights Edition. Thanks, and come back again next time.

Listen to the podcast here. Produced as a courtesy of Interarbor Solutions: analysis, consulting and rich new-media content production. 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. 16. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.

BriefingsDirect SOA Insights Analysts Explore SOA's Role Through Failure, Governance, Policy and Politics

Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition, recorded Feb. 2, 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, Volume 11, a weekly dissection and discussion of Services 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 blogger, and Redmond Developer News magazine columnist.

Our panel this week, and it is the week of Jan. 26, 2007, consists of Steve Garone, he is a former IDC Group vice president, founder of the AlignIT Group, and an independent IT industry analyst. Welcome, Steve.

Steve Garone: Thanks, Dana, great to be here again.

Gardner: Also joining us, Joe McKendrick, a research consultant, columnist at Database Trends, and a blogger at ZDNet and ebizQ. Welcome back, Joe.

Joe McKendrick: Hi, Dana, greetings.

Gardner: Also joining us is Jim Kobielus, a principal analyst at Current Analysis. Welcome back, Jim.

Jim Kobielus: Thanks, Dana. Hi, everybody.

Gardner: This week we’re joined by our guest Miko Matsumura, the vice president of SOA products at webMethods. Thanks for joining us, Miko.

Miko Matsumura: I appreciate being here. It's a great group.

Gardner: Now, Miko, you joined webMethods recently through the acquisition of Infravio. How is that going? Is that officially closed now, and what's the outlook for the two companies working together?

Matsumura: Well, it’s officially closed, and it’s very exciting. I tend to take an Infravio startup perspective, and from that perspective it’s almost like there are 10 times the number of sales people to talk to. It’s a little bit like The Darwin Awards guy that put a rocket engine onto his Chevy and raced it on the salt flats. Things are going a lot faster, and it’s kind of fun.

Gardner: Cool. Is this going to be a case where it’s the Infravio tail that wags the webMethod’s dog?

Matsumura: I listened to the [webMethods President and CEO] David Mitchell earnings call last night and we had a game, a virtual drinking game, we were playing by instant messenger. Every time someone said the word Infravio, we would say,"Drink." Were we actually consuming alcoholic beverages, I’m sure we would have been pretty soused by the end of the call.

Gardner: Cool. Well, it seems like so far it's a happy match up. It’s good to hear.

Matsumura: So far, so good.

Gardner: One of the topics I wanted to get into this week, and we’ll throw this out to the entire group, is looking at failure in SOA. What is the problem with those projects that are not going well these days? We talk a lot about SOA, the business value, when the maturity is coming, and where the technology and standards are going.

But I thought it might be worthwhile to take a step back and say, "Where are the warts, and why are they there? What can we learn from that?" You’ve had some experience in the field, Miko. Many of our panel speakers are working in these areas consistently. So I wanted to ask the panel, anyone at all. Have you come across SOA projects that have not been stellar successes? And, if so, are there any immediate lessons to be learned?

Matsumura: I'll answer, since you called my name out, and since it’s also a glorious introduction to have someone say, “Yes, I’d love to talk about the topic of failures and for this they have a guest expert.”

From our perspective, the thing that is really vital about this topic is that in 2007 we’re as likely to see catastrophic failures as we are limited success. There are a huge number of moving parts within SOA, and I'm going to use that almost as a handout point to this very well-considered group of folks. We need to categorize for the listener which moving parts are more dangerous than other moving parts, because those are the things that eventually cause the thing to kind of wiggle the wrong way, and send it to a tailspin. Any thoughts about that?

Garone: I’ve gotten involved in some research in the past, and it doesn’t really relate to SOA, but the results that I see from this research have tended to point out two major areas that cause or are the main factors behind these kinds of failures. One is a difficulty in nailing down and keeping a continuous eye on requirements for an application. The other has to do with corporate backing for that particular effort within the company. It's more focused on the people-oriented things and the collaborative issues associated with deciding what to build and how to build it.

What you just indicated was that, in the case of SOA, the focus in terms of failure might be more on the technology-based pieces associated with building an application. Do you see SOA being different in terms of what actually is responsible for failures?

Matsumura: I'm delighted to have you take that approach, because I’ve actually cast this net out into this group as a very neutral test to see what kind of like fish will come out of it. I used a very generic term, "moving parts," but I didn’t specify. Your inclination was to think that I was talking about technology.

Garone: Well, people do so …

Matsumura: That’s exactly what I was hoping to elicit -- the idea that, in fact, a lot of the moving parts -- and the most dangerous moving parts -- are people. From our perspective, the system is sort of cybernetic, half-human, half-machine. The human pieces of SOA are the parts that we’ve seen in failure mode.

It’s not necessarily just the human beings themselves, but, as you described, the interfaces between the human world and the machine world, whether those interfaces are the specifications used to design applications, or the mechanisms used to manifest constraints and policies. They make sure that people, when they do fight each other, fight each other in a way that's productive, as opposed to destructive.

So, thank you very much for heading in that direction. Any one else have anything about "moving parts"?

Kobielus: I think that SOA failures are a subset of IT project failures, which are of course legendary. The most common reason IT projects fail is lack of the appropriate business justification for them. Quite often, their aims are so broad and nebulous that there are over-heightened expectations built up about how it will change the business and contribute to revenues, profitability, and so forth.

There’s a "boil the ocean" element of SOA justifications, because SOA as a set of best practices, is often pitched as, "We’re going to totally clean up; we’re going to totally clean up our development practices and our integration practices. We’re going to orient them around this new grand unifying scheme called SOA."

When projects are pitched in that way, and justified in that way, you’re just setting up the SOA project for failure.

Matsumura: I want to plead guilty as charged. I don’t want to monopolize, but I do want to say that I just recorded an SOA governance podcast on my own, the theme of which was, “Reorganizing the Billion Dollar Software Project.”

Kobielus: I didn’t mean to imply that you were the kingpin of failure, and, in fact, I figured that people who are having trouble in the field look more toward the governance value in order to help solve their problems. I thought I was giving you a soft ball not a hard ball.

Matsumura: No, I appreciate that. Anyhow, I’ll cool my heels and let the others speak.

Gardner: No, you’re the guest. That’s fine. But some of our other discussions on this weekly podcast in the SOA domain come back to the notion of systems integrators (SIs) and even management consultancies getting the lion's share of business in the near term with these things, because it is about culture, people, and process. And the user companies need to shift a lot of what they are doing in order to exploit the benefits of some of the technology and standardization.

I wonder if you agree with that. Do you think that for the next two to five years vendors like yourselves are being dragged along, or do you have another relationship with the SIs that have to get in there and monkey around a little bit with the culture to get companies to transform?

Matsumura: Being dragged along might be a tall order. The reason I say that is that we’ve learned that the people who control the SOA are the people who essentially control the policies. The policies include metadata, repository, and registry -- the kind of policies that are machine-enforceable, but also involve human factors. In a way, the model is more of an equal partnership now.

On the other hand, real system integrators like to control policy as a way to permanently set up a base camp inside an account, pour people through the door, and take over. It's something that we know they're salivating about.

Gardner: Joe McKendrick, what do you think? Is this a control issue right now? Or is there some jockeying going on among the internal constituencies in an enterprise, some of the vendor’s constituencies, and also the SIs? And who’s going to win?

McKendrick: There is a lot of jockeying going on, and Steve has pointed this out in a previous podcast as well. There’s a tension between various groups in the enterprise. I guess there’s a lack of a clear definition as to who is going to be doing what, and who is going to be controlling what.

SOA, of course, is inherently cross-enterprise -- or in theory it’s cross enterprise. An SOA that’s confined to a single silo or single piece of the enterprise, by definition isn’t necessarily an SOA. It’s another proprietary system.

I was curious as well as to what the definition of failure would be in an SOA situation. Personally, I'm not familiar with situations where an SOA, or components of an SOA, had to be rolled back, such as you’ve heard about with spectacular ERP failures. It seems that there may be heightened expectations of ROI or increased business agility, which don’t happen immediately, but components of the SOA still may stay in place and just be sent off in a different direction.

Gardner: Maybe we should define failure. I was thinking of it as an instance where these new practices and methodologies were tried, but people didn’t think they were working. There weren't cohesive approaches. There wasn’t standardization in the organization.

And, so they went back to business as usual, which would have been some of the older application-development ownership and deployment practices, silo-types of affairs. So, in other words, a reversal from a movement toward holistic services, used broadly, to "I’ve got my set of apps. I'm going to maintain control over them. And, if you have any kind of changes or requirements that you wanted to address, you can get in line" mentality.

Matsumura: This strikes to me as a way of defining retreat as a "strategic advance to the rear." There are definitely potentials for failure. Since failure is an orphan, even though success has 10,000 fathers, I can’t allude to a project I know that experienced a failure condition.

For example, a project I was involved in for the insurance industry was widely touted as an early SOA poster child by the vendor. The CIO was on the speaking circuit, which was dragging him off the field, and he had essentially outsourced the entire project toward a single source. What eventually happened was that this particular individual ended up having to leave the company.

I think that the CIO had this mistaken impression that the service interface abstraction allowed him to outsource completely the operational concerns and the implementation concerns, and eventually to treat this service interface as something like a child’s car seat, where really mom is driving.

It’s important to treat the interface abstraction layer like a saddle on a horse, which means that the only people who can successfully get from Point A to Point B are the people who have the skill of riding and controlling the horse, which is the service implementation. It’s really an abstract or complicated metaphor. It’s not hard to lose control.

The whole thing we alluded to early about this integrator setting up a base camp inside a company ... we’ve had customers who deliberately, pre-webMethods, used Infravio as a wedge and basically said, “We don’t want a single vendor to come in with a product and a set of services, because we don’t want them to control everything. We want an independent to mix things up."

There is a very significant danger of the inmates running the asylum or the integrators taking over the whole account from the inside.

Kobielus: I think that the way to define SOA failure is the failure of SOA as a set of practices that a company adopts, the company’s failure to realize the grand claims made for SOA. These include such benefits as improving interoperability, simplifying your IT environment, reducing the cost of that environment, speeding up the development of applications, and enabling greater flexibility in terms of where you can source various components, portals, databases, and integration components from.

An SOA project or initiative is a failure if it increases the complexity of your environment, if it increases cost, if doesn’t make much of a dent in the incompatibilities among different platforms, or if it locks you into a given vendor.

That’s why last week I brought up the whole notion of SOA suites. This notion of an SOA suite from a single vendor who provides everything for you seems to fly in the face of, "Isn’t SOA supposed to allow me to mix and match the BEA, Oracle, webMethods, Microsoft, and everybody else’s components in my environment ?"

If, at the end of the day, you’re a CTO and you say, "Well, here’s my SOA strategy, and we standardize on Oracle or webMethods" -- are you really gaining anything over the monolithic days of yore?

Gardner: So, we can agree that something that would be opposed to failure would be less lock-in, and that could be lock-in from a vendor, lock-in from an integrator, or even internal lock-in, where there is a very strong division within IT or some other organization that’s holding the rest of the enterprise hostage.

Is SOA a democratization type of an effect, or is it really giving command-and-control through policies that you could think of as a governor or an accelerator -- a brake-pedal/dashboard type of an affair -- where suddenly those in the organization that may not have had power before gain it? Is the failure when the control doesn’t go to the right people?

Matsumura: Yes. That hits the nail on the head. I was giving the keynote of the governance track at The Open Group SOA Conference in San Diego [on Jan. 31], and one of the questions that came from the audience was about metadata. Who controls the metadata?

This question is basically The SOA Question, because the people who control the policy metadata are the people who are running the show. The thing that we’re trying to establish here is that the SOA success model is essentially a model where there are federated controls and delegated controls. The reason why this term "federation of control" is so significant is because we’re trying to achieve a balance between the central function, the IT function, and the distributed function, or the business function.

People talk about the agility and control. If you want to balance these things, you need a mechanism that enables some amount of control by the people who are on the periphery, in the business units, trying to create agility. Then, [there comes] some amounts of control by the people in the center, who are trying to create more orthodox standardization and security and orthogonal cross-cutting concerns.

Having the wrong people controlling the wrong things is exactly the pattern that causes things to go a little nuts. The old-school model -- having one single point of control for everything -- has actually proven to be undesirable. While it is not prone to failure, it’s not prone to success either.

Gardner: I suppose when we’ve seen enterprises that are in a suffering mode, when IT and the business are not aligned or not syncing up, well, that can often be due to a cultural clash. For example, if it’s a distributed company and they try to have a distributed approach to IT, that can break down.

If they’re a centralized company, but IT is decentralized among departments that are doing their own applications -- then that could break down. But what’s probably more productive is, as you say, a hybrid approach where certain functions, let’s say procurement, should be centralized. If you can take advantage of a volume approach to your procurement, if you can go to your vendors and suppliers with a larger bid, you can get a better deal. So there are lots of reasons why procurement should be centralized.

But there are other examples, perhaps around knowledge management or around innovation and collaboration, that should be very ad-hoc, very decentralized. How can you manage both of those types of cultures across the company, and then instantiate that through how the IT department behaves and reacts? Anybody have a sense or reaction of that?

Kobielus: A SOA and a SOA initiative are a success if it gives you the ability to adapt the SOA governance structure to your actual business governance structure.

As you’re saying, your business governance structure will evolve over time. All business models change. So the extent to which your SOA initiative and your SOA governance are totally centralized and totally rigid -- but your business environment and the challenges and threats and so forth are constantly changing -- then your SOA failure will ultimately become a business failure, a failure to adapt.

Garone: I’ll concur with what you just said, but also add more in the way I look at it: I don’t necessarily see a contradiction between some levels of centralized control and being able to achieve business agility. The argument for business agility really is about making sure that you make changes quickly to dynamic market conditions and relationships, and so on.

While too much centralization may make that a little bit more difficult than it would be if everything were ad-hoc, I don’t think it makes it impossible. Of course, the world is about balance. The world is about finding that midpoint, where control and governance is centralized enough to keep things safe and secure, and to be able to take advantage of business opportunities -- where consolidation makes sense -- while at the same time staying agile. That’s really the challenge, the way I see it.

Gardner: I guess we need some standard methodologies or best practices around how to approach the whole organization culturally. That brings us into a discussion around ITIL or around what The Open Group has been doing [in terms of certifying SOA architects and the move to the "Town Planner" model of enterprise architrect roles].

Miko, let’s go back to you, do you have a sense of whether there is a legitimate standardization approach that is welling up in the marketplace?

Matsumura: I’ve just been speaking with the head of The Open Group, SOA Governance Working Group and absolutely there are efforts in this area, under the banner of TOGAF, ITIL, and other types of processes. It’s still reasonably early in the game, and what people need to understand and establish are the basic patterns and best practices. A lot of the efforts that create these extremely ornate methodologies are intended to be recipe-book and all-encompassing or one-size-fits-all approaches. I think it’s early in the game to take those approaches.

What I would do is take a look to see if there’s any precedent for a model for policy-managed systems that balance the need of a central entity and the needs of distributed entities, against the desires of the whole. If you look at it from a metaphorical perspective, for example, the federal government of the United States is a very interesting model. You have essentially a bunch of business units called states, that each have their own legislation, their own competency centers called state legislatures, and even their own executives called governors.

Those look a lot like business units to me. If you look at the notion of federation and the federal government model, what you see is this whole principle of jurisdiction. Ultimately, competency centers become the legislative bodies within these organizations. All of the efforts that I’ve seen to codify methodologies around SOA tend to focus on these competency centers or centers of excellence, primarily because there needs to be an inclusive organization for adjudication and jurisdiction, as opposed to having a model, where it’s just a single iron-clad dictator that controls all policy.

If you want to go that way, let’s just go and live in the mainframe and forget about SOA. Not that this would necessarily be a problem, we just have to do it deliberately and well.

Gardner: This is great. We’re getting at the point where world political history is perhaps a guide to how to approach SOA. Do you want a Third World dictatorship? Do you want empires extending their influence? Do we want a Pax Romana approach? Or do we want a pure democracy or a federated democracy? I’m thinking more about Star Trek, when the Romulans and the Klingons get together. If you could only get that to happen in IT, would be in a lot better shape.

Matsumura: Just to extend that metaphor to the initial theme about failed SOA ... . You can actually look at the failure modes of failed states. If you look, for example, at how you establish and foment democracy, there are some models, some really good, real-world cases about how not to establish democracy. Not to get too overly abstract, but there are a lot of practices and principles around establishing policy federation. The interest in doing so is the interest in establishing a controlled paradigm that actually serves the common good in a way that enables agility, but also enables this centralized capability of control.

Gardner: Right. If your company is behaving like Zimbabwe, you need to do something different.

Matsumura: Exactly.

Kobielus: We talk about political governance in terms of the world community. There is no one right governance model within a state or among the various states of the world. But clearly, history has been marked by individual states or groups of states playing and towing with, if you can use the word, various governance models ranging from absolute dictatorships and empires down to sort of laissez-faire, no centralized government.

But governance is an abstract concept, and you don’t necessarily want to dictate one governance model that’s applicable or should be applicable to all organizations and industries. Everybody has their own pressures, market pressures and so forth. In terms of SOA governance, there are radically centralized models in a given organization. It could be a radically centralized governance model within a given industry sector in the sense that basically one monopoly company controls an entire sector of the economy and they then dictate all the SOA policies and practices for all of their tributaries, as it were.

In the world, you have 230-something countries that are sovereign states ostensibly, and they establish various bilateral treaty relationships and also participate in various multi-lateral treaty organizations like the United Nations and NATO and so forth. Any given country is probably, involved in various international governance schemes as it were -- but also internally, from generation to generation, from revolution to revolution it’s going from centralized to decentralized. One size doesn’t fit all generations of governance.

Gardner: So, maybe we should take a lesson from the United States in Iraq, where you need to look at what you’re getting into. You might not want to just take a company and inject a pure democracy or a federated approach. In fact, each company has its own history, its own culture.

You might want to do the equivalent of a Myers-Briggs test and figure our what kind of company it actually is. Then, figure out in what way to approach governance, so that we don’t try to overstep what’s possible on a linear basis. I suppose it’s also evolutionary. Some companies might need to start out as strict dictatorships, and then perhaps the government withers away and it becomes a democracy. We’ve seen the example of Eastern Europe over the last 20 years. Any thoughts on politics and geopolitics as a lesson for SOA?

Garone: I think it’s a great metaphor. I’m thinking about the model that I think makes sense in that regard, although it’s kind of obvious, which is basically, the U.S. Constitution and the federation of states. You’ve got certain things that are up to each state, and certain things that are up to the federated entity sitting on top of all of it.

Gardner: If I could just pause you. The first step, the Articles of Confederation, which gave too much power to the states, didn’t work.

Garone: Right. So, now you’ve got a dynamic situation where some of that can change and over time. Plus you can also “amend your constitution” to make changes as appropriate. But, there was not always a set of things that are controlled by the centralized entity, the federal government, in the metaphor. But there’s also a certain set of things that those individual states need to comply with in making their own rules.

Matsumura: I just want to jump in here and talk about the U.S. Constitution, which has some key design patterns in it. If you actually look at the separation of power declared in the preamble, it says that the purpose is, "... in order to form a more perfect union." So, there’s this notion of the intent of the formation of this governing entity, which is the goal of a more perfect union, which essentially means that there’s a distribution of power and that the consent of the governed essentially be the overriding principle.

The idea that comes out of that, though, is the clause "provide for the common defense." That’s really talking about the security domain, whether it’s physical security or technical policies associated with the current data. The idea is that it actually should be a federated concern. In other words, security is everybody’s business. You can’t just delegate it to one unit and say, "It’s your business."

The earlier comment about how there’s no one-size-fits-all is absolutely the case. For example, I just spoke with a bank that's highly decentralized. I also spoke with one of our customers, Johnson & Johnson, which has 200 operating companies, and is fairly decentralized. Their central IT exerts a pretty strong coordinating function. So, we’re talking about the big picture, which is, how do extremely large entities organize themselves and how do they achieve success in that organization?

Garone: It comes down to what an organization wants -- centralized or decentralized IT functions. Getting back to the whole notion of the Founding Fathers of the United States, they were not of a single mind among themselves on the proper governance structure. You have Alexander Hamilton, who wanted highly centralized. Then you have Thomas Jefferson, the fellow who wrote the Declaration Of Independence, who wanted it quite decentralized.

And they yanked back and forth until various things happened, and that got more centralized. Then, you had some of those, like in the southern states, who felt it needed to be highly decentralized, and fought a war to try to enforce that kind of order. It’s one of these things that just keeps rocking back and forth, from one generation to another, in terms of the right approach.

Kobielus: Look what’s happening in Venezuela now with this guy Hugo Chavez. He’s totally centralizing everything, establishing a new dictatorship there. Not all of his country people are happy with that. I saw in The New York Times that a lot of them are applying for asylum in places like Spain and elsewhere. This is highly political, but on the IT front, it’s the same thing. Quite often, SOA is justified on a project-by-project basis. "Oh, yeah. We’ll do this project according to the principles of SOA," without necessarily implying that they’re trying to impose SOA practices across all projects and across all systems.

Gardner: Now the corporation as an organizational definition has been around for couple of hundred years. You look back to early mercantile activities, to some of the Dutch companies that had started in 17th century, for example. The modern company is certainly at least a hundred years old.

If we look at some of the large conglomerates, there’s a history of progression around corporations as entities in a more modern sense. Perhaps what's different now, though, is that companies are of, for, and by -- if I could borrow another political statement -- technology. Technology so permeates how a company operates, particularly if you’re Internet-facing and if you’re using and exploiting the Internet for more and more of your supply chain, your distribution, your transportation, for the way in which you attract sales and customers, and so on and so forth.

So technology now is at an intersection with the corporation as an organization, and perhaps that’s what’s forcing this need for a different look at how to organize in general, and, therefore, on how to govern.

Matsumura: I wanted to respond a little bit, too. One of the themes that emerges from our conversation here is that we’re talking about SOA as more or less of a post-modern infrastructure. What I mean by that is that some of the themes that emerge in post-modernism, post-structuralism is the notion of the breakdown of the dominant narrative, which is that there isn’t a universal "thing." The resistance to the one-provider IT stack model, the suite model, is the notion that there isn’t a single system that can rule them all, over all others, and that heterogeneity, components-wise, is the law of the day. Think about that particular heterogeneity in terms of how it functions from a policy perspective.

We talk about federations and policy context, but there’s a degenerate case, where essentially what you’ve done is you’ve created a federation of two. This means that two business units come up with an agreement, or two companies come up with an agreement, which is referred to as a contract. The reason I’m alluding to this degenerate case is that a contract is treated as a completely different class of legal structure within our governmental system, and is protected by the civil law system. When disputed parties get into contention, it’s basically a civil issue.

When someone breaks a policy held by the government at-large then it is either a federal or state issue. From the perspective of creating an appropriate taxonomy, it’s important to consider that these two cases are actually pretty different. Perhaps an attempt to establish initially a sweeping universal regime of centralized federated policy may actually be subsumed by these kinds of groupings of pairs of twos or threes -- or United Nations or NATOS -- or just the kind of loosely coupled and smaller policy domains that are built on top of individual agreements between provider and consumer pairs.

Gardner: I guess we’re somewhat fortunate that there are only about 200 countries in the world, but there are thousands and thousands of companies. So, there’s a lot more opportunity for experimentation in the marketplace and for competitive forces to play out dominance. We can see some success stories, as well as failures, and we can learn from those successes on how to best organize a highly technologically advanced corporation.

McKendrick: We talk about the post-modern corporation. Where are these companies going to get their IT? Where are they going to get their technology? We’re seeing more and more instances of companies going outside, not wanting to get involved with the bits and bytes of managing a technology infrastructure.

We call it "software as a service," "managed hosting," and various types of acronyms and terminology. But I’ll bring Nick Carr into the argument here. Nick Carr said IT doesn’t matter. It’s going to be ubiquitous, available like a utility. Any company can tap into it, whether it’s internal or external, to the point where it’s not that big of a concern.

Matsumura: I can’t resist shooting at this. It’s going to require you to follow along with the metaphor that we’ve drawn. If you can’t suspend your disbelief in the metaphor, it will be hard for you. The metaphor of nations and the competition between nations has typically been along the lines of warfare in our history.

Look at the metaphor of business at war, which is essentially competition for the survival of the integrity of your company against all others. It’s not on the battlefield, but it’s for customer value, for creating services that people treasure. In the history of warfare between governments and nations, what we found is that the organizations that leverage technology to their advantage are the ones that come out ahead.

Abdicating the responsibilities of the management of technology to a commoditized provider creates an extreme vulnerability because your competitive differentiation should not be held or embodied by some generic provider. I think even Nick Carr has backpedaled from his hard-line IT commodity position.

Gardner: I’ve noticed that Nick has backpedaled a little bit, but again we’re back to where it’s not necessarily all-or-nothing. There are going to be some aspects of technology that are commoditized, that should be accessed centrally, and there are many others -- perhaps this will change over time -- that are differentiators. Control over how your organization behaves and controls your assets and resources strikes me as something that you would never want to commoditize.

Kobielus: Think of this notion of where companies in the most post-modern age are going to get their governance structures from. I think a lot of the governance risk and compliance management vendors -- it’s a new market space; companies like SAP and OpenPages and MEGA International and BWise, and others, are building up platforms that have both verticalized and horizontalized governance templates, rules and workflows, and so forth. Increasingly companies or enterprises will standardize on a dominant governance risk and compliance management vendor for their organizations, and then use whatever templates they choose. And their SIs will modify them to suit their own needs going forward.

Bringing this back to the whole notion of where nations get their governance charters. I just read a book, a really good one, called "Declarations of Independence," and it shows that the first actual declaration of independence ever created to found a nation was our Declaration of Independence in 1776. You wouldn’t believe how many other countries have actually plagiarized or borrowed language and whole concepts from it, including Vietnam. The declaration of independence for Vietnam in 1945 directly quotes from our Declaration of Independence, which I found highly ironic.

Garone: I’m going to bring back outsourcing into this discussion as well. Post World War II, the nations that have relied on the Unites States for its defense have thrived economically, because they have not had to spend so many dollars on their own defense -- Germany being the prime example. They’re under our umbrella, and their defense budgets are much lower than ours, and these nations have thrived and moved forward.

Gardner: Well, without getting too deep into what is or isn’t the right approach in world affairs, clearly we’ve defined here that a successful SOA is a lot about politics, power, and moving beyond traditional norms of organization. How you do that probably is going to involve failures. If the Unites States is a good model, it had to fail a couple of times. It failed with the Articles of Confederation. It failed in dealing with slavery up until the Civil War, and perhaps for a hundred years afterward in terms of how it was dealt with in practice, if not in law.

So the idea that we started this discussion with -- where are the SOA failures -- perhaps we should look to failures as a necessary set of learning activities, in that SOA is not going to just happen and spring up like a fungus or a mushroom after a spring rain, but it’s going to have to be something that’s hard-earned.

Matsumura: Well, the way I want to respond to is that having maturity in the way that you deal with failure is essential. If you look at the way that our policy system functions within the United States, what you have is you have a set of policy assertions about what it is people can and can’t do. But then you actually have a policy enforcement mechanism that’s heterogeneous and distributed. You have the FBI, the CIA, the state and local law enforcement, the Army and the National Guard.

You have all these different policy enforcement points everywhere, manifesting these policies. What is extremely important to understand is that there’s an entire judicial system whose function it is to take those policy enforcement actions, monitor their efficacy, and enable the whole system to readjust and adapt.

So, I think that it’s not just an accident of, "Let’s just run out there randomly, screw up badly, and then sit there and try to recover and learn." I think that having a learning engine that monitors, adapts, and revises policies, and having a competency center, an adjudication point that’s deliberately there for the purpose of making those adaptations -- that is an essential function.

Gardner: Or checks and balances ... . If you’ve got failure, that could be a very good learning experience, where you need a check and balance in place, and so the progression toward the value and benefit of SOA can be accomplished. It will be a different path for each company, but they’re going to have to have checks and balances to keep the progression going forward, rather than reverting back to the past, and in a sense giving up.

Well, this has been a very stimulating and interesting discussion, I’m glad that you all could join us. It took on a little different characterization than I was expecting, but a necessary vantage point on SOA in order to make it successful.

We’ve been joined here with our usual panel, Steve Garone, Joe McKendrick, Jim Kobielus and our guest, Miko Matsumura, vice president of SOA products at webMethods. This is your host and moderator, Dana Gardner. You've been listening to BriefingsDirect SOA Insights Edition, Volume 11. Thanks for listening and come back next week. Thank you, gentlemen.

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.

Listen to the podcast here.

Transcript of Dana Gardner’s BriefingsDirect SOA Insights Edition, Vol. 11. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.