BriefingsDirect SOA Insights Analysts on IBM’s Telelogic Deal and Open Source ESBs

Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition podcast, recorded June 15, 2007.

Listen to the podcast here. If you'd like to learn more about BriefingsDirect B2B informational podcasts, or to become a sponsor of this or other B2B podcasts, contact Interarbor Solutions at 603-528-2435.

Dana Gardner: Hello, and welcome to the latest BriefingsDirect SOA Insights Edition, Vol. 20, 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.

Our panel this week consists of Jim Kobielus, principal analyst at Current Analysis. Welcome back, Jim.

Jim Kobielus: Thanks, Dana. Hi, everybody.

Gardner: We’re also joined by Todd Biske, he’s an enterprise architect with MomentumSI, an Austin, Texas consultancy. Thanks for joining, Todd.

Todd Biske: Thanks Dana.

Gardner: Joining our show for the first time is Brad Shimmin. Brad is also a principal analyst at Current Analysis. Welcome, Brad. Tell us a little bit about your area of coverage.

Brad Shimmin: Thanks for having me, Dana. I focus on application infrastructure and spend most of my time thinking about middleware and SOA.

Gardner: Terrific. That’s the right mix for our discussion. We’re here to discuss some news and events for the week of June 11^th, 2007. I attended the Rational Developer Conference in Orlando, Florida this week. It was a little bit warm down there, but a busy time nonetheless. There was lots going on within the Rational Brand Division, within the software group, and within IBM. I came away with some observations I'd like to share. Have we been joined by another guest?

Dave Linthicum: It’s Dave Linthicum.

Gardner: Thanks. Also joining us today, Dave Linthicum. He's the CEO of Linthicum Group. Good to have you, Dave.

As I was saying, we’re just getting into our topics, and we’re going to look at some of the IBM news this week that came out of the Rational Division. There was the intent to buy Telelogic, a Swedish firm that’s got a lot of product across requirements, tests, QA, architecture and modeling, as well as embedded and system development. So, we’ll talk a little bit about that.

We’ll look at some of the announcements out of the Rational Developer Conference, including the Jazz Community, an innovative commercial/open-source community approach to development. Also, one of the more interesting product announcements was Rational Asset Manager, essentially a design-time metadata repository that can be used in conjunction with an operational or run-time registry and repository for a lifecycle approach to services.

What’s more, we’ll go around the table and look at what research folks have been conducting this week. That might include a look at WS02, the IONA Artix announcement, and some announcements also from BEA.

So, let’s start with the Telelogic acquisition. Telelogic is a publicly held company in Sweden, and IBM had to jump through hoops in order to acquire this company. They also announced it at their developer conference, which to me was an indication that this timing was not entirely their choosing.

Why don’t we start with Jim Kobielus? IBM and embedded -- we haven't seen anything along those lines for a while. They jettisoned the Rational embedded drive before IBM had acquired Rational, but now they seem to have a new-found interest in embedded. That's increasingly focused on end-to-end development, recognizing that the entertainment and media sectors are going to be creating devices different from a personal computer. IBM doesn’t want to miss out on the opportunity to leverage its back-end systems vis-à-vis these new types of devices. Any thoughts, Jim?

Kobielus: Clearly, IBM over the last few years has made stronger moves into the appliance space and really helped to define it. Obviously, with the DataPower acquisition a few years ago and increasingly taking their data warehousing appliances -- I think they’ve already revamped that entire product family -- they can scale from very small, or relatively small, data warehouses to very large ones.

IBM is trying to fuse their chief software products and technologies with their hardware engineering expertise to develop products for various markets. Embedded operating systems, embedded application components, and so forth, are key to all that.

So, when I saw that they were acquiring Telelogic, it made perfect sense. IBM is very much bringing together the hardware and software worlds into appliances, both for the business and potentially for the consumer market.

Gardner: They mentioned synergies several times. Synergies would include the silicon. You know IBM is big with Power PC. They also have this new Cell family of customizable, modularized silicon designs. So, there’s an opportunity for them to go to the embedded market with an optimized silicon and platform approach. Of course, Rational is in the business of helping developers be productive across lifecycle and to manage development, not so much in the tools category itself.

I think they see a wide-open opportunity in embedded that is still a fairly wide-open, roll-your-own test, roll-your-own tools, even roll-your-own IDE or real-time operating system. So, I wonder if anyone else has some thoughts on the embedded angle on this?

Shimmin: Well, Dana, not so much about the embedded angle, sorry to say, but perhaps something that might transition us into talking about Rational. When I look at what IBM is doing here -- and this is pursuant to what Jim was just saying about their synergies between hardware and software -- I see IBM doing two things.

One is renewing the focus on software development on the design time and development time side of things. Then, I see them taking their expertise in hardware and putting the two together to build what a lot of the software companies or platform companies really wish they had in the space, and that is the ability to do two things: create well-performing software and actually have software that performs well in the production environment. They’re going to be pretty well positioned to take advantage of those two things.

Gardner: That’s interesting because that fires high-level observation I made between the Rational Conference and the Impact Conference around SOA innovation just several weeks earlier. That was that IBM is anticipating the change in the definition of applications and systems. It is really focused on trying to get very vertical in terms of expertise about businesses in verticals, align that with their systems, and then allow for some level of consulting that joins these, whether it’s their consulting or someone else’s.

They seem to be involved now more and more with getting very close to the application, almost to the point of being in a position to be dominant in terms of custom application development. Do you have any sense from your perspective, Brad, about the whole notion of the shift in the definition of applications and how to create them?

Shimmin: Absolutely, Dana. It’s funny. Both IBM and Oracle are the two companies leading the chart with what you just said there. They’re taking tentative baby steps, because this is a pretty daunting task they’ve undertaken. That is, as you said, dive deep into a given vertical and a given set of business processes within that vertical to provide literally out-of-the-box functionality. You’ve got your data models. You’ve got your actual BPEL processes. You’ve got everything that surrounds whatever it is you need to actually get some sort of process up and running within their environments.

Maybe five years ago or so, platform vendors really focused on the foundation infrastructure of what these applications run on. They’ve realized in maybe the last six months that the success that they’re going to enjoy is going to come from their ability to save their customers money from the exorbitant consulting and professional engagement fees that usually come hand-in-hand with rolling out software like this.

So, what they're doing is pretty cool, and I applaud them for it. As I was saying a second ago it’s a pretty long row to hoe and it’s going to take a lot of energy on Oracle’s and IBM’s part to actually fulfill this and to say, “Okay, we’re going to give you a set of business processes with all the data you need to set them up and get them running for your vertical.”

Gardner: I think they’ll try to come downstream to a certain level and then hope that there’s an ecology of other providers that are even more in the weeds of vertical by vertical that they can help support and become friendly with. Right?

Shimmin: I think IBM is actually leaning that way and they have a very strong ecosystem already in place.

Gardner: Hey, Todd Biske. Telelogic also has an enterprise architecture product. Have you evaluated that or been familiar with it at all?

Biske: I have not evaluated it myself. Momentum’s CEO, Jeff Schneider, said maybe we’ll see some more activity on that product. It’s interesting, because I’ve yet to run into an organization that’s really leveraging some of the EA-specific products that are out there. They still tend to do 90 percent of what they need to do in Visio, rather than some of the specialized tools in that area, but, as the discipline matures, we’re going to see a lot more of that.

I want to talk a little more about this notion of it bringing IBM closer to the application business that you first commented about in your blog. At least, that was the first time that that was brought to my attention.

I have a friend from college who has worked in the embedded space pretty much since we graduated, and he contacted me recently about applying SOA to some of the work that he was doing. It surprised me a little bit, because it’s not a space that I’ve had to deal with. I’ve typically been in big IT and big enterprises. It opened my eyes that their environment for developing is maturing as well. They are getting to higher levels of abstraction and taking advantage of the same types of programming models a typical enterprise developer is.

I thought they were going to be so focused on performance and real-time behavior of these systems, that they may not have a strong interest in some of the things that Web service standards and XML have to offer, because of the tradeoffs from a performance standpoint. He said, “No, we are looking at all of that.”

Now, with IBM making this acquisition of a company that’s dealt in the embedded space, it really shows that development is still development. IBM is now recognizing that it’s not all just about “build whatever you want.” We are getting more specialized, and maybe the right way to get into the applications market is to create specialized tools for particular vertical domains, rather than providing the applications themselves.

It’s definitely something to pay attention to, as we go along. They did it on the tool side; they did it on the software side with the Webify acquisition last year; and I would guess that we’ll continue to see more in this direction.

Gardner: I suppose if you get very specialized in managing the process of creating applications at that very fine level, then that’s as good as creating the applications themselves. Let’s go to Dave Linthicum. Any thoughts about the Telelogic acquisition?

Linthicum: What’s missing in the space is a holistic design tool around SOA. I looked at Telelogic at the EA Conference in New Orleans a couple of months ago. I was impressed with it, but it didn’t have a lot of the components it needed to drive an SOA. I think IBM saw the potential for providing not only a design tool, which they have with the Rational stuff that you mentioned -- basically development lifecycle -- but also a holistic architecture tool to deal with artifacts and requirements and all those sorts of things that Telelogic does, and they’re looking to connect the dots. If they do come out with a holistic SOA-oriented design tool built around their technology, they’re going to have a huge hammer to beat into the market.

Gardner: Interesting. Did you get a chance to take a look at this new Rational Asset Manager, and what did you think of that?

Linthicum: I did look at it from the online piece, and I think that it’s going to have value in this space as well. The folks at IBM are not dumb. They’re out in the back, trying to figure out how all this stuff is going to fit together. They want to have not only the mega-stack in terms of deploying technology and development technology, but the mega-stack in terms of the design time stuff, including holistic enterprise architecture, asset management, service management, and SOA governance.

So, it’s going to be very difficult not to see IBM in almost all the larger SOA implementations out there, once they have a critical mass of tools. They’re investing right now. They see this as a long term strategy and a way to gain revenue 10-15 years down the line. I think they’re making some smart moves. I would have acquired Telelogic as well, if I were IBM.

Gardner: It seems that $745 million isn’t heck of a lot, given what companies go for these days. It seems like they got a pretty good deal.

Linthicum: Oh, it’s a bargain. They did very well buying it, and they’re going to reap a lot of benefits from it. This is the right move from IBM and the investors are going to love that three or four years down the line.

Gardner: One of my takeaways was that Rational, as an entity and a functional component within IBM, is rising. It’s really bringing together some of the other brands, including Tivoli and the SOA and WebSphere activities. There’s also a role for Lotus with collaboration among and between developers. So, it’s interesting that Rational, which seemed like an odd man out a few years ago, is really becoming somewhat of a mortar between the IBM brands, and also gives them more interception points in these accounts. That is to say, they can work with OEMs, now that they’re in the embedded space. They can work with ISVs through Rational. It just gives them more traction points to pull other aspects of their value into play.

Kobielus: That’s exactly what I’ve seen too, Dana. Rational is becoming the crown jewel within IBM. In my area of focus, master data management (MDM), the Rational tool has become the primary master data modeling and domain modeling tool for all of IBM’s MDM products. I agree. It was probably their most important acquisition in the last 10 years.

Gardner: Just for an element of balance, there is significant product overlap between Telelogic and IBM Rational, particularly on requirements, gathering, and management. However, they took pains during their press conference and analyst discussions to say that there is product overlap. They’re bound by the laws in Sweden not to get too specific about what they plan to do, but they say that there is very little market overlap. Where IBM plays in requirements and where Telelogic plays in requirements are quite different. So, I’ll be curious to see how they do, let’s say, RequisitePro, a popular Rational tool, vis-à-vis the other aspects within Telelogic.

One last item in the IBM news. They announced this Jazz community, jazz.org, and it’s essentially an open environment, which people can join and help contribute to the development of Rational products. This is somewhat of a trial balloon with IBM saying, “Wow. Look, how successful Eclipse was as a governance environment and a community development force in the market. How can we take what was good about Eclipse, but apply it to commercial product development, not just open-source development?”

It strikes me that if the companies who partner with IBM that have a vested interest in how their products relate to the Rational products contribute and help define the Rational products, then the same model could be applied to other commercial aspects within IBM, and they could then perhaps even take the model to other products. Has anyone had a chance to look at Jazz? Do you think that this is a wacky idea, or do you think it will get traction?

Shimmin: I looked at it a little bit. This is not the first time this has been done, and it certainly won’t be the last. As you said, they saw the success of Eclipse and they saw that it was an environment that fostered innovation. As we all know, it’s very hard for large closed-source vendors to innovate quickly, while maintaining a customer base accustomed to once-a-year big upgrades, punctuated with little patch here and there.

I look at what IBM has done, as well as TIBCO, Sun, BEA, and Red Hat -- even though they’re not closed source -- and I see them using the tools that the open-source community fostered in order to collaborate over a large-scale network of developers, and they’re applying it, just as you said, to closed source. There are many benefits to that.

First and foremost is a quicker turnaround on bug fixes and getting to a GA. When you’re dealing with the traditional closed-source development cycle, you build your software, you send it out to maybe 10 trusted customers. They hammer on it a little, and you have your own internal people hammering on it, and that’s maybe a three month venture.

Using 10 customers, who have their own jobs to do and don’t give this a lot of shrift, sets you up for failure. That’s why we see so many post-release patches going out. What this is going to do, if it succeeds and can be applied to closed source, is let these large vendors get their code out quicker in a much more tip-top, enterprise-ready fashion.

Gardner: I suppose it also allows end users to have more of a say in what they’d like to see in the products that they buy or use -- how they evolve.

Shimmin: Absolutely. IBM is taking a tiered approach to it, and some of the others have too. As we were saying with these trusted customers and partners, partners in particular are going to play a big role in this, but they would get access to source code at deeper levels. Folks that maybe are smaller customers or just interested parties, who want to make this product go forward, will have more limited access, unlike a traditional open source. They’ll have more limited access to the details of the source code.

Gardner: As I thought about this, it seemed to me that there has been an enabler in the market that’s allowed this to take off more than it would have in the past. That’s because of companies like Black Duck and Palamida that are able to evaluate code very quickly and determine its origins. IBM seems to be a little bit more flexible about opening the code up for people to look at and use. They’re assured that if it were to go into some commercial production, they’d able to find out and put an end to it, or at least get it into their royalties and licensing business. Do you think we’re at the point now where we can manage code to such a level that this permeability around the use of code is much more open and free?

Shimmin: Should we be thanking Microsoft, Novell and SUSE for that a little bit?

Gardner: Well, bringing it to people’s attention that it’s not black and white. It’s grey, right?

Shimmin: Absolutely.

Gardner: Anybody else have thoughts on Jazz community development in a commercial production effort?

Biske: It’s an interesting idea. I wonder how different it is from some of the efforts already going on. Clearly, we have commercial efforts built on open-source products. The key question here involves open-source products that are not available for free. If developers are working on it and they can build it and use it, how is that model going to come together if they say, “No, you only have a license to run it in a development mode and nothing more than that?” Is that going to be followed or not? Are they going to bother to enforce it, or do they really know in the long run it’s going to take the same direction that Eclipse did.

IBM has a commercial version of Eclipse, but largely people just go with the free product, because they can still include all the plug-ins that they need to. If they need to buy add-ins to it, they’re okay with that. So, they can focus their attention on Eclipse and create a framework, and can plug-in commercial components as they need to.

The other risk that they take is that the community is just going to look at this and think they’re just looking for free work. trying to take advantage of developers who just love to code and could care less whether they’re getting paid for it or not.

Gardner: I guess it all comes down to incentives and motivations. It might propel people to “donate” to an open-source project, similar to the incentives and motivations that drive them to contribute to a proprietary closed commercial environment.

