Understanding Reference Models Within the context of Enterprise Architecture, reference models provide an opportunity to identify, logically organize, and reuse enterprise assets.
Since an “asset” is declared such by the enterprise, a reference model can contain many different types of assets.
As a result, a reference model may focus on a specific set of assets.
The Federal Enterprise Architecture has taken the time to create the foundation for five reference models, while TOGAF has two reference models. The most common reference model is the Technical Reference Model, which focuses on organizing the logical and physical IT components used in building architectures.
A good analogy for understanding how reference models are created and used is a simple child’s toy – LEGO.
When building with Legos, children can follow the pre-designed instructions which come with the set or they can combine sets to create even bigger, better models.
Legos have a variety of building blocks which vary in shape, size, color, and even purpose, but they are all interchangeable.
The quality of the creation is based on its structural integrity. Now, imagine providing a catalog of all the available Lego pieces for the children; a catalog which allows them to identify what building blocks they want to use before building their creation.
The catalog identifies what pre-defined sets each piece was designed for, its intended uses, and even the child’s historical use of the block.
In addition, the blocks can be easily identified because they are organized methodically—maybe by shape, size, and color.
The physical location of each block is traceable and the location is recorded in the catalog. A reference model plays the same role for an architect that the Lego catalog described above would play for a child; it allows the architect to quickly identify and use existing and available building blocks in the architecture.
In fact, the architect can even look at existing solutions using the same building blocks to understand and assess the ‘structural integrity’ of a developing architecture.
For the enterprise, a reference model provides an opportunity to define and share architecture building blocks for use and reuse across the organization.
In other words, they can restrict what blocks or creations are available to the enterprise. Creating a Reference Model The following process will look into creating a technical reference model; however, the process can be used in creating other reference models that the organization deems necessary.
The basis for the creation process is the FEA technical reference model because of its simplicity. The purpose of a reference model is to catalog all the components used in supporting the enterprise to achieve its goals.
The success of a reference model depends on its organization.
A Technical Reference Model (TRM) focuses exclusively on the technical components of the enterprise, which are the hardware, software, and standards of the enterprise’s IT infrastructure. TOGAF builds its TRM from an application perspective: first by identifying the purposes of their application solutions, then breaking down each application to its functional components, and finally describing its underlying communication infrastructure.
FEA breaks down the technical components based on the services they support.
Both approaches identify 3-5 levels of details in properly organizing the components. For our purposes, we will be using the FEA approach, which has three levels of detail.
The first or top-most layer defines the framework for the reference model.
For the TRM, the top-most layer represents the service areas.
In FEA’s other reference models, the first layer represents measurement areas (performance), business areas (business) and service domains (service component).
In TOGAF, the top-most layer is application type.
For enterprises considering or already adopting service management frameworks such as ITIL or COBIT, service areas may prove to be the best course of action (most service management frameworks are service-oriented). The Service Areas identified by FEA are: Service Access and Delivery – identifies those components used to access or deliver information between users and across organization units Service Platform and Infrastructure – identifies those components which make up the physical IT infrastructure, such as hardware and software Component Framework – identifies those components which make up the logical IT infrastructure, such as security, business logic, data management, etc. Service Interface and Integration – contains the enterprise’s middleware and standards to ensure interoperability between services The FEA approach provides a framework which supports the most diverse range of technologies available, and the framework is appropriate for the size and scope of the enterprise it supports.
For your organization, the framework may be too broad.
Additionally, if your organization has already done some work in classifying its services, then you should leverage that work accordingly.
This is especially true if the architectures and existing configuration management databases are going to be tightly integrated. The next layer in the TRM focuses on the function of the components to the service.
For instance, in the first service area, some components will provide access to information, such as web browsers, while others will deliver information to the user, such as the Internet.
It’s useful to note that the Internet is considered even though the enterprise has no direct control over its performance, only its use.
This is an important aspect of understanding and tracking enterprise assets.
In a business landscape relying heavily on “cloud services”, the ability to track assets not under the control of the enterprise will become a necessity in forming a comprehensive reference model. The final layer of the TRM focuses on the type of components used to support the infrastructures.
While the level of detail at this level is high, some organizations may decide that further categorization may be necessary.
In any case, the TRM should represent the actual component type and the standards which they use.
For instance, an organization may have several different types of services, each performing a different function, such as web, file, application, etc.
In addition to identifying each server appropriately, the organization may have a standard build which must be adhered to; that is, every web server must look the same.
In truth, several standard builds may exist depending on the roles and function of each component.
A web server may provide any one of several roles for the enterprise depending on its physical and logical location, its function, and its base configuration. After seeing how FEA creates its Technical Reference Model, a process for creating a basic reference model can be perceived and the process has three steps.
Each step requires the organization to answer one of the following questions in order: What are the general areas of concern? What functions fall within each area of concern? What component types provide the required functionality? While each question represents a specific layer, your organization may require additional layers for further classification.
There is no right or wrong answer.
The true test of the reference model’s effectiveness is the ability to quickly identify and leverage existing information on components. Component Information
Read more about ITIL Or : For enterprises considering or already adopting service management frameworks such….: