Print

Transitional Gap Analysis (TGA)

Many of the current products and technologies related to web services and enterprise systems are relatively new and have only recently entered a stage of maturity suitable for organizations and applications larger than the Small to Medium Sized Enterprise (SME – defined by the OECD as a company with up to 500 employees and annual revenues up to USD $50 Million) or similar scope programs/projects. Since many commercial products have been initially targeted at the SME, there are often problems associated with robustness and scalability to the Large Enterprise. Large Enterprise projects are especially complex since they frequently require a multinational implementation approach and process larger volumes of information. Traditional enterprise system technologies are typically expensive and require highly specialized skill-sets to properly implement. This creates a significant problem within an organization with regard to maintaining adequate skill-sets or adequate funding to engage external experts in order to analyze, design, and implement an enterprise platform. Since 2003, many of the major vendor suites have become increasingly integrated and require much greater knowledge of internal API’s and component integration configuration. The TCGAF and DNEAF analysis resource reports offered by Aurenav provide product and technology specific resource descriptions to help an organization recruit the proper skill-sets for internal programs and projects.

The current practice of building dedicated (vertical or domain) platforms is expensive, difficult to reuse many of the developed artifacts, and hard to implement in an environment where funding and resources are in short supply. Additionally, different projects compete for the limited funds and resources that are available. This creates a critical need within the IT organization for a method that can be used to evaluate different projects. The TCGAF helps in mitigating a number of important risks associated with these types of programs and projects.
 
Transitional Gap Analysis is used at the CIM and PIM levels of MDA to provide an economic justification for a project (especially when compared to competing projects within the organization). Comparative Gap Analysis is used at the PIM to PSM levels of MDA to evaluate different candidate implementation approaches for a particular project.
 
dneafbg04_thm.jpg
 
The Initial PIM to PSM Mapping and Scope Constraints model above illustrates how the DNEAF is used to jump-start the Transitional Gap Analysis. The resulting high-level model can be drilled-down to identify the enterprise service components as illustrated in the PSM Component Model Drill-Down model below. Note that the functional component objects in the top model map one-to-one with the package elements in the lower model (Most UML CASE tools only support proper drill-down via the UML Package element).
 
dneafbg05_thm.jpg
 
The DNEAF is based on the Model Driven Architecture (MDA) standard defined by the Object Management Group (OMG).
 
“The MDA defines an approach to IT system specification that separates the specification of system functionality from the specification of the implementation of that functionality on a specific technology platform.”

This approach allows defining a system’s functionality independently from the restrictions a specific technological platform might impose. Once the system’s functionality is specified in a platform independent way, it can be implemented on several different platforms.
 

The MDA defines three core concepts:

Concept   Definition
Models   “In the MDA, a model is a representation of a part of the function, structure and/or behavior of a system.”
Models are written in a formal specification language such as the Unified Modeling Language (UML) or the Interface Definition Language (IDL).
 
Abstraction, Refinement, and Viewpoint   Abstraction is defined as the suppression of irrelevant detail. Abstraction criteria are used to determine what is included in a model. “A model that is based on specific abstraction criteria is often referred to as a model from the viewpoint defined by those criteria, or in short as a view of the system.” Models can describe a system at a higher or a lower level of abstraction, i.e. hiding or showing more details of the system. Some pairs of such models are in a refinement relationship with each other: the more abstract one is called the abstraction, and the more specific one is called the realization.
 
“Zooming” in and out   The MDA permits zooming in and out of a model showing objects or interactions. Zooming out is defined as going from a more detailed model to a more abstract model to hide the details, and zooming in is defined as going from a more abstract model to a more detailed level to see those details. Zooming in or out may result in multiple alternative models.
 
 
The MDA defines three different categories of models:
  • The Computation Independent Model (CIM)
  • The Platform Independent Model (PIM)
  • The Platform Specific Model (PSM)
All three model categories are essential in full life-cycle IT programs and projects and can exist at different levels of abstraction. Within each model (CIM, PIM, and PSM), there is a hierarchy of abstractions beginning with a high-level view and progressively drilling down into more detailed views. The three views are traditionally illustrated as a three-tier stack with the CIM on top and the PSM on the bottom. To better understand these concepts, it is more helpful to illustrate the CIM to the left and the PSM to the right of the PIM. In this view, the PIM can be seen as the fulcrum, or balancing point, for the overall model.
 
A PIM provides the formal specifications of the structure and the functionality of the system abstracting away both the business and the technology details. As its name suggests, it describes the components and their interactions in a platform-independent way. A PIM can be mapped to both a computationally independent business model, referred to as a Computation Independent Model (CIM) and to a technology and product specific model, referred to as a Platform Specific Model (PSM). Importantly, A PIM can be mapped to multiple CIM's and PSM's. There are 4 different transitions defined involving PIM's and PSM’s:
 
  • PIM to PSM: When a PIM has been developed to a level of great enough detail, it can be mapped to one or several PSM’s. Over the past few years (up through 2004), the PIM to PSM transition has received the greatest amount of attention with regard to published documents on MDA. An example of a PIM to PSM transition can take place when mapping different products to meet required functional and nonfunctional system requirements.
  • PIM to CIM: When a PIM has come to a level of great enough detail, it can be mapped to one or several CIM’s. This transition mapping is not typically emphasized in the available (as of 2004) MDA literature, but it is implied. An example of a PIM to CIM transition can take place when reengineering business processes.
  • CIM to PIM: When a CIM has come to a level of great enough abstraction, it can be mapped to a PIM. Platform Specific Models can, such as PIM’s, exist at different levels of abstraction. This transition involves moving from a highly detailed CIM to an abstract PIM. The goal is to shift from the detailed business processes and organizational structure to a functional representation of the business requirements. An example of a CIM to PIM transition can take place when planning to introduce a new software product into an organization in order to meet the business requirements.
  • PSM to PIM: When a PSM has come to a level of great enough abstraction, it can be mapped to a PIM. This transition involves moving from a highly detailed PSM to an abstract PIM. The goal is to shift from a detailed description of the information technology and underlying systems processes to a functional representation of the information system requirements. An example of a PSM to PIM transition can take place when planning to introduce a new Enterprise Resource Planning (ERP) product into an organization, which typically requires changing the existing business processes in order to fit the ERP product.
The TCGAF is a pragmatic and easy to use MDA framework that can be rapidly introduced into any organization. Test cases involving real-world programs and projects have demonstrated that people can learn to effectively work with the TCGAF at a productive level within two weeks. Aurenav can provide experienced mentors to help your organization adopt both the DNEAF and the TCGAF. The TCGAF was developed by Donald Baldwin at the EICT Applied Research Laboratory operated by Aurenav Research Institute in Stockholm, Sweden.