Shimmin: There are no selfless acts. Right, guys? When I scroll some message boards for these development efforts, I see people in enterprises saying, “I need access to this API because I need to extend the product to work with something I’ve built in-house.” I think that’s the kind of work that’s going to drive us forward.

[[[Speaker:]]] It’s the same phenomenon as the developers who are employed by a vendor like IBM. They quite often work excessive unpaid overtime, just because they’re committed to their jobs, their products, etc. In a sense, now you’re roping in the partner ecosystem as well. They’re putting in essentially unpaid overtime to help out the mother-ship vendor get its products debugged and developed.

Gardner: If I were an ISV in the Rational universe or ecology, and I had an opportunity to have a say in what their products did or didn’t do, or if I could contribute some minor hooks, that might greatly benefit my business, I might be very motivated to do that.

Okay, let’s move on to some other topics. WS02 announced ESB 1, which is largely based on the Apache Synapse ESB. I want to make a disclosure that WS02 is a client of mine, and we should consider that as I present comments. I wonder if anyone else took a look at this, and had some thoughts on, “Wow. Yet another ESB and yet another open-source support maintenance business model entrant in the SOA ecology?”

Shimmin: Dana, I talked to them briefly about this before they released it. Like you, I saw this as, “Oh, yes, here’s another one, and maybe Red Hat should worry.” But, I don’t think anyone else is going to worry, except maybe the pure play ESB vendors like Cape Clear.

They’re focusing on what everybody in this space is trying to focus on, performance. Everyone has realized that ESB is at its level of maturity. You need to really be focusing on availability, reliance, reliability -- the “ilities” -- of deployment. This is the third vendor in the last month -- this would include IONA, Cape Clear, and WS02 -- who has talked primarily about the performance of their ESB and their ability to parse through messaging in a very highly scalable manner.

Gardner: They also seem to feel that they’re coming from a pure Web services heritage, without trying to drag a legacy business model into the mix. Therefore, their ESB is more ecumenical. Does that make sense?

Shimmin: I got the same vibe from them too, but I feel as if every vendor with an ESB these days feels the same way. They realize that, as with databases, you’re going into a heterogeneous environment regardless, and most likely inter-departmental, inter-company you’re going to have multiple ESBs and different messaging platforms that need to interoperate.

Gardner: Let’s take that to Todd Biske. He’s an enterprise architect. On one hand, choice is good and on the other hand, choice is bad. Are you are getting too much choice when it comes to ESBs?

Biske: It doesn’t bother me. I’d rather see a lot more in the open-source space. They’ve got the freedom to keep it more focused on some of the target areas. In the case of WS02, they really are focused more on what I call the middle capabilities, rather than on service development and execution capabilities. You see a lot of the commercial ESBs going in the direction of giving you an orchestration platform and a composition platform. All of it is about building new services, and not about connecting existing consumers and existing service providers.

Some of these open-source ones are keeping it a little bit more constrained and targeted. Now, with the open-source model, if an enterprise needs to augment that for their particular needs it gives them the ability to do so. I’ve run into a few clients who are looking at some of these products and have a potential need to do that. The openness is a plus for them.

I don’t necessarily see it as too many ESBs out there. The market naturally will shake them out on its own. This is just the way these product spaces work. I don’t view it as an SOA bad thing.

Gardner: As a system integrator, you must feel pretty good about high quality open-source code coming around. Doesn’t that suit your business model pretty well?

Biske: Absolutely. At Momentum, we’re vendor neutral, and I know Dave talked in a recent podcast about the importance, when dealing with system integrators, of having one that is not closely tied to a particular partner, unless your company has already decided that you’re married to this particular vendor. Then, it makes sense.

If you’re looking for your pure systems integrator, you have got to select solutions that are in the best interests of the client, not the best interests of the consulting company or the partner ecosystem around this. Having open-source products gives us a lot more flexibility in meeting the needs of the clients.

Gardner: Dave Linthicum, do you want to weigh in on this?

Linthicum: I don’t put as much value as everybody else does into the open-source equation. In fact, my client base -- and it’s Global 2000 and government folks -- are indeed buying ESBs and other things based on the notion of having access to the source code. I just can’t imagine in my lifetime that they would ever want to become a product development vendor and would have the skill set to actually maintain a middleware product, having built a bunch of those in my lifetime. I’m a little skeptical about the ultimate value there. To me, open-source needs to have marketing value. I’m not sure it’s going to have a lot of technical value going forward.

My larger concern with the number of ESBs out there is that, in many instances, these have a tendency to be queuing systems with service interfaces on top of them. Therefore, they’re more information- or data- oriented than transaction-oriented. That has a tendency to limit some of the emerging patterns I’m seeing within SOA. People are looking basically to automate these high-end business transactional systems well beyond just data consumption and production.

Most of the ESBs don’t really address that. They basically become queuing systems with a nice interface on them. To Todd’s point, they do have orchestration layers and other development technology. Some of the higher ESBs out there definitely have that capability. That seems to be nice, but it still seems to be limited by the underlying infrastructure that they’re selling.

I’m concerned about the number of the ESBs in the market, and I’m concerned about the ability of those ESBs to deliver the ultimate value as the SOA we’re building becomes much more sophisticated.

Gardner: Any other thoughts on ESBs before we move to our next subject? Let’s go to Brad. He is the new guy on the block. Let’s pick on him a little bit. What did you write about this week, Brad, and share a little bit about your insights if you wouldn’t mind?

Shimmin: This week I looked at two things primarily. One was the release AmberPoint made regarding their SOA validation system and their SOA management system. They have two products and they just versioned them to 6. I found what they were talking about very interesting, because, as I was just saying a second ago, they too are focusing on performance.

What they’ve gotten at is their desire to be in a run-time environment, because, as you guys know, they are like the Switzerland of SOA run-time governance in our industry. They are focusing on being able to scale their platform, and they have a number of partnerships and potential partnerships with hardware manufacturers, going back to our earlier discussion about IBM and their DataPower acquisition.

They seem to have this idea of, “Well, we’re run-time governance only, and we have the capability to be design-time governance as well, but we’re not going to get into that space.” I found that interesting, because they’ve just announced this as a part of this pre-flight check that they do. This is similar to the type of the service that IONA launched with their Registry Repository, in which when you check your WSDL into the Registry Repository, it actually goes out, looks for dependencies, etc.

In the AmberPoint product, but a little bit more predominantly positioned, they actually go look at that WSDL as it relates to other processes across the entire application and looks for any interdependencies, broken relationships, and anything within the production environment that may cause a problem.

I think about companies like CA, HP, and IBM, who all really are trying to come at the same problem, but from the design and development side, and I think of AmberPoint coming at it from the run-time side. I feel like, “Well, why don’t you guys just get together? Let’s put these two notions together and make it so that we have a more coherent lifecycle management of our codes for SOA implementations that starts in design and ends in run-time.”

Gardner: What’s going to fill that middle role or the gap between these run-time and design-time capabilities, so that we get that feedback loop, perhaps even an automated approach to optimizing and assuring quality and reliability. Is that going to have to be wetware? Will people fix that problem, or can it be productized?

Shimmin: It’s a combination. When I talked to AmberPoint about that very question, Dana, we were talking about it with regards to this throttling technology they have, where they can look at PKIs and SOAs that have been defined inside the Registry Repository and tell the process to slow down on Thursday afternoons, for example, because I need these other process to take priority on that date and time.

I said to them, “Well, gosh, I know there are a lot of tools out there at designed/development time – a lot of BPM products for example -- let me establish these and stick them in a registry. You just pick those up automatically and start executing them.” They said, no, because the schema and the amount of data that comes from this is not really enough to do it.

Gardner: These are just different orbits, right?

Shimmin: Right.

Kobielus: One of the glues, of course, is a common registry and repository infrastructure between the design-time and the run-time environments, but just as important is the wetware, as you indicated, a common governance environment with roles and workflows. People who are doing the design and optimization of the Web services and the people who are administering the services in a run-time can be collaborating on a ongoing basis.

The common rules and policies of this common infrastructure, be it AmberPoint on the run time or tons of other vendors on the design time, they can all share. So, it’s a bit of the registry and it’s a bit of the governance human administrative workflow.

Biske: It’s interesting that you bring that up, Jim, because one of the things that I wanted to come back to was the Rational Asset Manager. It seems to be typical of IBM that in their SOA offerings they’ve got three of everything. If the registry repository is the key, and I agree with you that this is really the unifying component on some of these things that are dealing with policy on the metadata, they’ve got Rational Asset Manager, which is effectively a metadata repository, and then they’ve got WebSphere Registry Repository, which is another metadata repository.

I’ve had conversations with them going back a couple of years on this subject, asking “How are you going bridge those, and what’s Tivoli using on top of this as the common metadata storage for all this?”

Brad hit on the other point, in his conversation with AmberPoint, that it’s not the fact that you have a metadata repository out there, but it’s the information that’s going into it. Until there’s some standard level of policy domain languages that these tools can leverage, you’re going to still see people just building their own fiefdoms and saying, “Well, you’ve got to have either AmberPoint everywhere or HP everywhere -- or whatever your management system of choice is -- to be able to do some of these things, like throttling across systems, and some of the run-time policy enforcement. It does need to bridge all the way back into the development tools.” So, again, IBM’s in a great position, providing products in all of those spaces, but it’s going to be difficult to pull off.

Gardner: Thank you. Now, you brought up an interesting point, which is that they would love to be able to have that chokehold. So, obviously, vendors have some vested interest in their own business models of making this less heterogeneous than other aspects of the environment -- this ability to create the feedback loop, manage exceptions and change, and optimize for performance and design. What do you think about that, Dave Linthicum? Is that possible or is it too late for them to do that, given the general heterogeneity and nature of SOA?

Linthicum: It’s possible for the newer offering, but they will have some pushback, given the fact that every domain is extremely different. One challenge that people have, when they try to get out in the market with this kind of stuff, is that ultimately what they think they’re implementing is different than what’s actually being implemented. I see a huge chasm between the perceptions.

For example, I was at the Gartner event this week to do a talk on ROI, and I got a chance to wander around and talk to a number of the people who are pushing in the market, both customers and users. There’s a very different perception as to what vendors think the problems are and what the problems are that users are actually experiencing. There’s going to be a bit of a sobering [[[-- come to Jesus --]]] that’s going to happen over the next year or so, when these guys push out there.

Gardner: Where are the two camps in terms of the difference between what they think they’re changing?

Linthicum: In the user community, all the problem domains I’m seeing, definitely in my client base, are unique. There doesn’t seem to be any one set of solution patterns you can apply across the board. You see bits and pieces of a stack and how simplistic those problem domains are. The vendors don’t see that when they design SOA in general. They typically give you the same stack and the same problem description. I’m not seeing a consistent problem description out there to work with the client.

Gardner: Well, of course, you can understand the perspective of the vendors. In order for them to have a volume business and repeatability and automate, they’d like to be able to take one hammer for all nails.

Linthicum: You can’t do that, and that’s the problem people are running into right now. I saw the same thing back in the integration days, back in the AI days. We tried to take one problem domain, all the spaghetti code, and put it through a single hub. While that was applicable to a small percentage of the problem domains, it wasn’t widely applicable. It wasn’t applicable to all problem domains. SOA is even more complex than that. Vendors are going to find that they’re missing the boat in terms of understanding the needs of the people they’re trying to serve.

Gardner: Once again, we come up against these issue of technology and people, where people are much better at matching nails to specific hammers or types of hammers, so that technology can run with it once they’ve established the proper relationship. SOA again becomes very people intensive. You need to be in the weeds to understand the business, and specifically you need to understand the particular company.

Linthicum: Dana, it’s all about people. As I’m getting further along in this stuff and learning more about it, I find that the people issues are really the core of all this all. I can solve any problem with technology, and probably everybody in this space can do the same thing. However, getting people aligned with how that’s going to happen and setting them up for success is the ultimate challenge right now, and the vendors need to understand that.

Shimmin: Back to our example of AmberPoint. If I have a nice BPM tool that lets me find my PKIs and SOAs, and if it’s not in my best interest to include that additional data the additional artifacts that AmberPoint is going to need to make that throttling automatic, why am I going to do it? I won’t.

Gardner: This is interesting, because I hear two different things in the market as well. On one hand, there’s a recognition that you can’t get the labor you want. You can’t get it on the continent that you want it on. And, people are trying to find ways in which to reduce the number of people, because they’re costly and they’re hard to hold on to. Yet, what we’re hearing here today, and I agree with it, is that we’re actually entering a phase where more people, with more specific knowledge and talent, are going to be required, and they’re going to be required onsite, not necessarily doing this through instant messaging. Any thoughts on that?

Kobielus: That explains why I’m seeing more emphasis in the SOA space on pre-built domain models, essentially solutions that package up the rules, the best practices templates, the workflows, the policies, and so forth, for a particular problem domain, be it in the MDM space or be it in the ESB space. The customers are demanding these accelerators so they don’t need to hire people who are smart enough to build all that stuff from scratch. If the vendor and their partner ecosystem have already frozen all that expertise into the solution, the customer can be productive from day one. So, the customer could have a little bit longer to go find the appropriate smart people, wherever they happened to be, whether in Indonesia or Chicago.

Shimmin: That’s why you look at the Rational and Jazz announcements this week and you see the reality that IBM is seeing, which is that, although we want to have this deep knowledge that’s in-house, that’s not likely to happen. You need to go where the talent is. So, the software is hopefully bridging those gaps.

Back to what you were saying earlier, Dana, about even Lotus being able to play in this, I think what’s going to become a much more predominant paradigm is that sort of telepresence for the entire life cycle of software for all involved in that.

Gardner: Well, let’s just hope the human resources people don’t get too involved.

Biske: I have a little bit different take on this. I still feel that it’s not that we need better developers, but that the technologists need to become more business aware and more business savvy.

There are a lot of businesses that may be looking offshore for a lot of these efforts, strictly from a cost reduction effort, but that doesn’t necessarily mean they’re going to get any better technical solutions than they would have with resources in-house. It just may mean that they’re going to get it less expensively, and even that is debatable.

So, they haven’t really improved things from that standpoint. In terms of business agility, they’ve reduced their cost, but is the IT solutions actually helping the business any more than it did before when all the work was being done internally? The only thing that’s really going to help push it along is to get people who are both knowledgeable about the business, as well as knowledgeable about the technology, and being able to bring those two worlds together.

Shimmin: I don’t think BPEL is the only way to do that, but that seems like that’s all vendors are focusing on right now.

Gardner: I’m a little bit concerned about that. I had this conversation with Sandy Carter at IBM about how they’re looking for “T-ish people” who have horizontal business acumen and understanding and then a vertical stem around deep technology. I’m thinking to myself, these are fundamentally different kinds of thinking. You’ve got right-brain people; you’ve got left-brain people. Most people favor one or the other. There are not necessarily going to be very many who are very good at both.

Maybe we should be thinking about this as small pods or teams, where you’ve got a business person who is savvy, you’ve got a technologist who is savvy. And, then you’ve got a facilitator, a person who is very good at motivating and communicating, and create three-person pods to approach this, rather than think you’re going to get it in just one individual.

Kobielus:[[[???]]] Right, because these are all separate domains of complexity. You can be really astute on business issues, if you focus on that and you continue to refresh your understanding and the nuances of all of that day in and day out. Likewise, all the technology areas are themselves entirely stand-alone spheres of complexity. Imagine one person trying to juggle those different spheres of complexity all day, every day, and do a good job of it. That’s really hard from a wetware perspective.

Shimmin: Do you guys know the notion of extreme programming? The idea is to have these micro teams with two people who are always working on a given aspect of a project. Why not have one of them be the IT technologist and the other one be the business analyst?

Gardner: There’s an opportunity here for someone like a McKinsey to come in and start analyzing the organizational dynamics of approaching SOA, what sort of teams should be put together, and what sort of people should have certain skills. This whole notion of one person doing it seems to me as farfetched. These teams could be much more capable and much more distributed. You could push them into different activities within this problem set and they won’t necessarily have to be physically there.

Biske: Companies that have started to practice user-centered design and some formal usability practices are probably in a much better position. One thing you find in doing that is that you immediately have to get out of this customer-supplier relationship and into a team environment, as you describe, for developing solutions for business users. They’re part of the team. They’re not a customer.

Pointing to other potential groups, someone like Patricia Seybold Group, and their focus on customer innovation, some of those concepts really need to be brought in here to stop viewing IT as a supplier to the business and instead as a partner and working from a team standpoint.

You’re absolutely right that the T can be built by creating a team, rather than looking for one superstar individual that understands it all, because there aren’t too many of them.

Gardner: Well, I’m afraid we’re out of time, but I think we’ve stumbled into a topic that I’d like to pick up again in another show. That’s the organizational approach and the relationships between customers, supplier, integrator, and how they come together, or not, and what we need to do to come up with some new approaches around that. So, thank you everyone for joining. Once again, we’ve had Jim Kobielus, principal analyst at Current Analysis. Thank you, Jim.

Kobielus: My pleasure.

Gardner: Todd Biske, enterprise architect with MomentumSI. Please come back, Todd.

Biske: Thank you.

Gardner: Dave Linthicum, CEO of Linthicum group. Always good to have you, Dave.

Gardner: Also, a newcomer, who we hope he will become a regular, Brad Shimmin, also principal analyst at Current Analysis.

Shimmin: It’s been a pleasure everyone, thank you.

Gardner: This is Dana Gardner, principal analyst at InterArbor Solutions. You’ve been listening to BriefingsDirect SOA Insights Edition, Volume 20. Come back again next week. Thanks, everyone.

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. 20. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.

SOA Insights Analysts Discuss Likely Future of SOA at Open Group Conference

Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition podcast, recorded July 23, 2007.

Listen to the podcast here. 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 a special presentation of BriefingsDirect SOA Insights Edition, an ongoing series of podcast discussions on 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.

We are recording this special podcast on "The Future of SOA" before a live audience at the July 23^rd, 2007 plenary session of the Open Group’s Enterprise Architecture Practitioners Conference in Austin, Texas. Welcome to you all.

Our panel today consists of Eric Knorr, executive editor-at-large at InfoWorld. Also, Tony Baer, principal at onStrategies; Todd Biske, principal architect at MomentumSI, based here in Austin, and, Beth Gold-Bernstein, vice president of ebizQ Learning Center. Welcome to the panel.

Our topic today is “The Future of SOA.” We want to take a look at what might happen if a lot of the things we’ve been considering for SOA actually happen.

One of the interesting things we heard this morning from Dave Linthicum was that he's anticipating that, in as few as five years, the role of enterprise architect and the role of SOA architect will meld.

I thought that was a little ambitious, and I wonder if I could put that to our panel. Before we get into the future of SOA, we should actually determine when the future of SOA will be important.

Beth, what do you think about five years? Do you think we are going to see SOA actually become part and parcel of all enterprise architecture activities?

Beth Gold-Bernstein: Five years is definitely ambitious. All the polls that we’ve done at ebizQ have shown that the market is really in the early stages of adoption. From my point of view, the sooner the SOA architect’s role is rolled into enterprise architecture in terms of governance the better. It is a subpart. And it is, as Dave said, best practice in architecture. We’ve known that for a couple of decades, actually.

We are getting there. Standards have gotten in. But there is more to that than just architecture. It fundamentally changes the way we create applications. That means developers need to change the way they are architecting applications, and that’s very different. It's going to take quite a while until we build up the different levels of services.

Gardner: I’ve always thought that SOA was a journey, in which you never actually get to the destination. Todd, what do you think? Is this an ongoing journey, or is there a future point for SOA when we can determine, “We’ve made it; it’s working”?

Todd Biske: I definitely agree that it's a journey. One of the things that I have seen in my work as a consultant, and prior to that as a practicing enterprise architect in a major enterprise, is that you're always going to have these new initiatives come along that may start out from a point solution.

Just as was said this morning, if solves a small percentage of my problem, if you're only looking at a narrow scope, and you’ve got boundaries around it, you are not seeing the whole enterprise.

So, in enterprise architecture practice the enterprise is not going to go away. It will continue. It’s always a journey that we have to integrate, whether it’s SOA, BPM, or any of these efforts into those long-term initiatives that keep going on.

If the company goes away, well your SOA probably will go away with it or at least be folded into someone else's. But definitely it’s a journey that involves culture change, and that takes a long time.

Gardner: There's an interesting whitepaper being delivered at this event, and it’s part of this notion of "boundaryless information flow." It appears to me that we're all going to be creating new information on an ongoing basis throughout our organizations. So, the boundaries will always be created, and therefore will need to be torn down.

Let’s go to you, Tony. What do you think about this notion of "people" as an important element about the future of SOA?

Tony Baer: There’s no question about it. You and I have been bouncing off each other a new acronym -- and I’ll have to credit you on it -- human-oriented architecture (HOA). Those of you who have been looking at the headlines over the last few weeks, have seen that the usual suspects on Oasis -- IBM, SAP, Oracle and others -- have formally said, "We are going to submit a proposal to incorporate human workflow into BPEL" -- actually into SOA in general.

It’s a recognition on their part that very few processes are completely automated. That’s one side of the story. The other side is that, when you are looking at defining processes, you have to take a look at the context of people's roles, whether the process is automated or not. So, it goes both ways. You can’t have SOA without people, whether you call it human-oriented architecture or whatever.

Gardner: Alright, Eric, to you now. We might actually drop the words, "Services Oriented Architecture." We might still call it generally, "architecture," but it does seem as if this is always going to be a chicken-and-egg relationship.

As we get more kinds of processes, we're going to come up with different standards to try to tear down different walls around siloed platforms or information stores. If we don’t call it SOA in five years, what do you think we should call it?

Eric Knorr: Dave had it exactly right this morning. It’s something that will be subsumed within enterprise architecture, as a whole. It’s part of the ongoing saga of making IT more efficient.

If you listened to Dave’s keynote this morning, he also mentioned that out of the implementations that he had seen, 80 percent were in trouble. Adoption, on a broad level, is still relatively at an early stage right now.

So there is a certain danger right now in SOA in terms of the acronym and its impact on the industry. It maybe another one of these initiatives that looks like it’s going to be very successful. You go through the hype curve, and then it begins to fall away. When that happens, I think it will be absorbed into enterprise architecture. The basic principles won't go away.

Everybody is gravitating toward service orientation within the enterprise, and there are all sorts of reasons why that makes sense from management and architecture reasons, redundancy development, and other things. That will continue to go on, but as a trend, it may have a definite life span -- and that may be only a couple of more years.

Gardner: An interesting observation from the last presentation from Deutsche Bank was that the costs seemed to be going down, according to their forecast over the next several years, and that benefits are going up, at least in terms of one subset of SOA activities. That would lead us to believe that, at least from Deutsche Bank’s perspective, SOA is going to be an ongoing productivity benefit.

If we are able to create a more boundaryless enterprise, if we can get people to work more harmoniously with processes, and agility and change become de facto attributes of IT, then we really will be coming up with something different.

So, let’s look at that. Let’s assume that much of what we’ve heard today is prologue to the future, whether it’s five, seven, 10 years -- and whether we call it SOA or not is not so important.

How is this going to first affect the IT department? Then how is it going to affect the business? Then, take a step further and ask how this might change the characteristics of what we consider companies and how they relate to one another.

Let’s start with the IT department. Todd, you’ve worked in an IT department. If you had a boundaryless information flow, if you had agility, and you could have IT work at the pace of business, what do you think the impact would be on how IT departments actually behave?

