by David Groves
As you develop your IT architecture, it becomes clear that achieving real business benefits requires a fundamental change in the way you think about system design. In this first article in a series of three articles on Service-Oriented Architecture (SOA), BEA offers helpful tips, insights, and a Domain Model to help you both plan and develop a successful SOA implementation.
Albert Einstein once said, "The significant problems we face cannot be solved at the same level of thinking we were at when we created them." Applying this concept to today's enterprise computing, the challenges IT faces in delivering successful solutions to the business cannot be overcome without changing the way we think about IT. For developers and enterprise architects alike, SOA provides a structure for that change. The questions to consider are: How do we migrate to that new level? How do we prepare for such a fundamental change? How do we ensure we make that change in the most cost-effective, least organizationally traumatic way? The answers all begin with proper planning.
SOA is not a technology so much as it is a way of thinking. It is a bold agenda for infrastructure reformation and represents a culture shift in how we employ technology and work together. Its sudden popularity is less a product of hype than it is recognition of SOA as an evolution toward providing closer alignment between our business and our IT systems. And that evolution is stunning and far-reaching in its implications for the success of our enterprise.
Service-Oriented Architecture is an IT strategy that organizes the discrete functions contained in enterprise applications into interoperable, standards-based services that may be combined and reused quickly to meet business needs.
A service is a module of code, governed by a service-level agreement, that can be accessed via a standards-based interface. Each service represents a piece of functionality that maps explicitly to a step in a business process. Services can be written from scratch or mined by exposing modules of existing system functionality from previously "siloed" applications.
Over time, a catalog of services can be built up, allowing business functionality to be fluidly accessed and reused across many different systems. In this way, SOA can eliminate duplicate data, rekeying of information, and human error at the tactical level, while enabling strategic change. For example, SOA can be used to create a single view of the customer and, in the process, open up new possibilities for cross-sell and up-sell, thereby offering services for a more attractive user experience.
Part of the paradigm shift of SOA is a move from Application Infrastructure to Service Infrastructure. Prior to SOA, applications were organized into "silos" with point-to-point connections. SOA uses the same back-end application engines and middleware but leverages a converged Service Infrastructure Layer, as shown in Figure 1.
Figure 1. Service Infrastructure Layer
As you begin to implement SOA, use the following formula:
To be successful, SOA requires IT and the business to work together in new ways. As you plan for SOA, you will need to create an effective balance between technical and non-technical elements. To this end, BEA has developed a Domain Model (shown in Figure 2) to help guide you through planning the six key areas that must be given equal consideration to ensure a successful implementation.
Figure 2. The BEA Domain Model
The first three—Business Strategy and Process, Architecture, and Cost and Benefits—are a good place to begin the planning process.
SOA maps IT functions to your business processes, enabling business improvement over time. This mapping process is best expressed as follows:
It is important to establish a reference architecture for your IT organization. This is not a current state diagram, but a long-term vision to build against that should incorporate a two- to three-year architectural vision of where your business is heading. Take the time to define your architecture's guiding principles and policies, but be wary of making those guidelines an end to themselves. The flexibility and modularity of the SOA system should take first priority.
SOA is designed to hit the ground running, and it is important to prioritize the development of services in a cost-benefit order, so that your SOA shows ROI from the start. With careful planning, "start-up" costs can largely be absorbed into existing budgets. Over time, the reuse of service modules ensures a lower start-up cost for each new business application. Ensure measurability by setting your baseline at the beginning of your implementation, and avoid the need for backfilling down the road.
BEA's SOA Maturity Matrix (shown in Figure 3) will help you monitor your SOA rollout so you can check your progress against the different phases of development. This matrix is divided into three stages: Exploring, Expanding, and Exploiting. To assess your architecture's maturity level, you can use something like BEA's Online Self-Assessment Tool.
As shown in this figure, adoption is not generally an all-or-nothing approach. The typical adoption is a phased approach, which is why the other topics in this article, such as defining a long-term architecture and finding immediate business value, are so important.
The goal of this article is to offer you some pointers for organizing successful SOA planning, and our belief is that in taking this approach you can achieve the smoothest SOA rollout possible, moving your organization to the next level of development and business agility.
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.