Continuing in series of What is Service Oriented Architecture or SOA

Requirements for a SOA Strategy

In order to realize the benefits of SOA there needs to be a balance struck between the long-term enterprise goals and the short-term, immediate, business requirements. Institutionalizing a series of operational, design, budgetary, operational, and provisioning practices in the initial stage of an SOA journey can assist in establishing and maintaining this balance. The deployment of cultural changing disciples must be performed in an incremental and iterative manner. This will allow for the required organizational learning curve. An SOA roadmap provides an iterative and incremental mechanism to continuously describe an organization’s journey as they progress. A path for the SOA journey has three critical characteristics:
Scope:
A SOA roadmap should be comprised of six distinct, but interrelated and interdependent, jurisdictions. The fundamental success of an SOA effort is directly related to the successful execution in each of these jurisdictions. An organization’s SOA roadmap should define and delineate the boundaries of the SOA effort as well as establishes a flexible timeline for achieving their SOA objectives. The SOA objectives of an organization should be divided into phases that are manageable and that can be iteratively and incrementally realized.

Quality:
A SOA roadmap will remain relevant for the life of the SOA effort by being iterative and incremental as well as through the application of a “Mature & Change” process at each major exit-point, milestone.

Maturity:
 A SOA roadmap is an “organic document” that is continuously describes organizational experiences and lessons learned. As the SOA effort matures, along the SOA roadmap, it reaches higher levels of complexity and sophistication, but does so in a govern fashion. An SOA roadmap is created by first assessing the current capabilities and disciplines of an organization and their applicability to SOA.

Building a SOA Roadmap
Creating a SOA roadmap involves four phases: Planning, As-Is Assessment, End goal, and Definition.

Planning
A SOA effort is organized and defined in this phase. The SOA stakeholders are incorporated into the process through various communication avenues and briefing, and a mutually agreed upon priorities and constraints are established. The appropriate level of clear communication is essential in this phase due to the involvement of representation from across the organization. The outcomes of this phase include:

  1. A defined scope for the SOA
  2. Establishment of boundaries and alignments with peer IT efforts
  3. An illustrated business case to justify the SOA effort
  4. Defined current and future business objective alignment

As-Is Assessment
The establishment of metrics and measures of the current state of affairs is conducted in the assessment phase. Current services and capabilities need to be identified as a potential “on-ramping” point for the SOA effort. Pilot projects need to be identified as well in this phase. By interviewing and questioning the SOA stakeholders an organization should examine the jurisdictions of concern. The “as-is” state of each of the jurisdictions of concern needs to be analyzed, base-lined, and validated. A mechanism needs to be devised to assemble the examination of the following:
  1. Business Approach: Business strategies and processes are examined beginning at the top level of the organization and working downward into each level and area of the organization.
  2. Business Value: Summary of current cost and budgetary structures and cases of value add to the organization.
  3. Architecture: Examination of “as-is” architecture, policies, and standards
  4. SOA Legos: Investigation of existing services, technical processes, tools, and technologies
  5. Projects: Examination of existing systems, and on-going and forecasted projects
  6. Relationships and Outcome Management: Investigation of current governance and organizational relationships, policies, and processes.

End goal
The end goal phase involves the determination and definition of the “to-be” state of the organization, as it related to the SOA effort, and ensuring that there is cross-organizational agreement.
  1. Business Approach: Relationship of the SOA end goal with business strategies and processes.
  2. Business Value: Definition of metric and measurement requirements.
  3. Architecture: Organizational guiding tenets, requirements, reference architecture, policies, and standards.
  4. SOA Legos: Ecosystem requirements for supporting shared services and tool standardization.
  5. Projects: Alignment of SOA effort with projects and applications
  6. Relationships and Outcome Management: Relationship, governance, and compliance structures and policies.

Definition
Organizations begin defining an SOA roadmap in this phase. As per the information findings from the previous phases, a complete gap analysis should be conducted for the organization’s SOA objectives and suitable timelines. The immediate events will be well defined and detailed with future events being more in flux and fluid in order to incorporate the lessons learned during progression.
  1. Business Approach: Alignment of opportunities based on the value added to the business.
  2. Business Value: Roadmap of future metrics, cost and budgetary structures, and benefits cases.
  3. Architecture: Roadmap for the immediate, medium-, and long-term reference architecture.
  4. SOA Legos: Prioritization of shared services strategy and standardized processes.
  5. Projects: Impacts to projects and applications.
  6. Relationships and Outcome Management: Projected relationship and governance structures, policies, and processes.

An organization’s SOA roadmap must be treated as an “organic document” that continuously describes experiences and lessons learned of the organization. As the SOA effort matures, along the SOA roadmap, it reaches higher levels of complexity and sophistication, but does so in a govern fashion.


