Phase 1: Capturing IIW business requirements
The need for appropriate tooling and model patterns appears in the early phase of requirements analysis. The work packages of this phase are assigned to business analysts with deep industry knowledge and high-level IT skills. The deliverables of such work packages are often non-structured documents, such as meetings protocols, presentations, and word processor documents. The information collected in this way often does not have any independent models. The information is delivered as is for the next phase (the business model), which creates the overhead of manual processing of large numbers of input deliverables. There is a clear need to introduce high-level, non-entity-relationship models.
Access to the knowledge and reference solutions is another requirement. The available solution patterns should be represented in an appropriate way to allow business consultants an efficient and easy way to do the following:
- Access the IIW framework patterns and documentation
- Collect requirements in the IIW framework
- Map deliverables from the requirements analysis phase to the components of the IIW framework
The IIW introduces the foundation layer models to provide business consultants and analysts with the toolset and intellectual property resources, which are distributed as commercial product. The foundation layer models include the following:
- Conceptual model
- Contains the business metadata to be used in other models
- Analytical requirements model
- Uses the business metadata identified in the conceptual model to document the requirements of analytical queries
- Business concepts vocabulary
- Delivers the dictionary-like representation of collected business terms
The conceptual model is the highest model for the definition of business requirements. The business data collected in this phase are fairly unstructured. The conceptual model delivers the tool support to collect the information about numeric and non-numeric data elements and dependencies between them.
The parts of the conceptual model are:
- Aggregate descriptors that focus on measure-based requirements. The aggregate descriptors are references as measuring templates for the analytical requirements model.
- The concepts part of the model, which is focused mainly on the collection of hierarchically ordered metadata. This part is used in the analytical requirements model for the definition of dimensions.
The aggregate descriptors model represents a list of pre-defined descriptors. Each descriptor contains a unique label and documentation text, as shown in Figure 3.
Figure 3. Properties of the Accounts Receivable aggregate descriptor
(View a larger version of Figure 3.)
For calculated measures, you can use a feature to document the calculation expression and reference related measures. An aggregate descriptor can be linked to another model (for example, the analytical requirements model or analysis data model).
The concepts part of the model contains the following types of metadata:
- Can be numeric or non-numeric. The numeric descriptors can be used for calculated measures.
- Describes relationships between concepts.
- Describes the order of business concepts. Each
concept has several sub-concepts that classify and describe the concept. The
following three sub-concepts are used:
- Accounting period type
- Account status reason type
- Account status type
- Account type
Figure 4. A cut-out from the conceptual model depicting a fragment of the account hierarchy
The conceptual model is an important feature of the IIW for documenting business concepts and their dependencies at a high business-level view. It also shows the existing dependencies and relationships of a business object, such as the business object account in Figure 4.
The purpose of the analytical requirements model (ARM) is to group and classify the concepts collected in the conceptual model. An analytical requirements model represents single analytical requirements. An analytical requirement contains measures and dimensions needed to analyze a particular business case.
Analytical requirements are grouped into several groups called focus areas. Each focus area represents a domain of business problems, such as claims analysis, product management, risk management, and so on. You can create substitute focus areas. For example, claim efficiency analysis can be a substitute for claims analysis, as shown in Figure 5.
Figure 5. Focus areas of the analytical requirements model
A focus area contains analytical requirements. An analytical requirement contains a set of measures and a set of dimensions. For example, the requirement Customer risk analysis contains the dimensions Policy, Product, and Time dimension, and it contains the measures Number of accidents and Number of claims, as shown in Figure 6.
Figure 6. Sample analytical requirement
The links between the analytical requirements model and the conceptual model are crucial. All measures and dimensions are linked to appropriate concepts in the conceptual model. Measures reuse aggregate or measurable properties that are pre-defined in the conceptual model. Dimensions are views or wrappers of business concepts, classifiers, relationships, or descriptive properties that are pre-defined in the conceptual model.
The advantage of this linking approach is that semantically identical measures or dimensions referenced in different analytical requirements are mapped to the single concept in the conceptual model. This solves the problem of redundancy and enables putting the documentation about a particular business concept in a single place. Conversely, you can inspect any element of the conceptual model for references from the analytical requirements model.
IIW is delivered with a set of pre-defined analytical requirements grouped into focus areas. Business users can select the analytical requirements to modify or create new analytical requirements. See the article Scoping the IBM Industry Model for banking using Enterprise Model Extender and InfoSphere Data Architect for more information.
The business vocabulary (or business glossary) is a required deliverable of any data warehousing project. Often it is maintained manually as a semi-structured document with dependencies on the requirements catalog and data models. The IIW delivers the business vocabulary as an integrated part of the modeling environment.
The business vocabulary summarizes the business terms collected in the conceptual and analytical requirements models. The business vocabulary consists of defined terms (words) grouped to dictionaries, as shown in Figure 7.
Figure 7. Business vocabulary
(View a larger version of Figure 7.)
Each word is provided with the description, which is the description of an appropriate element of the conceptual or analytical requirements model. The business vocabulary is open for modifications. Business users can edit or create dictionaries and words. Business users can define a word life cycle in which users can specify status, such as candidate, accepted, standard, and deprecated.
The business vocabulary offers several other features, including the capability to specify synonyms or related words.
You can export the content of the business vocabulary to IBM InfoSphere Business Glossary using the Metadata Server.
This section gave an overview of the major models of the IIW foundation layer. The models are the framework for collecting the data during the requirements analysis. The models are the deliverables for the next phases.