Saturday, August 11, 2007

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 23rd, 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.

Thursday, August 09, 2007

BriefingsDirect SOA Insights Analysts on Appliances, BPEL4People, and GPL v.3

Edited transcript of weekly BriefingsDirect[TM] SOA Insights Edition podcast, recorded June 29, 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 21, 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. We are joined this week on our panel by Tony Baer. He's a principal at OnStrategies. Welcome back, Tony.

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

Gardner: Great. Also Jim Kobielus, principal analyst at Current Analysis. Hey, Jim.

Jim Kobielus: Good morning, one and all.

Gardner: Brad Shimmin, also principal analyst at Current Analysis. Welcome back, Brad.

Brad Shimmin: Thanks for having me back, Dana.

Gardner: Also joining us, Todd Biske, an enterprise architect at Momentum SI, an Austin, Texas consultancy. Good to have you, Todd.

Todd Biske: Thanks, Dana. Glad to be here.

Gardner: And our guest this week, and it is the week of June 25, 2007, is Jim Ricotta. He is the vice president and general manager of appliances within IBM’s software group. Glad you could be with us, Jim.

Jim Ricotta: Glad to be here.

Gardner: Now, Jim, let’s get into a little bit of background on how you came to be at IBM. You were with DataPower, a Boston-based XML messaging appliance vendor until -- when was it -- about a year ago, maybe a little bit more?

Ricotta: That’s about right, Dana. We’ve been part of IBM for about 18 months. We were acquired toward the end of 2005. Before that, I was the CEO of DataPower for the previous three years starting in 2003. Prior to that, I ran the content networking division of Cisco Systems. So, I went from Layer 4 through Layer 7 of networking to this middleware appliance concept, and now I find myself on the other end of the fence in the world’s biggest middleware business, which is IBM.

Gardner: Could you explain what your purview is there under appliances? How wide is your role in terms of product and development?

Ricotta: IBM acquired DataPower for the current products, but really more for the potential. IBM sees a lot of potential to take appropriate functions, "appliance-ize" them, and deliver a lot more value to clients that way.

I know we're going to talk about this in the discussion, but the basic concept of an appliance is to allow customers to get their projects going more quickly, experience lower total cost of ownership (TCO), etc. My role is the general manager and VP of appliances, not just WebSphere DataPower SOA appliances. We have a broader remit and we are looking at a number of different appliance efforts for different parts of the IBM product set.

Gardner: Right. I wonder if you could also relate this to the SOA discussion. In general, SOA conceptually aligns with appliances rather well. It’s about individual parts that contribute to the larger iterative types of development and being able to manage the runtime more dynamically. How do appliances conceptually, in your mind, align with SOA?

Ricotta: One of the reasons that SOA has been a very fertile ground for appliances is the standards -- the idea of standards and the idea of a layered architectural approach. Thinking of my background, if you look at networking products, what really made routers and other types of networking such big horizontal businesses was that there were standards. The first routers were software products that ran on Unix Boxes.

But as you got standard protocols and the ISO stack took hold, it became possible to build a device that you didn’t have to program or patch. You just turned it on, configured it, it did its function, and that allowed that business to really grow.

SOA has its own version of an ISO stack with the WS-Standards and the layers from things like BPEL, all the way down to XML and the basics. That’s what enabled this approach of putting together a device that supports a bunch of these standards and can fit right into anybody’s SOA architecture, no matter what they are doing with SOA.

Gardner: Okay. Another topic, a subset of SOA, is the discussion around Enterprise Service Bus (ESB). Is the relationship between an appliance improvement for performance aligned with where you see ESBs in the market?

Ricotta: At IBM, we see ESB as a key part of any SOA architecture and deployment. If you do it properly, and we can talk later about what it means to do an appliance well, you tend to get a performance solution. You’ve done optimization. You’ve done a pruning back of all the potential functions.

So, the ones that you have, you tend to have good performance from, as well as the other benefits I pointed to, easy deployment and low TCO. So, given that ESB is the core of SOA, in many ways having an appliance alternative is important.

Gardner: Let’s go to Jim Kobielus. Jim, you were curious about the scope of appliances as a term, but also as a concept. Why don’t you take the questioning from here?

