Continuing in series of What is Service Oriented Architecture or SOA

Effective Planning :
As organizations begin to plan for their SOA journey, they must strike a balance between the technical and non-technical elements. SOA requires the IT organizations and the business to operate in new and ever changing manners. A framework is needed that addresses each of the above practices. The Service-Oriented Architecture Framework (SOAF) is comprised of jurisdictions, each with equal focus, which speak to the practices. The jurisdictions are interrelated and interdependent. The success of an enterprise SOA journey is dependent upon applying equal focus to each of the jurisdictions of concern.

  • Business Approach
  • Business Value
  • Architecture
  • SOA Legos
  • Projects
  • Relationships and Outcome Management

The explosion of these stream will begin by addressing three of these jurisdictions specifically business approach, business value, and architecture.

One of the goals of SOA is to provide better alignment between business processes and the IT functions that delivery those processes. This mapping enables process, and ultimately enterprise, improvement long term. In order to perform this mapping one must 1) Examine current enterprise processes and identify the required support functionality, 2) Cultivate functionality from existing systems and assets, give birth to new functionality where required, and guarantee that all services provide clear service-level agreements (SLAs) and 3) Exploit the enterprise services by orchestrating services into processes, measure the alignment to the enterprise strategy, and recognize maturity opportunities.

Business Value :
Providing the business case for an SOA journey is unlike defending traditional software projects. This is due to the realization of SOA benefits on an enterprise-wide scale. SOA provides opportunities for increased value that are excessively higher than those of traditional software efforts. This is accomplished through the optimization of business processes utilizing shared services. Innovation through SOA is a key differentiator in building a business case.
It is important to prioritize the development of services so that the SOA exhibits ROI from the start. The “on-ramping” cost can largely be immersed into existing budgets. The business case must account for these initial “on-ramping” costs yield benefits that accumulate and accelerate in the long term.
Initial SOA investment impact can be reduced by methodically selecting the appropriate capabilities to spearhead the SOA journey. Reuse of assets and capabilities will ensure lower on-ramp cost for new application. The IT funding model will change over time due to increased ROI. Traditional IT investment continues to increase as over time and as the number of capabilities increases, which is drastically different from the funding mode l for an SOA delivery mechanism. As the level of SOA adoption penetrates the enterprise and the level of reuse increase the investment level will begin to stabilize and increased at a predictable rate.
Architecture
Enterprises typically providing funding for and construct IT based upon each line of business. A Reference Architecture (RA) is essential for an enterprise SOA. This is a long term vision of evolution, two to three years, for the enterprise. An enterprise should spend time and effort in defining architectural guiding principles and policies. The guidelines must NOT be an endpoint unto themselves.
The RA must be service-centric, standards based and enterprise focused. Traditionally IT is obtained or developed as a response to the requirements of a particular domain within the enterprise and deployed for utilization by that domain. Shared capability approaches stemming from code or component reuse have failed due to the project-by-project focus of development efforts. Many times functionality is replicated through project-by-project development approaches due to the fact that each project addresses a specific set of requirements. A service-centric approach to delivery IT requires a shift in the development and deployment mindset. Capabilities are designed, developed, and delivered once for reuse at all levels within the enterprise. This leads to the SOA promises of reduced cost, fast time-to-market, and agility in order to respond to changing requirements.
and share information. There have been previous attempts to provide standards-based component models, for example Common Object Request Broker Architecture (IT projects are typically delivered through the most expedient approach that will satisfy stakeholder requirements. This often leads to the proliferation of technologies throughout the enterprise. This leads to serious integration issues when the technologies have to interoperateCORBA) and Distributed Component Object Model (DCOM). These types of models experienced failure due to the implementation technology required and supporting standards stalling in development. XML (Extensible Markup Language), Web Services, and UDDI (Universal Description, Discovery and Integration) are the foundation for a standards-based SOA for supporting re-use. The technology for supporting this approach is readily available and truly platform agnostic.
As mentioned earlier traditionally IT has been delivered on a project-by-project basis within the individual lines of business of an enterprise, the response of many enterprises to this approach has been to institute enterprise architecture organizations. These organizations were focused on technology selection for the enterprise and were not authorized to enforce other recommendations. An enterprise SOA requires that organizations of this type be provided with the authority required for full lifecycle management of the SOA, a standards-based mechanism for defining, deploying, monitoring, and managing functionality at the appropriate granularity and visibility levels. The required provisioning ecosystem must be constructed from service-centric enterprise architecture (EA) which contains the appropriately enforced governance principles and policies.

Tomorrow : Requirements for a SOA Strategy

Other useful tips on Java, JEE/J2EE
Del.icio.us Digg! My StumbleUpon Page