Biske: It would be a dramatic shift from what we see today. As Beth pointed out, and other people have said, adopting SOA is a fundamental change in the way that IT operates. It’s a cultural change, and an example that I point to is the notion of a service provider.

During the Austin Energy presentation today, I asked, “A power company is a service provider. They are used to that concept. How does IT act as a service provider, whether they are doing internal services used by their colleagues on another application or are producing services that are being used by customers, business partners?"

We're used to building a solution, putting it into production, and going on to the next project. IT is a very project-based culture.

If you move to SOA, you have to shift more toward a product-based culture, where you have a life cycle that goes on over multiple versions and doesn’t end until you take that service out of production.

You have to deal with customer management, looking at the different scope -- one of consumers and how they utilize those services. How you leverage that information in building new services is where it may tie into your business intelligence (BI) efforts and technologies associated with that. This move from a project-based culture to a product-based culture will be the biggest shift.

If you want a good example, look at companies that practice product management, and at the things that they sell, and you will probably gain a good idea on how IT needs to operate.

Gardner: Beth, you’ve mentioned that you think there are a number of technologies that are going to be important in terms of how they relate to SOA activities. What’s your take on how this agility that we’re anticipating will affect the adoption of technology within IT departments?

Gold-Bernstein: There are related technologies on this. BI is one of them. It’s very important to get the business value out of the SOA infrastructure. BPM is another that is separate technology, but related to SOA.

Very directly it can be used to create the overall end-to-end process. While underlying services are delivering the functionality of the overall application, business process management (BPM) will give you visibility and monitoring.

Also, event-driven architecture (EDA) processing is a separate discipline, but an event-driven SOA delivers higher agility. It provides even predictability, and the technologies are coming forward.

So once you have the SOA infrastructure down, the discipline of creating very loosely coupled components, and layering on top of that BPM and event processing -- then you will be able to deliver to the business the value, the intelligence, the visibility, the monitoring, the predictability that will make the business more agile.

Gardner: Are you anticipating that, as SOA is adopted successfully, it acts as a catalyst, accelerant, or a multiplier to the adoption of other technologies that can then be brought to bear on business issues?

Gold-Bernstein: Absolutely.

Gardner: What’s your take on that, Eric? Are you as optimistic, or do you have any cynicism on that?

Knorr: I wouldn’t say I am cynical about that, but what Beth says does make sense. It’s interesting, too, to see what happens to applications like BI that right now have their own proprietary integration infrastructure in the enterprise.

That’s a big part of what the BI players offer. What’s left? Well, the analytics. As you see SOA methodology spreading through the organization and the ISVs, you'll begin to see a more component-oriented way of developing applications that will permeate the commercial software vendors.

That’s a very long-running project. SAP has been talking about that since 2000. Oracle seems to have jumped in a little bit further with the Fusion platform, while that remains to be seen in the way it plays out. But I do think it will penetrate those areas, and the event-driven angle is very important.

Gardner: Before we leave the implications for the business, we also need to step back and revisit what Dave Linthicum said this morning about other mega trends. He mentioned Software As a Service (SaaS). We have heard other blanks or X’s "as a service," whether it’s integration, platform, or infrastructure.

What do you think will be the impact on IT and the business, as SOA not only opens the floodgates to some of these other technologies, but also opens the floodgates to more ways of acquiring and consuming services outside the organization?

Tony?

Baer: In a way, that’s déjà vu all over again. I remember that during the bubble, when we were all having a lot of fun, we were talking just B2B exchanges. It was the idea of, “Well, you can find something.” It was like an eBay for the supply chain.

You can see how far that went, because it went against established practice in the supply chain. Twenty years of supply chain management theory was: Consolidate your partners, get to know them better, and don’t partner anonymously.

My sense is that what has to come of all this is not just a random coupling. Ten years ago we said all these components out there are not going to just couple randomly. There are going to be partnerships. We were starting to talk the other day about semantic integration, but behind every successful semantic integration is a successful human partnership.

Gardner: So part of a SOA success trajectory would be the ability to consume, as an enterprise, services in a marketplace, where such pressures or forces as competition and a drive for lower costs and higher benefits could play quite nicely.

Baer: And partnerships …

Gardner: And partnerships, so that you find areas where you might overlap with someone in your supply chain. And you must start handing off some of your services, and you might adopt some of theirs.

Baer: Or, perish the thought, start within your own enterprise -- if you can get beyond all the political roadblocks.

Gardner: There are political roadblocks inside of your departments and your companies. Imagine the political roadblocks you’d fight trying to partner with others companies entirely?

Baer: Exactly.

Gardner: So we do come back to this "people" and "what I learned in kindergarten"-mentality.

All right, so let’s not think SOA is all just peaches and cream. You mentioned this semantic issue, Tony.

If I've got a Tower of Babel inside my enterprise, or in a department, where different types of doing things or identifying them are scattered across whatever someone puts in an Excel spreadsheet, then we have this ongoing battle around how we identify that which we want to use, consume, or produce within services.

Todd, let’s get back to you. Let’s discuss what I believe is an inhibiting factor, which is this whole semantic issue. What do you see happening around standardization that is a counter force to that?

Biske: I don’t know that it’s so much standardization that’s the counter force. Certainly it is, but I look at the information integration problem, or master data management, enterprise, logical data model, whatever you want to call it. It's actually a good space to look at and say, “Okay, what do we need to fix to do SOA right?”

Groups trying to do a master data management (MDM) effort or come up with an enterprise canonical data model create this group that goes off on an island. They sit there, lock themselves away, and try to come up with this uber-model, but they miss making the connection back to the people that are working on the projects that actually need to use that information.

It's pointed out that it takes too long to get it done, or it's not meeting my needs. The same thing can happen with SOA if you’re trying to define services in the enterprise context. We don’t want this to happen.

In both of these cases, we need to figure out how to make this information relevant to the projects that need to execute properly and take those incremental steps to get us there.

Clearly, having a consistent semantic model is critical to the success of SOA. If we don’t get the consistency across our services, we wind up creating more work for the consumers. And as the previous presenter from Deutsche Bank said, it’s all about consumption. It’s not about producing. It's about creating services that are easy for our consumers to use.

Gardner: Beth, how do you think that some of the technologies that you mentioned earlier, intelligence and management of applications and services, can be brought to bear on the semantic issue? They seem somewhat divorced at this time.

Gold-Bernstein: Actually a different technology that’s being brought to bear is semantic integration technology. There are standards bodies. I know that the Open Group is working on some of that as well, and some vendors have put forth some semantic integration or enterprise information integration (EII) products.

Software AG came up with one. They have inference engines underneath them. I can remember being at the conference when IBM introduced SNA and told everyone, “You have to build your enterprise data dictionary.”

I worked with organizations that did that. They had the books on their shelves, but it didn’t do anything. They were just books on the shelves. The difference now is that we have the integration technology, and with these semantic integration technologies, we can build these taxonomies incrementally on a project-by-project basis, and then add to them over time, grow this in an organic way, and still be able to move forward that way.

I think that will be the successful way. Semantic integration is not receiving a lot of press. Software AG brought out a great product a year and a half ago or so, and is going nowhere with that so far. That is the future and a very important one, because a dirty little secret about integration, is that 80 percent of the budget is spent on semantic integration.

Gardner: Eric, in addition to the semantic issue internally, as we discussed, being more influenced from outside the organization, we already see popularity of things like mashups, RSS feeds, and content brought to bear on business processes.

Do you think that, as SOA matures and we look to the future, there needs to be a delineation between internal and external content, and who's going to be in role of managing that boundary?

Knorr: I'm not sure who's going to be in that role, but mashups have an immediate role now for SOA adoption. Basically, if you were able to wave the magic wand today and transform your entire application infrastructure to make it SOA-based, you wouldn’t see any difference.

So mashups are a great selling tool. They may not be strictly SOA, but if you got a couple of internal data sources, and maybe Google Maps on the outside, and you throw some Salesforce.com data on there too, you can begin to illustrate for upper management, what agility looks like. That’s one good thing about mashups.

I've been surprised in some of the panels that I have done, with the resistance you get, even to something like Salesforce.com, which is a fairly well-established application right now in the marketplace.

Gardner: It’s a business application right?

Knorr: Right. But, back to the mashups, I think a good way of looking at mashups from a practical perspective and how they fit into all this is that there is a lot of rogue application development going on there under the radar, that nobody in upper management really knows about.

So mashup platforms -- whether they are from BEA or IBM -- they have their first iterations of those types of platforms, or outside the firewall, where you are actually doing development on the outside. These provide a framework for the rogue application development.

Eventually this kind of stuff outside the firewall will be folded into the greater SOA somewhere down the line. In a way, that’s really what's most exciting about SOA, and most difference is the ability to begin to connect to those external services and bring them into the fold.

This goes back to the early days of web services. XML grew out of a desire to open up EDI, and there was this whole thread of web services that were all about B2B connection. Then came Microsoft, saying that one day the Internet will be the operating system, and we will build applications on top of it. Well, that’s interesting to see.

Gardner: I suppose another way of looking at this is that the pendulum keeps swinging across several major variables, one being distributed, and then consolidated. And we go back and forth. And another is complexity that gets solved, but then simply opens up another type of complexity that needs to be solved arrives.

And so if SOA is successful, it seems like we're dealing with a complexity of integration, but then that opens up the complexity of semantic issues, and people and behavioral issues, and then boundary and political and government issues.

So assuming that we can get boundarylessness on this sort of scale, and we have the pendulum going back and forth among these complexities, does the business recognize enough return on investment to say that SOA was worth it? And when will we reach that sort of an economic business rationale? Tony?

Baer: I hate to say this, but I just recalled what David Linthicum was saying this morning about the inherent tension between-project based SOA and the enterprise architects. We all seem to be talking past each other.

To satisfy your client in the business, you are going to show them that it’s deliverable. And the client is saying, "I am not paying for your enterprise architecture. I want a solution that helps me right now that’s a sure fit, an 100 percent fit. I do care if you make it 80 percent, and I have to pay the cost of generalizing it to the rest of the enterprise." So, there is an inherent tension there.

I like what Eric was saying about using mashups as a step forward. That’s what you were saying about semantic integration. We need to work this from the ground up instead of the grand enterprise data model.

We have to take an incremental approach, and don’t try a project to boil the ocean. Then, after you’ve done that, if you can somehow sell it to the business, there might be some internal budgeting mechanism or brownie points, where there can be some sort of internal trading system. And then maybe there is a way to subsidize that extra 20 percent of development.

Gardner: Now, wait. I thought that SOA was going to make agility the number-one requirement that we are going to meet in IT departments. Whether you're Deutsche Bank with a five- to seven-year window on recovering costs -- or a bit more of a common company that has to deal with quarterly returns, and are seemingly always under pressure to cut costs -- there's got to be a better business payback here.

Does anyone, as we discuss the future of SOA, have a sense of where the business people recognize that this is successful and we have made it? What sort of benchmarks would that require?

Knorr: I have a comment on that one. It all has to come back to the business strategy. There are a number of organizations out there that don’t have an enterprise architecture practice, yet, they're trying to do SOA.

As a result you have SOA applied to projects, and you are missing the point that’s on the strategic side of this. We've heard the term "boil the ocean."

We can go to the opposite extreme as well and say, “Okay, I am going to just redo all of IT. We're going to change all of the fundamentals behind this and do it all at once.” That’s not going to work, to completely do the opposite extreme in saying, "everything is ground up."

You need this middle-out approach, but it has to be driven by the business strategy. The way to determine "Have I been successful?" is, "Have I been successful in adopting my business strategy and meeting my business goals?" If I have, then I am doing the right things.

Every enterprise is going to vary in the extent to which IT contributes to those goals. For some organizations, IT may be a strategic asset. There may be lots of specializations that do what I would call a vertical domain that makes sense to them.

For another organization, IT may not be so much of a strategic asset, and they just use it for the standard, horizontal features of HR and business support services.

The best thing for them may be to go down an outsourcing route with a company, saying, “Okay, make sure you are able to keep up with what we need by adopting SOA on your end. But that’s really a part of you being a good business, not necessarily our being a good business.”

It all comes back to what the business is trying to do, and to try to understand how IT can contribute to that solution. If I don’t have any idea on how IT contributes, I am never going to be able to say I was successful or not.

Biske: I think we focused a lot on organizational resistance today, but that’s not to say that there isn’t a lot of success out there in the marketplace right now.

Where you see that success is in telecom and in financial services. Financial services, of course, because they have the money and they are always first, but also because you are talking about a relatively heterogeneous array of services that they can create, recombine and put together into different products. The market demands that they come up with a very broad variety of products that they can deliver to their customers. They are seeing that agility quicker than anybody else.

Gardner: A mega trend that's with us these days, but we didn’t bring up yet is globalization. Companies are competing in ways that they never had to before. So perhaps competition, the ability to compete and win markets and outflank your direct competitors and partners efficiently, and to do mergers and acquisitions well because your IT department can keep up with the business strategies -- perhaps these are the big payoffs from SOA.

Perhaps we'll we see companies effectively embrace what we’ve talked about today, make agility a de facto means through which IT performs at the pace of business. And then they become big companies, get bigger and better, take over more customers, deliver better services, partner across a larger ecology, become masters because they are at the forefront of their markets, and other players become slaves.

Or, am I being a little bit too loose? What do you think, Tony?

Baer: In this thing you were talking about -- globalization, M&A scenarios -- sometimes circumstances have a nice little way of concentrating the mind.

When you all of a sudden are faced with putting two organizations together, which happens pretty often in the business -- M&A is not exactly the exception these days. At some point you have to say, "Look, we need to take an architectural approach."

"Our tried and true methods have been tried and they are true, but they may not be valuable. We keep just going back on our traditional way, our traditional path of execution, and we're just going to develop ourselves into a brick wall."

Gardner: Eric, do you really think that if you are a successful SOA company, you are going to just drop the SOA and just say, “We’re a successful company?”

Knorr: A successful SOA company as what?

Gardner: As someone who executes well on what we have been discussing -- SOA. Does that really make you a successful company?

Knorr: Absolutely. It can contribute to it in terms of agility. There's no question about that. I can’t imagine somebody hanging out their shingle as an SOA company and having trouble getting over that one.

Gold-Bernstein: You asked when a company can say they are successful? In my view, every SOA project needs to contribute to the benefit of the business. It's not down the road five years. Everything you do needs to show benefit, and incrementally. There are different styles of SOA.

We talked about mashups. There is interactive SOA and event-driven SOA. So you are monitoring things and you are giving business intelligence. There is process-driven SOA, with which I'm optimizing my business processes or I'm using a horizontal business process and reusing what I already have.

So I may be building my architecture incrementally, based on different business problems. It's just the approach I'm taking to give more agility. All along the way, to be successful at all, you have to deliver business value for every single project. I don’t think you can wait at all.

Gardner: Okay, before we go to questions from the audience, Todd, for an IT department that can go to their business leadership and say, "You tell us what you want us to do and we will help you do it," versus one that says, "Get in line and wait, give us a list of requirements, and we will get back to you" -- which one is going to be around in five years?

Biske: I don’t know that either of those would be around in five years. We're talking internal IT. I don’t like the notion of a customer-supplier relationship.

It has to be a partnership. So it's not that IT comes to the business, or the business comes to IT. IT is part of the business. And they all sit down at the table together and have equal discussions on what's the right thing from a strategic point of view for that business.

If ever it's the case of just me going and saying, “Give me your requirements, and I will build what you need" ... that’s like saying, "Why don’t you go ahead and outsource me, because someone else can come in and ask you that same question and probably leverage economies of scale better than I can."

If it's the case of "it's pushing too far," you're not creating that shared understanding of the technologies involved to really enable the business to contribute. It has to go in both directions, you have to mutually understand -- IT has to understand the business better, as well as the business side has to understand technology better.

