Composing functional architecture

A functional architecture consists of a description and design for the set of capabilities/functions that the enterprise utilises in pursuit of its aims and goals. Assuming that the aims and goals are well understood, the capabilities/functions required to deliver them can be designed and described using a consistent frame of reference. Furthermore, there is a choice of mature approaches for accomplishing this task that have been employed successfully across a broad range of industries. We will briefly consider two of them:

• Zachman Framework
• The Open Group Architecture Framework (TOGAF)

Any framework for describing and classifying architecture needs to be flexible enough to work at each layer comprising the architecture and will provide different levels and types of specialist detail to different audiences.

Zachman provides a grid that can be completed using a set of simple interrogative prompts as columns and different points of view, or audience types, as rows. The content can be as detailed and specialist/technical as needed and in addition can reference externally held inventories and other specification documents as required. The objective is to provide meaningful descriptions and definitions that are of use to the enterprise. Often the project to complete the framework stimulates debate which itself articulates key decisions and issues that need resolving within the enterprise.

A detailed exposition of the Zachman Framework and its use can be found here: https://zachman-feac.com/zachman/about-the-zachman-framework

The TOGAF content framework also provides a means of consistently classifying, describing, and designing enterprise architecture. It is more proscriptive in relation to implementation as it is intended to ensure alignment across all the enterprise architecture domains, or layers including implementation and metrics/measures. Because it specifically includes metrics/measures, the TOGAF content framework can be used more easily to manage transitions/transformations: not only representing the current enterprise architecture but also quantifying the delivery of desired future states.

All artefacts produced using the TOGAF content framework are delivered under a project methodology. Architecture principles are defined and used to take stakeholders’ requirements and the enterprise (business) strategy as the guide for delivering documents, diagrams, and inventories of architectural components. These are then used to describe and define the current enterprise architecture, as well as any desired future states. This emphasis on describing and deriving architecture in relation to requirements is fundamental to TOGAF, as are the plans for implementing and managing transitions/transformations, which are also included in the framework’s classification system.

A detailed exposition of the TOGAF Content Framework and its use can be found here: https://pubs.opengroup.org/togaf-standard/architecture-content/chap01.html#tag_01_02_02

Further discussion on defining a strategy and negotiating priorities with stakeholders can be found in:

• “Developing a strategy in business”
• “Negotiating with stakeholders”

Although the TOGAF content framework can be used without a requirement to employ the Open Group’s methodology, the classification’s approach does drive  alignment here, likely due to its emphasis on practical implementation. Therefore, rather than get too tied into a particular approach (methodology) we will apply principles from the Zachman framework and Open Group’s content framework to derive an example of a functional architecture oriented around the capabilities, or functions, that the enterprise might provide.

As we have illustrated above, functional domains such as Finance, Sales, and Manufacturing are first defined and then their constituent functions are stipulated. These form the large scale, or course grained, functions and the finer functional capabilities which compose them. The concept of ‘granularity is important here as defining these constituents too coarsely  or too finely will affect their reusability when composing solutions across the enterprise.

If we consider this model to be at ‘ level 0’ with respect to definition detail, we can continue to subsequent levels of detail according to our priorities and the benefits we are intending to derive from our efforts. In practice each level 0 component of our model could refer to a catalogue or inventory of the same name which contains the various enterprise architecture assets for lower level definitions in documents and diagrams. It is common to define the architecture to about 3 levels deep for most purposes and up to 5 levels deep for more specialist analysis and design.