Transcript of Webinar on SOA Trends with Analyst Dana Gardner and Cape Clear CEO Annrai O'Toole

Edited transcript of SOA trends webinar recorded Nov. 15, 2006.

Listen to a podcast of the webinar here. Sponsor: Cape Clear Software, Inc.

Welcome to a special BriefingsDirect presentation, a podcast created from a recent webinar with Interarbor Solutions Principal Analyst Dana Gardner and Cape Clear Software CEO Annrai O'Toole. This sponsored webinar presents a Services Oriented Architecture (SOA) market perspective by Dana, followed by comments by Annrai, and some questions from the live webinar audience. Today’s topic is how the value provided by SOA may be the best way to demonstrate the business value of SOA investments. Now, let’s listen to the analyst’s perspective.

Dana Gardner: Hello, we’re going to work through a state-of-the-market analysis on SOA at a very important juncture in SOA's evolution. An incredibly important issue right now is whether we are going to win broad acceptance and deep penetration, or whether SOA remains somewhat marginal.

There are a number of things going on in the market that we will look over. Trends and developments in information technology (IT) such as market acceptance and tipping points -- and a sort of social-animal instinct and on how people behave -- become very important. It is no longer just about the technology; it's about what motivates people, particularly in their businesses.

So, let’s take a level-set in changing times. These are very dynamic times. There are so many things going on in addition to SOA that we can’t look at SOA alone; we have to look at it in the context of what’s going on in general with IT and business. Over the last two to four years, we have seen SOA develop as a vision, spawned off the work done with Web services, progeny of object orientation and components, bringing it into a standard environment and, hopefully, into much broader usage across IT -- not just in development but in how people conceive of IT; a transformative type of activity.

We have gone through SOA standards. We have seen companies come up with methodologies, and have had examples of successful, and not so successful, implementations of SOA in the marketplace. Most, if not all, of the large vendors are solidly behind SOA. We’ve seen them use the terminology. Some are talking more about the business results than the SOA nomenclature itself. It is clear from IBM to SAP, to Oracle and Sun, that their products and services are based on SOA principles. We expect that will then follow through into the marketplace. We are also seeing quite a bit of development from the large global systems integrators around SOA practices.

Question for SOA is when, not if

It has been my analysis for several years that this is an extremely big deal, but what has been missing is the agreement generally in the marketplace as to not if, but when, to do this. We have also had a lot of activity in the marketplace around startups merging and rearranging their businesses. If they did not start focused on SOA, they seem to be heading in that direction. And that has led to a period of consolidation. We have seen mergers and acquisitions, partnerships, and ecology developments.

We’ve seen the notion of SOA, and it includes governance, bleed over into how IT actually functions -- and not just how development and deployment strategies are defined. We are really up against the tipping point here. The crucial issue for SOA is how that tipping point manifests itself.

The real force behind SOA is a transformative activity, both for the technologists in the IT department as well as for how IT is conceived, perceived, and used by the businesses. This has been an ongoing issue for many years, if not decades. At this point we have quite a bit of buy-in around SOA from the technologists. What we see mainly, however, is SOA use behind firewalls and within fairly vertical applications, within a defined business process activity.

What's more, many services today are data-centric. My studies show about two-thirds of current in-production SOA services have been data-service layer or data-centric services, and so perhaps as few as one third are being devoted to business logic and transactional activities. This, of course, will vary from company to company, in vertical industry to vertical industry, but the trend is showing a predominance of interest in making data available as a service. That service is then consumed and used in non-SOA activities and in more traditional integration portal Web applications, and Web or thin-client presentation applications.

How will SaaS and SOA emerge together?

So, SOA remains somewhat tactical even at most mainstream enterprises. There is also an important trend line around software as a service (SaaS) providers as they build their applications to be consumed and used as services. They might have a deep impact on how SOA is consumed -- almost on an outsourced basis rather than a homegrown basis -- and we are going to be tracking that carefully.

An inhibitor to the business side of the house in enterprises adopting SOA broadly is a lack of discretionary spending in IT for SOA types of investments. There is a lot of confusion around SOA and its values, and what business terms and issues are the motivators. Therefore SOA remains difficult to define and rationalize in purely economic terms. There are a lot of reasons for that.

