Enterprise Architecture 

 Network Architecting Metamodel

Enterprise Architecture is awash with frameworks, models, methods, taxonomies, ontologies and other confusing and potentially conflicting terminology.

This page is an attempt to set out the fundamentals and their interelationships for Network Architects, adopting a pragmatic approach and in accordance with the KISS principle. Occam's Razor is not used as further justification (paraphrased as "simpler explanations are, other things being equal, generally better than more complex ones") as anyone who has tried to undestand the nuance of that particular law of succinctness will likely to have become even more confused.

A metamodel describes concepts and their relationships for the purpose of building and interpreting models that themselves are an abstraction. In other words, a model of related models. The following metamodel sets out primary components of EA from a network architecting perspective and describes their inter-realtionships and application. The primary components are:

  1. Architecture Development Method (ADM) - using the TOGAF9 ADM;
  2. Framework;
  3. Taxonomy;
  4. Reference Model; and
  5. Architecture Repository.
Metamodelmodel

Architecture Development Method

The TOGAF ADM is a cyclical (i.e. accounts for lifecycle and ongoing architecting) model/method that is applicable or adaptable to any context or cicumstance, particulalry at this high level.There are two other main parts to TOGAF, besides the ADM:

  1. The Enterprise Continuum that "provides context for the leveraging of relevant architecture assets and provides navigational help when discussions move between different levels of abstraction", and
  2. The TOGAF Resource Base - guidelines, templates, checklists, and other detailed materials supporting the TOGAF ADM.

The TOGAF ADM provides a best-practice model for the development of architecture from concept through implementation, change and lifecycle management and for the development of architecture assets. This ADM also provides for an architecture-agnostic means to bridge architecture efforts between different EA practices where, for example, a provider and a client may use different frameworks, or where multiple providers deploy different frameworks for the same client.

It also combines Information and Systems Architectures as Phase C, whereas the EA Taxonomy of this web site separates them as two distinct levels. The ADM can be readily adapted to accommodate Information and Systems as two separate levels when defining architectures.

Framework

An architecture framework is a tool which can be used for developing a broad range of different architectures. It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks. (The Open Group)

A service provider's framework needs to be one that is externally focused. It needs to be adaptable to each customer's environment; and to bridge the frameworks of those customers who have adopted their own.

Components:

  1. Operational and Business Context, and Governance. The overall context in which architecting is undertaken, the internal and external constraints on the business and its use of ICT and the model under which a customer's ICT is managed:
    • Customer profile and demographics which shape the architecture taxonomy particularly where another primary provider may be a participant in the customer's ICT;
    • Regulations - those constraining a provider's services and the customer industry-specific regulatory environment (e.g. Payment Card Industry;
    • Data Security Standard) that affect ICT; and
    • Customer policies and standards as they relate to ICT.
  2. Architecture Domains providing the organisation with the methods, processes, discipline and organisational structure to create, manage, organise and use models for managing the impact of change at the levels of:
    • Business Architecture;
    • Information Architecture;
    • Systems Architecture; and
    • Infrastructure Architecture.
  3. Architecture Descriptions provide a mechanism for standardising the documents that define the architecture of an enterprise. Architecture Descriptions can include, or be entirely constructed from the Architecture Views.
  4. Architecture Library, the Enterprise Architecture framework defined from the architecture descriptions lodged in the Architecture Repository and the tools contained within it.
  5. External influences upon the Architecture:
    • Operational and Business Context. Describes the external setting which influences and shapes the way an organisation operates.
    • Governance, Compliance and Coordination. The internal influences upon the customer's environment.
    • Fundamental Inputs to Capability. Major drivers to the actual operations of an organisation - infrastructure and personnel.
    • Research and Technology. Impact of research activities and technological advances (realised and predicted), both within and outside the organisation.

Taxonomy

A Taxonomy is a classification scheme. It allows for complex ICT environments to be broken down into increasing levels of detail while identifying the relationships and interdependencies between architecure segments and their component parts and is an indispensible part of EA practice for aligning all design work for common purposes and outcomes.

Architecture segments should be described at increasing levels of detail as determined by the requirements. Architecture segments can be set out in Systems Breakdown Structures, which can form Architecture Views.

Architecture Segmentation is a high level representation typical of a large organisation's architecture, whether it has been formally defined as such or not. In such an example, network services would be one of the possible Segment Architectures together with ICT services such as centralised computing, security or hosting etc. Each such Segment Architecture can be separately represented as Systems Architectures. In the telecommunications segment, these may typically be network, security, unified communications etc.

Collectively, those telecommunications architectures from a System-Of-Systems, as would the combined components of any other Systems Architecture such as a mainframe operations service.

The Segment Architectures also collectively form an ICT System-Of-Systems, and so on at the higher levels of the segmentation.

Reference Model

The Reference Model is intended to assist in the development of architecture within a specific domain, or layer, of an organisation to:

  1. Create standards for both the objects that inhabit the model and their relationships to one another.
  2. Communicate: Break down a large problem space into smaller problems that can be understood, addressed and refined.
  3. Break a complex process into entities and define how these differ from, and relate to, one another. Create clear roles and responsibilities.
  4. Allow the comparison of different things. By breaking up a problem space into basic concepts, the reference model can be used to examine alternative solutions.

The Reference Model is used to develop the Architecture Phases set out in the ADM. It sets out generic components for each Architecture domain (Business to Infrastructure), and the primary Architecture Development steps from Baseline Architecture to Architecture Definition that applies to each of those domains.

The example provided is from a Network Architect's perspective and sets out the steps applicable through each of the 4 architecture levels.

Reference models are useful for a wide range of purposes and multiple models can be used in the development of an architecture. Examples include:

Architecture Repository

A repository of all artifacts produced from design efforts for potential re-use.

Building blocks are replicable components, that based on the way they are configured, together make up an architecture. A building block can be any component, available for replication and may be physical, logical, virtual or theoretical and could be any of:

  • Systems and their component hardware or software;
  • Networks;
  • Services Catalogue items;
  • Designs;
  • Processes;
  • Practices;
  • Principles; and
  • Artifacts such as Architecture Views.

                                                                mainpage

                 Business Architecture Information Architecture Systems Architecture Infrastructure Architecture