In any given domain, a Reference Framework (RF) provides a common backplane for consistency, collaboration, sharing, and reuse. Without a consistent framework, the domain in question will remain an interesting concept but deliver suboptimal business value. With an appropriate RF the work of individual projects, programs, divisions and partners will be coordinated with just enough formality to ensure that the many moving parts can fit together when and were needed.
A RF is needed to:
Often it is not necessary for an organization to invent a green field RF. There are typically various framework initiatives that are in varying stages of maturity that may provide a ready-made RF for a given domain.
It is also quite likely that organizations will wish to integrate with RFs that are already used by them, and coordinate with other RFs in overlapping domains.
However, whilst these may form a useful starting point they may be incomplete in content, or the scope may be too narrow or too broad. Additionally, even those that are relatively mature may be inconsistent with each other in areas where their domains overlap, which is not unusual.
Organizations often cannot simply clone or acquire an industry framework ‘as-is’ without having a major impact on their existing working practices. Forcing major change on the organization may be unnecessary and as well as incurring a major cost, may lead to resentment and difficulties in persuading parts of the organization to comply with a framework, or them only paying ‘lip service’ to it.
Hence, organizations will often find they need to create their own unique RF, or tailor an existing RF to better match their own requirements or to complete missing details.
This research note provides an overview of the process for the creation and evolution of a RF.
A Reference Architecture (RA) “should” provide a blueprint or template architecture that can be reused by others wishing to adopt a similar solution. A Reference Model (RM) should explain the concepts and relationships that underlie the RA. At Everware-CBDI we then use the term Reference Framework (RF) as a container for both as shown in figure 1. Reference architectures, models and frameworks help for example to provide a consistent understanding of topics such as Cloud Computing or Enterprise Mobility.
Unfortunately, such formality is absent from the various reference architectures, models and frameworks that have been published for Cloud Computing; these frequently mix elements of architecture and model, and then apply one of the terms seemingly at random. Hence another reason why organizations will find a need to create their own unique RF that addresses these issues.
In developing the CBDI-Service Architecture and Engineering Reference Framework (SAE) in support of SOA (Service Oriented Architecture) Everware-CBDI separated out various parts as shown in figure 1. We developed a detailed RA for SOA and a RM for SOA, with particular emphasis on a rich and detailed Meta Model for SOA and a Maturity Model for SOA. We also developed a detailed process and task decomposition for SOA activities.
But the RF is easily generalized, where the various elements could be applied to any domain. The benefit of this approach is that elements of the framework can then be mapped to each other in different ways to support alternative perspectives such as different usage or adoption scenarios, or the viewpoint of an individual participant or organization.
Figure 1 – Generalized Reference Framework
An overview of the elements in the RF is provided in table 1. They are discussed in more detail later in the note.
Defines the concepts and principles
Defines the Life Cycle for the key deliverables or assets.
Defines a maturity model against which an organization can benchmark itself
Defines the capabilities an organization should possess in order to be successful in the domain
Provides the common vocabulary that underlies the Reference Framework.
Defines the architectural views at different levels of abstraction.
Maps best practice to each of the views. Identifies the deliverables for each view, and the policies, patterns and standards that apply to each view.
Architectural Views can be expressed in terms of the meta model which defines the key concepts, deliverables, and assets.
e.g. the subject of a policy should be a concept in the meta model
Defines the decomposition and sequencing of activities that take place relative to the domain
Process model should reflect how the life cycle state changes of the key deliverables or assets are accomplished, and how the deliverables or assets will be transformed from one architecture view to another
Defines the roles and responsibilities of the participants in the domain, and the skills they require
Organization defines the roles and responsibilities which regards to the key deliverables and assets, as well as the participation in the process
Table 1 – Elements of the Reference Framework
The extent to which each of these elements is detailed will depend on the requirements and objectives.
These elements are not isolated but related to each other as highlighted. The real value is often in the mapping that can be made across these elements. Hence focusing on only one element may be less productive in the long term if the other elements are not addressed at some point.
Figure 2 – Establish Reference Framework Process
Figure 2 illustrates a high level activity diagram of the process to establish a RF. Activities include,
The process is likely to be iterative. For example, you are unlikely to define the complete meta model before defining the architectural views. Much of the meta model will be discovered or refined whilst defining the views.
Again, the amount of effort spent on each of these activities will depend on the requirements and objectives.
As discussed in the introduction, whilst organizations may use an existing RF as their starting point, they typically still need to create their own unique instance that best matches their specific needs.
Hence the place to start evolving a framework is to understand requirements and to assess the suitability of existing frameworks.
The first step should be to articulate the business value that may be derived from the RF in order to support decisions relating to collaboration and sharing. This is essential in order to justify the investment and to get management buy in and support.
Similarly it is important to establish the scope of the RF and its intended audience. The scope of the RF is determined by the extent of the domain which it covers, and its organizational reach or applicability. It is essential that the organization understands the boundaries of the RF.
An understanding of the objectives for establishing an RF will help to drive the RF activity and perhaps focus the work on specific elements. Ask some straightforward questions to establish the purpose of the RF, for example,
An organization may already use one or more frameworks and they need to be reviewed to assess:
Existing architectural frameworks may already contain extensive details of existing assets and provide valuable input to the RF. Some elements of existing frameworks may be immediately useful, particularly data architectures and logical models, application asset registers and integration schema definitions. However there will usually be differences and gaps in the underlying meta model that will render the information less than complete.
Enterprise Architecture (EA) frameworks such as TOGAF, DoDAF, MoDAF, FEA, etc., may provide a good starting point. These will often contain a high level cross section of many of the elements of the RF, but not at sufficient detail for a specific domain. Also, by their nature they may be more abstract than is required for a specific domain, where the vocabulary needs to be domain specific.
Conventional enterprise architecture describes an information system in terms of structural properties of the system. The architecture identifies components, building blocks, standards, policies and products which form the basis for planning and guiding systems delivery.
Not surprisingly new domains can introduce change to the structural properties. There are new and different building blocks, standards etc. These don’t necessarily replace the existing properties, mostly they complement and extend. However there are also areas where fundamental differences apply, for example in areas such as scoping and applicability, security models, reuse policies and so on, and we need a new model that combines the old and new in a cohesive whole.
Assets are the key deliverables that an enterprise wishes to track and manage. They will reflect concepts in the meta model. In addition the relationships (dependencies) between assets are also important to manage. In modern agile environments, there are typically many moving parts, which is what can potentially deliver greater agility. Hence identifying them and showing how they will be governed as they move through the life cycle is essential. For example to help resolve issues with versioning and impact analysis in complex component- and service-based systems. It is therefore absolutely critical that asset inter-dependency is:
To manage the domain therefore we require a framework that defines and manages assets throughout the entire life cycle. Tasks here include,
One of the defining characteristics of any methodology is the structure used to capture the relevant aspects or perspectives of a system, whatever system that may be – business, information system, hardware, or what have you. The RF includes five views – Business, Specification, Implementation, Deployment, and Technology. These views comprise a consistent level of abstraction for deliverable artifacts that relate to distinct set of stakeholders. This provides an effective mechanism for grouping practices, deliverables, policies, etc., based on a particular stakeholder view or perspective.
The framework is organized by view, and within each view there are key architectural elements that together provide a coherent approach.
To establish the framework each of these architectural elements must be defined and guidance provided sufficient for the purpose of the specific enterprise, to guide or govern appropriate levels of consistency.
The reference process should provide a consistent view of the activities required to plan, architect, enable, deliver and manage assets, services and solutions relevant to the domain. The reference process shows how the necessary state changes to the key deliverables and assets will be achieved.
The reference process may be decomposed or organized along the following lines,
A discipline is performed by roles which have the ability to execute the process units and tasks defined for that discipline or a work package. While some companies might establish a team that corresponds to a Discipline, others organizations might design more fluid organization structures.
To perform these tasks, roles must possess the appropriate skills.
Responsibility for key deliverables and assets can also be assigned to roles. A RAEW matrix may be appropriate for this – setting out which roles have Responsibility, Authority, possess the Expertise, or do the Work.
The RF should be more than a pretty picture or report that is read once by people and then filed away.
Ideally it should be a living document that provides a growing body of knowledge on the domain that interested parties will return to for guidance, to access useful templates and tools, and to collaborate in its development.
At a minimum the RF should be published as some form of wiki that can be gradually extended, rather than a fixed report.
It is beyond the scope of this report to look at the following in detail, but these are all related activities that should be considered
Without enabling the RF through these kinds of capabilities the RF runs the risk of politely ignored!
The Reference Framework or Architecture will not emerge by accident from pilot or pathfinder projects. Larger enterprises need to take a structured approach to delivering the levels of architectural commonality and diversity that are appropriate for the organization at evolving states of maturity.
A more complete and detailed version of this research note, together with task definitions and accompanying assessment and planning tool in Microsoft Excel format is available to our CBDI-SAE Knowledgebase subscribers.