How  Reference Models Fit into A Technology Strategy

Model Definition

The term “model” may be one of the most overused words in technical (and other) documents. Yet it is not clear that the term has a precise definition or that everyone who uses it means the same thing. Even adding an adjective does not always clear up the ambiguity. However, this ambiguity does not detract from the usefulness that models can play to convey important concepts.

Graphical models or diagrams are most often used to convey a particular structure or concept, while data-based models (usually in the form of spreadsheets) are typically used to evaluate alternatives and make decisions.

Both types of models are often essential in communicating complex technical concepts as part of systems design. The most useful models are those that have been vetted through practical application, and that can be explained in simple terms, without resorting to complex jargon.

Reference Models

It is common to see the term “reference model” used in project proposals, product, and service descriptions, and a wide variety of technical documents.  While the precise meaning of the term might be lacking, a clear statement as to the purpose of using such a model can help remove any confusion.

Such models are most often a graphical description or summary used to establish the context for a particular subject or activity. Their main purpose is to position the subject with respect to related subjects, and to describe the relationship between individual components.

An Element of Technology Strategy

Reference and other types of models are important, if not essential elements of a technology strategy. This strategy is, in turn, a valuable reference in areas such as defining the project scope and lifecycle management. The strategy and the models used to describe it provide continuity and consistency in decision-making. However, the number of models used in some strategies can be overwhelming, and some specific models may be too theoretical or esoteric to be of practical use.  It is important to clearly understand who will use each model, as well as the specific purpose in mind.

Used by Specific Roles

Reference models can serve as important tools when communicating to a wide variety of decision-makers and other stakeholders.  The variety of roles involved is itself a contributing factor to the variety of definitions for “reference model.”  These models are typically developed and used by several specific roles involved in designing and constructing complex systems, including:

• System Architects – Senior or lead system designers are often referred to as “system architects.” This role is typically responsible for the overall system design, including identifying major functional elements and the relationships between them. This includes the definition of major data and control flows.
• Developers – Developers are responsible for translating the overall system design into specific functional elements. Reference and other more detailed models are essential vehicles for the communication of key functionality and constraints.
• Project Managers – Project managers are an important audience for various types of reference models. They use them for purposes such as defining and managing the scope of a development or implementation project. Since project managers may not have detailed expertise at the same level as system designers, it is important to capture and communicate essential design elements without unnecessary jargon or complex terminology.

Intended Purpose

Models serve several purposes within a well-crafted strategy, including:

• Defining Terminology – As a communications vehicle, a reference model should use the simplest possible language and terminology. Analogies or examples may also be used.  To be able to address the broadest possible audience, it is very important to avoid using jargon or arcane terminology.
• Defining Scope – This is one of the first steps in project management, and potentially one of the most difficult. Mistakes made at this phase can result in project overruns, missed expectations, or even complete project failure. Clear and thorough communication with stakeholders is essential for setting proper expectations.  Reference models also provide excellent tools for defining scope in terms of functionality or range of affected business processes.  
• Positioning Functionality – One of the more common challenges system designers face is to position a new or existing system with respect to other similar or related systems. Reference models of various types are particularly useful for this purpose.

One of the best-known examples is the OSI Reference Model shown in Figure 1. This is a conceptual model that characterizes and standardizes the communication functions of a telecommunication or computing system. It describes seven layers, from physical to application, and is the basis for a wide variety of network communications protocols. More importantly, it established the practice of describing such architectures as a series of layers. Its purpose is to guide vendors and developers so the digital communication products and software programs they create will interoperate, and to facilitate clear comparisons among communications tools.

Although useful for guiding discussion and evaluation, OSI is rarely actually implemented, as few network products or standard tools keep all related functions together in the model’s well-defined layers.

• Managing Expectations – Managing a technology portfolio and associated programs or projects includes open dialog with stakeholders about their expectations. Reference models can provide an effective tool for this purpose.
• Explaining Concepts – In addition to use in project management, reference models are useful resources in more general communications.  In many situations, a picture can truly be "worth a thousand words" allowing a concept to be communicated and accepted easily and rapidly.

Notable Examples

Two general reference models have become widely accepted for positioning functionality, managing expectations, and describing fundamental concepts.

The first of these is the ISA-95/IEC 62264 reference model, shown in Figure 2. This hierarchical model is in turn derived from the Purdue Reference Architecture (PERA). It describes five functional levels ranging from the physical process and instrumentation (levels 0 and 1) to enterprise level information systems (level 4).