SOA Legos
One of the most crucial elements contributing to the success of an SOA journey is the institutionalization of a culture, throughout the enterprise, which cultivates the notion, and expectation, of reuse. The discrete, reusable services and architectural elements that can be combined to author composite applications and service ecosystem for the building blocks, like legos, of a SOA. The “SOA legos” form the basis of a catalog of enterprise capabilities over time and each is added to this catalog as it is implemented. The ROI of an enterprise is demonstrable and steadily increases as the number of capabilities in the catalog increases. This is due to the amount of new code development and service ecosystem needs for future projects are reduced. There are two categories of “SOA legos”: software legos and organizational legos. Software building blocks are such things as code, services, applications, data models, processes, and components. Organizational building blocks as things such as best practices, lessons learned, standards, tools (development, deployment, and management). By utilizing a collection of building blocks organizations can develop applications. The building blocks form the enterprise infrastructure and should be developed incrementally and refined iteratively and build-up the enterprise’s target architectures.
The ability to clearly define and implement a service at the proper level of granularity and with the appropriate level of coupling is essential to the success to the SOA journey. The implementation process must be consistent and repeatable process. At the center of any SOA is the notion of a service which is defined as “a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description”2. A service can be illustrated by three components:
  1. Interface: Provides a means for interacting with a service, which is standards-based, by users in order to access the service functionality according to the service contract.
  2. Contract: Is an agreement by two or more parties which specifies the conditions of use of a service including the service purpose, functionality, and constraints on the real world effect of the service.
  3. Implementation: Is composed of the actual code, application interface, or other technology asset exposing functionality through a service. Services are either exposed by creating new applications based upon services or from existing applications.
Exposing services can be accomplished either from existing applications or by developing new applications based on a service-centric paradigm. One of the initial technical questions, and probably the most difficult to resolve, is which services to implement first? When building the “SOA lego” baseline for the SOA journey, organizations typically begin with the simplest services at the core of the enterprise. These services should be business-unit, line-of-business agnostic and gradually migrate to business-unit specific capabilities. By following this type of progression will allow organizations to be comfortable with the process of constructing and reusing services without having to become mired in complexity. Some of the initial services organizations build are typically services that perform infrastructure functionality such as logging, monitoring, auditing, and error handling.
Services have both functional and non-functional characteristics. The main functional service characteristics are its execution model, exchange model, and level of complexity. A service’s execution model describes the manner in which a service is invoked and the communications exchanged: synchronous or asynchronous. The exchange model of a service describes the method, direction, of message exchanges: unidirectional or bi-directional. A service’s level of complexity refers to the granularity of a service.
Service granularity is the level of abstraction of a service. Services are either fine-grained or coarse grained. A fine-grained service is one provides specific capability, for example as standards-based of invoking an application programming interface (API) or manipulating an enterprise data object. Shared services that provide common business operations are also typically fine-grained services. Coarse-grained services are those services that provide a mechanism for accessing high-level, complex business capabilities, such as employee on-ramping and mission planning. Coarse-grained services are often long running and involve the coordination and collaboration of finer-grained service execution.
The non-functional characteristics of services involve things such as volume requirements, quality of service (QoS), and execution length. Portions of the service contract are comprised of these dynamics.
Service characteristics and functionality permit the categorization of services in layers of a service-oriented architecture. This categorization serves in the decision making regarding service utility and prioritization.
The IT disciplines required to realize SOA should also be considered as “SOA legos”. Such disciplines include a versioning strategy, service provisioning, testing, and verification and validation. It is essential that adherence to IT disciplines be strictly applied and enforced. One of the principal roles of SOA governance is to ensure the scope and enforcement of such standards.
A SOA ecosystem will be required to deliver the “SOA legos”. A common ecosystem component is a service registry. A service registry provides a mechanism for service consumers to discover available services and for service providers to broadcast the existence of services. One of the critical features of SOA is the ability to discover and reuse capabilities that conforms to a needed contract at the time it is needed. Several other ecosystem components for developing and provisioning services exist and are considered “SOA legos”:
SOA fabric or “Enterprise Service Bus (ESB)” which provide dynamic routing, mediation, and translation capabilities
Identity management and Enterprise Security frameworks that provide a security infrastructure
Configuration management for managing the deployable components and for configuration of hardware and services provisioning at runtime
Business Activity Management (BAM) for measuring SOA performance against defined contracts and SLAs
Portal technology for multi-user experience delivery
There are several technologies and platforms available for providing the necessary ecosystem components. The basis for SOA must be standards based which allows for a best-of-breed approach to acquiring the necessary components. It is best to deliver the “SOA legos” and ecosystem in an iterative manner.

Tomorrow : Projects

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