Successfully Planning for SOA - Part 1

Successfully Planning for SOA : Taking a strategic approach to realizing SOA (Part 1) by David Groves

As you continue to develop your IT architecture, it becomes clear that the route to achieving real business benefits requires a fundamental change in the way you think about system design. In this article on services-oriented architecture (SOA), I'll share with you helpful tips, insights, and a domain model to help you plan this change, and ensure the success of your SOA implementation.

SOA: A New Way of Thinking

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." In today's enterprise computing, this suggests that the challenges IT faces in delivering successfully to the business cannot be overcome without changing the way we think about IT. For developers and enterprise architects alike, services-oriented architecture SOA provides a structure for that change. The question then becomes: How do we migrate to that new level? How do we prepare for such a fundamental change? How do we do so in the most cost-effective, least organizationally traumatic way possible? The answers begin with proper planning.

SOA services-oriented architecture is not so much a technology as it is a way of thinking. It is 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 services-oriented architecture as an evolution towards providing closer alignment between our business and our IT systems. Also, that evolution is stunning and far reaching in its implications for the success of our enterprise.

What Is SOA, Really?

Service-oriented architecture is an IT strategy that organizes the discrete functions contained in enterprise applications into interoperable, standards-based services that can be combined and reused quickly to meet business needs.

A service is a module of code, governed by a service level agreement, which 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 either be written from scratch or mined by exposing modules of existing system functionality from previously "silo-ed" 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 services-oriented architecture can eliminate duplicate data, rekeying of information, and human error at the tactical level while enabling strategic change - for example, by creating a single view of the customer, and in the process opening up new possibilities for cross-sell, up-sell, and offering services for a more attractive user experience.

New Infrastructure Paradigm

Part of the paradigm shift of SOA is a move from application infrastructure to service infrastructure. Prior to SOA services-oriented architecture, 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 (Figure 1).

Implementing SOA

As you begin to implement SOA, use the following formula:

• Think Strategically, Execute Tactically: Start by realizing a single-core process with simple, agnostic services that span multiple business units
• Top-down: Identify the services required to support this single-core process
• Bottom up: Identify functions in existing systems that could be exposed as services to support this process
• Infrastructure Services: Identify common supporting functionality requirements
• Expand Slowly: Technically challenging projects may be undertaken concurrently after initial projects have proven successful
• Build an Application Catalog: On a project-by-project basis, harvest and reuse service modules, thereby reducing your cost curve over time
• Focus on Benefits: Phase projects in order of ROI, in stages that include plateaus for consolidation

Using the BEA Domain Model To Plan Effectively

• To be successful, SOA requires IT and the business to work together in new ways. As you plan for services-oriented architecture SOA, you will need to create an effective balance between the technical and nontechnical elements. To this end, BEA has developed a domain model (Figure 2) to help guide you through planning the six key areas that must be given equal consideration to ensure a successful implementation. The first three (Business Strategy and Process, Architecture, and Cost and Benefits) are a good place to begin the planning process.
• Business Strategy and Process: Mapping services-oriented architecture SOA to Your Business

SOA maps IT functions to your business processes, thereby enabling business improvement over time. This mapping process is best expressed as follows:

Analyze: Study processes and identify the supporting functionality required
Develop: Harvest functionality from existing IT assets, develop new functionality, and ensure that all services have clear service-level agreements.
Utilize: Orchestrate services into processes, measure alignment with strategy, and identify opportunities for optimization

Architecture: Defining Long-term Needs
Establish a reference architecture for your IT organization. This is not a current state diagram, but a long-term vision to build against, which 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 unto themselves. The flexibility and modularity of the services-oriented architecture SOA system should take first priority.

Cost and Benefits: Demonstrating Immediate Business Value
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 services-oriented architecture 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.

Using the SOA Maturity Model
BEA's SOA Maturity Matrix will help you to monitor your services-oriented architecture SOA rollout, thus helping you to monitor 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 may use BEA's Online Self-Assessment Tool (www.bea.com/soa).

Conclusion
It has been my goal in this article to offer you some pointers for organizing successful services-oriented architecture SOA planning, and my belief is that in taking this approach you can achieve the smoothest SOA rollout possible, and move your organization on to the next level of your development and business agility. For more information on BEA's SOA solutions, please visit www.bea.com.

Source: http://soa.sys-con.com