Gardner: Let's take some questions from the audience. This one is, “SOA can’t exist without governance, and there's been a lot of discussion about technical reference architectures. Where are the governance reference models? Are we there yet with governance? Do we have something we can point to and say, 'That’s the way you do it,' and if not, why not?”

Biske: I'll jump in on that one. Working for a consultant firm, obviously we come in and help with governance. It's interesting that we heard "technical reference architecture," and then "governance reference architecture." But I actually view the reference architecture as part of governance. I like to simplify governance to three simple things: people, policies, and process.

First, you have to have some level of authority to put policies in place. If no one recognizes any authority to establish policies, they're not going to be successful. So that should be enterprise architecture or something. Certainly, at an architectural level, you would expect reference architecture material to come from enterprise architecture as the authoritative source.

The reference architecture itself now is an expression of the policies associated with architecture. I have got something concrete. Later, you are using the style, saying, "must," "must not," "should," "should not," but that’s giving exclusive guidance, creating the policies that now the development projects have to follow.

Finally, you have to have process that goes along with that. So, as Beth pointed out, I don’t want to create a bunch of dictionaries that just sit on the shelf and gather dust. I have to have the process to figure out how I actually get people to follow these policies. It’s unlikely that you're going to be able take a strong-arm view, create your police force and just have your key checkpoints where the law is laid down.

Probably it's going to come back with a lot of resistance from your developers, unless your culture is already used to operating in that manner, which, I suspect, most companies are not.

You need to create transparency. You have to have involved with the establishment of the policies people who are also the ones that work with the projects on a day-to-day basis, so there's a feedback loop from the trenches, as well as guidance from above.

You need transparency into the activities that are going on as they occur, versus sitting back, waiting eight weeks to hit the architecture checkpoint, and when it's too costly to make changes, and say "Oh, you're not doing it according to the reference architecture."

You want to have that constant communication, transparency on both sides into the reference architecture development, as well as the development of the specific solution architectures, and everybody really works harmoniously. Its not going to happen overnight, but you always have to consider your consumers.

Gold-Bernstein: Can I add one thing, Todd? I agree. One other thing you need is management, because in SOA it’s dynamically binding. You don’t know whether the policies or the SOA’s are being delivered upon. You need real-time management and visibility, and automated management. So, if something is out of governance, it’s out of policy that is reported on, and you have procedures there to act upon it.

Those are becoming very important, and the thing is that people aren’t adopting them until they’re way down the road. In the beginning of SOA, you have to begin your governance, it has to develop alongside your architecture from the very beginning.

Gardner: So this is clearly another topic for another day: management and governance, do or don’t they come together?

Here is another question: "There are continuing references to semantic data. Two approaches to adding semantic information to data include Resource Description Framework (RDF) and Topic Maps. Any thoughts on RDF and Topic Maps?"

Baer: I think its too early, frankly. I mean, at this point it’s kind of "chicken and the egg." Very often, you’ll have vendor product come out, and then standards will then follow. I don’t mean to make this sound like this is vendor-driven, but in the area of semantic integration of services, there are a handful of products out there and maybe a handful of people actually working with this at this point. So, my sense is it’s too early to call.

Biske: RDF has one advantage right now in that, there are some close ties between that and REST, and certainly REST is continuing to gain in mindshare. I'd like to describe REST as more resource-orientated architecture than service-oriented architecture, but again that’s a debate for another podcast.

If you take this resource-oriented view, clearly RDF fits very nicely into that. But again, those technologies are still just coming out of the incubation stage. How to properly apply that in an enterprise context is still quite a ways off.

Gardner: And, as an indicator of the interest on this topic of semantics, another semantic question, "How far are organizations in their internal enterprise semantic model activities, and what is the extent of adoption?"

Beth, I think, you said it’s something on the order of 80-90 percent, and you had some percentage of activities devoted to semantic issues?

Gold-Bernstein: Oh, no! What I said was that’s the budget of an integration solving semantic issues, but they are doing it manually, re-solving that every time they hook something up. It’s a huge problem, but as far as solving it at a semantic level with semantic metadata and tools automatically doing it, we’re just not there.

Gardner: So your answer to the question of the extent of adoption is "relatively low."

Gold-Bernstein: Yes. It’s not even on the map.

Knorr: And it’s one of the oldest, ugliest problems within IT.

Gold-Bernstein: Absolutely.

Gardner: And we’ve heard that the data issues need to get worked out before many of the other benefits of SOA can be.

Biske: If you're going to have composite applications in the enterprise, and they're tapping into data stores that contradict each other, it’s not going to work.

Gardner: So get your data and semantic acts together.

Biske: Where we do see a little bit of effort happening, and it's wrong to necessarily call it semantics, is in increased adoption of vertical standards, a set of XML tags for a particular vertical domain.

Is that really semantics? Probably in the purest sense. Is it a step in the right direction? Yes.

If you're trying to say, “How do I represent my messages on my services in a way that’s consistent," you certainly can’t go wrong with starting with an industry-specific model. Is that the full way to leverage semantic technologies? No. You are a long way from that, but it's a step in the right direction.

Gardner: It seems to me that if you want to carve out a leadership position in your vertical, that you will take on the heavy lifting of semantics, and then extend it across your ecology.

Gold-Bernstein: But it doesn’t solve the problem for all of those packaged applications, home-grown applications, and everything else you are trying to reuse and integrate with. So, that’s the real semantic problem.

Gardner: Okay, last question, we’re out of time. "We talked about product-based versus project-based cultures. We have a plethora of products and enterprises, they have to continuously evaluate and determine the right fit. So, this is saying, 'We have a lot of product strategy activities, but if we productize services, won’t that result in a similar world of confusion?' And if we can’t even decide on what products to take to market and when, how can we decide which services are appropriate in order to allow us to then fight over which products to take to market?"

Biske: Let me make one quick answer to that, and let everybody else jump on me. By that logic, eBay should never have worked.

Gardner: Explain.

Biske: The whole idea of eBay and this marketplace of things that people are selling, they are selling probably new products. How are you going to make sense of it? How are you going to find it?

Somehow, eBay has put together mechanisms that are partially based on timeliness. There's some very good semantic integration and very good metadata management. Somehow, they put together what should otherwise, by conventionalism, be an impossible task.

In an enterprise, the process isn't easy, but the scope of the problem is going to be a little more containable than eBay.

Gardner: I hear another mega trend here, and that is social networks and the wisdom of crowds applied to services and products with governance, so that we have somewhat of a free-market approach that allows the wisdom to rise to the top?

Biske: I'd actually turn it around a little bit. The original question was part of the reason why we have all this problem in choosing products is that we didn’t have a product-based view to begin with. We didn’t have a capability-based view of, "These are the capabilities I need. Let’s go find the right thing to fit that." Instead we said, "Let’s go pick a product, and now look at what capabilities it gave us."

If you begin with this capability-driven view, now the products just naturally fit, whether they are internally developed, purchased externally. It creates the opportunity for more of a marketplace, leveraging all the conversations about it that the social networks may create for evaluating and selecting things appropriately, whether its internal or external.

I think we should have the same conversations about internal service providers and the quality of service they provide that we have with external providers.

Gardner: Well, we will have to leave it there. Thanks, you’ve been listening to BriefingsDirect SOA Insights Edition.

I want to thank our panel in a live presentation before the Open Group Architecture Practitioners Conference. We’ve had Eric Knorr, executive editor-at-large at InfoWorld; Tony Baer, principal at onStrategies; Todd Biske, principal architect at MomentumSI, and Beth Gold-Bernstein, vice president of ebizQ’s Learning Center.

I'm Dana Gardner, your host and moderator, principal analyst at Interarbor Solutions. Thanks very much for listening.

Listen to the podcast here. Produced as a courtesy of Interarbor Solutions: analysis, consulting and rich new-media content production.

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.

Transcript of Dana Gardner’s BriefingsDirect Podcast on The Future of SOA. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.