The power of an SOA is in its ability to enable business agility through business process integration and reuse. SOA achieves this in two ways: By encouraging solutions organized around reusable services that encapsulate functional capabilities separated from their implementations and by providing facilities for managing coupling between functional capabilities. Modeling can be used to bridge the gap between business requirements and a deployed services-based solution. SOA models raise the level of abstraction to allow you to focus on business services. Model-driven development approaches can be used to generate SOA implementations, by using platforms such as Java™ 2 Platform, Enterprise Edition (J2EE) or IBM® CICS® that meet business functional and nonfunctional objectives while enabling business agility.
The term service-oriented architecture (SOA) has several connotations. Practitioners commonly use SOA both to define an architectural style and to describe a common IT infrastructure that enables IT systems that are built using that architectural style to operate. These are useful technology-focused perspectives, but, by themselves, they are not enough.
To achieve its potential, an SOA-based IT infrastructure (hereafter, referred to as simply SOA) needs to be business-relevant, thus driven by the business and implemented to support the business. We need a way of designing SOA solutions that are connected to the business requirements that they fulfill. This is hard to do if the business requirements are given as a simple list of requirement items and the level of abstraction of the SOA is captured in several XML documents that describe a collection of Web services.
What we need is a way to formalize business requirements and raise the level of abstraction so that SOA can more closely resemble business services and how those services might meet business goals and objectives. This ties the deployed solution to its intended business value. At the same time, we need a way of isolating business concerns from the evolving SOA platforms that support them.
Modeling and model-driven development (MDD) can help achieve these goals. Models allow us to abstract away the implementation details and focus on the issues that drive architectural decisions. To some extent, the approach we will be describing applies one of the fundamental principles of SOA to the development of SOA solutions: separation of concerns and loose coupling. Here, we cleanly separate the tasks and responsibilities of business analysts from those of IT staff members.
Usually, business analysts will be focused on business organizational and operational requirements necessary to meet business goals and objectives that achieve some business vision. Often, they are not concerned with (nor sufficiently skilled to deal with) IT concerns, such as reuse, cohesion and coupling, distribution, security, persistence, data integrity, concurrency, failure recovery, and so forth. Further, business process modeling tools don't often have the capabilities necessary to address these concerns, and, if they did, they probably wouldn't be effective tools for business analysts.