News

Build a Reuse Framework for SOA

• By Lee Thé
• February 21, 2008

Service-oriented architecture (SOA) is touted by many as the key to code reuse, which, practically speaking, is easier said than done, according to experts. The idea is that you get cost reductions with code reuse, but even enthusiasts agree that it won't happen without careful planning. The topic was a popular one at the Open Group's Enterprise Architecture Practitioners Conference, held in San Francisco at the end of January.

At the event, Srikanth Inaganti, a lead consultant with Wipro Technologies, spoke in a session on building a reuse framework for SOA. He has spent the last two and a half years at a client site, working on promoting reuse across divisions. So he speaks from the trenches. And he's part of the Wipro team that's developing SOA frameworks and consulting toolkits.

In this presentation, Inaganti discussed the importance of reuse in the context of SOA transformation, issues involved in promoting a reuse culture inside the enterprise and what he modestly referred to as "tentative solutions."

SOA What?
SOA radically changes how you develop applications, Inaganti said. You consume services in your ecosystem and add value to the system by adding new services to the portfolio. But reuse isn't relevant if you add something that can't be accessed by more than one consumer, or which doesn't add to the company overall.

Reuse is most relevant with time-tested things, according to Inaganti. Using them reduces risk, time to market, and maintenance and operation costs.

One example is an executable. Most executables are tightly coupled, with no sense of multiple consumers. But maybe you can host it centrally instead of deploying the code. That's how you reduce complexity. On the other hand, he speculated that "by going to SOA we're increasing the number of failure points sometimes."

Reuse Bottlenecks
Inaganti has encountered many impediments to reuse. He cited four trouble areas at the enterprise architecture (EA) level:

• Lack of organizational support
• Lack of supporting IT processes
• Lack of IT standards
• Lack of acceptable reuse metrics.

He cited four more trouble areas at the SOA level:

• Lack of awareness and advertisement of reusable services
• Inadequate SOA quality assurance (QA)
• Deficiencies in service design
• Shortfalls of opportunity identification.

Inaganti observed that few customers put enough time and effort into the planning phase. Consequently, he said that "the lack of a portfolio view is not giving us a generic design."

Someone has to tell developers that the service can be reused in different contexts. Next, someone has to test the code to make sure that it works. So producers of the code have to be aware of reuse. Consumers of the code have to know about your SOA-enabled applications.

Some claim that SOA doesn't really require standards, but Inaganti insisted that from a cost perspective you need IT standards. For example, he found that one customer was using five search engines across 10 Web sites. You can control that sort of diversity without killing innovation. However, just having registries and repositories isn't enough. You have to identify the champions and create the groups required to support reuse.

Enable Reuse
Inaganti described the kind of reuse framework that can supplant all of those impediments to reuse, starting with four solution areas at the EA level:

• EA charter definition
• IT process refinement
• Compliance checks
• Models for cost savings and utility.

He cited four more solution areas at the SOA level:

• Service registry and repository
• Testing for reuse, agility and performance
• Guidelines for service design
• Business process and IT landscape study (top-down, bottom-up).

You need to study the entire value chain of the enterprise, Inaganti said, and map those processes to the different applications running there, using both a top-down and a bottom-up approach.

Then, your subsequent service design has to be really good, embodying best practices for the different consumers, with data being stored in the same schema for different consumers. You start developing a service by looking for an opportunity within an application, perhaps by finding a bottleneck. However, to do that you have to target your performance testing against the actual load.

Register Services, Create Incentives
Of course, once you've got a bunch of services, you'll need a repository to make it possible to reuse services across the company. A repository is going to host all the service artifacts for you, enabling new customers to go there and get a feel for the service. Inaganti cautioned that while registries and repositories are important, they only help you to a point. For example, there can be problems querying registries from different areas.

Users have to be able to find the service they need when they need it. And they have to want to use it, which can be a challenge.

"You'll see a lot of resistance to using components -- especially homegrown ones," Inaganti said. "There's less resistance to customized commercial components."

So evangelizing reuse takes more than citing cost savings, which is where proponents usually stop. IT has to be able to put a real case to management. And to do that, you need chargeback models. That's the most direct way to incentivize a business unit to do something for other units. You also need to define your reuse charter and include compliance checks.

Build a Reuse Framework
A detailed reuse framework requires dozens of discrete elements. For example, you'd start with opportunity identification. But that alone includes a business process study, an IT landscape study, and research in consumability, composability and data utilization.

Inaganti thinks that the key parts of such a framework are producing acceptable reuse metrics and reuse promotion, including software development life cycle review checkpoints.

Reuse metrics include:

• Number of services deployed
• Number of service customers added per each service
• Number of requests made to the service within a timeframe
• Cost savings per consumer
• Revenue from usage.

Charting using these metrics produces an S-shaped expense/savings curve through time. Spikes occur when new consumers are added to a service client portfolio. Spikes also appear as cost savings in application or service client development at vendor rates (adjusted for service upgrades, reconfiguration and development costs, if any).

Overcome Entrenched Processes
Inaganti went on to discuss his experiences on-site with his client, a large apparel, food and beverage services company. Here he faced a long list of challenges:

• No formal EA charter linking business goals with IT goals
• A relatively new central architecture group
• Lack of correct IT project inventory -- not being improved continuously
• Business continuity in need of improvement
• Reuse opportunities in need of improvement
• Overly lengthy cycle times for deploying applications
• Overly high software licensing costs at the enterprise level
• Need to lower total cost of ownership and reduce maintenance costs.

Inaganti said he tackled all of these challenges by conducting workshops to spread the word on reuse and SOA. He identified opportunities for improvement, and worked to create an architectural review process that better ties IT into business processes.

Finally, he showed how he added business discovery, design phase and predeployment checkpoints to find and institutionalize reuse opportunities.

A certain number of IT department veterans just want to reach retirement age without having to develop differently. They justify resisting SOA and reuse by calling them pipe dreams -- the Next Big Thing that's sure to fall flat on its face.

But if the devil is in the details, so are the angels. Inaganti's presentation revealed the kind of detailed road mapping and persistent effort required at every step if you want to make reuse actually happen and overcome the inevitable foot dragging.