ADM Governance

How and should the Architecture Development Method be managed?

The ADM should be governed and managed. It is important that the management of all processes and artifacts are supported by a Governance Repository. In addition, the Architecture Board should be satisfied that the Architecture Method is being applied correctly throughout all the phases of the ADM iteration. Any proposed architecture should comply with the ADM as compliance is fundamental in terms of the governance of an architecture. Compliance will ensure that all the necessary deliverables are produced and all considerations pertaining to the architecture are made.

What is a Governance Repository?

The Governance Repository is used to manage different types of information for a proposed architecture – specifically:

  • Information about auditing that has occurred – this audit information generally records all completed process actions related to Governance.
  • Any reference information / data – reference data is used for direction and instructions during the implementation phase of the project.
  • Process status – this information pertains to the state of any governance processes

Narrowing the scope of architecture activities

There are many reasons to narrow the scope of an architecture activity; specifically:

  • Taking into account stakeholder and objective concerns that need to be addressed in the architecture
  • Constraints pertaining to the availability of resources (E.g. people or finance)

The specified scope for an architecture activity should allow all the work of all architects working within the enterprise or organisation to be effectively unified and governed. A specified scope will ensure that there is no cross over in terms of work activities being produced. In addition, a scope will also require the definition of reuse and the the way architecture architecture partitions relate.

When limiting the scope of an architecture activity there are four different dimensions that can be utilised:

  1. The Enterprise focus or scope
  2. The four architecture domains (Business, Data, Application and Technology)
  3. The level of detail otherwise known as the “Vertical scope
  4. Project schedule or “Time periods

When first starting to narrow the scope of an architecture it is usual to express the scope in terms of: Enterprise Scope, Time Period and the level of detail.

When the scope of the organisation is known, then an applicable combination of Architecture Domains can be selected which are inline with the problem being solved.

Ensuring integration and consistency across different organisational teams.

It is possible that different teams or people across the enterprise or organisation may be working on the same proposed architecture(s). Therefore there is the need to ensure that there is consistency and that any outputs can be easily integrated. This is where the Integration Framework comes in.

The Integration Framework sits above the individual architectures and can be an Enterprise Framework or a Meta Architecture Framework. The main purpose of the Integration Framework is to:

  • Ensure that architect(s) understand how the various components fit into the proposed architecture.
  • Develop the architecture models that meet the enterprise level capabilities
  • Define the compliance and conformance specifications that will allow the easy integration of the architecture components

The Enterprise Framework is a content framework which is used to position the different artifacts or domains.

A Meta Architecture Framework which may contain items such as standards, guidelines, principles or models) ensures the migration, conformance and interoperability between architectures.