Making Alfabet your own - part 2
Tags: alfabet
Published: 2019-10-10 13:32:48

---
title: Making Alfabet your own - part 2
published: true
tags: #alfabet
canonical_url: http://techcommunity.softwareag.com/techniques-blog/-/blogs/making-alfabet-your-own-part-2
---

## Configuring the Alfabet meta-model

**In this series we look at how to configure the Alfabet product for best fit best practices in business and IT transformation. This episode focusses on the Alfabet meta-model.**

| Issue 3, 2017 | [![](http://techcommunity.softwareag.com/image/image_gallery?uuid=202eb7e1-9148-4c65-b29a-54c4302ab65e&groupId=10157&t=1326987658425) Download PDF ](http://techcommunity.softwareag.com/ecosystem/download/techniques/2017-Issue3/SAG_Making_Alfabet_Your_Own_TECHniques_Jul_WEB.pdf) |
|-|-|
## Introduction

Business and IT Transformation (BITT) is based on a methodology—a systematic way of solving a particular problem. As such, BITT activities need a description—a model—of all of the involved elements and how they relate to each other in this context. This meta-model, by nature, needs to follow a strict rule set to implement and sustain the methodology. Its composing elements are “Object Classes” and the scheme describing how they are related. Alfabet has an extremely rich out-of-the- box meta-model that lays the basic foundation for all Alfabet implementations. The classes that constitute the meta-model are a set part of the product. But configuration possibilities enable another layer of description to be added to the classes as needed by a particular organization’s use case. Class configuration allows you to define what information you want to include for each class so that relevant evaluations and reports can be made available to the enterprise.

## Making the meta-model meaningful to your organization

The classes in Alfabet’s meta-model appeal to a horizontally broad base of user organizations. They are generally agreed-upon classes required for the set of BITT activities that Alfabet covers. However, the product offers the possibility to opt out of using certain elements and aspects of the meta-model or to extend the meta-model to be able to reflect the peculiarities of any organization.

One specific means of amending the meta-model is the use of Class Stereotypes. A Stereotype is a sub-classification within a class. By configuring stereotypes, it is possible to have several sub-types of a certain class. For example, the class “Organization” may have the stereotypes “Holding,” “Enterprise,” “Business Unit” and “Department” to be able to differentiate functional specifics along the organizational structure. The class “Location” may have the stereotypes “District,” “Country” and “Region” to cater to the different levels of granularity of information needed at these different structural levels.

Stereotypes allow for:

- Planning and managing at a more refined level of detail including specifically targeted processes and RACI schemes for stakeholder contribution  
  
- Keeping the amount of information available for a user at a manageable level (i.e., assigning only certain stereotypes to particular user profiles)  
  
- Capturing specific data relevant only to the stereotype  
  
- Refined access control (user access only to certain stereotypes)

Extension of the product’s class model is also possible through the use of Class Properties. Properties are used to describe attributes of an object in a particular class. They are what your organization deems important to know about the objects in a class. For “Application,” for example, the standard model provides things like “Name,” “Version,” “Start Date” and “End Date” of the application’s lifecycle, and supported “Business Processes”. An organization may wish to amend this set of standard properties with, e.g., “Recovery Time Objective” or “Application Type”—the former being an integer and the latter based on a pick-list of string values.

Alfabet provides many, many properties for all classes out-of-the- box but it also allows for custom properties to be created in case additional information is relevant to the class. Many data types, such as string, integer, text, Boolean, date, reference or reference array, are available for defining properties.

## Using the organization’s nomenclature in the meta-model

Classes and their standard properties are identified internally in Alfabet by a Technical Name. The Technical Name cannot be changed. But each class and property has an Interface Caption which is how it is expressed externally. Alfabet provides standard interface captions but these can be configured to fit the nomenclature and taxonomy of the enterprise

![](http://techcommunity.softwareag.com/documents/10157/8763256/alfabet-your-own-img1.png)

**Figure 1:** Standard interface captions for classes are delivered with Alfabet. They can also be configured to adapt to an organization’s own particular nomenclature.

## Other configuration possibilities within the Alfabet meta-model

There are several other configuration options for the meta-model to fine-tune Alfabet to the needs of your organization:

- Object states to describe the operational status of an object in the enterprise (e.g., “Planned,” “Active,” “Retired”)  
  
- Object lifecycle phases to describe the succession of stages that an architecture element goes through (e.g., “Pilot,” “Production,” “Sun-down”)  
  
- Release statuses to describe the state of approval or quality for an object in the enterprise (e.g., “Draft,” “Described,” “Reviewed,” “Approved,” and “Rejected” for projects or “Created,” “Accepted,” “In Progress,” “Work Completed,” “Returned,” “Re-Assigned,” and “Closed” for assignments [tasks]).

Alfabet delivers standard, out-of-the-box definitions for all of the above, but customers may define their own terms as required.

Stay tuned for our next episode on configuring information displays in Alfabet.