Question and Answer: How Much Momentum Does Service Oriented Architectures Have?
It’s a service-enabled world out there. Who’s along for the ride so far?
- By Eric Kavanagh
- December 7, 2005
An old expression notes that where there’s smoke, there’s fire. An excellent barometer for assessing the penetration of cutting-edge enterprise technology is the consulting world: where there’s consulting business, there’s penetration of innovative technology. Once the tech has been around for a while, the workforce adapts and most companies can hire in-house staff to implement. But when dealing with the leading edge, that’s the sweet spot for consultancies.
By that metric, it would appear that service-oriented architectures (SOA) are definitely on the rise. TDWI asked Alex Rosen, who manages the SOA practice for MomentumSI, what they’re seeing on the SOA front.
What are you seeing in the realm of service-oriented architectures (SOA) lately?
There’s a new wave of service-oriented architecture that’s standards-based, which will bring the concepts that a relatively small number of enterprises have used in the past to build services, to a much wider audience. When I talk to almost every company, they say they’ve had a services approach in the past, but many have decided to re-label EAI (enterprise application integration) as services initiatives. They may have done EAI that really involved a lot of data synchronization and wasn’t really focused around loose coupling. They might say that was a services initiative: “We were doing SOA, but now we’ll just do a new way.” That’s a rewrite of history. Most enterprises do not have a history of doing true SOA, whether standards-based or not. There are some examples of enterprises that have in the past taken more of an enlightened, loose-coupled approach, and built architectures that are consistent that are current with SOA concepts.
How does an enterprise service bus (ESB) fit into the equation? Are most companies purchasing ESB products from vendors, or building their own solutions?
What we’re seeing—and it may be a function of when people are looking to make use of consulting—is that most organizations feel they have a need for an ESB, but there are not that many which have deployed packaged products to provide that functionality; specifically those products that are labeled as ESB. In that arena, we had until recently, IBM saying ESB is a pattern not a product; but then within the last few months, they changed their tune and now provide a product that’s called their ESB.
There have been other vendors providing ESB products, but the number of installations they have is not very high. People recognize the need, and it’s not uncommon to find enterprises that have created essentially a home-grown version of an ESB. That follows a common pattern that we see in technology, where there will be some efforts to create something to fill a need, then vendors come in and package up what they see as that common need in order to provide that service.
Which industries are the early adopters?
We’re agnostic as to industry; our focus is around what you can accomplish with SOA. However, where there seems to be most interest, acceptance and need is financial services. And then a few other verticals are in very competitive industries; specifically pharmaceutical—we’ve seen a fair amount of activity in that market. There are banks and some others that have built their own service buses, if you will, and are using them. They’ve adopted the basic web service standards, and have built capabilities to do things like transformation, transaction handling, into a BUS infrastructure that they use.
How will SOA affect the enterprise software industry as a whole?
It’s going to change dramatically. What we’re seeing with SAP and NetWeaver, is that essentially they’re taking their monolithic product and re-architecting it into a set of services and processes, and delivering them to the enterprises in a way that will allow customers to much more easily customize such a major industry application. It’s a well known industry challenge, taking an application or set of applications like SAP’s and trying to integrate them into your business processes. It’s not uncommon to see that people must adapt their business to the software. As the business application providers build their products in a way that is amenable to use in an SOA, then enterprises will be able to start from their particular business process, and pull in the functionality that a vendor provides; rather than having to start with, or be highly influenced by the processes that come out of the box.
When you think about that, breaking monolithic applications into smaller services, that could potentially have a major impact on how you buy your enterprise software, because you may be able to buy it in a smaller granularity to just perform the pieces that you need. And there’s also the whole concept of software as a service, which we believe is a wave that’s picking up steam. You see that with Salesforce.com, which has focused on small to mid-sized business. But now some larger enterprises are starting to make use of that. What’s the impact of that type of solution? It’s huge.
Have you noticed any erosion of revenue for licenses of big software vendors?
Not yet. We’re seeing companies test-building in-house, building services that are provided by the larger applications, using tools that are designed specifically for building services. That may challenge the business around J2EE application servers, because there’s a lot of push for faster, less-costly ways to build the services that an enterprise needs. So we’re seeing a lot of use of Spring Framework, which is an alternative to J2EE. In the enterprises that are making use of it, they’re doing so because it’s a faster approach to getting things done. The basic belief is that J2EE has really slowed down the building of software; and that’s fairly clear. In the past, people were able to build client-server apps faster than interior applications using J2EE, so we’re swinging the pendulum back, and some frameworks are gaining traction; and making it faster to build services.
What are the standards in “standardized” SOA?
There are basically two sets of standards. There’s what’s called the WS-I basic profile, which puts together a version of SOAP, a version of WISDL, a version of XML, a version of UDDI, that work together; so there’s interoperability. Those have been around for a while, but what they lacked was the ability to support all of the requirements that you have in an enterprise, requirements around reliability, security and transactional integrity. What we have today is the implementation of open standards that support those requirements. Specifically, there’s the WS reliable messaging standard, which is implemented in the Windows communication foundation that was generally available last month; that’s the Indigo set; the WS security, which is actually a family of standards, but provide the pieces that allow you to deal with single sign-on, securing message contents.
Then there’s the transaction standards; again, a family of standards. In that arena, there’s still some work to be done. The Windows communication foundation, which is the leading edge from a major vendor right now, has not implemented all of the requirements around distributed transactions, but has done a big chunk of that work. But people have been able to build SOA on those basic standards; they had to use home-grown non-standard ways to handle enterprise concerns, though.
Does MomentumSI promote ‘Intentional’ SOA?
You mention the concept of Intentional SOA. Perhaps you’ve heard of accidental SOA? One way of looking at that—it’s very easy in all of the vendors’ Integrated Development Environments (IDE) to create a service; and it’s easy to consume a service; and what we’ve seen is development groups creating and consuming services without any type of management or infrastructure support to handle the dependencies that are created when those applications begin to rely on each other, talk to each other. That’s very problematic; it’s the type of thing that can explode. So if people think they’re doing SOA because they’re consuming Web services, they’re sadly mistaken, and they could use some assistance in looking at SOA from a bigger picture. They are likely creating more problems for themselves in the medium- to long-term. They may see some advantage, but if they don’t address governance, management, mediation… That’s accidental SOA.
What we talk about is the service oriented enterprise: people, process, technology. The technology can be challenging, but is often the thing that winds up being the easiest piece to get through. In a large enterprise, trying to adopt SOA, you run into a large number of non-technical issues that ideally get addressed early on [such as] new processes for building software; some are around ownership and the concept of shared services, how those get built and paid for. We’ve seen enterprises that have gone down the road of doing some architectural work around SOA and then are surprised when they put in some initial pieces of infrastructure, but don’t have any services being built. How do we actually equip our teams to make use of the framework we’ve built, or the tools that we’ve created?
How long till SOA is the accepted standard for enterprise architectures?
It’s unfortunate that sometimes the companies that are the most leading-edge about technology, are the ones who might need SOA the least. There are companies that have a very conservative approach to technology that are now doing things like migrating off main-frame, building object-oriented solutions; and those companies look at SOA and are intimidated, or feel that they should wait until they do other work before they move to SOA. In reality, those are the ones that can take advantage of the biggest value proposition, which is the ability to service-enable what you have in your enterprise, and make use of it in new ways; make it really easy to tap into. So, when will it become mainstream? It’s difficult to say just yet. Will those conservative companies recognize the value and be willing to make a leap past going through what the leading edge did five, six years ago? toward what the leading edge is now: SOA? If there are successes, we’ll see mass adoption very quickly. Right now, it’s the companies that are more progressive about their technology that are doing this; and it’s hard to gauge how quickly everyone else will follow along.
In our non-scientific poll on SOA, we currently show more than two-thirds of respondents saying that their enterprise has either fully embraced SOA, or is actively investigating its benefits. How do those numbers compare to what you’re seeing?
Of those who say they’ve fully embraced SOA, I do not believe that it’s that large. There are many companies who say they’re doing it, and have begun an initiative, but it runs into some challenges. Six months or a year into it: have we fully achieved what we believed? The problem that is most often the case is a failure to look at what you’re doing from a strategic point of view, and looking at all the various things that this new approach can affect.
When you think back to object-oriented approaches, in that transition, you’d get a survey result of lot of people saying yes, but it took training, mentoring, a lot of changes in the software development methodology, before you had mass adoption.
Are you keeping tabs on third-party Web services that you recommend to your clients, or are most of the services they’re using built in-house?
Our clients are primarily building services internally; they’re not very focused on use of external services. There are catalogues, Strike Iron is in that business. That’s also been a part of what Grand Central Communications has been about, and some others in that space as well. We go into an enterprise, and I’m dealing with one that has 2,000 applications right now; they’re not looking to bring in more stuff; they want to take advantage of what they have, and get rid of duplication, to reduce their code base so they can better manage their enterprise.
Anything you’d like to add?
Three other things: Take a look at our CEO’s blog: http://Schneider.blogspot.com. You mention incendiary items [in your article on the end of the software industry as we know it], so you might enjoy that.
Second is, there’s been a release this week of the Service Component Architecture. Basically, IBM and BEA and some others have released an approach to building services that they’ve used in the past. My CEO tells me that this approach was used by IBM in building or service-enabling Siebel’s CRM system. So, what I’m getting at is that the enterprise software vendors have been going down this path for some time, so they have new generations of their products that offer up pieces in Web services.
And thirdly, how is this all affecting BI stuff? So, Service Integrity is a company that has a very interesting offering in that they’re trying to capitalize on what is potentially a new way to do BI. The idea is that with all the messages traversing over an SOA, if you can wiretap, then you have a whole new way of identifying when things occur that are of interest to the enterprise. That has relevance in certain applications. In an SOA, with messages you can pull off the wire, and do some analysis on, you can eliminate the intrusiveness of typical reporting or BI solutions into the application.
When you ask the question: Is SOA affecting BI? That’s how I’m thinking of it. In reality, there’s not enough out there yet; most enterprises don’t have enough of their traffic going through services where you can pull that data, or pull the messages off just yet. But in the future, that’s going to be a very common approach. That changes the game. We have yet to see how we’ll take full advantage of having messages go across the network in common format, XML, especially if an enterprise goes through the process of creating a standard set of messages. We’re just now at the point of discovery.