The market is going to work toward a better understanding of the rationale behind businesses as they seek investments in this disruptive technology. We will move from monolithic silos of development and deployment infrastructure and sort of break that apart. Then after the decomposition process we can extend and reuse and redeploy -- hopefully with a great deal more efficiency -- these resources as granular components or services.

Follow the money

Though the concept is quite strong, the benefits in terms of numbers and metrics can be rather soft. We could tell people they are going to be more agile, be able to change in the marketplace more quickly, and be able to consolidate and use more singular architectures. Yet these are not numbers you can bring in on a quarterly basis and say, “Here’s what SOA has done for us this quarter in terms of dollars and cents.” Financial rewards are part of a long-term transformative process as well; something we expect will take years, if not decades, to fully play out.

SOA is really a journey without a destination and, as such, it is harder to quantify and qualify in terms of payback. If there is no destination, when does one know one has succeeded? This also affects cross-organizational use and deployment. There is a traditional chicken-and-egg relationship on whether developers move first, or the SaaS operators, or the people who deploy them on-premises, and that’s currently being played out.

For the true payback of SOA to come about, be it in soft terms or hard terms, it does require a horizontal, holistic, and general usage. Politics are also involved here. We have people that have been quite content to remain within a small, isolated arena with their own budget to control, working for several well-known and established taskmasters.

