In-Depth
SOA: You’ll Need More than Technology
To transform a company’s architecture to an SOA model, a systematic long-term roadmap is critical.
by Anthony Gold
Every few years the IT industry embraces the "next big thing." Occasionally, it is a technology in search of a solution or a technology ahead of its time. However, many times it is a technology that solves a real problem just as the requirement emerges. A recent "next big thing"—open source (e.g., Linux)—addressed the IT needs of lower cost, increased flexibility, and freedom of choice. It took years and the commitment of both large IT providers and customers of all sizes to take open source from an interesting idea to today’s mainstream successful development and product model.
Service-oriented architecture (SOA) is the current "next big thing." After years of discussion and definition, SOA is being actively deployed just as businesses are focused on more effectively integrating business processes and IT services for greater flexibility and managed cost. Built on supporting technologies such as object orientation and open standards, SOA helps make IT more responsive by addressing the very real business issues of code and functional reuse, the cost of development and maintenance, and improving business agility and responsiveness.
Service-Oriented Architecture Issues
A large IT services company has 26 different applications that require tax calculations. Each application has the code embedded, each developed differently. Sometimes, they generate the same results.
A March, 2006 Bloor Research report stated, "The average company in the Fortune 500 has over 48 different financial systems and [three] enterprise resource planning systems."
After years of decentralized IT spending and the lack of a comprehensive enterprise architecture, enterprises realize that they need to remodel their architecture before they can undertake next-generation projects such as self service, multi-channel integration, or composite applications. An organizing model is needed to exploit the improvements in Information Technology and more effectively integrate it into the business. In a constantly changing business environment (mergers, acquisitions, divestitures, lean operations, outsourcing, in-sourcing, and partnering), forward-looking enterprises are increasingly interested in service orientation and the service-oriented architecture model.
The terms multi-channel, multi-portal, multi-application, multi-divisional, and business to business have several traits in common. They:
Involve heterogeneous IT systems
Address the need for process integration
Provide seamless information flow
Linking people, processes, channels and applications to deliver a consistent and integrated experience at a lower cost is the goal of every organization. To address these issues, organizations are leveraging service orientation in their business by:
Building shared IT Infrastructure to eliminate redundant infrastructure services
Creating shared-services enterprise platforms to provide the foundation for interoperability and composite applications
Enabling new self-service applications to lower the cost to serve customers, employees, and partners.
Service orientation provides business users with known services they can call upon and compose into business processes as needed—building systems that can adapt as the business changes.
Service orientation is not a new or radical idea. It has existed in IT environments for many years, though only in limited proprietary forms until recently. The emergence of key standards, particularly Web Services, has contributed to the creation of common service oriented environments that can more effectively interact with one another. This more standardized approach to service orientation holds the potential to solve diverse technical and business issues.
Ultimately, service orientation offers business and IT executives and system architects a means to escape from the inflexible and incompatible collections of IT systems and applications that most companies have acquired over many years. The difficulty and cost of getting legacy systems and software to interoperate, not to mention the challenges of modifying them to adapt to changing business requirements, have overwhelmed IT budgets and stifled innovation.
SOA aims to lower the interoperability hurdles by converting monolithic and static systems to modular and flexible components, enabling IT to focus on supporting the changing business needs, rather than spending time and money on perpetual upgrades or keeping a legacy computing environment limping along.
Among the key SOA terms we’ll use in the rest of this discussion:
Service: a repeatable business task, such as calculating sales tax, checking customer credit, or opening a new account
Service orientation: a way of integrating business processes as linked services, and the outcomes these services bring
Service-oriented architecture: an IT architectural style that supports service orientation
Composite application: a set of integrated services that support a business process across different applications built on SOA principles
The following figure illustrates the transition from today’s siloed environment to the service oriented model.
In this context, applications are considered (and are managed as) services. These services, along with Web Services and other system capabilities, are mixed and matched to meet the needs of a business process. The objective is to reduce or remove redundancies in both internally developed and commercial packaged applications and provide common services for common tasks (e.g., tax calculation). The result is a simpler IT environment consisting of reusable components that can be logically connected to deliver a business process. A key benefit is the ability to more quickly respond to market forces and business problems at a lower overall cost.
In service-oriented deployments, applications and business processes are presented as collections of standards-based components (or "services") each of which performs a discrete function. The self-contained services are loosely coupled and designed to be used in a message-based, event-driven manner, rather than being tightly coupled and hard-coded to function narrowly. The services themselves can either be built from scratch or created by wrapping existing business logic and exposing it by means of standard interfaces.
SOA builds on the principles of modular engineering seen in modern manufacturing—automotive, airline, or computer industry. For instance, in the automotive industry, a car is assembled from a modular set of components. The same is true in the computer industry. When a product (or business process) is modularized, the core pieces of its design are split up and integrated according to a formal architecture or plan. From an engineering perspective, design modularization has three objectives:
Accommodate future uncertainty
Make integration of complex systems manageable
Enable parallel evolution, innovation, and processing
Modularity accommodates uncertainty because the elements of the architecture may be changed after the fact to accommodate unforeseen requirements, without violating the design (or governance) rules of the architecture. In such an architecture, new modules or components may be substituted for older ones easily and at low cost.
Figure 2 (below) positions SOA architecturally and highlights these benefits.
Creating, Deploying, and Managing an SOA
Reaching the goals of an SOA requires more than technology. It requires systematic planning and management commitment. Embracing web services by itself does not create an SOA, though Web services are a critical technical underpinning. Similarly, SOA is an enabler, not an end in itself, and it requires time to be integrated into an organizations operating philosophy. It requires the emergence of tools and processes, and most importantly, organizational buy-in from both business units and IT. However, most organizations can begin to achieve and measure benefits immediately if they choose a staged approach rather than trying to move en mass to an SOA model.
Deploying an SOA—Rip and Replace vs. Focused Deployment
Some product and services vendors advocate a "rip and replace" approach to SOA deployment. Part of their sales approach is to identify all the potential benefits that an SOA can offer and recommend that the sooner an organization consolidates applications and systems across the enterprise and creates components and services, the sooner the benefits will flow.
Some degree of consolidation will likely save cost. However, integrating systems, constructing new services, and building composite applications should not be done all at once across the enterprise. It is a high risk technical and political endeavor to attempt a far-reaching transition across multiple business units and application environments.
Using the remodeling metaphor, trying to change the entire IT and business infrastructure to an SOA all at once is a bit like changing all the plumbing (pipes, fixtures, etc,) in a house while trying to live in it. Life gets very complicated while everything is torn up and little is of use until everything is complete.
An incremental approach is easier to manage and get right and will deliver immediate business benefit rather than just infrastructure change. Migrating an organization to an SOA is a long-term decision and needs to be driven by business needs, not architectural purity.
A Tiered Approach to SOA Deployment
A tiered approach simplifies change by enabling enterprises to take incremental steps toward a unified solution, rather than ripping the old out and replacing it with the new. Business metrics dictate the speed at which updates are made. Monitoring those metrics isolates the areas of greatest need, helping to maximize ROI and minimize risk.
The tiered approach is made up of three phases.
Phase 1: Discovery
The first step in SOA adoption is to prioritize the business process areas that impede agility most and offer the greatest business benefit. Consider what applications are not working or what business opportunities are worth investing in. Once these are identified and prioritized, you can draw the architectural plans, similar to the plans one would see during a building remodel. A key architectural design point is how much of the structure will be remodeled. We can remodel a systems project, an entire line of business system, or the entire enterprise itself.
The architectural plans for a remodel must take into account that others have to continue to use the system during the remodel. Rules and regulations, management plans, and other policies are drawn at the same time so the people, processes, and technologies involved can be regulated and managed in a successful, low-risk, and cost-effective manner—one that won't cause a complete work stoppage while construction is in progress.
Phase 2: Steamlining
In the next (and longest) phase, infrastructure and existing structures are tested and reworked to prepare for the new construction. Any changes that have to be made to existing systems are made in this phase. Services and software are developed, implemented, and tested. Security and management software is implemented, and the people, processes, sites, and other elements are also secured.
Phase 3: Transformation
In the final phase, the new building is maintained and managed by a highly effective system. Highly skilled people and detailed processes allow for constant change in a business model built on SOA. In highly effective SOA adoptions, the key element of success involves implementing business process changes that will have the greatest effect on the business—in terms of agility, performance, return, and risk.
This governance and development model yields the best return with lowest business disruption, avoiding rip and replace.
Throughout this three-phase process, it is extremely helpful to have a methodology available that can provide visibility across the enterprise and beyond organizational walls. While a single application area can begin to position itself technically for SOA, the significant value comes from cross-organizational sharing. Recall the tax example with 26 different tax modules. Reducing that environment to a single component that is shared and provides consistent, accurate results benefits the whole organization.
Building an SOA requires an understanding of the links between the key dimensions of the business—strategy, process, applications, and infrastructure. To get this understanding, organizations must get better visibility into the enterprise. They can either (a) obtain the technology and apply their own resources to evaluate their applications and infrastructure or (b) engage with a services vendor who has clear expertise in this area. Without this visibility, there is opaqueness to the application choices and infrastructure decisions that are made.
The Need for Planning
The evolution to SOA for a large enterprise requires systematic planning. This is typical of any large architecture revision or transformation project. The following table identifies the steps recommended in SOA planning. Later, we will review a deployment roadmap. The focus is on preparing the organization to embrace a services-oriented approach and how preparation requires identifying who makes decisions and what decisions need to be made.
The most significant element of deploying an SOA is by governance. An individual or team must be responsible for such deployment tasks:
Evaluating the technologies to be used
Selecting the projects to target and which to leave alone
Choosing the deployment methodology
Measure the return
For the most effective transformation, we recommend these steps:
Establish governance: Set up a cross-organizational team to manage the adoption and deployment of an SOA. Analyze the challenges in governing an SOA from development time to runtime, including policies, standards, guidelines, and boundaries
Create a road map: Learn the fundamentals of building an SOA strategy, beginning with the examination of current "as-is" business processes and "to-be" business processes. Ensure that there is visibility into business processes across organizational boundaries, where relevant.
Ensure alignment between process, applications, and infrastructure: Align the processes against the application infrastructure. The goal is to leverage the value of existing systems and integrate existing functionality into new applications with minimal investment.
Create a business case with phased execution: Translate the road map and alignment understanding into an actionable business. Calculate the benefits of code reusability, rapid integration, and real-time access to data and functionality throughout the enterprise.
Create an integration compatibility framework: Establish guidelines to ensure true interoperability across enterprise platforms and systems.
Create a tactical execution plan: Identify the key areas in an organization to target first for near-term ROI and subsequently for future projects. Include a plan to measure the resulting benefits.
Secure your environment: Take practical measures to ensure your secure SOA environment. Provide identity-oriented access to Web Services.
Guidelines to SOA Success
SOA is not a product/technology. It doesn’t come in a box or as a purchased service. SOA is an architectural principle expressed independently of technology. To transform a company’s architecture to a SOA model, a systematic roadmap is critical. We conclude our discussion with guidelines will help you build that roadmap.
Build the right team: Pick the right team members, including key architects from across the organization. Choose the right SOA architect, and understand the standards and technologies. Know what you don’t know and leverage partnerships for success. Finally, communicate, communicate, communicate. Publicize your results often (such as in quarterly announcements, and evangelize each success.
Organize for success: Create a center of excellence. Centralize program management, architecture, and planning, and organize infrastructure services, release management, and other processes. Define the delivery approach, standardize the delivery model, and build or integrate delivery IP.
Leverage organization and partner knowledge: Obtain executive sponsorship, and create partnerships with vendors who have experience and tools. Align your vision with the executive leadership team and other key senior executives. Focus on early, quick wins (make those successes visible), and demonstrate the project’s value to the organization.
Maintain flexibility: Do not design too far ahead of your business’ need or product capability. Keep infrastructure services light and modular. Your design components should remain abstract to ensure reusability. Limit the number of services to prevent proliferation that can lead to management issues downstream.
- - -
Anthony Gold is vice president and general manager, open source business at Unisys. You can reach the author at Anthony.gold@unisys.com