In-Depth
Build a Reuse Framework for SOA
Some say the benefits of reuse are exaggerated. Prove them wrong by implementing a plan of action.
by Lee Thé
Service oriented architecture (SOA) is often touted as the key to code reuse, which experts say is easier said than done. The idea is that you benefit from cost reductions with code reuse, but even enthusiasts agree that it won't happen without careful planning. The topic was popular 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 about 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. He's part of the Wipro team that's developing SOA frameworks and consulting toolkits.
In his 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 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. However, reuse isn't relevant if you add something that can't be accessed by more than one consumer or that 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 such 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, "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, but 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, 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 asserted, and map those processes to the different applications running there, using both a top-down and a bottom-up approach.
Your subsequent service design has to be 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.
Of course, once you have several 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."
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 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).
Inaganti went on to discuss his experiences on-site with his client, a large apparel, food, and beverage services company, where 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.
If the devil is in the details, so are the angels. Inaganti's presentation revealed the kind of detailed road map and persistent effort required at every step if you want to make reuse happen and overcome the inevitable foot dragging.
--
Lee Thé's first computer was a state-of-the-art unit with 48K RAM and a 1MHz processor. He has been writing and editing computer magazine articles since then, in between scuba diving trips. He's based in the San Francisco Bay Area.