Level: Introductory Brian Byrne, IFW/IAA Process and Integration Models Architect, IBM
Brian Yarow, Senior IT Specialist, IBM
14 Jul 2006 from The Rational Edge: The authors describe how IBM's Industry Models for targeted industries can be customized to support unique business requirements via the IBM Rational and WebSphere toolset.
 This article outlines the use of IBM Rational tools to develop service-oriented architecture (SOA)-based solutions using IBMs Industry Models. As shown in Figure 1, IBMs Industry Models are a collection of interrelated models that address different aspects of the analysis and design of applications or integration solutions for key industries such as banking (Information Framework, or IFW) and insurance (Insurance Application Architecture, or IAA).
We particularly focus here on those models that relate to the analysis and design of an SOA to support the operational needs of an organization.
Figure 1: The Industry Models relating to service-oriented architectures
The Industry Models are structured as a set of foundation models that act as a standard taxonomy upon which the other offerings are built. Derived from these are detailed process-analysis models detailing the end-to-end processes required to support an organization's business. Derived from these, in turn, are detailed service-analysis and service-design models that act as blueprints for SOA projects within an organization.
It is important to understand that the IBM Industry Models do not provide an "out of the box" solution. Rather, these Industry Models are a deliberate abstraction from the specifics of any one organization, in any one problem domain, and provide the blueprints and standards upon which the specific process and underlying services may be constructed.
The goal of the Industry Models, and of enterprise modeling in general, is to provide consistent patterns and artifacts across a wide range of the enterprise. This approach to modeling greatly improves the chances of producing a truly reusable service-based infrastructure. It does not however bypass the implementation stages of software development. The patterns described within the IDM (interface design model -- a sub-model within a given Industry Model) will provide invaluable guidance to those seeking to expose, for example, the capabilities of existing Customer Information Control Systems (CICS) transactions as more reusable XML messages. Nevertheless, there is still the task of writing the Common Business Oriented Language (COBOL) code to translate from an ideal XML message into transaction invocations.
Each individual financial institution and, indeed, each individual project within that institution, will have a distinct set of challenges relating to the target operating environment. These challenges range from the limitations of existing systems and infrastructure to the challenges of the selected solution architecture. The challenges encountered deploying enterprise-wide Web services will differ from the challenges associated with the construction of an enterprise-wide J2EE architecture.
The Industry Models support the identification, analysis, and design of requirements-based solutions, irrespective of the target environment. The technology-based challenges of enterprise integration vary with the selected infrastructure. However, the challenges of capturing and expressing business requirements and of deriving a service architecture from these requirements do not vary significantly, and it is the intent of the models to support the requirements-based analysis and design of systems in a way that is not biased by a particular solution architecture.
Moreover, capabilities are provided to transform and deploy model artifacts into technology-specific domains, for example, a Business Process Execution Language (BPEL)/J2EE environment as described in the next section.
Customizing the models
Since the Industry Models are intended to be customized by an organization, it is reasonable to assume some methodological guidance in doing so. While IBM has not attempted to replace the many references detailing the finer points of Unified Modeling Language (UML)-based analysis and design, the Industry Models are accompanied by a set of recommendations detailing their usage within SOA-based projects; a high-level outline of these recommendations is shown in Figure 2.
Figure 2: The Industry Models customization roadmap
In short, this method is heavily focused on detailed process analysis in order to identify highly reused business tasks that may be further explored as service candidates. This provides a complete understanding of the context of each service and a solid exploration of likely reuse.
Highly reused business tasks are modeled as system use cases. By exploring the input and output information requirements of these service candidates, we can realize the discovery and customization of an extensive, third-normal form class model that captures the detailed data requirements associated with service candidates.
These use cases in turn are used to extend a design-level services (component) model with specific operations on component interfaces. A design-level UML model is constructed to provide a detailed definition of the internals of each component and the services that they expose. This design model is sufficiently formalized to allow the generation of a platform-specific component (e.g., Java models) or service contract such as Web Services Description Language (WSDL).
Top down vs. bottom up
The Industry Models are well suited to top-down analysis and design, driving service definitions based on pure business requirements. However, few financial institutions today are operating on a "rip and replace" basis; indeed, most organizations strive to retain their considerable investment in existing systems, which motivates them to expose the capabilities of existing systems through highly reusable business services.
Clearly, a purely top-down approach is not ideal in this scenario. Considering only pure business requirements is likely to result in service definitions that are impractical or impossible to implement, given the constraints of existing systems. As shown in Figure 3, this often leads organizations to follow a bottom-up approach, which has its own challenges. Heavily biasing service definitions based on the known capabilities of today's systems will certainly yield viable solutions, but will the services approach meet business needs any better than the systems to be integrated already do today?
The Industry Models start with a purely business-driven approach -- analyzing business-to-be processes and deriving analysis-level service definitions. However, in moving to design, the real-world constraints of today's systems must be considered. Are the services we have analysed realistic? Can they actually be built? In most engagements, significant compromises are introduced at design time due to the nature of legacy.
Figure 3: Considering solution constraints with the Industry Models
This means that the Industry Models tend to follow neither a top-down nor bottom-up approach. Instead, top-down analysis meets solution-focused design. Two quite separate (but traceable) models are maintained: a detailed analysis model based on requirements and a formalized service design that takes account of constraints of the deployment environment.
Tooling implications
Mapping this dual model to real-world tooling capabilities results in the typical project roadmap illustrated in Figure 4.
Figure 4: Industry Models tooling landscape
The steps outlined in Figure 4 can be more fully described as follows:
- Based on a defined project scope, capture initial business requirements in a semi-structured form using IBM Rational RequisitePro. The level-1 process definitions of the Industry Models are often used to guide this process and to ensure the use of standard terminology.
- These requirements are then used to drive the customization of the Industry Models analysis processes within IBM WebSphere Business Modeler. This includes analyzing the data flow through each process, capturing reusable data aggregates across all processes. These process models are then harvested from the project and reviewed at an enterprise level. Importing the process analysis into IBM Rational Software Architect and IBM Rational Software Modeler (RSA/M) as an activity diagram facilitates a visual compare/merge against existing enterprise-wide process definitions. RSA/M also contains the mappings from process tasks to system use cases that support those tasks. These mappings are used to identify the subset of the existing use-case model that is affected by the project.
- This Business Object Model (BOM) is extended within RSA/M with additional data requirements and business rules, resulting in a complete analysis model of the service candidates. In particular, analysis is performed to identify the most reusable aggregations of the classes of the BOM model. These aggregations are closely aligned to the information requirements of the business process and will be required to formalize reusable XML data types at design time. This completed analysis is then harvested from the project before being validated and merged with the enterprise-wide business model.
- This analysis is then used to extend the design-level service definitions (IDM) of the industry models, within RSA/M. This typically involves the extension of the existing service interfaces within the model to provide service definitions that meet the expressed business requirements while taking heed of existing systems and other constraints. This service design can then be used to generate WSDL definitions or other service descriptions.
- The process models captured at an analysis level must now be used to structure a design-level process. This involves taking account of the finalized service definitions as well as other design-level artifacts such as portlets, externalized business rules, or staff interactions. This results in a detailed process specification within WB Modeler that takes account of the definition of reusable software artifacts and the constraints of existing systems. This process model is then used as the source for BPEL generation.
- Both the BPEL definition from WB Modeler and the WSDL definitions from RSA/M are imported into WebSphere Integration Developer (WID) in order to structure a final solution. WSDL services are bound to the BPEL tasks that invoke them, and additional bindings are created to any portlet, rule, or staff activity invocations as required.
Conclusions
The IBM Rational and IBM WebSphere tooling has evolved over recent years to support enterprise business modeling. Seven of the top ten worldwide financial institutions now use IBM's Industry Models to support SOA or other project initiatives. Together, enterprise modeling and robust modeling tools are making SOA a reality.
About the authors  | | | Brian Byrne has been with IBM for six years and is the lead architect for the Industry Models in the Process Integration and SOA space. With a background in large-scale distributed systems, Brian has extensive customer experience on SOA projects with major world banks. |
| 
| | Brian Yarow is a senior technical specialist for IBM Rational, working with clients to help determine how Rational tools can benefit their organizations and ensure success. Prior to Joining IBM, he spent thirteen years in the IT consulting arena, working with dozens of Fortune 500 companies to automate their business processes. |
Rate this page
| 