Kobielus: Okay. Thank you, Jim, and thank you, Dana. The notion of appliances in the industry has been expanded and stretched almost to the breaking point over the last few years.

I agree with Jim on what he's saying in terms of some of the core features of any so-called appliance -- quick deployment, low TCO, a basic function-limited component of some sort that is fairly easy to slot into your existing architecture and be deployed because it incorporates open standards and all that. But, the notion of an appliance comes out of the hardware world.

That’s no problem for IBM/DataPower, because from the get-go your appliances have been hardware based -- circuit boards and other devices that could be merged into racks and so forth. In recent years, the term "appliances" has been stretched to the point where now there is something called a "software appliance," or a concept of a software appliance, that many vendors are starting to tout in their products -- and not just individual vendors, but in collaborations.

In fact, just this very week, actually it was a couple of weeks ago, I ran across a couple of additional new mentions of software appliances or when Sybase and Red Hat announced that they're working together on a so-called software appliance that’s just a bundling and integration of two software products: Sybase’s database in business intelligence (BI) products and the Red Hat Linux operating system. Ingres about five months ago announced that it has a software appliance-product family called Icebreaker.

Some BI vendors, like JasperSoft, have been saying, “Hey, we're going to integrate our product with that so-called software appliance and voila! Here's something that you can install quickly at low TCO, etc.”

What I'm getting at is what they are now calling a software appliance is no different than what has been traditionally simply been called a solution, or simply a software package, that integrates two or more disparate components into a single component -- a single package with a single install.

I'm trying in my small way to beat the drum that the industry needs to scale the definition of an appliance back to its traditional scope. It’s a hardware-centric performance-built component, because, at some point, if everything is a software appliance, then the very term "appliance" is redundant.

Gardner: How about that, Jim? I guess you mentioned that appliances started with software and then became baked into a hardware lock-down, and now the term is expanding.

Ricotta: We've got to be careful, Dana. When I talked about routers, what I meant to say was that they were software products and then they became appliances. When they became appliances, they ceased to be software plus hardware. They were one thing. We see that in our industry all the time. It’s good to be at the beginning of a trend, but then, if your trend becomes too popular, everyone wants to jump on the bandwagon and the message can get diluted.

In fact, some of you who we talked to years ago when we were DataPower, might recall that, for a while, we stopped using "appliance." We started using the term "network device," because everyone saw what we were doing. Even though all they had was a Dell server with a CD with preinstalled Linux and their app, they would put a badge on the front say it’s an appliance.

I agree. You've got to be careful, because, again, there’s usually a performance value, although not always. Think about your TiVo or your iPod. That’s not a high performance-value proposition, but you always have to have a consumability value proposition and a low cost-of-ownership value proposition.

Our customers say, “Geez. We could do what your box does with software running on a server, but the operations folks tell us it would be two times or four times more expensive to maintain, because we have to patch all the different things that are on there. It’s not the same everywhere in the world in our infrastructure. Whereas with your box, we configure it; we load a firmware image, and it’s always the same wherever it exists.” Again, from my experience, that’s the way people treat routers.

So, our view is an appliance is three things that the customer buys at the same time: They buy hardware, software, and support, and it’s all together. That’s really what we think is the core value proposition. It’s cool to make a VMware image with your stuff that someone can easily deploy, but that’s something different. That's a solution, an application, a bundle, or something.

Kobielus: I think that the three core definitions of an appliance should be, "It is tangible." That’s something that you can actually throw against the wall if it screws up. Next, "Is it simple?" Now, Dana, "warehousing appliance" is not an appliance. It’s like saying that my Toyota Camry is an appliance. It’s the assemblage of many components, each of which can individually screw up. Then, thirdly, it should be pain free -- no setup and no administration or very little.

Gardner: Okay, so to understand, Jim Ricotta, you don’t consider a virtualized instance of something that’s bundled to be really an appliance?

Ricotta: No, we don’t. Again, you have to put that on a server somewhere and it doesn’t have the properties that an appliance has.

Gardner: You've got to be able to plug-in, swap-in, swap-out physically.

