The importance of Service-Oriented Architecture (SOA) “hygiene” in enterprise IT architectures has received considerable attention. Most IT architects seem to agree that an SOA significantly benefits distributed enterprise architectures and should be adopted in whatever flavor best fits the organization and culture.
This article examines the different kinds of resource investments that accompany an SOA implementation, projected returns on these investments, and how the returns can be enhanced with the right business alignment and perspective.
SOA Overview
At the core of any SOA implementation is the ability to build new services or expose existing applications as services in a consistent, seamless manner, regardless of technical differences beneath the hood. Services, which are nothing but business functions or software components, when exposed via standard protocols and payloads become easily accessible across the enterprise.
For brand new projects and application development built on SOA principles, developers will build new services. But for several home-grown applications and existing vendor products, some kind of wrapper will be required over and above the core business functions they offer.
For example, a banking application can expose a business service that fetches the complete account details of a customer using an account number. This service can be designed to accept a simple XML message as an input and provide a response over standard transport/payload protocols such as HTTP and XML. Under the hood, it might be invoking a stored procedure call to a database or call a core banking COBOL application via a COBOL copybook-formatted message. When this concept is extended to cover different families of business functions offered by a variety of applications, it’s called a “service-enabled” or “service-oriented” architecture (see Figure 1).
This approach offers several advantages:
• An “application-centric” view of IT architecture changes to a “business function-centric” view. Each application can then be viewed as a provider of a specific set of business services. For example, a core banking system becomes a provider of services, such as “fetch customer data,” “transfer funds,” etc.
• Client applications can just focus on business logic rather than the technicalities of talking to specific systems.
• Different applications performing the same type of function call can reuse the service instead of having to establish independent point-to-point communications. For example, a loan, Customer Relationship Management (CRM), and sales management application can all use the same “fetch customer data” service. Traditionally, these systems would have had to establish their own independent communications with the core banking system.
This is just the tip of the iceberg. SOA can mean much more in a given business context, provided it’s aligned with the right set of business perspectives.
Nature of SOA Investments
In an enterprise-scale SOA implementation, there are typically three types of resource investments (see Figure 2):
• Software: Tools and technologies required to build services on top of new and existing applications
• Hardware: Servers upon which the services will be hosted
• People: The team that develops, deploys, and maintains services.
Each of these investment resource areas is explored in more detail in the following sections.
SOA Software
As indicated earlier, dedicated SOA tools are required to service-enable existing home-grown applications and vendor products and expose their underlying business functions as services. This can be challenging because many of these applications have been architected in a traditional manner, without the notion of SOA. While many third-party application products have begun to re-orient themselves in the services world, the day when every application natively exposes its functionalities as services is still far off.
SOA toolkits hide the nuances and variations of underlying technical implementations of diversified applications and provide a consistent, seamless, and easy-to-use XML interface. In the banking services example previously cited, the SOA tools enable communications with COBOL applications without the need to provide copybook-formatted messages to the client.
SOA Hardware
It’s best to host SOA on top of dedicated hardware for scaling purposes and to allow for independent service maintenance. While certain parts of the SOA platform can exist with core applications, the crux of service implementations should be independently hosted, as they typically tend to grow—both in terms of number of transactions and applications that are exposed—over time. Horizontal and vertical scaling is easy only if the platform itself is independent and isn’t a shared infrastructure.
When SOA implementations span multiple geographies, planning for the SOA hardware becomes even more significant, as certain local service calls may need to be routed to other applications located in a different part of the globe. For example, a bank customer from Europe querying a U.S. ATM might have to be routed back to the core European banking application. This becomes even more complicated when the customer has different accounts in the U.S. and Europe and the bank wants to provide seamless access to both.
In summary, the salient features of SOA hardware include the ability to:
• Support a growing number of services—either on top of existing applications or those developed as part of new projects
• Reside and scale independently
• Span geographies when required
• Transcend different varieties of operating system and server families, if required.
SOA Team
A dedicated team of professionals with different levels of skill sets is required to plan, implement, and maintain an enterprise-scale SOA platform. An organization’s SOA competency center should include business architects, technology architects, service family teams and team leads, developers, testers and systems and operational staff (see Figure 3). Important features of capable SOA teams include:
• People with different backgrounds and skill sets—spanning architecture, development, and operations—all with a deep understanding of the SOA
• A project sponsor for the whole initiative as well as a business sponsor who has the responsibility of ensuring business visibility and involvement in the project
• Architects, managers, and other leads for independent teams
• A chargeback model that will support the existence of the team.
Funding SOA
A full-blown SOA implementation involves both fixed and variable costs. Fixed costs include all the software and hardware investments previously mentioned. Variable costs include the cost of training and maintaining the team, and expenses associated with software and hardware upgrades, for example. Both need to be justified in the proposal based on the anticipated monetary returns. The projected returns should at least include breaking even in three to five years (depending on the number of related projects and scale), after which the entire SOA platform can be operated as either a profit or infrastructure center on a “business as usual” basis (see Figure 4).
Vast differences in the proposed idea for an SOA initiative and the projected returns exist during the funding stage. Some organizations feel that SOA should start small and then grow big while others cite greater successes with embracing SOA on a larger scale. The industry has been striving to come out with an all-encompassing ROI formula, but it’s still a ways off.
All these approaches fall in two categories:
• SOA as an IT initiative
• SOA as an enabler of a business initiative.
The remainder of this article will explore challenges associated with the former approach, then focus on the benefits of the latter.
Approaching SOA as an IT Initiative
SOA, projected as an IT initiative, is currently the most popular approach. Enterprise architects, the nominated SOA champions in an organization, hail from traditional IT and enterprise architecture departments. The business side of an organization usually has little involvement as the approach looks at SOA as a transformer of existing IT architecture. In this scenario, an application building methodology takes root and the entire initiative becomes technology-centric.
Monetary returns, in this case, are projected to accrue from cost savings for:
• Reuse of services across multiple projects and applications. As more applications start reusing the same service, the Total Cost of Ownership (TCO) is expected to fall across the enterprise.
• Simplified development, testing, and deployment. As SOA exposes a single set of interfaces, applications no longer must connect to different back-end systems.
• Ease of maintenance. Since SOA provides a single generic backbone for various kinds of communications, troubleshooting becomes easier, reducing maintenance costs and simplifying enterprise communications.
Figure 5 shows the various phases of the SOA implementation cycle.
These benefits are true and proven, but as you attempt to translate them into numbers for ROI calculations, a myriad of problems surface. The approach is inherently pitted against several unrealistic assumptions and implementation challenges. This makes it difficult to justify a six-to-eight-digit investment. Specifically, these challenges are as follows:
• The approach inherently assumes compulsory participation of most or all application projects in the IT pipeline, a difficulty with any organization. Any new technology must prove itself in an enterprise before being widely adopted, so it’s difficult to convince the business and project owners of various business initiatives and projects to adopt SOA unless something has already been proved in the enterprise backbone.
• Since the development and maintenance cost savings achievable per individual service reuse may not be substantial, you must consider several business initiatives over a longer time. In most organizations, however, few confirmed IT budgets can be projected beyond a year, so the pipeline of projects that can eventually adopt SOA could be jeopardized.
• The number of services that compose a given application can’t be projected unless the specific nature of a project is studied and functional specifications are well-understood. Obviously, such clarity isn’t possible for projects not yet started, so it’s tough to project the level of reuse and associated savings.
• It’s difficult to divide the development effort into services and service calls because application development is approached as a whole, not in parts. So the numbers projected as development efforts toward services may be mythical.
• Many organizations are now resorting to cheaper offshore facilities for application development and maintenance. If this is the case, cost savings for development and maintenance will be further shrunk.
• It’s difficult to attach numbers to the relatively intangible SOA benefits. For example, everybody agrees that SOA promotes business agility, but projecting a dollar value to that is always problematic.
All these issues have forced analysts and consultants to consider alternative approaches. Some feel that since it’s difficult to quantify all the benefits, SOA projects should be funded and adopted as strategic initiatives. Unfortunately, it’s not possible to justify any IT investment in an organization without the promise of returns, so enterprise architects must head back to the drawing board and come up with ROI figures, regardless of whether it’s meaningful in the SOA context.
Another suggestion is to first approach SOA on a smaller scale, limiting the scope to one or two projects, and then grow it to an enterprise scale. While this seems reasonable, it reduces the reach of SOA to such a negligible extent that it can hardly create an impact. It might pacify doubters in the organization, but when you enlarge the scope, the same set of ROI issues arise.
So there’s an urgent need to re-evaluate the SOA value proposition from a business perspective to determine if the whole initiative can be realigned with the overall goals of an organization.
Realigning SOA Goals in a Bigger Context
As we think about the role SOA can play in business goals, problems, strategies and wins, we realize that each organization’s goals and strategies are different. Each business vertical is under different pressures and time constraints, so any effort to align SOA with business motives is meaningful only in a given context. You cannot assume any common set of problem areas across all businesses, making generalist theories few and far between. This is in contrast to IT problems, many of which are common across large-scale enterprise architectures.
Alignment strategies can be discussed only at an organizational level. Consider a sample set of business strategies and goals a retail bank aims to achieve in the next three years:
• The bank wants to expand its business into new territories via investments and acquisitions. Business volume is expected to increase by at least 40 percent in the next three years because of these efforts.
• IT operational and maintenance costs are considered prohibitively high, so the bank wants to reduce maintenance costs by at least 25 percent in the next three years.
• The credit card processing time is prohibitively high when compared to competitors, so the bank is seeking a drastic reduction in processing time.
• The bank wants to enhance its channels and improve up-selling and cross-selling to existing customers, which it believes can increase overall business by 15 percent.
These are all different types of goals meant for different parts of the business with no direct relations or dependencies. When the strategies and actions to achieve these goals are established, IT needs to evaluate the situation and determine if SOA can help achieve the desired results.
If business volume is to increase by 40 percent, there should be a corresponding increase in the volume of transactions. The following questions naturally arise:
• What’s the cost of developing and maintaining a business transaction?
• Can the present set of applications cope with the expected increase in volume?
• Will hardware and software upgrades be required? If so, at what cost?
• What role can an SOA initiative play?
Answering the first question requires understanding what’s happening in the enterprise today, both in terms of statistics and costs. It’s a shocking reality that many large enterprises lack statistics at such a granular level. Often, the IT view of an enterprise consists of a series of vertical applications, whereas the business side focuses on the business processes and transactions. So it’s difficult to arrive at a cost of transaction, but when computed, it’s usually an astonishingly large number. In this case, the 40 percent increase in business and the corresponding increase in transaction volume will translate to additional transaction costs.
With the second question, you must look at all the core applications in the bank, including the current transaction volume they’re servicing, hardware resource utilization, etc. and combine this with the expected increase in transaction volume to determine costs for a given application. Usually, the applications would either be incapable of servicing this additional volume or might demand additional maintenance and hardware.
Now we have two new problem areas to address. One is the significant cost of supporting a business transaction; the other is the investment required to keep up with the projected increase in volume. Both of these issues arise from a single business strategy that was subjected to a simple impact analysis.
Can SOA help reduce the cost of a transaction? The answer is yes. SOA exposes every vertical application as a set of business services, enabling an organization to better understand the behavior of a business transaction. With this understanding, it’s possible to determine if the existing methodology is the best means for providing this service, or if a simpler approach exists. The volume of requests going in to a given service can be identified, and both critical and auxiliary services can all be analyzed in the light of SOA.
By considering a set of core applications and their corresponding services, the enterprise architects should be able to project a sample set of transactions, the existing costs and eventual savings, and the potential visibility provided by SOA. For example, let's say that $600,000 is paid in software maintenance, $300,000 in labor costs, and $200,000 for hardware for a given application. There’s no easy way for us to distribute these costs across the hundreds of different types of transactions that this application supports because that’s not the thought process when building monolithic applications.
SOA changes this. The business will now be able to view the set of services offered by this application, prioritize them, and charge the corresponding business divisions accordingly. This is an incredible power. Each business division can pay based on its usage and requirements instead of a single flat rate. For example, you could now say that out of $1.1 million spent on this application, 38 percent goes for highly critical transactions used by only two business divisions, 40 percent goes for critical transactions used by seven other business divisions, and so on. Since 22 percent of services are considered less critical, the maintenance overhead on them can be correspondingly reduced.
We began with a generic analysis on how to measure and reduce transaction costs, but with SOA you can achieve something even further: the ability to charge different business divisions based on their usage and requirements. This is meaningful to different business units and IT because it will help businesses rethink their requirements and identify what’s critical. This will eventually reduce overall transaction costs.
Regarding the second goal, reducing operational and maintenance costs by 25 percent in three years, let’s assume that, upon analysis, you discover major proportions of these costs are spent on maintaining one or two monolithic yet critical core systems in the bank. The complex nature of these systems has prevented IT from replacing them. Too many business-critical systems rely on this behemoth on a daily basis for various complex transactions, and replacing it would be risky and prohibitively expensive. Any further reduction of operational costs isn’t possible, however, given the present state of affairs.
Can SOA play a role here? Yes, it can play a critical role in enabling smoother transition and replacement.
The criticality of the monolithic application stems from the complex nature of the built-in business logic and the dependency of external systems on this logic. With SOA, we can develop a set of business services on top of the core system and slowly migrate the calling clients to the service interface from proprietary mechanisms. These services insulate the clients from the back-end systems, making it easier to migrate to new applications behind the scenes. Of course, this requires daily synchronization between the old and new systems and a transition plan, but the situation is much more appealing from the client systems perspective. This transparency of transactions, regardless of the nature of service provider, is a powerful benefit of SOA. If we can attribute even 10 percent of the overall cost savings achievable out of this transition to SOA, we’ll be closer to the budget figures.
Readers can analyze for themselves the scope of SOA in the other two business strategies listed but not discussed here. Most people come to the conclusion that SOA helps with these other business goals and strategies.
Conclusion
Those who have already implemented an SOA or are considering doing so should consider these ground rules for success:
• Take an SOA implementation approach that’s pertinent to your organization’s overall business goals and objectives.
• Explore how these business goals can be turned to IT goals or how IT can help achieve these goals.
• Spend sufficient time collecting relevant data that will properly position SOA.
