News Stay informed about the latest enterprise technology news and product updates.

Why service providers need to pay attention to SOA

Service providers might be a little overwhelmed by service-oriented architecture (SOA) solutions, but it's time to go beyond the confusion and learn how you can increase ROI with SOA. It is a means to an end, says Robert Schneider, an independent SOA consultant, instructor and published IT author with more than 15 years of experience leading successful IT initiatives. In this Q&A, he offers ample reason to get behind it. What is SOA exactly?
It is many things to many people. What we like to do is boil it down to a set of principles and apply these principles to the real-life benefits of SOA.

Let's talk about the benefits first: If you apply service-orientation you have more return on your IT investments, because you are getting things like reuse; you're a more agile organization because you're able to compose new solutions from existing logic. You're going to get better ROI with SOA and you're going to reduce the amount of time you spend on maintenance. You want to try to move away from maintenance and toward developing new solutions to solve business problems.

You are also going to have a closer alignment between the business people and the technology people. If you think about the way applications have been built, you see a lot of siloed applications that are written with one purpose in mind. They are very closely aligned with that initial purpose, but there is very little thought given to reusing the logic that went into the siloed application. What we're trying to do with service-orientation is assemble, either through the things that we build, or the things that we buy, a collection of agnostic services -- and by agnostic I mean multipurpose, or reusable services -- from which you can compose new solutions. There is always going to be some new writing of logic to do; but if you get into a place where you are able to reuse, think about the time-delivery implications and the ROI. Tell us more about how SOA can bridge IT and business.
To follow the services-orientation approach to building solutions, you would follow the business people all the way through the process. Traditionally, the business people write a spec about what they want, but that's where things stop. They generally don't get more involved. The IT people try to interpret that spec and they deliver a model of a one-off solution -- an application that is meant for one purpose. What we're proposing in the service-orientation world is that business folks stay involved all the way through the design process and help IT folks come up with reusable services. There's a much closer alignment between business and IT and [it's] much further along. It also changes the way IT organizations structure themselves through the channel. You move away from the notion of being a specialist in one application to one of being a specialist across the business. Some people refer to SOA as the "same old architecture" -- is it?
I don't think so. What makes SOA possible now is we've seen the adoption of open service standards like HTTP, like SSL and so on. SOA is really meant to bridge organizational gaps. It's also a really good collection of standards that have been built up and that are all open. I would argue that, unlike a lot of past architectures, this is meant to be open source; it is meant to be available to anybody who wants to implement on that.

In the past you might have had a closed architecture from IBM or Microsoft. A lot of the work from the past six or seven years enabled the foundation for SOA. A lot of the things that we talk about with SOA come from tricks inherent to earlier architectures: object orientation, EAI and remote procedure call programming. SOA is an evolutionary step along that road.

What makes SOA especially exciting is that we have a set of open standards-based approaches to doing implementations and a complete technical infrastructure that makes this possible. With things like HTTP and SSL, there is now a ubiquitous, well-adopted, generally accepted infrastructure that you can build and design architecture on top of. And it is organizationally agnostic. In other words, if I'm building a solution, a client will be able to do their integration with their customers and their customers' partners and so on. It sounds like SOA is constantly evolving.
It is. Generation 1 of the Web services world is where most people's heads are right now. Generation 2 encompasses standards for things like transactions, security, addressing and things along those lines; it really let us build a cross-enterprise, robust platform for delivering solutions. What role does the channel have in this process?
I see two major areas in regard to the channel: If you are talking about VARs who are writing their own new solutions, they are already using service-orientation principles whether they know it or not; they are focused on reuse and getting products out very quickly. A lot of times software vendors will lead the way with regard to this. A lot of the concepts that factor into service-orientation originally came from commercial product vendors because they are operating under a much tighter timeframe than IT. They are all about getting reuse and having a well-designed, normalized set of services. They don't want to reinvent the wheel every time they build a new feature on their product.

For VARS who are delivering solutions to market, they are likely going to be integrating with their customers' internal systems through service-oriented approaches -- like Web services for example. If I am a packaged-software vendor, I'm going to have to have a Web-service interface for my application. What we're seeing is that many people confuse Web services with service-orientation. Web services are a mechanism that you can use to achieve services-orientation. You can achieve service-orientation through many other means as well. Service-orientation is a philosophy and a set of guidelines -- they're not concrete or black and white. Do you find SOA hard to sell to businesses because it's hard to explain?
It's changing, but SOA is a means to an end -- the end being, "We want to have better ROI," or "We want to have better agility." The business people don't really need to know, or understand, that we are using this architectural philosophy called SOA. They will know that this thing installed quickly and integrated very easily. If I'm hired to go in and integrate solutions, and I use SOA, the business user is not going to care what I used, but will care that I'm able to bring a solution very quickly and implement it very smoothly. Are consultants or integrators making money with SOA?
Absolutely. The easiest way to integrate a solution is through things like Web services. That's serving as a driver for the whole adoption of SOA. It's a new way of doing things. Mash-ups such as Google maps, which are overlaid with other information, are examples of new types of applications that can be built because of SOA building blocks.

One example of this is an application called skibonk which is a mashup of a Google map with ski information; without the common infrastructure you couldn't do this, because everyone would have their own protocol. Innovative channel people are going to be building -- and are building -- new types of solutions that were unimaginable five years ago because we have the ubiquity of the Internet, with common standards upon which these Web services and service-oriented architectures are built. How can channel professionals ratchet up their revenue with SOA?
Go in and offer customers innovative solutions. For people who develop solutions, they have to already be offering service-oriented integration because their customers are demanding it. They want to see a Web-service interface. Somebody who is a consultant would look at service-orientation and Web services as a means to an end -- the end being better integration, better interoperability and a faster ROI.

You should be able to get reuse out of every dollar you spend on IT. With the service-oriented world, we move away from integration and more toward interoperability. Customers spend a tremendous amount of money on integration. But we try to move toward a world where interoperability is there out of the box. Are businesses interested in SOA?
It's a push/pull kind of thing.

The push is they are being asked to do more with less -- always. They are being forced into ROI considerations in terms of reuse and agility. The competition is always increasing and through things like acquisitions, where customers inherit multiple solutions. The best way to get those things to interoperate is to look at doing the service-oriented approach to the architecture.

The pull is that they are now seeing the benefits through other organizations that are using SOA. Plus, they are seeing the benefits of doing things like composite applications.

I think it boils down to simple methods, better ROI and reducing the burden that IT has. IT labors under the idea of drudge maintenance, and maintenance consumes a tremendous amount of the IT budget. If we reduce the amount of time we spend doing drudge maintenance and move toward building innovative solutions that are getting out there faster, we become more agile as an IT organization. It also makes the channel people more agile on delivering solutions faster and tying those solutions into customer environments more quickly -- which will create a higher-margin business. Anything else that we haven't hit on?
It's always interesting from a channel perspective, because you always have to break things down into those who are building systems and those who are integrating systems. The systems-builders are being forced into this world because their customers are very much aware of Web services and they want that approach. For those who are integrating solutions, this becomes a very powerful mechanism that they can use to get their work done faster and move up the value chain.

Dig Deeper on IT systems integrators

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.