Ricotta: Yeah. I read a good article about the history of the networking business, and it talked about this transition I just described, where routing software moved into these boxes and then became very, very popular. This article noted that some of the early networking companies -- Cisco, Nortel, and others -- found that if you took software, locked it down, and put it in a box that had a fan and got warm, people had an affinity. IT people have an affinity for things that you plug-in, have a fan, get warm and do something useful.

Gardner: Todd Biske, as an enterprise architect, you probably concern yourself mostly with software. Do you think through on the level of an appliance or do you let the operations people worry about that?

Biske: No. Actually, I’ve got a lot of background in working with appliances. When I was an enterprise architect back at an enterprise, or actual Fortune company, we had this natural convergence that was always occurring between the group responsible for our middleware, or our software infrastructure, with the network engineering team. You can look at something like an HTTP proxy, and you’ve got Apache as a software-based solution, but then there is also a whole variety of appliances that can do the same thing.

So, there is always this natural tension of smart network devices versus some of the software products that were involved. The key thing for me that hasn’t been mentioned yet is that it does have to be more than just commodity hardware with some preconfigured software put on it.

Marketers for companies looking at leveraging either VMware machines and things that are preconfigured are looking for a term for this. "Appliance" does fit, because it gives you the right conceptual model.

A manager I worked for had the term "Dial-tone Infrastructure." You want to plug it in, pick it up, and it works. That’s the model that everybody is trying to get to with their solutions. But, when you're dealing with an appliance, you have to have that level of integration between the hardware and the software, so that you're getting the absolute best you can out of the underlying physical infrastructure that you have it on.

Any software-based approach that’s on a commodity hardware is not going to be optimized to the extent that it can be. You look at where you can leverage hardware appropriately and tune this thing to get every last ounce of performance out of it that you can.

Gardner: So, you like the notion of having some secret sauce in this, but you also like the notion of not having to create that secret sauce yourself?

Biske: Absolutely. You always have to look at where you want to leverage it. Another example where the technology could be applied would be in the use of blade servers. The biggest knock that I see from software guys on appliances is that it’s this gateway model. You’ve got to figure out the appropriate choke point at which to have it. If you adopt a blade server architecture, now you’ve got this backplane that's the perfect gateway for a lot of these hardware-based capabilities.

The ability to leverage some of these appliance technologies and hardware-optimized solutions in a blade center approach has a lot of potential as well. Then, you’ve naturally got that choke point, and you don’t have to figure out, "Well, because I’ve got datacenters all over the place, I really need hundreds of these appliances, rather than just two or three, because of how I’ve designed my middleware distribution."

Ricotta: That’s a great point, Todd. I'm not here to introduce products on this call, lest I run afoul of all of IBM’s attorneys, but we are looking at different form factors, like blades, as a good way to expand the appliance portfolio.

Gardner: Great. Thanks, Jim. Brad Shimmin, any thoughts in this subject?

Shimmin: Absolutely. When I look at this, I see two camps. You’ve got the hardware manufactures and then the software manufacturers in the SOA space, both seeing the benefits we’ve all been talking about thus far in terms of TCO, ease of use, and simplicity. Back to what Todd was saying, the key differentiator we’ve been talking about this far is the performance; the speed at which these things run, and their abilities based on that.

When you look historically at appliances like SSL accelerators, the reason they're not sitting on servers today is because servers can’t keep up with that wire speed you need. If I look at something like Layer 7 Technologies, they have their XML accelerators, and I see that as a perfect way to utilize a piece of hardware to run something that needs to go fast. I look at companies like Cape Clear and others in the ESB space, and I see them desperately trying to make their ESBs go as close to wire speed as possible, although we know they’ll never get there. I see them saying, “I wish I was running on an appliance.”

I see the two sides converging, but at the same time, I see there being something very valid about a piece of software that acts like an appliance. Layer 7, for example, released what they called a "virtual soft-appliance." If it quacks like a duck, and walks like a duck, it is a duck, right?

But the difference is, it’s just not going to go as fast as it was going to go on the Layer 7 device. If you and your enterprise are going to get all the advantages from a piece of software that you are going to get from a single piece of server hardware, you don’t need the performance from it. I don’t see that as being a problem and something we should try to shun.

