Successfully Planning for SOA: Long-term SOA Planning

by David Groves
02/07/2006

Abstract

In the first article of the Successfully Planning for SOA series, I discussed what Service-Oriented Architecture (SOA) is and how to ensure it delivers value to your business. I paid particular attention to the Business Strategy and Process, Architecture, and Cost and Benefits segments of the Domain Model. The second article, discussed how to create an effective SOA roadmap. In this final article, I review the remaining three segments of the domain model: Building Blocks, Projects and Applications, and Organization and Governance, focusing on how to integrate them into your long-range project planning.

Long-term SOA Planning

The BEA SOA Domain Model, shown in Figure 1, is a useful tool to help guide you through your SOA planning strategy. The six key areas highlighted in the diagram should be given equal consideration to ensure a successful implementation.

Figure 1
Figure 1. The BEA Domain Model

The previous articles in this series examined the first three—Business Strategy and Process, Architecture, and Cost and Benefits. However, planning for SOA does not end as you begin implementation but continues throughout each phase of your SOA program.

The final three segments of the Domain Model are especially useful to you in ensuring ongoing evaluation and flexibility of your program as you move through each iterative and incremental stage. Effective evaluation of your progress as you proceed will allow you to "course correct" if you find you are off the mark in delivering successfully in terms of business value. The rest of this article examines each of these segments in more detail, showing how they contribute to long-term SOA planning.

Building Blocks: Leveraging (and Reusing) Your Assets

SOA relies on successfully institutionalizing a culture of reuse. The building blocks of SOA are discrete, reusable services and architectural elements that can be combined to form composite applications and service infrastructure. As each building block is implemented, it is added to your overall catalog of SOA capabilities. As that catalog grows, less new code and service infrastructure needs to be developed for future projects to be delivered, maintenance costs are reduced, and ROI is demonstrably and steadily increased.

Defining a service clearly and being able to deliver it into live deployment in a consistent and repeatable manner is central to the success of your SOA program. A service can best be defined by three elements:

  • Service implementation: The implementation of a service is composed of the actual code, application interface, or other technology asset containing functionality that will be exposed via this service.
  • Service interface: A service interface provides a standards-based means for the users of a service to access its functionality according to the contract it offers.
  • Service contract: The service contract specifies the purpose, functionality, constraints, and usage of a service. Examples of contract details would include security requirements, speed of response, throughput, and availability.

Services can either be exposed from existing applications or they can be built from scratch, but which services should you implement first? Simple services at the core of your organization are best, starting with the most business-unit-agnostic services and gradually working toward more business-unit-specific functionality. This approach allows your teams to become accustomed to the process of building and reusing services without becoming preoccupied with complexity. Likewise, you should begin with the technically easy services and work your way toward the more technically challenging. Some of the earliest services may be infrastructure services such as logging, auditing, error handling, and similar functions.

Projects and Applications: Implementing Your SOA Roadmap

The service roadmap begins with identifying the IT projects and functionality that already exist in the enterprise's portfolio. Next, the enterprise needs to develop and prioritize the projects that will complete the architecture, as well as individual projects that deliver business value.

Begin with an understanding of the state of existing applications and projects to determine where existing functionality can be reused. Functionality that is wholly specific to the application in which it resides, or the project for which it is being developed, may be safely deemphasized.

It is important to capture the following:

  • Current application functionality, services, and dependencies
  • Granularity and capability of existing services
  • Interdependencies between current applications and planned or in-progress projects, and related development and maintenance challenges
  • Current common service usage
  • Costs and other metrics relating to application development
  • Information accessed and delivered by applications
  • Data models, transformation, and translations used in applications
  • Workflow and process flow involved in applications
  • Use of services such as single sign-on, logging, error and exception handling, monitoring, and notifications
  • Service-level agreements, quality of service, and related non-functional business information
  • Details of current delivery milestones and immediate project timeframes

These data will help you build a good picture of your current projects and applications, and help you identify common functionality.

Organization and Governance: Setting Expectations

SOA requires cultural change in how people work together. It is necessary to establish closer coordination between IT functions/divisions, to facilitate a focus on delivering business value across the board, rather than simply within a functionality silo.

Two main themes are fundamental to being successful in this domain. First, it is essential to provide adequate education so that the team understands not just the technical aspects of SOA but also the cultural changes required. Organizations that do not deliver these key messages will struggle to ensure they are acted upon.

Second, Organization and Governance is about considering the adoption of SOA as an enterprise change program, not just the latest technical directive. Getting and retaining buy-in from senior executives will help different divisions of the organization to operate seamlessly together, and ensure that you have sufficient authority to obtain compliance as well as to evangelize.

Different organizations establish Organization and Governance in different ways to suit the maturity and direction of the enterprise. A centralized, top-down organization is often most effective for initial SOA implementation, followed by a federated or partially-federated governance, and finally by a more autonomous hierarchical system. This organization can take a holistic and impactful view of structure, funding, operational processes and tools, standards, skills change management, and guiding principles. It will also help to decide upon, institute, and enhance processes around the following SOA FAQs (among others):

  • Who defines and modifies systems?
  • Who is allowed access to the services?
  • What quality of service must we provide?
  • Who will pay for building the services?
  • Who will pay for service infrastructure?
  • How will the interdependencies of services be managed?
  • How do we expose services to outside parties?
  • How will we measure the success of SOA?

Finally, the Organization and Governance function will ensure that progress, and business value delivered through your SOA program, is measurable. If metrics are not being achieved, cost-effective corrective action can be taken.

Summary

My goal in this series of articles has been to give you a clear guide for planning and deploying SOA within your organization using BEA's Domain Model as a framework for planning, implementation, and review. This article has focused on long-term planning, pointing out how SOA relies on successfully institutionalizing a culture of reuse, why it is important to understand your current set of IT projects so you can capture common functionality, and finally, how the Organization and Governance models should be established. For more information on the Domain Model and BEA's solutions for SOA, visit the BEA SOA Resource Center

David Groves , Americas SOA Practice Lead, BEA Systems Worldwide Consulting Development, has 11 years of industry experience covering IT strategy, enterprise solutions consulting, program management and delivery methodology.