SOA’s best when business pulls the strings

SOA—the idea of a service-oriented architecture for software applications—has undergone a more quiet rate of adoption since its heyday in the hype cycle.

“The SOA story has certainly died down,” said Jason Bloomberg, analyst at ZapThink. “It’s not as sexy as it used to be. That means people are getting it right.”

SOA adoption faced many hurdles. First and foremost was getting buy-in from upper management for a SOA initiative. IT people who understood the benefit of moving to a service architecture were presenting it to management as a technology imperative.

“The thing taken to management for funding was the promise of a SOA world. It should not have been exposed as the goal; it’s the means to achieve other goals,” said Michael Rowley, CTO of business process software provider Active Endpoints.

Along with the misconception that creating a SOA is a goal unto itself is the assumption that you have to move to the architecture as one holistic effort. It can be done in steps, experts say, with the understanding that its business value increases with the size of the implementation.

“The goal is to make all the assets of enterprise available as services,” Rowley said. “Even if you get there incrementally, it’s more and more valuable” as you service-enable more application data and business logic.

As a software provider, “we don’t lead into the marketplace with a SOA message. We go in with connection technologies and environments,” said Glenn Johnson of Magic Software, which sells integration software.

“It’s about the business process, not necessarily the tools. As a vendor, maybe I shouldn’t say that. But you justify the architecture with point-to-point solutions. It’s like a Trojan horse that you can then apply to an overall architecture strategy.”

Moving to a SOA is, in fact, a business decision, not an IT decision, according to HP distinguished technologist E.G. Nadhan. And, it’s not always an application conversion exercise; often, organizations simply want to integrate their so-called legacy applications into a larger, more up-to-date software portfolio via services.

HP encourages organizations considering a SOA implementation to first look at their application set at the business-process level, asking how the application is enabling the realization of business goals. “When we look at enterprise transformation, it is done in the context of business objectives and IT,” said Nadhan.

Some applications might be fine the way they are, he said, while in other cases, business processes might need to be updated or improved, or requirements have changed. In those cases, the application might need to be retired or rewritten, or a pre-built off-the-shelf application might fill the business need. “You don’t want to reinvent the wheel,” he cautioned.

In still other circumstances, you might have an application that works just fine—it’s robust and reliable—but people are no longer happy with the user experience. “You can create a façade that’s state of the art, but behind the scenes, it’s the legacy app that’s running.”

HP’s Tom Hall, global offering manager for the company’s SOA and Integration Services, HP Enterprise Services, discussed the AirlineSOA platform the company helped create, which serves as a reference architecture for the company. One legacy application, the airline seat map, had all the code, workflow, point-to-point interfaces and application logic tightly integrated. And, he said, at one time it served the airline industry well, before airlines changed rules regarding sitting in an exit row or upgrading to a better seat. It’s no longer a static process, he said.

“Every time you needed to implement any kind of change, you had to change the application,” he said. “Now it’s a composite seat-map service, with an interface, externalized business rules that are easy to change to meet demands, with utility security services at the bottom. It all doesn’t have to be encapsulated or hard-coded in the application,” said Nadhan.

ZapThink’s Bloomberg agrees with the assertion that moving to a service-oriented architecture should be driven by the business. “SOA is not about the tools. It’s a set of best practices for organizing IT to meet changing business needs. The technologer is an enabler” of the business, he said.

SOA, Bloomberg said, is becoming core to many organization’s approaches to IT architecture. “The relationship between business processes and architecture is becoming clear. SOA offers a way of dealing with complex heterogeneous environments that has people rethinking how they do integration.”

Tools, however, can often make the transition to a SOA go more smoothly.

Steve Lattman, CIO of PSCU Financial Services, the largest provider of back-end member services to local credit unions, said his organization had a need to get to data on a highly available basis, but that was siloed from an application standpoint.

“The business was pushing us to provide more data in different landscapes,” he said. “Everybody was asking for all these data and information points; we said we need to create an architecture that allows us to deal with all these requests for data across all the applications they want.

“We started looking at middleware and building it ourselves, but decided it would take huge amounts of resources and time.”

The company purchased a commercial system integration tool from a company called Metastorm, which Lattman said “speeds up our ability to deliver data and gives me the ability to create a lot of metadata associated with the data. Now we can begin to understand how much data we get from individual sources (and the types of data as well) so we can better estimate growth patterns and how the business is running. If I understand how much data is being asked for, I can make key business decisions.”

From an architecture standpoint, Bloomberg said, a move toward complex systems theory is being seen. “Current integration involves everything being put together and it works. But it’s not flexible.” The complex systems theory, he said, is about getting semi-autonomous elements to interact in ways that incorporate how people work. It’s more agile and metadata driven. The metadata, not code, describes behavior.”

Bloomberg sees SOA as a governance challenge, not a programming question. “There is a huge opportunity for governance-centric, metadata-driven, complex systems software. The code-writing part is becoming less and less of the story,” he said.

Magic Software’s Johnson said, “In my view, we’re past the bottom of the trough in the hype cycle. That’s where the value comes from. Companies that have stayed with it are seeing the benefit. But that also implies that some have crashed and burned along the way. But if you tie [service architecture] to solving a specific business problem, you’re more likely to get continued support for that kind of architecture approach.”

Weighing costs and benefits
The Avis Budget Group car rental company created a team shortly after 2000 to study the future of the company’s Wizard reservation system, said CIO Gerard Insall. “We knew it would be a competitive disadvantage if we didn’t move” to a service architecture.

Insall said his team was able to get management to agree to building out the architecture even without a project that would demonstrate a return on investment. This is where many SOA plans come to die, he said.

“In this [economic] environment, it’s hard to get the initial investment” to build out an SOA, he said. “No one project has the kind of ROI that a business would want to see to justify building out the infrastructure.” Instead, his team started creating the architecture in chunks, as “SOA lends itself to that,” he said.

Another important step in avoiding SOA failure is to have someone or some team in the organization own it, Insall said. “Business folks are leery of the IT architecture aspect because it costs a lot of money. But if you don’t put it in place, you’re way behind your competition in time to market.”

Avis Budget Group’s reservation system was “very heavily legacy mainframe at our core,” he said. “It was developed quite a while ago, and will take considerable investment to move off that core. We’re looking at it over a long period of time.”

Insall admits the company went through a difficult integration period. “We chose [IBM] Tivoli, which works great once it’s integrated, but the integration itself is arduous,” he said. But the team plugged away, and its SOA became mature about five or six years ago.

“We had the governance around it, we’re centralized with quite a few development teams, and we have a common life-cycle process,” he said. “We didn’t include all the right people at times—we had legacy developers driving solutions to legacy systems without having architecture people reviewing—but we got past that and now have metrics for reuse of services.”

The company’s first real success has been seen in reservation services, with more than 300 partners today, including Priceline. “It used to cost between US$40,000 and $60,000 to set up partners. With SOA, now it costs about $5,000…It’s mostly texting,” said Insall.

Adopting a SOA opened up the company’s legacy back end, where applications were written in Assembler and COBOL. “We moved a location service off the mainframe, which was the largest amount of Assembler code in our system,” Insall said. Making that move, he added, alleviates the risk of what happens when Assembler developers all retire. “Someone else around the world might take that over, but there’s no guarantee.”

The tools, he pointed out, weren’t cheap. “WebSphere, MQSeries [from WebLogic], we’re talking about hundreds of thousands of dollars at a clip, and if you need enterprise licenses, you’re in the million-dollar range.”

He did say cost has to be measured against the benefit of putting the organization in position to react and move more quickly. “Where we’ve lost is where the business was beaten to the punch by a competitor.”