In response to recent developments and trends such as the Industrial Internet of Things (IIoT) and cloud computing, some have criticized this model as being too rigid in forcing functions to be positioned at a particular level. Nonetheless, as a core concept of the ISA-95/IEC 62264 standards, this model will continue to figure prominently in systems design.

The ARC Collaborative Manufacturing Model (CMM) shown in Figure 3 provides a simple but very useful way to position current, required, or requested functionality within the larger enterprise architecture. This model positions functional elements in the context of three intersecting axes, each representing a specific domain (i.e., Enterprise, Lifecycle, and Value Chain).

The Collaborative Manufacturing Model is one of the fundamental concepts at the core of the ARC Collaborative Process Automation System (CPAS).

Each of these examples has achieved a high level of acceptance and recommendation as a context in which to describe a wide variety of more detailed topics.

The Value Question

Even though a wide variety of contributors and stakeholders commonly use reference models, the quantitative value of such models remains elusive. Although it may be difficult or impossible to assign a specific numerical or monetary value, the qualitative value is much easier to identify.

Here, it is important to remember that just as with art, “[value] is in the eye of the beholder.” This is why applications of reference models should be tailored to the needs, expectations, and perspectives of the intended audience.

When pursuing support and buy-in for a proposed project or development, reference models can provide a convenient framework for identifying the specific functionality being addressed. Positioning functions within such a model is an early step in identifying specific objectives and identifying metrics that will be used to assess success.

With support confirmed, the same models can then be used to identify and describe specific requirements that become the basis for system design and configuration. The combination of models and requirements provides the primary vehicle for clear communication with prospective suppliers. A logical extension would be to use the same models and requirements as the primary criteria for selecting the best option from several possible alternatives.

Increasing Perceived Value

As discussed below, although the value of models is largely qualitative and a function of the specific perception, steps can be taken to increase that value:

• Seek guidance from trusted sources – Reference models are available from a wide variety of sources. When choosing models as the basis for an architecture or technology strategy, it is best to select one from an accepted or widely used source, such as established international standards or an existing reference architecture.
• Keep in mind that the less technical it is, the more useful the model with be – Regardless of the source of the reference model, it is very important that it be presented in simple terms, without requiring an understanding of complex technical topics or concepts.
• Describe inter-model references and relationships – If multiple models are referenced, it is important to clearly describe the relationships between them.

Architecture Domains

Several related models may be used as part of each of several conceptual levels or architecture domains. Figure 4 shows each of these domains and how they are related.

The Business Architecture describes the work or business processes in terms of major functionality and required information flows. Analysis of these processes results in the identification of requirements that are major inputs to the definition of the Systems Architecture.

The Systems Architecture identifies the major functional systems and subsystems, as well as the data that flows between them. This architecture provides an effective tool for identifying overlapping or missing functionality in an enterprise architecture. This functionality is a major input to the definition of the Technical Architecture.

The Technical Architecture describes the information technology infrastructure that supports functional elements. This includes arrangement of infrastructure components (e.g., servers, network devices, etc.), specification of operating systems and other systems software, and the network and security design.

The Product Architecture includes the identification of specific product versions and lifecycle positions. With the process, etc., lifecycle positions, systems and technical capabilities defined, this is the final stage in the definition of specific products or solutions required.

Essential Tools

These and other models are some of the essential tools required for the effective management of complex solutions or systems portfolio. A future ARC report will describe these tools in more detail, providing guidance on their use.

Recommendations

Based on our research and analysis, ARC has several recommendations for owner-operators and other technology users.

Position projects in a broader context – Use widely accepted industry reference models as tools to position a proposed project or activity in a broader context.

Look to leading industry standards – Seriously consider using established and accepted industry standards as the source for reference models. This will help avoid unintended dependencies on specific technologies or products.

Select sources that are practical and not too esoteric – The most useful reference models are those that have been proven and validated in practical applications or case studies. Avoid reliance on complex or esoteric concepts that your stakeholders may find difficult to understand.

Architecture domains - Express principles, models, and standards in the context of each of four specific architecture domains (Business, Systems, Technical, and Product). Clearly describe how decisions in one domain influence or drive decisions in the others.

Share examples and case studies – Describe and share case studies on the use of reference models to serve as illustrative examples.

 

If you would like to buy this report or obtain information about how to become a client, please Contact Us.

Keywords: Reference Models, Scope Definition, Project Management, Architecture, ARC Advisory Group.