Service Oriented Modeling and Architecture (SOMA) is a modeling and design technique developed by IBM that provides prescriptive steps for how to enable target business processes by defining and developing a service-based IT solution. SOMA provides the communication link between the business requirements and the IT solution. It provides guidance on how to use business model and information as inputs to derive and define a service-based IT model. SOMA, as a methodology, addresses the gap between SOA and object orientation. This methodology approach provides modeling, analysis, design techniques, and activities to define the foundations of an SOA. It helps to define the elements in each of the SOA layers (see Figure 1) and also to take architectural decisions at each level.

At the heart of SOMA is the identification and specification of services, components, and process flows. At a high level, SOMA is a three-phased approach to identify, specify, and realize services, components, and flows (typically, choreography of services). The first phase is that of service identification, where various techniques are used to identify an exhaustive list of candidate services. The second phase is that of service specification, in which a detailed design of services and components is completed. The realization phase focuses on making architectural decisions, justifying the most prudent approach to implement the services.

SOMA focuses directly on the services, service components, and flows. These SOA constructs reside between Layer 2 and Layer 4 of the architecture stack. However, the activities performed as a part of the end-to-end methodology influence the placement of components in the other layers of the stack. Figure 2 illustrates the focus of SOMA as it pertains to the solution stack.

One of the main outputs of the SOMA method is a service model. It is recommended that a service model constitute of the following artifacts about services:

• Service portfolio: List of all the enterprise services
• Service hierarchy: A categorization of services into service groups
• Service exposure: An analysis and rationalization of which services should be exposed and which should not
• Service dependencies: Representing the dependencies of services on other services
• Service composition: How services take part in compositions to realize business process flows
• Service NFRs: The nonfunctional requirements that a service must comply with
• State management: The various types of states that a service should maintain and implement
• Realization decisions: Architectural decisions, for each service, around the most justified mechanism to implement the service

The techniques employed in the various phases of the method address one or more parts of the service model. Although there may be other work products that can be developed by exercising the various phases and activities of this method, we concentrate on the service model in this excerpt.