Introduction

According to industry research studies by Saugatuck Technology, Gartner, and others, many large enterprises have adopted or will adopt Service-Oriented Architecture (SOA) as their strategic direction, regardless of the underlying technology.

In a recent study, Saugatuck Technology found that "SOA is experiencing slow but steady adoption among large and mid-sized enterprises."¹ (See Resources.) The study includes 40 in-depth interviews with senior IT executives (users) and application architects working at large and mid-size enterprises and notes that "37% of the senior IT executives...interviewed indicated that their firms are currently in a limited or full production stage of SOA deployment."¹

While noting that Gartner predicts that 80% of all new applications in the next two years will be SOA based, the Saugatuck study shows user expectations are optimistic and indicate "....that nearly 67% of users will have a limited or full SOA production environment by 2008...". ¹Other Saugatuck research data suggest that a figure less than 45% might be a more realistic range of mid- to large-size enterprises in limited or full SOA production by 2008." In any event, 45 to 80 percent adoption of SOA by mid-to-large size enterprises within the next year is significant.

More complexities surface as SOA is applied to more complex tasks. Complex tasks involve various types of integration templates to address different business challenges and needs, such as legacy integration and transformation, applications, packaged application integration, composite business services, and custom development.

As an architect, you often play a lead role in bridging the business and IT requirements on an SOA project. This article discusses some key success factors and lessons learned while moving from traditional development to SOA.

Back to top

Assess organizational readiness

An architect must deal with many misnomers and challenges in an SOA project. One major challenge is organizational readiness. But, before addressing this challenge, it's important to determine what business value SOA can bring to the organization and properly plan for the transformation.

Many SOA projects are initiated simply because the customer wants SOA in their long-term strategy, although they haven't actually quantified the business benefits SOA would bring or identified which business areas can be improved. In turn, ill-defined delivery schedules and scope are a result, with subsequent poor customer satisfaction when the client’s expectations are not met. False expectations can result if, during the early sales cycle, participants don't have adequate SOA knowledge to determine the scope of the work or to educate clients prior to signing the contract. Clearly, it's equally important that the delivery team and the client thoroughly understand SOA.

Opinions on SOA generally fall into one of two camps: SOA is the best thing since sliced bread or SOA is nothing but hot air. These are extreme positions, and SOA actually rests between the two. Unfortunately, as an architect you might deal with clients and development team members who espouse one of these two opinions and are, consequently, either overly positive or negative. Overcoming the extremes requires substantial cultural transformation, and education, as part of the SOA development process.

"SOA is nothing new—all hype, no substance."

To overcome negative fallacies and counter the nonbelievers, you can point out that SOAs have been around since the early 1990s and have made significant progress. It's also important to remember that today's Web services standards already have far broader industry and user acceptance compared with some other technologies, such as CORBA, which has helped SOA to gain wide acceptance.

"SOA is a revolutionary paradigm shift and a panacea."

For the overly positive camp, you need to point out that SOA is more evolutionary than revolutionary. There is progress in doing similar things as before, only better. That's not a paradigm shift, but is an important shift nevertheless. SOA evolves an enterprise’s approach to distributed computing and improves on its implementation, but SOA doesn't represent the disruptive change that would qualify as truly revolutionary.

SOA is particularly useful in heterogeneous environments that are subject to frequent changes in the business environment. You need to first verify with the client whether their IT environment is homogeneous. If so, then SOA is probably not for them. Is high performance more important than loose coupling? Would the client rather tightly control the consumers of IT functions in the organization in order to squeeze every last bit of performance out of the technology? SOA isn't right for them then, either. Even for companies that can benefit from SOA, don't assume that the only architecture they need will be SOA. After all, SOA works well with other architectures, and SOA by itself doesn't solve information and semantic integration challenges. Companies need additional technological approaches to solve these more challenging problems.

Before initiating an SOA project, these questions should be answered:

• What does SOA really promise to the business?
• Why should spending new money on SOA improve the organization's bottom line?
• What benefits will SOA bring into the business, and what should an organization do to ensure their investment is paid back in the future?

