Typically, an enterprise already has a set of applications that supports most of the required business functions. So, when it comes to service definition, you might think it's simply a matter of exposing the existing application functions as a set of services, similar to traditional enterprise application integration (EAI) practice. Not so. Properly defining services is one of the most difficult tasks when implementing a solution based on Service-Oriented Architecture (SOA). Unfortunately, this approach rarely works. It is, in essence, "a technology-first approach and a recipe for disaster and/or serious over-engineering." 1 (See Resources.)
A better approach to service-oriented decomposition is based on the enterprise-wide business model. The approach includes designing a set of services that defines the enterprise architecture blueprint supporting the current business goals and providing capabilities for future changes. It requires you to start "with the scenarios/business needs, play those out against the existing/new systems, zero in on the points of tangency, and from there plan a flag for harvesting a meaningful service." 1 (See Resources). Services, defined this way, allow traceability between IT and business functions. This approach is "an example of a delivery strategy that can help you to adhere to the vision for your enterprise architecture." 2 (See Resources).
This article discusses a service-oriented decomposition approach that conforms to the enterprise business drivers and principles of service-oriented computing. It is based on initial partitioning of the enterprise IT functions into services based on the business model and then refactoring of the initial service definitions so that they are aligned with the overall enterprise architectural goals. This approach can be implemented as a multi-step process with the following activities:
- Hierarchical decomposition, based on the enterprise business model, to ensure alignment of resulting services with current, and future, business functions
- Refactoring of the initial service decomposition, to align it with architectural goals, such as performance, scalability, security, and so on
- Using the enterprise semantic data model, based on the business model, to ensure interoperability of the resulting services
This article uses the fictitious ACME Insurance company as an example. ACME specializes in two lines of insurance: personal auto and inland marine. ACME deals with all the issues associated with the complete insurance servicing life cycle—including rating, underwriting, and servicing insurance policies. To minimize complexity, the example focuses solely on the issuance process. Some details, while necessary from the insurance company's perspective, will be omitted if they don't add value to our discussion.
At the core of insurance issuance lies a proprietary rating model that is used to determine the appropriate customer premium. The model, developed over time by ACME's underwriters, determines the risk associated with issuance of the insurance policy, based on the rules and risk factors associated with the particular line of business and defined by a specific insurance product.
ACME has an insurance administration system in place. The IT staff developed and evolved the system, which has several proprietary and off-the-shelf packages supporting all the required functions. The applications shown in Figure 1 currently support the issuance process.
Figure 1. Current ACME applications
- "Accept Inland Marine terms and conditions" is a Java™ 2 Platform, Enterprise Edition (J2EE)-based Web front end that allows users to enter the terms and conditions for a policy, receive a quote, and view the state of a policy. A similar application, "Accept Personal Auto terms and conditions," supports the same functionality for a different line of business.
- "Inland Marine Policy and Product Administration" is a Visual Basic 6 (VB6)/COM application supporting two basic functions:
- Product administration—supports creation of new insurance products for this line of business and maintenance of existing products.
- Policy administration—supports the complete policy life cycle, including quote, issuance, endorsement, rewrite, and cancellation. This application also relies on a claims feed that provides information about claims history for the given policy.
Product and policy administration for the personal auto is implemented as two separate CICS/COBOL applications. In addition, the "Motor Vehicle Report" application allows access to driving records for insured drivers from the department of motor vehicles for the appropriate state.
- "Inland Marine Rating" is a VB6/COM application, implementing a rating engine for inland marine insurance. Similar functionality for the Personal Auto application is implemented using a CICS/COBOL application.
The existing set of applications fully supports ACME's current needs. However, they fall short of supporting the following long-term business goals:
- Standardization of policy issuance process
- Currently issuance for Inland Marine and Personal Auto uses two completely different processes and sets of screens, based on two different sets of applications. This requires either doubling the amount of employees to support the two processes or more extensive training for the same employees to support both.
- Streamlining the policy issuance process
- In the current implementation, the process can take over two weeks, making it hard for ACME Insurance to compete with other insurers.
- Improving quality of claims data
- For the Inland Marine underwriting, currently the claims data feed is only updated monthly, which can lead to inaccurate underwriting data.
- Better management of "in flight" policies
- The management reporting system only provides information about completed applications, making it impossible to introduce corrective measures during the processing of policies.
- Business expansions
- The current applications support only manual entry of the policy. This hampers participating in insurance exchanges that require electronic submission of applications and the return of the policies quotes.
- Process changes
- For example, regulatory compliance requires the introduction of records management. ACME is investigating adopting a document management system for managing policy documents. ACME also sees potential in cross sell options, and is looking to introduce customer relationship management (CRM) procedures for this purpose.
ACME's existing IT systems provide all of the required functions for supporting the above goals, but the architecture, or organization, makes it hard to achieve the goals. The application-centric nature of the current implementation is problematic because every application is built and maintained individually, with no (or very little) consideration for the other applications in the company.
As a result, the core business function—insurance policy issuance—does not exist as a holistic process. Its functions are spread between existing applications; each application is responsible for a part of the process, and the overall integration is implemented as an afterthought.
Most of the company's business goals require making the business process the focal point of ACME's architecture. A well-defined and externalized implementation of the policy-issuance process is the key ingredient for a flexible, adaptable IT architecture that supports the enterprise's long-term goals. For example, management of in-flight policies and streamlining of issuance requires end-to-end visibility of the issuance process. Such visibility is virtually unachievable without externalizing this process.
ACME's architects searched for a solution aligned with the business goals and decided to adopt the SOA approach for policy issuance implementation.
The foundation of SOA decomposition is an enterprise business model, which contains the primary representation of the resources and processes for meeting operational, tactical, and strategic business goals. A business model is an essential component of a successful service-oriented decomposition, ensuring consistency and flexibility of resulting services across the enterprise (motivations for adopting an SOA approach). A high-level model must be in place to help set the direction, partitioning, and taxonomy of services. Implementation details can be developed over time as SOA implementation progresses.
There are many approaches to defining enterprise business architecture. Some architects base their interpretation of business architecture on a corporate organization. A business function or process model can be used as a starting point to draw connecting lines between vertical functions and horizontal processes to describe a cross-functional process within the business.
A general definition of enterprise business architecture is:
"..[it] defines the enterprise value streams and their relationships to all external entities and other enterprise value streams and the events that trigger instantiation. It is a definition of what the enterprise must produce to satisfy its customers, compete in a market, deal with its suppliers, sustain operations and care for its employees. It is composed of architectures, workflows, and events. A value stream is an end-to-end collection of activities that creates a result for a customer, who may be the ultimate customer or an internal end user of the value stream. The value stream has a clear goal: to satisfy or to delight the customer." 3 (See Resources.)
The value streams effectively describe core enterprise business processes containing the ordered sequence of activities that produce results from functional components of IT (services).
This approach lets you define core enterprise business processes and services required to support them. It is also a foundation for determining effectiveness and efficiency of current processes.
The key component of a business model is the description of the enterprise business processes, which defines their supporting activities, inputs, and outputs. Process activities provide the foundation for defining the enterprise services. Using the business model as the starting point in decomposing the solution into services facilitates the alignment between business and technology—one of the objectives of the SOA approach.
The service partitioning driven by the enterprise business model corresponds to top-down design and represents the hierarchical decomposition of processes into services and processes.
At the top-most level the enterprise system can be represented as business processes orchestrating multiple services. In general, each service can be further decomposed using subprocesses that orchestrate lower level services. Figure 2 shows the hierarchical decomposition into business processes and services.
Figure 2. Decomposition of processes, services, and components
Decomposition is a well-established technique. Depending on the objective, many decomposition criteria can be applied. The decomposition criteria have a significant impact on architecture goals such as performance, flexibility, comprehensibility, development time, changeability, reuse, and so on.
Several factors influence hierarchical decomposition:
- Granularity
- The higher level the process or service, the larger the
granularity of the interface. High-level processes or services
do more work per invocation than lower-level services. This makes sense,
because the higher-level services are using lower-level services to implement
their functions. Choosing the appropriate granularity of services is not a
simple proposition. Currently there is no mathematical theory or methodology
that can tell a designer or architect whether service decomposition has been done
correctly. The following test4 can validate the service's granularity.
-
The business-alignment perspective probes the alignment between the
proposed service and the business:
- Can this service be justified based on a business perspective (model)?
- Does the business want to expose the service to their partners?
- Does the business envision outsourcing this service to a trading partner?
- Is this service critical to the functioning of the business?
-
The composability perspective considers the ability to use the
service in many business processes (for example, in a different context than the one
where it has been defined):
- Can this service be taken elsewhere and composed into another business process?
- Does composing this service into another business process require a deep composition hierarchy?
-
The business-alignment perspective probes the alignment between the
proposed service and the business:
- Visibility
- The higher the level of the process or service, the broader its visibility. For example, the enterprise business process has visibility (or scope) across the entire enterprise. Its interface is available to all enterprise users. In contrast, a low-level business process or component is only visible within its application scope. Users outside that scope cannot see or use the business component directly, but only indirectly through a higher-level service.
Generally, these factors go together so that high-level processes have large granularity and broad visibility, while low-level components have fine granularity and limited visibility.
To implement the hierarchical decomposition, ACME's business analysts started to identify enterprise business services by developing an enterprise business model for policy issuing. This model covers all key business processes within the company, including the major business activities required for implementing the processes and their sequencing.
The ACME business model is based on industry-standard concepts, definitions, and high-level processes defined by the IBM Insurance Application Architecture (IAA), which has defined a standardized policy issuing model (see Resources). Following IAA allows ACME to leverage the collective knowledge accumulated by the insurance industry. Based on the IAA, the high-level policy issuance process is shown in Figure 3.
Figure 3. Simplified policy issuance process
Decomposing the solution into services based on the business model yields a set of services, as shown in Figure 4. In this case, we are using only one level of decomposition.
Figure 4. ACME services, based on the hierarchical decomposition
The hierarchical decomposition based on the enterprise business model allows for alignment between business and IT, but does not guarantee that resulting services will adhere to the basic services tenets. The following additional aspects of the service should be factored into the decomposition process.
- Explicit boundaries
- Services interact through explicit remote
invocations. Service implementers can control execution within the service
boundaries, but not cross-boundary invocations. Such invocations can be
subject to network latency, network failure, and distributed
system failures.
Splitting latency-critical functions between multiple services can lead to violations of performance requirements for the overall system. Similarly, true two-phase commit requirements between two or more services are typically not achievable. As a result, if based on a business model, several services are defined with the following characteristics:
- Strict invocation latency requirements
- Two-phase commit requirement
These services should be combined into a single one, internally implementing invocations and two-phase commit, providing combined functionality.
- Autonomy
- Services are developed, deployed, and versioned
independently of each other and of the systems that consume them. Creation of services that are heavily dependent on each other
increases their coupling, thus having a negative impact on their autonomy. If
using a business model, several services are defined with:
- Heavy reliance on the same existing code (application)
- Being used together, for the most part
These services should be combined into one, providing combined functions.
- Services share schema and contract
- Implementing service communications using XML schema-based messages lets you define service interfaces, which are agnostic to both programming languages and platforms. You can ensure broader levels of interoperability, and consequently wider applicability, of services. Semantic messaging (data model) should be used for definition of the service interfaces.
So back to the decomposition of the policy issuance process: ACME has acquired a complex document management system that can handle both document composition and archival. Though the enterprise business model indicates separate services for these functions, the decomposition would yield two services with strong dependencies on each other. Factoring the composition and archival responsibilities together carves out a service that observes the autonomy boundaries.
Both Create quote and Issue policy require rating of the
policy. As mentioned, rating is the main competency of the insurance
company and can change (improve) independently from other implementations. Based
on the autonomy principle of service, it makes sense to implement rating as an
independent service, which can be used by both Generate
quote and Issue policy
services. A set of ACME enterprise services, after refactoring, is shown in
Figure 5.
Figure 5. Refactored ACME services
Defining the interfaces of the identified services is an important part of the SOA decomposition. The interface definition entails specifying the messages that services exchange, consume, and generate.
The top-down design, based on the enterprise business model, yields interoperable semantic interface definitions. The resulting semantic data model defines the standard business objects or entities of the enterprise, such as an insurance policy, claim, and so on. An SOA implemented around the semantic data model (interoperability) represents a semantic SOA.
The semantic SOA offers enhanced interoperability between services: at the interface level, all of them work from the same data definitions. In effect, this eliminates the need for message transformations between services. Because service interfaces are created based on the standard enterprise semantic model, it is guaranteed that every service will understand and correctly interpret any message, regardless of the service consumer.
Although the semantic data model seems similar to a standardized enterprise data model, the two are radically different and should not be confused with each other. The semantic data model defines the messages exchanged by services. The messages implement interservice communication. As such, they're transient and do not reside in a data store (at least, not explicitly).
In contrast, the enterprise data model defines the data structure and relationship between the data in the database. It focuses on aspects such as fast retrieval, low redundancy, partial aggregates, and so on, that are irrelevant outside the data store.
Implementing SOA involves service enabling of existing enterprise applications. Changing the underlying data model is an extremely expensive proposition that often requires completely rewriting applications. In contrast, the SOA messaging infrastructure is part of building the architecture, which means that it can be created as part of the SOA implementation.
There are different ways, using patterns and best practices, to achieve semantic interoperability in SOA. Experience has shown that the same enterprise business model that is used for defining service should also cover the semantic data definitions. For example, both IAA and ACORD define XML messages for insurance industry transactions. These standards reduce the time and effort required for business partners to create new data interfaces with each other.
Semantic data model guidelines
When defining the SOA semantic data model, keep in mind that it provides the foundation for XML data messaging, not data persistence. There are several important considerations for the model creation.
XML uses a hierarchical data model. The hierarchical model differs significantly from the data models used in traditional databases, such as the normalized relational data model that aims for fast updates and retrievals, or the dimensional data mode, which aims at slicing in various dimensions. As a result, common database design techniques (normalization, joins, foreign keys, and so on) are rarely applicable in this case. They usually lead to an overly complex XML implementation. XML model design typically requires significant de-normalization of data, trying to minimize cross-references between XML objects.
XML payloads are subject to marshalling/unmarshalling when crossing each service boundary, so using "small" types in XML incurs significant serialization overhead, which in turn has a negative impact on performance. Every XML type is marshalled/unmarshalled into a separate object, which means that using small XML types leads to creation and deletion of many objects during execution. It is recommended to increase the size of XML objects during semantic data model design.
Excessive nesting of XML types can lead to significantly more complex XML processing of the payloads. It usually leads to creation of additional language objects during marshalling/unmarshalling, and requires a more complex notation for accessing the data. It is advantageous to minimize the amount of nesting in the XML payloads definition.
In this article you explored an approach to service-oriented decomposition that is an extension of the service identification defined by Service-Oriented Modeling and Architecture (SOMA). The approach supplements domain decomposition and goal-service modeling5, which is used by SOMA with refactoring, based on enterprise architecture principles and semantic messaging definitions for ensuring service interoperability. You also learned about:
- Improved alignment with the business
The hierarchical decomposition that follows the enterprise business model generates services aligned with the business. This provides direct traceability from business artifacts to business services.
- Process focus
Decomposition, according to the enterprise business model, emphasizes enterprise business processes rather than the applications that implement them or the data that they consume. This emphasis fosters the shift from function-oriented to a process-oriented mindset, opening the doors to new possibilities (process simulation, semantic compensation, key process indicators, and so forth).
- Semantic messaging model
Top-down, model-driven decomposition defines a service's functional boundaries and allows for defining the enterprise semantic data model. Using this model leads to creation of more interoperable, looser coupled services.
- Improved overall architecture
Architecture goals such as security, availability, and low coupling are as important for service identification as functional decomposition.
Many thanks to Edward Kuffert for numerous suggestions that greatly improved this article.
Learn
- 1Grady Booch discusses different approaches to service design in his blog
Software architecture, software engineering, and Renaissance Jazz blog : SOA Best
Practices. (March 11, 2006)
- 2Tom Fuller introduces software
factories in
"A
Foundation for the Pillars of Software Factories," The Architecture Journal, Issue 9, 2006.
- 3Ralph Whittle and Conrad B. Myrick present the
approach to business model definition in
Enterprise Business Architecture: The Formal Link Between Strategy And Results,
CRC Press, 2004. (ISBN-10: 0849327881)
- 4Karin Duermeyer presents factors influencing SOA decomposition in
"Bridging Business Value to SOA: SOA Best Practices." (PDF) (IBM Business Consulting Services, 2005)
- 5Ali Arsanjani's
"Service-oriented modeling and architecture" provides an excellent introduction to SOMA. (developerWorks, Nov 2004)
-
"Defining SOA as an architectural style" by Boris Lublinsky
defines SOA, and explains why it's important to align services with your business
model. (developerWorks, Jan 2007)
-
"SOA
Design: Meeting in the Middle," by Boris Lublinsky, describes various approaches
to SOA design. (Aug 2004)
- Building SOA solutions with Industry Models and the
IBM Rational Software Development Platform by Brian Byrne and Brian Yarow describes how
IBM's industry models for targeted industries can be customized to support
unique business requirements using the IBM Rational and WebSphere toolset. (developerWorks, Jul 2006)
-
"Implementing an SOA with common technologies" describes decomposition techniques. (Cutter Enterprise Architecture Executive Report, Jul 2004)
-
"Data on the
Outside vs. Data on the Inside" by Pat Helland outlines differences between service interfaces and underlying service data, and their impact on each other. (Microsoft®, 2007)
-
"Unifying Data,
Documents and Processes" by Boris Lublinsky
provides a unified architcture for SOA and enterprise data. (Enterprise Architect 2004, Vol 2, Number 2)
-
"Achieve semantic interoperability in a SOA" unveils the mysteries of semantic interoperability in a SOA context. (developerWorks, Jun 2006)
-
"The
four tenets of service orientation" defines major SOA principles. (BPMInstitute.org, May 2005)
-
"Principles of Service Design: Service Patterns and Anti-Patterns" provides fundamental principles for designing and implementing Web services, including a brief review of SOA concepts and a detailed discussion of several patterns and anti-patterns that developers can leverage when building Web services. (MSDN, Aug 2005)
-
"Versioning in SOA" by Boris Lublinsky describes an approach to versioning in SOA. (Microsoft Architect Journal, v11)
- Get more information about
IBM Insurance Application Architecture.
- Read more about development and use of standards for the insurance, reinsurance, and related financial services industries at
ACORD.
- IBM on demand demos to learn about various software products and technologies from IBM.
- Stay current with
developerWorks Live! webcasts.
- Check out developerWorks Live! technical events and briefings
Get products and technologies
- Download Rational Method Composer to get customized yet consistent process
guidance to your project teams and IT organization. This product also includes the latest version of
IBM Rational Unified Process® (RUP®).
- Download
IBM product evaluation versions
and get your hands on more application development tools and middleware products from
DB2®, Lotus®, Rational, Tivoli®, and WebSphere®.
Discuss
- Participate in the discussion forum.
- Read what everyone is talking about in
developerWorks
blogs and
get involved in the
developerWorks community.
Boris Lublinsky has more than 25 years of experience in software engineering and technical architecture. For the past several years he has focused on enterprise architecture, SOA, and process management. Dr. Lublinsky is a technical speaker and author, with more than 50 technical publications in different magazines, including Avtomatika i telemechanica, IEEE Transactions on Automatic Control, Distributed Computing, Nuclear Instruments and Methods, Java Developer's Journal, XML Journal, Web Services Journal, JavaPro Journal, Enterprise Architect Journal, and EAI Journal. Currently Dr. Lublinsky works as a principal architect at Herzum Software, where he is responsible for the design of component-based development factories and consulting with customers on component-based development and SOA. You can reach Boris at blublinsky@hotmail.com.
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