Gardner: Let’s talk about the hardware for a moment. Jim Ricotta, the conventional thinking around appliances is commodity-level x86 hardware, perhaps a Linux kernel, but IBM has other hardware lines, and there is Power and this new Cell architecture. We're also getting into multi-core in a big way. For an appliance, perhaps the end user isn’t necessarily concerned with the hardware or even the kernel. Is there an opportunity for the secret sauce to extend across different types of hardware in the future?

Ricotta: The idea with an appliance is that the clients don’t care what’s inside. They care about the functions that the device does. The way we have architected our product, we do have lots of choices. We can pick the right processors and, even before we became part of IBM, we had used some ASICS to speed up certain parts of the XML processing pipeline.

Now, we are doing much more of that, we’ve got some new projects kicked off, because IBM has a lot of various state-of-the-art custom silicon and ASIC technology. So, yes, we will continue to leverage whatever hardware constructs give us the qualities we need, from performance, cost, and reliability, and we will continue to shield the IT users from that, because they don’t want to see it really.

Gardner: I know you can’t pre-announce it, and we don’t certainly expect that, but there seems to be some momentum building here for a cascade of announcements at some point -- the year of the IBM appliance if you will. Is that going to be in 2007 or 2008?

Ricotta: We'll be active in both. You'll hear from us, later this year, as well as next year.

Gardner: Okay. So, the "years" of IBM appliances. Let’s revert to the SOA discussion. Is there anyone on the panel who want to discuss why they think appliances dovetail conceptually and with SOA?

Kobielus: They dovetail, because the very concept of an appliance is something that’s loosely coupled. It’s a basic, discrete component of functionality that is loosely coupled from other components. You can swap it out independently from other components in your architecture, and independently scale it up or scale it out, as your traffic volume grows, and as your needs grow. So, once again, an appliance is a tangible service.

Shimmin: I see it similarly, in that an appliance can act as an enabler for other pieces of software in terms of providing that level of performance and scalability that those pieces can't do on their own. Such as we are seeing with ESBs and other areas. Those pieces of software need desperately some piece of hardware somewhere that can get them the information need in any timely manner.

Gardner: Do you think there is a parallel here between what we’ve seen on the World Wide Web in terms of content delivery networks and application management and acceleration -- what the enterprises are going to want to do internally, and not just enterprises, but also service providers, those who are going to be doing software-as-a-service (SaaS) and co-location activities, similar top what we’ve seen from Amazon and others.

I'll throw this back to Jim Ricotta. Is there a bit more than what we are discussing in terms of the role here?

Ricotta: We definitely see some parallels to what went on with the Web and CDNs. We have some discussions underway with network providers that have big corporate clients who are now launching their first B2B Web services, and they are basically utilizing SOA-type functions between organizations across Wide Area Networks. These carriers are looking at how to provide a value-added service, a value-added network to this growing volume of XML, SOA-type traffic. We see that as a trend in the next couple of years.

Gardner: Before we move on to our next subject, did anyone else want to address the general issue of appliances?

Baer: I have a very short observation, which is that history tends to go in cycles, and I imagine or recall similar discussions with the CAD/CAM vendors back in the 1980s with all their turnkey systems.

Gardner: Whoa! We're going way back.

Baer: Exactly. So, appliances are not new in this space. There’s always been a need to do optimized processing. We've just taken a detour during the era of open systems, but now we can start the approach again without the religious wars that we fought about 10 or 15 years ago.

Gardner: Great.

Ricotta: Let me make one comment also. I’ve heard a lot about performance in appliances, and I want to implore you all to think more, and maybe talk to someone like Todd, who has done the ROI, the evaluations, and all that kind of thing. It’s really much more. In fact, when I talked to our customers, it’s about TCO and then "time to solution" and "time to deployment." And, then performance.

Gardner: Jim Ricotta, do you have any metrics, a typical instance of a better ROI or reduction in total cost, compared to a distributed computing environment approach?

Ricotta: I can give you some data points that I collected. I’ve heard big global IT organizations, when they do their TCO calculation, say a router is $100 a month to support, a server is $500, and a DataPower SOA appliance is maybe $200 to $250. Those are the kind of ranges I hear.

Gardner: So, we are talking a potential 50 percent reduction in total cost?

Ricotta: Yes.

Gardner: Well, that does tend to get people’s attention.

Ricotta: Yes.

Biske: Something that hasn’t been brought up, and I think it’s something organizations have to consider, when they look at appliances versus software-based solutions, is the operational model. A lot of this space in the middle in SOA is all about what I would call a "configure-not-code" approach. Appliances, by definition, are something you configure, not something that you are going to be developing code for. So, it’s really tuned for an operational model, and not for a developer having to go in and tinker around with it.

A lot of the vendors claiming to produce software appliances are now trying to move closer to that. There’s still a big conceptual difference there and that’s really where a lot of the savings can come in the total cost of ownership. It isn’t how much work you have to go through it to actually make a change to the policies that are being enforced by this software appliance or device, and there are big differences between the products out there.

Gardner: So, you really like the idea of specifying, and that perhaps is another layer of efficiency in cost reduction when it comes to creating an architecture.

Biske: Absolutely, but the key to it all that Jim mentioned earlier on is standards. You don’t have much of a market for devices in the space, unless you’ve got the standards.

Gardner: You're back to an integration problem.

Biske: Exactly.

On BPEL4People and WS-Human Task ...

Gardner: Speaking of standards, let’s move on to our next topic. The BPEL4People specification came to fruition this week. Tony Baer, you wrote about it. Why don’t you tell us about this extension to BPEL, and a separate specification, WS-Human Task.

Baer: It’s interesting that they made both spec proposals separate. But, it’s not any type of surprise. IBM and SAP have been talking about this for about 18 months to two years, if I recall. What was a little interesting was that Oracle originally dissented from this, and now Oracle is part of that team.

Essentially what the hubbub is all about is that all the SOA folks have looked at BPEL and find something interesting. It does well with machine-to-machine, or at least with designed-for-automated processes to trigger other automated processes based on various conditions and scenarios, and do it dynamically. But, the one piece that was missing was most processes are not 100 percent automated. There’s going to be some human input somewhere. It was pointed out that this is a major shortcoming of the BPEL spec.

So, IBM, SAP, Oracle, BEA, Adobe and Active Endpoints have put together a proposal to patch this gap, and we’re going to submit it to OASIS. We’re going to do with two pieces. One we’re going to call this BPEL4People. We’re going to add a stopping point to say, "Put a human task here." That’s essentially BPEL4People. It’s a little more than that, but essentially boils down to that.

In terms of the actual description of the task, the semantics of the task, this could be a whole separate standard called WS-HumanTask. Where I tend to see the value in this is that invoking a human task as a service is not necessarily a call for relationship with orchestration. You don’t necessarily have to orchestrate in order to invoke a human task.

What makes this little more interesting than a normal spec announcement is that it’s pretty controversial. It draws a lot of heated opinion, as you don’t sit on the fence on something like this. The BPM folks, who tend not to be IT folks, but more process analysts, said, “Heck, BPEL has never been robust enough for our needs. It’s too simple. It’s too much of a lowest common denominator. It doesn't represent subtleties of complex processes.”

So, you have this “tug-of-war.” The announcement of BPEL4People and WS‑HumanTask has simply not settled this. It’s brought the issue back even louder again. It just makes life kind of interesting here.

Gardner: Now, let’s go to Todd Biske. In the real world that you live in, people and process coexist, and we'd like them to coexist better. Does this satisfy some of the needs that you observe in the market?

Biske: I think that we definitely need this. There's a constant tension with trying to take a business-process approach within IT when developing solutions. If you look at the products that are out there, you have one class of products that are typically called "workflow products" that deal with the human task management, and then you have these BPM Products or ESBs with orchestration in them that deal with the automated processes. Neither one, on their own, gives you the full view of the business process.

As a result, there’s always this awkward hand-off that has to occur between what the business user is defining as the business process and what IT has to turn around and actually cobble together as a solution around that. Finally getting to a point where we’re saying, "Okay, let’s come up with something that actually describes the true business process in the business definition of it," is really important. The challenge, though, is that it does potentially involve a fundamental change to the architecture of the solution.

It’s very different to develop a middleware product that can handle human workflow, because now you’ve got to have that state management. Previously, in an orchestration product, you didn't really have to worry about the state. The initial process gets kicked off, it automates that all the way through to the end, and you’re done. Then, you can release all of those resources for processing.

Now, you have to sit and go into this "wait" cycle for humans to do what they need to do, and you have to have a fundamentally different architecture for the solutions that provide that. It will be interesting to see when we actually see products that are claiming to support BPEL4People, what it changes to the landscape these vendors provide, and whether they have to take two products they previously had and combine them into one.

Gardner: I wonder, on one level, whether this is going to address something, but open up a potential can of worms around how things are done. It seems to me that this is a Pandora’s Box that we’ve attached to business process and now have opened up. But, potentially there are some benefits, particularly if you consider more interest these days in Web 2.0 or Enterprise 2.0 activities, where collaboration, social networking, and the “wisdom of crowds” is brought to bear on how businesses behave and how systems react.

Any response to that, Jim Kobielus or Brad Shimmin?

Kobielus: That’s right, Dana, because if you look at the whole notion of orchestration, it implies a rule-driven flow of context and control throughout a distributed process. It’s very much the machine assembly-line metaphor, but if you look at actual business processes, they’re very unstructured or semi‑structured and dynamically self-redefining. In other words, most real-world workflows are a coordination or collaboration process and not really amenable to strict rule definition or strict flow definitions upfront. Everything is very ad hoc.

I am not very sanguine about the prospects for BPEL4People to take off in terms of actual adoption in the real world, in real human driven workflows. It’s just messy for standards.

Gardner: So, you think there’s a need but you don’t think this is the band aid or approach?

Kobielus: There is a need for modeling tools that can help organizations to find roles, rules, and routes among human beings within workflows. I see the human workflow industry and the BPM market as being two distinct markets that don’t really benefit from a common standards framework. I am the jury that is still out on this whole issue.

Gardner: They remain orthogonal for you.

Kobielus: They definitely are orthogonal.

Gardner: Brad, how about you?

Shimmin: I'm glad we’re doing this, although I also feel it’s weird that we’re pushing it out as two different standards, one with a really sad name, and the fact that if it takes the same course that we took with BPEL, it’s going to take another two years at least for this to become truly actionable.

Gardner: You don’t think there will be a line outside of the store waiting for a BPEL4People.

Shimmin: No, the iPhone line was not to be confused with the BPEL4People line. This can be useful, if other standards come along for the ride, like BPMN. If we can pull those along together, then this is going to make a big difference for people. As Jim was saying, the idea of creating business processes that involves humans is nothing new, but it’s something that's very fleeting and hard to nail down. The folks who have been doing B2B integration for years have been looking at this problem and have been trying to solve it, because most of their tasks, like order-to-cash, has some sort of human aspect to it, no matter what.

Gardner: Do we need to put little chips in people’s heads to communicate by, say, Bluetooth to an appliance? Is that what’s needed? Jim Ricotta, what’s your take on this?

Ricotta: It does seem like you’re not going to be able to realize the vision of SOA, unless you can work in the human aspect. I haven’t spent a lot of time with things like BPEL and the top levels of the SOA stack, so I can’t really comment about how workable it is, but it seems like it certainly has to be addressed somehow.

Gardner: So, we seem in agreement about the need. Tony Baer, do you want to have the last word on this -- or Todd Biske? We have pessimism about this approach.

Baer: I'm not very sanguine about BPEL4People. The HumanTask probably has some potential interesting application, if you have a very simple task, a real commodity task that’s done often and you want to be able to reuse it.

The fact that it’s divorced from the BPEL4People stack, is probably a good thing, because there’s some use for this outside of that. I'm very leery about BPEL4People, and I think even the BPEL4People folks are not exactly sure of themselves either. The other thing I'll throw in, and I am not trying to imply any sort of ultimate solution, is that there are other approaches that are being attempted to solve the problem and to get around the bottleneck.

The analysts, the process folks, do take to modeling tools, because they provide a high-level picture of their processes. I don’t know what’s going to come of this, but you’re starting to see some efforts to make models executable. Now, it’s not going to boil the ocean or anything like that, but it’s an interesting approach and might have some niche uses.

Biske: Following up on Tony’s and Brad’s comments, from the enterprise perspective, I have much more interest in things like BPMN than I do in BPEL4People or even the original BPEL. Unlike some of the Web services specifications, when you are to hide a lot of that, developers had to deal with WSDL. There was no getting around it.

A business process developer doesn’t have to deal with BPEL. They’re dealing with some graphical interface that the BPM product has provided, and behind the scenes, that may be turned into BPEL. I may want it for portability, if I decide to change my business process engine, but the average developer shouldn’t even have to see that.

They do need to work on things like the modeling tools. So, the efforts around BPMN are much more important for enterprise developers. The BPEL space is probably of interest just to the vendors in the space, so they can promote some level of portability for these solutions across products. Or, if you’ve got a heterogeneous environment, can we make sure that we go across the environment. The average developer shouldn’t have to deal with it.

On iPhone Day and GPL v.3 Day ...

Gardner: Okay, thanks. Today, and people who listen to this or read it in the future weeks might not recognize the importance of the 29th of June, but it’s iPhone Day, and it’s also GPL Version 3 Day. Apparently at noon eastern, we’re going to hear about the long-awaited and somewhat controversial drop of the new GNU Public License Version 3.

I suppose one of the things that’s caught my attention about this is, since the Microsoft-Novell covenant on patent issues and protection for Novell users of SUSE Linux distribution through Novell, the people who were drafting this new version of the license decided that there was a loophole that needed closing.

Apparently, new terms were designed to prevent a repeat of the Microsoft patent covenant with Novell, and also to extend any patent protection across anyone using the similar products under GPL v3. It’s a little bit murky, this license, as it comes out. Apparently, some people will be moving to this by default, without even knowing it. There are other people who have already put in a statement saying that we’re still going to adhere to GPL v2, and, therefore, not going to version 3. I think it’s going to be a challenge for those using, deploying, and managing open source to sort that out.

We’re also addressing some possible issues around the Sun Microsystems’ OpenSolaris kernel and operating system, and there might be an opportunity for them to come together in such a way that you could get OpenSolaris under a GPL v3 license. Sun has as much as said that they’re interested, but hasn’t committed.

There’s also an interesting aspect of this in that the Apache software license is going to be closer, and that there’s more agreement, so that developers who have the ability, can merge these two code bases without running afoul of, or being in violation of, either license. So, some potentially large impacts by the arrival of this new GPL v3.

Let’s go around the table and see what the impressions are. Tony Baer, do you think this is a big deal or does is cast more confusion? And, do you think it’s really politics more than technology?

Baer: My sense is it’s going to cast more confusion. I mean even Linus Torvalds has come out against GPL v3, saying that it puts too much of a straightjacket. I just think it’s just adding yet another new variant. If there were 50 Open Source licenses, I am just picking that number arbitrarily, today there are now 51.

Gardner: Well, they say that three quarters of open-source code in use is under the GPL.

Baer: Right, but the thing is whether it’s under GPL or whether it’s under GPL3. I haven’t followed this real closely, I would presume that if you’ve licensed your code or you’re licensing code under GPL v2, that it's not automatically advanced to v3, but correct me if I am wrong.

Gardner: I think that is actually the case with some licenses that don’t state otherwise.

Baer: Okay, that would make sense. It’s going to create a lot of confusion, because obviously the Microsoft-Novell deal was very controversial. The idea that an open-source vendor would even concede that a non-open source vendor might have some intellectual property rights here, after the joke of the SCO lawsuit. Novell was trying to get a halo effect, saying, "Hey, we’ll protect all you SUSE Linux users," and instead it just incurred a lot of ire throughout the community which is saying, "You just admitted that we might have some transgressions here."

Gardner: Novell came back and said, “No, no, we didn’t mean to make such a statement,” right?

Baer: Then Microsoft said, “No, no, no, that was our statement.” So, I just don’t see this solving anything, I think it’s just adding a lot more turbulence to the waters.

Gardner: What we haven’t heard is the response from Microsoft as to whether they think that this license closes a loophole, and that those who now go and get these coupons or these vouchers for support, in doing so, extend this protection across any users. As you point out, the actual Linux kernel is apparently going to remain under version 2. As with an appliance, do we need to bolt a lawyer onto every software distribution? It seems like it’s getting a little bit more complicated, whereas the point of open source was to get away from that. Anybody want to respond?

Shimmin: The open-source community is playing right into the hands of those who are detractors of the open-source community with this GPL v3. So, I can understand why Linus Torvalds is against it, just from that perspective alone. Even if it closes a loophole, it doesn’t matter what it does, if it fractures an already shattered -- if I could say something bold -- landscape in terms of licensing.

The people or the companies I worry about mostly with this are the ISVs who are utilizing open-source software for their wares. Over the last five or six years, we’ve seen a huge upswing, and companies are making good money utilizing open source in their foundations. If you don’t have to build a J2EE Server, great. You can build something on top of that and make good money on it. But, now they’re going to be dissuaded a bit, and they’re going to have to look over their shoulder a lot more than they did in the past.

Gardner: Do you think the compatibility with the Apache license will make some things easier?

Shimmin: Well, go all the way to the MIT license, if you really want to take away any limitations and restrictions. You’re going to see a lot of vendors try to use software that is utilizing those more open licenses. If they can utilize something that’s going to not come back and bite them two years later, I would do it. Wouldn’t you?

Gardner: That’s the whole point, isn’t it, to try to alleviate future complications and gotchas, and have a straightforward focus on the software and not the legality issues? Todd Biske is a practitioner. I assume that you’re involved with using open-source code from time to time. Does this announcement and new version make your life easier or more complicated?

Biske: It’s probably going to make things more complicated. Again, I have been involved with enterprises where, as they figure out how they were going to leverage open source, they had to get the legal department involved. The more complexities that are introduced into that environment, the longer it’s going to take and the more painful it’s going to be for developers who want to leverage some of these solutions.

While we haven’t seen any significant legal activity around the use of open source, with the exception of IBM and SCO efforts and some of the other things out there, you haven’t really seen any end users gone after. Should we get to that point, enterprises are really going to be running in terror from anything open source. I hope that doesn’t happen, because that’s really against everything that the open-source community is trying to achieve. I tend to be pragmatic on these things, and any time I see someone that’s really taking an extreme position, it gives me concern.

Gardner: I guess the complexity is there, but virtually all companies in the software business have some relationship with open source now, whether they use it in their development, base their products on top of a platform that can use it, or is an open-source or partially open-source company. It seems like this is not something to reverse, but something we need to manage. I wonder if Tony has any thoughts on that -- or any of you?

Ricotta: One thing I've observed, being part of IBM and product development, is that we devote a lot of resources, time, engineers, lawyers, and other people being very, very certain that if any open-source is used, we know about its origin and we can clear the legal hurdles. What this means is we’re going to have to spend even more resources doing that. I don’t know if there’s a solution in sight, but that’s our view of it.

Gardner: So, this might require a little bit more due diligence, and perhaps there are some caveats in the license that will make things easier for some folks and more difficult for others. But, in the final analysis, if open source still has compelling business and technical value that overrides this now additional delta of complexity, it’s probably business as usual.

Ricotta: Yeah, and companies, ISVs, or commercial producers of software will still utilize open source, but it’s going to be more work to do it, more expensive, and the clients, the enterprise architects and others who select the vendors, are going to have to ask more tough questions.

Gardner: So, the lawyers end up winning.

Ricotta: I don’t know about that, but it ends up raising the cost of development of software. That’s for sure.

Gardner: Well, if we have no other thoughts on the GPL v3, I think we can wrap up our show. I want to thank our panel.

We’ve been joined by Tony Baer, principal at onStrategies. Thanks, Tony.

Baer: Thanks, Dana.

Gardner: Jim Kobielus, principal analyst at Current Analysis. Great to have you with us, Jim.

Kobielus: It’s been a pleasure.

Gardner: Brad Shimmin, also principal analyst at Current Analysis.

Shimmin: Thanks, Dana.

Gardner: Todd Biske, enterprise architect at Momentum SI. Thanks again, Todd.

Biske: Thanks, Dana. Good luck with your iPhone.

Gardner: I'm going to wait a little while on that. Also, a special thank you to our guest, Jim Ricotta, vice president and general manager of appliances at IBM Software Group. Thanks for coming, Jim.

Ricotta: Thank you for asking me, and a very good discussion. Glad to be part of it.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You’ve been listening to BriefingsDirect SOA Insights Edition Vol. 21. Come back and listen again next week.

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