One technique you can use to help derive business long-term and short-term strategy, heat maps, and KPI values is Component Business Modeling (CBM). Remember the promise of SOA—building an IT infrastructure flexible enough to respond to the needs of the business. With such a broad and strategic value proposition, it's easy to accept that SOA is inevitable. But, every organization needs to carefully plan for the transformation from traditional development organization to a service organization by:

• Constantly staying open-minded
• Being above internal or external politics
• Focusing on the "big picture"

Often, these are the toughest challenges of a project.

Moving an organization towards service transformation takes time, people, processes, methods, and tooling support. It is a long-term architectural strategy to meet business goals and requires incremental adoption to reach the benefits. Knowing where the organization stands before starting the project, and the level of readiness, is important. To determine the scope of and effort required for a project, you should verify organizational readiness prior to making any recommendations. An SOA road map can help strategize the incremental plan. Unfortunately, not all SOA projects keep the big picture in mind.

Back to top

Get stakeholder support

An organization is made up of people who all have their own pain points, and play a critical part in the SOA transformation. "Business advantages" means different things to different people. An architect often has to deal with various types of people in the end-to-end development process, whether it's SOA or non-SOA.

We all know stakeholder support is critical to the success of any project, but it becomes much more important in an SOA project. SOA initiatives should be driven by business people, with business goals in mind, so they require more business stakeholders’ involvement than traditional development projects. Unfortunately, some of the business advantages espoused by technical people on SOA projects aren't business-related at all, but are technical advantages whose effect will only be felt by the IT department.

What sort of things can be considered business advantages? Different stakeholders will view SOA differently, depending on their commitment or responsibilities. Table 1 shows an example.

Even though different users have different needs in SOA, they all play an important part in the SOA transformation process. It's important to know the different users and to build a service ecosystem, which involves participation from all organizational roles. It is like a food chain—there is interdependency and a delicate balance among all players. In an SOA project, architects need to gain support from the high-level stakeholders (board directors) for project funding and sponsorship, as well as cooperation from the middle managers to gain their business knowledge, resources, and specialties. The SOA architect will definitely need the support of office works as well. They are often the ones who execute the operations and have the most detailed business operations knowledge, which is critical to successfully designing and defining the appropriate services at the appropriate level of granularity.

Different users also require different SOA education to fulfill their particular needs, so it's important to consider user training in your project. This does not have to be a massive undertaking. Different users may receive SOA training at different stages—preferably before becoming involved in their actual SOA efforts. For instance, board directors will have their education earlier than other user groups, since they need to support the overall strategy and funding. Their training will be at a more theoretical level.

Developers should receive far more practical training later on, so they can apply the knowledge immediately when the SOA development cycle begins. This process is important, and should be ongoing. You should advise the client to plan for education activities in the development process. Failing to do so can increase communication difficulties and result in poor deliverables.

Often, the most difficult part of any development process is dealing with people and politics, especially with multiple players such as vendor teams, a solution team, existing infrastructure supporting teams, and so on. They have different SOA maturity models, knowledge, and agendas. If the political agenda gets in the way, it creates unnecessary work and problems. Most often, it is the underlying cause of any failed project. To help minimize some of these risks, you can:

• Make sure you have management (C-level executive and board of directors) support.
• Build a strong partnership between the solution and client teams.
• Build a central knowledge portal (repository).
• Establish well-defined roles and responsibilities.
• Manage a good project plan.
• Establish an issue identification/tracking/resolution mechanism.

SOA brings business users closer to IT users, and vice versa. Bridging the differences and balancing the dynamics between these two groups, to ensure that IT deliverables are exactly what the business users requested and needed, is essential for the success of an SOA project.

Back to top

Transform the process in stages