SOA, in a sense, disrupts that. There is no central taskmaster with SOA (and that's why governance is so important). The idea is for more and more folks to have a handle on these services, and then use them in new and innovative ways -- closer to the line of business, closer to the business processes, and extending beyond the confines of the enterprise into a supply chain, for example. So there is naturally some control politics.

Also budgeting issues play a role, which often means control from the top down rather than the bottom up because it is the central command-and-control folks that effectively change budget structure and allocate funds. So that is in process now as well.

There is also the need for collaboration across these groups. Not only do we want to change how budgets might be formed, we want to encourage people to work in a simultaneous fashion rather than in a linear fashion. So the hand-off of an application project really can’t happen over a period of six months to 12 months anymore; it needs to happen simultaneously with development. The whole idea here is to go to the business side of the house and tell them we can work quickly and change the process for you, as you have to adapt to a rapidly changing marketplace.

Make the business case for SOA

Gaining market acceptance for SOA requires a compelling business and economic case, something that we haven’t seen, at least not in a cohesive matter. There isn’t a central SOA defining body; there isn’t a central mouthpiece for SOA or SOA activities. It is been happening on an ad hoc, willy-nilly basis from a number of large and small vendors, as well as integrators and professional service providers. It is happening almost as if we were in a social network, and perhaps we are. This is a global SOA social network effect that we are seeing. It is happening at a time when we can’t just focus on SOA, however.

We need to look at all of the other trends, changes, and, frankly, complexity that CIOs, decision makers, enterprises, and telecommunication carriers are facing. If we look at a laundry list of what is going on right now we are not only looking at SOA issues, but also Web 2.0 (and this new concept of Enterprise 2.0), event driven architecture, complex event processing, SaaS, grid-utility computing, application virtualization, open source software and its impact, business process management, and on and on. People are dealing with convergence issues and mobility issues cutting across different types of devices. We are talking about "fabrics" for interconnected networks.

IT trends are also in flux. These are not just technology issues, but affect how IT is consumed such as through "shared services," where IT departments function more as a business customer within an enterprise. They behave based on market forces internally and the need to fulfill service level agreements locally. A very hot area now is IT governance from regulatory impetus to general organizational business practices, where IT departments are maturing and behaving as would an accounting department or an external field organization.

We are looking at application modernization, with people rationalizing which applications should remain and which should go as part of a datacenter consolidation trend. There is infrastructure virtualization, where we can cut costs on hardware and find new benefits around platforms, and instances of runtime, where we can deploy applications in new and interesting ways.

There is also business continuity to consider. We have natural and man-made disasters and disruptions that need to be addressed and, therefore, redundancy plays an important part, and data centers that are strategically placed outside of places that are perhaps at risk. Furthermore, there are regulatory compliance and intellectual property issues involving what code can be used in which ways. This is all part of a barrage of issues that are affecting CIOs and decision makers simultaneously.

More ROI for SOA

Yet, despite the complexities, despite these numerous trends and changes in the market, aggregate spending growth for IT remains fairly confined. We see large single-digit numbers in many organizations. Even within that confined growth trend we still see 60 percent to 80 percent of the total IT cost going to just maintaining and keeping current infrastructure and applications running, which does not leave much for discretionary SOA spending.

As I mentioned earlier, not many individuals are jumping up and down and singing the SOA song in a mutual chorus. Microsoft, for example, has remained somewhat distant from using SOA as a phrase, although many of the business benefits they project for their infrastructure and applications (particularly the newer ones) do align with SOA methods and business benefits.

We need to energize folks to invest in SOA now. I have addressed this issue by looking at the many-faceted benefits of SOA, both as an opportunity and as an area of fear. There is an opportunity to beat your competition if you can embrace SOA and use some of these other large technical and organizational changes to your benefit; to make IT a weapon you can use to do better than your opponent and, therefore, get better traction in the marketplace.

There is also the fear that your competitor might do that to you. There is an opportunity to exploit new avenues for change by obtaining applications or modernizing applications including SaaS. If your opponent in the marketplace (or the person who might get to the marketplace first) is using SaaS, their costs are lower and their agility might be higher. So, there is a fear of that as well.

This is also a great opportunity to exploit these convergence issues, reach mobile workers, and better deliver data and application and logic to the end users across the organization. SOA benefits also work both internally and externally. They allow you to be an architected organization where the focus is on what you need to do in a market to gain new business and to know where the new business is expected to be in six months; to be an early mover, not a trailing-adopter.

Architecture for competitiveness and risk reduction

SOA architecture is absolutely essential to become a first-mover and to focus strategically on architecture over applications to win business. The relationship between the application and the architecture is something we must focus on.

It is not just the fear and opportunity, but general and broad risk reduction that should energize people about SOA. SOA can empower businesses to reduce their risk of losing value from past IT investments. SOA allows you to continue to reap rewards from your past IT investments; to not necessarily sunset applications, but find new value in them. You can mitigate your risk against not competing with newer companies that don't need to support a costly legacy because you can bring in greenfield and modern application architectures as well. SOA allows you to play with both legacy and new greenfield approaches.

There is also risk reduction and mitigation against the unforeseeable future; against new architectural benefits, IT benefits, or trends that might be here in two-to-three years. SOA has a risk-reduction benefit because it is defensive, it is offensive, it is inclusive, and it works across organizational boundaries.

There is also risk-reduction around data and application logic, and the use of data in applications in new formats. There is reduced risk in the ability to absorb and manage merger and acquisitions, expected or not. I’ve spoken with folks at venders like Oracle that say they probably couldn’t have done the J.D. Edwards and the PeopleSoft activities without Web services and, increasingly, without SOA. If they can do it to move fast and successfully in their markets, their customers need to think the same way.

They need visibility across an entire process chain to reduce risk in terms of actually controlling what is going on within IT. One of the things that we are discussing with IT governance and enterprise service buses (ESBs), and some of the standards and methodologies used, is an ability to gain a holistic total view into a process -- not just a set of technologies; not just a particular server farm or a particular layer within a distributed architecture but across a business process.

"How am I actually doing?" This is a very important element for businesses on a regulatory compliance basis for Sarbanes-Oxley, for example, but also for companies to be fleet. If you don’t know what you are doing or how things are going, you cannot react appropriately.

So, in summary, SOA is really a means, an ongoing journey. It has soft advantages, but I think it has great benefits in terms of risk reduction and of meeting opportunity rather than fearing opportunity. It is a defensive and offensive weapon, both inside and outside of the firewall, and it bridges the past and the future while encouraging organizational transformation -- not just IT transformation but business transformation.

SOA promotes total excellence over subset excellence and fosters change management as a core competency. It also allows for constant process refinement; things do not get locked in and then set into a monolithic and static hierarchy, they are constantly being changed and improved. The ultimate goal is to be able to attain many of these things with overall reduced cost of capital and in the cost of ongoing maintenance and support.

That is the end of my presentation on the state of SOA. It is important now to energize and find ways to make the business case for this because the managers, over time, will play out for those that are early movers. Thank you.

Cape Clear CEO comments

Annrai O'Toole: Thanks very much, Dana. I am going to pick up where Dana left off. Dana has pointed out a few of the topics here, and there are a few things that I would like to add to the mix.

Before we jump in to this, I would just like to stand back and think about SOA in a very broad sense. I have been writing a blog article about this topic as well. It is fair to compare SOA to things that we have seen in the past like client-server and the Internet because they are very similar. Those were terms that the industry applied to a big change. The Internet was very easy for people to understand, because it is very visual and people could get on to a browser and move around.

So, the Internet did not need a whole lot of selling. Client-server needed quite a bit. However, there were a lot of clear business benefits to client-server in particular because it came from a mainframe-dominated world of computing. Client-server essentially offered people a much cheaper hardware infrastructure, and a much cheaper way to get far more powerful applications onto people’s desktops. So it was pretty easy; business users could use those applications to see what it was all about and they received client-server at a high level.

SOA is very similar to client-server. SOA is essentially a set of technologies and a methodology and a philosophy about how we build enterprise applications. SOA is never going to have much meaning for the average consumer in the streets, but it does have a lot of meaning for large enterprises. We are here today to discuss what SOA means to business users and enterprises. As Dana outlined, it is a kind of struggle because we can approach a business user and say, “SOA gives you more agile applications.” They ask, “What precisely does more agile applications mean?”

The term in itself is vague and building any metrics around this is tough. The business users get the notion that they want the applications to change more easily, but it is very difficult to quantify that. If we asked business users and a focus group what they meant by "agile applications," I think we would get many different answers. If you read in the blogosphere about SOA, you read only the articles. Once people get beyond agile applications, they are into reducing integration in half and that is nice. It is definitely very quantifiable.

More meat for the business users

In particular, as Dana exemplified so well, you know there are so many things that IT is grappling with today. I am not going to repeat what Dana spoke about, but the business user and the context of reducing integration costs is important. I don’t think that there are many business users who jump out of bed in the morning and say, “How am I going to reduce IT integration costs?” So I think these are the two main planks about how we justify SOA to a business user today, and I think we are all being pretty candid here, but these are not great.

We need to do a better job on this. If you start reading all the stuff in the blogosphere about SOA, it is really techies talking to techies; it is all about how you adopt SOA and the architectural approaches to adopting SOA. At Cape Clear a lot of our content is focused on IT guys, which is correct, but we in the industry have the onus on us to do a better job of explaining this to business users.

So the bad news is that I do not have a magic answer to this, and the good news is that I have a few things to say that I think are interesting. There are a number of very powerful things that SOA is doing today, and we are involved in some of them. For instance, there is increasing use of software as a service (SaaS). A long-running problem that many business users have had is that they all want greater business applications that give them better insight into their business but they do not want to spend three or four years doing large enterprise resource planning (ERP) implementations.

So SaaS for a lot of cost reasons and efficiencies -- and in use adoption -- is doing really well. There is a new Salesforce.com-breed that has done extremely well there. Just last week we announced our partnership with Workday. They have a whole new take on ERP applications based on the hosted model. They are embedding our software, along with other companies. So there is a whole range of SaaS applications that are turning to SOA to provide the kind of back-end integrations between the SaaS and existing applications that customers already have. SOA is already playing a very important part in pairing the next generation of business applications. And I think many business users understand that.

This next line is not something that I think business users understand yet, but it is incredibly important. A lot of techies know this stuff, but as you begin and you look at what SOA is doing -- it is really blurring the line between the underlying middleware infrastructure and the sets of business applications. The clearest example of this is Oracle Fusion. Oracle is spending a ton of money in increasing the Fusion middleware line and they are not doing it because they want to find new middleware; not really.

Middleware and applications blur

Oracle Fusion is an application strategy, and the only way that Oracle is able to deliver a unified set of applications from all the things they have acquired is by integrating them together around Oracle Fusion. Oracle is very clear about this. If you read all the documentation or the messages that they are sending, Oracle Fusion is an application strategy. That is very important, because the infrastructure (the middleware stuff that we have all been involved with for years and years) is really getting more and more powerful. And so that’s really making this infrastructure into things that people can really build, can easily build applications, on top of.

Dana certainly picked up on this. I think that when you distill all this, what really stands out is that SOA is increasingly about liberating the business process because today many business processes are hard-coated in cement inside big-tent applications like SAP. We have a couple of ex-PeopleSoft people working with us at Cape Clear, and they tell a great story about how they used to do sales pitches against SAP. They went to the customer with a small cup of quick-drying cement and poured it into a mold. By the time they finished the presentation, the cement is set and it has SAP written on it.

They then say, “There you go, that’s the deal with SAP.” It is easy to design, but once you get your business process done, it is embedded in cement. For lots of businesses all over the world, the business process is very difficult to change because the idea is so hard to change. SOA is all about how to use that application in new and more transparent ways that are easier to change and that deliver agility.

I recently had a conversation with a Gartner analyst about how they describe the whole SOA space and the ESB space. They were saying that there were some conversations going on inside Gartner about the fact that they might change the definition for this and bolt the stuff into business processes management (BPM).

At first she recoiled against that saying, but the more you think about SOA, the more you realize that it is just about helping people understand, and making those business processes more transparent and more open to change. We here at Cape Clear see this forcefully with our customers. Just yesterday we announced a business activity monitoring (BAM) solution with the Cape Clear ESB. We are doing this because when people get an ESB installed, it gives them a perfect opportunity for the ESB to power a BAM for the dashboards, so they can understand what is going on in the business process.

We have a great story from one of our customers about repairing an online website. With the BAM solution in, we are looking at the site and we noticed there was a set of faults building up on the credit card validation side. This was tough to track down because of the very obscure problem. The BAM insight showed how the process had been written and, because of that, we were able to point out that they were losing a large number of visitors who were stopped at a certain point because the credit card validation was jamming up.

SOA as new business applications

This example validates having the ability to expose business processes and tell people what is going wrong and how to fix it. If you can show where things are going wrong and how they can increase the top line revenue, it is very easy to sell SOA. Every businessperson can relate to that. So, I just started to pull this together and join some dots here. You come to the conclusion that SOA is a new business application.

I am borrowing from those that have gone before me. The great Scott McNealy line at Sun was that the "Network is the Computer." He was saying that for years. That was a model for the longest time. When he was saying that, they were delivering things like RPC and NFS, and it made sense in those terms. When the Internet arrived it made huge sense and everybody agreed that the network is the computer.

Now, if you join the dots between a new world of easy-to-use host applications then making business processes transparent and being able to see what is going on in real-time in your business is essential. When you start to join the dots between those and other things that SOA is enabling, it starts to give real meaning to this notion that SOA is indeed the new business application. It is not about Web services and WSDL and BPEL, which is for technologists, but the business people need over time to see where they’re going to build applications, and it is around SOA.

As you start to frame it in those terms, we can come up with a language that explains what SOA is all about to business users and we absolutely need to do that. I’m writing this up in a blog article and will hopefully get it posted soon. If you want to join in the conversation and add your two-cents to what you have heard today, we certainly welcome you to do so.

So with that, I’m going to hand it back to the moderator and I am going to take some questions. Thanks very much.

Questions from the audience

Moderator: Thanks, Annrai. Okay, our first question reads, Annrai, you mentioned BAM as an example of an application-level benefit of SOA. What other business application-level benefits may be coming?

O'Toole: That is a good question. First, let me talk about just specifically in relation to how we at Cape Clear think about it, and then maybe more generically. So, one of the topics that’s gained a lot of attraction recently is this whole notion of SOA governance, whatever that means. It is a great term. If you dig into it and if you look at a lot of what the products today are offering in terms of SOA governance, it is about IT governance.

It is essentially a workflow system for IT, to make sure we’ve done the correct designs, to make sure we are going through the right development steps, to make sure we are following the right checklist in terms of deploying things and so on. So, it is a workflow to make sure that IT is doing the right thing.

That’s interesting, but it is not much use for business users. Business users, when they think about SOA governance, they want to have some notion that they can understand the set of services and what they’re doing, and just get more transparency into what IT is actually doing. To that end, we at Cape Clear, we’ve talked a bit about this notion of a SOA wiki. I mean a wiki is a fantastic way of communicating information in a semi-structured way.

A lot of the information that business users want about services is pretty semi-structured; they want to understand what services we are running today, they want to see high level pictures of them, and they want to comment on them and say, “It’ll be really great if you could do this rather than the other ...” They want an easy way to do that. They want to see nice pictures, maybe of business flow diagrams that go behind them. In fact, we see the SOA wiki in Cape Clear terms as a metaphor for how you deliver the next-generation of business tools.

The state of the art today in terms of business-level tools around IT are things like the Rational software from IBM. It is a very good set of tools, but if you look at what they do, they give you things like the Rational Unified Process, which is the UML system. That is not really of use to a business user. I’ll pay anybody handsome money if they can show me a business user that can make sense for a UML diagram.

So, I think there is a big need to take what we’ve done today in SOA and really start to build out the next generation of tools that are in the wiki mode to help business users see the set of services, and business processes, understand the set of policies that are being enforced by the IT organization, and be able to interact with those in a manageable way.

All this information flows into a repository, and can then be pulled out and IT guys can work on it then. But I see SOA going in that direction, and from that moving to the next-generation of business process modeling tools, and so on. There is a long way for the full plate of things, that both Cape Clear and the industry in general, is going to address around giving better business tools to business users.

How to get started with SOA

Moderator: Okay, thanks. I think both of you can comment on this next question. Dana, you can comment first and then Annrai. How does a company with a significant number of legacy applications get started with SOA?

Gardner: Well, the gist or the crux of the issue is where to start on this process. We have seen a preponderance of services around data and I think it is important for people to look at the data within those legacy applications and to liberate it so that it can be applied more broadly to processes, to offer visibility, and give metrics and knowledge about the business -- but outside of the strict confines of the applications and legacy applications.

So one of the first and perhaps best business pay-off activities you can do is to look at the data -- elevate it, cleanse it, and make it available as a service. This is probably something people have been doing within a fairly rigid set of database technologies. A good place to start is to take that data and abstract it to a services level or a layer where the metadata is more important in a process or holistic sense rather than the formats and originating repository.

Once you have liberated the data, you can start looking at liberating logic, exposing more of the applications as components or services, or at least integrating them beyond just a point-to-point basis; liberating them to integrate at a higher abstraction. So, you look at the data, you look at the logic, and it is also a great opportunity to start rationalizing which of those legacy applications are worth maintaining.

You might want to sunset some applications once you have the data out, or once you have taken out some of the logic in the COBOL or whatever code is there. You probably don’t have much documentation and the people who wrote it are long gone. It might make economic sense to retire some of it. If you’re not going to retire it, you might think about what platform makes more sense over a period of time. For example, should I move it to a Linux on Intel or x86 architecture? Should I think about decomposing them into either Web applications or client-server application services? So, look at the topology and what makes sense.

I would have the legacy rationalization process include movement toward SOA along with your movement of what to sunset, what to modernize, what to consolidate, and unify under the newer architectures. By doing that, you are protecting yourself against the risk of spending money needlessly on outdated things that are not contributing to your bottom or top lines -- and at the same time reducing your overall IT cost.

O'Toole: I do not have much to add to that other than our usual dictum which is to start small; define something that is definitely doable, and do it. There is a lot of learning that folks have to do if they get into this world, and they need to just get going somewhere.

How do SOA and Web 2.0 intersect?

Moderator: Okay, thanks. The next question is, How do you see Web 2.0 and SOA coming together? Is that what people mean by Enterprise 2.0? Dana, I think you were talking about this in your presentation.

Gardner: Yes, we’ve seen a lot of activity around social networks that allow collaboration on an ad hoc basis, using things like wikis, podcasts, blogging, transparency and openness -- where the technology is really above and beyond (and totally separate from) traditional applications and platforms.

These things could actually be services that you would take off of the Internet as a Web service from Google or Yahoo or some open source or proprietary company that you might pay for on a subscription basis. We have some of these new tools, and some of the younger folks that are coming into IT that are used to doing this in their high school yearbook or equivalent. So we are looking for these ways of communicating and collaborating, where you blend some of these Web 2.0 capabilities into an SOA opportunity, where you’re looking at automation.

You’re providing more graphical interfaces for people to start reacting to IT as a business user, where the automation of the services is beneath the covers and people are increasingly finding an intercept. How will they do that? Will people think about intercepting with business processes and an automated layer of highly abstracted IT through a traditional tree diagram, or will they think about it more like a discussion and how can I get other people who have an impact on this business process, either inside or outside of my company? How can I bring them into the process? How can we communicate and collaborate?

So, I think that there is a great deal of opportunity for Web 2.0 principles, ideas, and approaches to be applied to SOA, just as SOA is bubbling up. I see this liberating and freeing data and logic into services that can be arranged and re-arranged. Some people are worried that SOA becomes less relevant under Web 2.0; some will just use ad hoc and loosely coupled and some of the client interfaces as the equivalent of SOA. But you still want to have impact on your legacy systems, down into the distributed computing environment, while also taking advantage of these high-abstraction social interaction benefits.

O'Toole: Web 2.0 is fundamentally a consumer Internet technology and Dana’s point is well-made. If you look over the last four or five years, there is been very little change in the enterprise computing landscape. In fact, what we have seen is massive consolidation at the enterprise computing level ... this massive consolidation of big old giants, and I think there are lots of things people mean by Enterprise 2.0.

But one thing everybody would agree on is there is a big change coming at the enterprise computing landscape. The days of very cumbersome, hard-to-use monolithic expensive technology is coming to an end. As Dana mentioned earlier, we are at a tipping point where the whole existing enterprise and software world comes crashing down. It is going to be a big bang.

Moderator: Okay, thanks. The next question is for you, Annrai. What lessons did you take away from your dealings with Workday that speak to the advancements of SOA?

O'Toole: There are a few tactical ones in making SOA work in that 24x7 host environment. This is no walk in the park. It is a very demanding environment, and your stuff needs to be up to the job. The traditional interoperability stuff does not work. A lot of the people using the Workday service are using .NET clients. Everything we have spoken about in terms of adding SOA into operability and out-of-the-box integration all needs to work in production.

Workday is offering two elements: One is hosted applications, initially human resources functionality; and secondly hosted integration. They need to be able to host integrations on behalf of their customers, to talk to ADP and other payroll processes and so on. This whole multi-talented, hosted integration thing is a really interesting idea. And I think that’s come out as how we help a lot of existing enterprises move forward into this new world of SOA.

Key messages for ROI

Moderator: This will be our last question. What have been the key messages specifically around ROI that an IT professional or CIO could take to our CEO about why we should invest in SOA? Dana, maybe you could respond that?

Gardner: Sure, I think CIOs need to stress to their leadership the need to get behind transformation, and that all the complaints about IT will not back away by themselves. A proactive approach to transformation is essential. Once you have decided you want to change the mindset around IT from being a cost-center and an inhibitor and a place for excuses or to develop as quickly as code, then you will make the shift toward being a differentiator -- a place where IT are accountable.

If they can make change happen and become more accountable with both developers and operators working hand-in-hand on a common methodology or understanding -- that's architecture. They also need to take into account the networks and communications folks. It is not just cutting across developers and the operators. We need to bring in all those folks that used to exist down the hall alone with their PBX and their communications protocols and their own set of goobly-gook and acronyms, and allow for those communications to be exposed to services as well.

Then all those services need to be embedded within business process. It is not just about what you do with your PC. It is what you do with your phone, your mobile device, and multi-modality communications -- anything that touches IT. It all blends together.

So the mindset to take to your CEO is transformation. If they were invigorated by business process re-engineering 15 years ago, they should be reinvigorated by SOA and see it not through the lens of yet another technology shift, but really through a larger lens in order to be adaptable and changeable in the marketplace.

Moderator: Great, thank you. That’s all the time we have today. If your question was not answered online, we will be happy to follow up with you after the event.

If you would like to learn more about Cape Clear, please visit our website at www.capeclear.com. You can also register for one of our upcoming SOA forums. Thank you very much, Dana and Annrai, for your time today and thank you all for attending.

You’ve been listening to a sponsored BriefingsDirect Podcast with your host Dana Gardner, principal analyst at Interarbor Solutions. Remember that full transcripts of these podcasts are available at www.briefingsdirect.com. If you would like information on how to sponsor a podcast or to repurpose a webinar into a podcast, contact Interarbor Solutions at 603-528-2435 and at www.interarbor-solutions.com.

Listen to the podcast here.

Sponsor: Cape Clear Software.

Transcript of Dana Gardner’s BriefingsDirect podcast on the state of SOA. Copyright Interarbor Solutions, LLC, 2005-2007. All rights reserved.