A successful SOA implementation requires that an organization substantially transform their process to move from a traditional function-oriented, built-to-last, and long-running development cycle to a process-oriented, built-to-change, and incremental build-and-deploy process. Traditional development, in general, is aligned to application silos, is tightly coupled, and is structured using components and objects as building blocks. SOA development presents orchestrated solutions that are loosely coupled, using services as their building blocks. It's important to recognize the differences and establish a process to support the transformation.

For many companies, especially larger ones whose IT organizations have a certain critical mass, it's not a question of whether to build an SOA but of when. We're nearing the tipping point for Web services adoption in the enterprise. Companies are realizing both the tactical and strategic benefits of Web services and SOA. As they implement an increasing number of useful services in the enterprise, companies will be forced to tackle more significant architectural challenges. As soon as we cross that nebulous point, the sheer volume of services on the network will force companies to tackle SOA, one way or another. We won't need SOA everywhere, and it won't solve every problem. Many companies will still build poor, ineffective SOAs to be sure, but build them they will. It is important to tackle process transformation in stages, especially from an architectural perspective.

Transforming a process in multiple phases ideally should range from a layered architecture, to component architecture, and eventually, to SOA. Phasing provides the benefit of minimizing risks and allowing reuse of the existing architecture. The initial stage is to set up a layered architecture by:

• Creating an SOA architectural framework (guidelines, standards, and so forth) to guide implementation projects
• Assessing the existing architecture to support the SOA target state using that architectural framework
• Applying component architecture framework to in-flight projects where the architecture is not hardened

In the component architecture stage, you can apply SOA to a small project and demonstrate component reuse while minimizing the risk of new architecture adoption. A pilot project helps to test the waters. With this experience, the project teams can then apply SOA to larger projects and realize the reuse benefits identified in the IT strategy.

You can then establish an SOA governance framework by:

• Defining changes for the service development life cycle
• Defining an IT organizational model to sustain an SOA environment
• Establishing guidelines for service oriented business applications
• Identifying any new technology requirements

As we know, the major benefit of SOA is that it allows an organization to achieve a flexible and responsive business model, which responds with flexibility and agility to rapidly changing business needs. To achieve flexibility and innovation, an organization needs to break its business processes into manageable parts. It must allow applications to become increasingly modular, and simplify the underlying IT infrastructure required to manage and support changes in the business. In the journey to reach this model, it is important to define the right approach, including a governance structure to support SOA, as early as possible and with all the business objectives, not the technical features, in mind.

Determining a pragmatic balance between technical efforts and time to market is critical, since cost can play a part in the SOA development process. You also need to value ongoing flexibility over a one-time efficiency gain, and invest (where useful) in a diversified portfolio of applications to enable asset reuse. Investing in a diversified portfolio of applications, not a single packaged application or technology, reduces risks and creates opportunities to improve the business on many fronts and scales.

From the business process perspective, it is recommended that you:

• Centralize business processes across business units.
• Let partners and valued customers fulfill the service consumers’ needs, such as reducing manual processes, reducing costs, and increasing visibility into performance.
• Actively manage risk to balance competitive advantage and system performance.

If the organization has existing enterprise architecture, you need to examine its usability to see if it's based on SOA and open standards, and make the necessary modifications.

Whenever possible, it is also important to exploit patterns available today (for example, IBM's Patterns for e-Business), and use modern development tools to simplify business integration project development. See Asset-based support for more information.

Create a plan

An SOA governance and adoption plan is critical to the success of an SOA project. The process needs to be established as soon as possible, with long-term enterprise business values in mind, and be carried out incrementally. Organizational readiness plays a major role, and can be determined using the enterprise's service maturity level based on Service Integration Maturity Model (SIMM). Early adoption of an SOA reference architecture and governance model will help streamline and expedite the process, aiding your overall SOA transformation success.

SOA is architecture, and architecture is a set of best practices and patterns. Or, in other words, SOA is a discipline. You need a plan, as well as the required expertise. The best approach to building an SOA is to combine a bottom-up approach of building services that solve integration problems with a top-down, architectural approach. The architectural approach provides process-driven services that enable business agility, and goal-service modeling techniques, to make sure you address the long-term business goals. (See Service-Oriented Modeling Architecture (SOMA) in the next section for more information. )

Back to top

Asset-based support

In today's development process, we deal with more and more heterogeneous processes, tooling, and methods. The complexities in software development have grown substantially, compared to five or ten years ago, and are only going to increase. As an architect, you need to constantly consider new changes, adapt to challenges, and provide adequate solutions—all of which require a huge investment in learning. There often isn't enough time to get hands-on training before starting on a project. When possible, take advantage of prebuilt (proven and tested) assets, and minimize developing a solution from scratch.

Asset-based development support includes methods, patterns, guidelines, principles, previously built project profiles, and a repository. In the SOA world, this is especially important since the strength of SOA is reuse that lets consumers subscribe to the services that meet their needs.

Leveraging lessons learned, by using established services and applicable assets when defining a solution, will help to:

• Achieve the reuse.
• Reduce the development effort.
• Minimize risks.
• Increase productivity.

Unfortunately, not all projects take advantage of asset reuse. Often, a project is started without researching what's available and so once again the wheel is reinvented. SOMA has been recognized as the de facto method (or capability pattern) to support SOA development.

Service-oriented modeling and architecture consists of three general steps—identification, specification, and realization—of services, components, and flows (typically, choreography of services). See "Service-oriented modeling and architecture" in Resources for more information. The next release of SOMA extends to support end-to-end SOA development from realization to implementation.

SOMA introduces eight new disciplines and some other capability patterns. Among the eight disciplines, leveraging existing assets is addressed throughout the life cycle of the SOA development process, which in turn addresses the need for asset reuse. At the end of each phase (identification, specification, realization), a task called "service factoring and rationalization" is called out to support the refactoring process. The task makes sure we confirm what we have and determine which assets, including services, can be carried forward to the next stage. This is an iterative process, designed to provide quality checks, reduce risks, minimize waste, and maximize reuse.

SOMA also introduces capabilities patterns, such as Asset Consumption, Asset Construction, and Asset Governance, to address asset-development life cycle requirements (see Figure 1). After an asset is constructed, a certification process will take place to ensure the quality of the asset, and certify the reusability (which is part of the asset governance process). The certification process will manage the lifecycle of the asset development process.

As a general rule, prior to creating the solution you should examine what is available first, and make the best use of the existing assets (methods, best-of practices, guidance, and so on). Activities and tasks, including quality walk-throughs, should be included in the project plan. Depending on how much you can reuse assets, these efforts will definitely help minimize risk, reduce development cost, and increase the team’s productivity.

Back to top

Tooling support: from traditional development to SOA

SOA has put additional requirements on tooling, ranging from business modeling, SOA development, SOA testing (interoperability, composite business service, and BPEL testing), service metering and monitoring, to service deployment.

One tooling issue is the heavy footprint of most of the third-party vendor tools. The average installation process itself is very complex, time consuming, and often requires large system capability to run the software.

Perhaps the most challenging task is getting tools from multiple vendors to work together. Products don't always integrate well with others, impacting developer productivity and project schedule. Customer automation of scripts for installation, configuration, and testing (at a minimum) are recommended so that these processes can be expedited and repeatable. Procedural documentation can also help in this area.

Tooling by itself cannot meet the needs of all the different users (business analysts, designers, architect, developers). For example, modeling for business requirements, modeling for business optimization, and modeling for execution will require different sets of knowledge and skills, and perhaps additional tools.

In summary, tooling support requires education and training, which should be in the project plan as early as possible. Product selection, generally speaking, occurs before development begins. You must research what is available in the market and provide product comparisons of pricing, functions, supportability, training, and ease of use. You might need to make recommendations based on the customer's environment, business needs, and long-term objectives. Ultimately, it's up to the customer to make the decision. In any case, the final decision should be documented as the architecture decision.

Back to top

Summary

Along the path to an SOA solution, architects face a variety of challenges. It's essential to recognize that success requires multiple levels of transformation, and support, with the organization, people, process, assets, and tooling. When designing and managing a large SOA project, it's important to staff with software product experts, strategy and change consultants for organization change management, and SOA solution architects.

Gaining support from executives and all key stakeholders is equally critical. Managing customer expectations, and constant scope creep, requires a dedicated team of project managers and timely use of the process change procedures. Creative techniques may sometimes also be employed to share additional workload with the customer.

To develop an effective education plan, you must understand the customer development culture, and current processes and skills available. Customer resource availability, of people and machines, is critical to projects with tight timelines. Issues or delays must be quickly escalated to the customer’s highest executive sponsors.

To increase productivity and shorten development cycles, exhaustive automation across the board is also important.

To reduce development risks and cost, and greatly improve the chances of SOA success, use existing assets, including people, best practices, standards, programs, and documentation.

Back to top

Acknowledgements

The author wishes to acknowledge the valued input and feedback of Dr. Ali Arsanjani.

Resources

Learn

• ¹ "SOA Reality Check: Three Waves of Adoption through 2012" (Saugatuck Technology, Dec 2006) reports on interviews with dozens of senior IT executives to find out what they are—and are not—doing with SOA.
  
  
• ²Gartner, Inc. Predicts 2004: Web Services, by Whit Andrews (Nov 2003)
  
  
• Learn more about component business modeling.
  
  
• Executive strategy report: "Technology is not the trump card in mass affluent wealth management game" by Shyarsh Desai, Daniel Latimore and Greg Robinson. (PDF; Sep, 2003)
  
  
• Read Kerrie Holley's blog: Client Insights, Concerns and Perspectives on SOA.
  
  
• Understand the key activities for the analysis and design required to build a Service-Oriented Architecture (SOA): Read Ali Arsanjani's "Service-oriented modeling and architecture: Learn about the foundation of SOMA—IBM's methodology for SOA enablement," (developerWorks, Nov 2004).
  
  
• "Building SOA applications with reusable assets, Part 2: SOA recipe reference example" by Clive Gee and Eoin Lane. (developerWorks, May 2006)
  
  
• "Toward a Pattern Language for Service-oriented Architecture and Integration, Part 1: Build a Service Ecosystem" by Ali Arsanjani, Ph.D. (developerWorks, July 2005)
  
  
• "Increase flexibility with the Service Integration Maturity Model (SIMM) " by Ali Arsanjani, Ph.D. and Kerrie Holley. (developerWorks, Sept 2005)
  
  
• "Seven Fallacies of SOA" (zapthink, Aug 2004), by Jason Bloomberg, discusses SOA.
  
  
• Get unique resources for SOA and IT architects in from one convenient location: developerWorks e-kits.
  
  
• Get help for your next project at Rational Pattern Solutions.
  
  
• Downloads to make your SOA journey easier: Trial versions of Rational software products.
  
  
• In the Architecture area on developerWorks, get the resources you need to advance your skills in the architecture arena.
  
  
• More of an expert in SOA? Check out the SOA and Web services area on developerWorks.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

Get products and technologies

• Check out the IBM SOA Web site.
  
  
• Download IBM product evaluation versions and get your hands on application development tools and middleware products from IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

Tina is a certified executive IT architect for IBM Global Business Services Enterprise Architecture and Technology SOA and Web Services Center of Excellence. She has more than 20 years in engineering, with experience in architecting solutions for package implementation, custom applications, and SOA implementations. Tina has a good working knowledge of J2EE, Web services, and OSS technologies, and a strong understanding of the major architectural IT domains, including applications, data, processes, and infrastructure. As part of the Service-Oriented Modeling Architecture (SOMA) core team, Tina is currently defining the next release of SOMA. She also acts as the SOMA advisor to help actual SOA field engagements and ensure quality delivery. Tina has written many technical papers, spoken at technical leadership conferences, and is actively involved in many IBM Academy studies to help research and develop new ideas.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Assess organizational readiness
• Get stakeholder support
• Transform the process
• Asset-based support
• Tooling support
• Summary
• Acknowledgements
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers