Requirements Management Process

The Requirements Management Process is used throughout the entire Architecture Development Methodology life-cycle in all phases.

It’s key objective is to address the requirements of the enterprise or organisation, store the requirements and then pass the requirements to and from each ADM phase when required.

The Requirements Management Process is what drives the ADM and this is why the Requirements Management Process is at the center of the ADM life-cycle as shown below.

It is imperative that an architecture is able to handle changes in requirements as by its very nature an architecture is subject to changes such as:

  • Stakeholder uncertainty regarding requirements and solutions
  • What was proposed and what can actually be delivered (e.g. Constraints may force a change in deliverables)
  • Drivers and constraints outside of the control of the ADM or enterprise, such as changes in technology, new legislation for example

Phase H – Architecture Change Management

The main objectives of Phase H or the Architecture Change Management Phase are:

  • To appraise the efficiency and performance of the architecture and provide proposals for when the architecture may need to be altered.
  • To ensure that the proposed architecture is able to achieve the specified business values.
  • To ensure that any baseline architectures can continue to evolve e.g. Changes in the business or technology may force baseline architecture(s) to be altered.
  • Determine the circumstances and provide a process which will allow the architecture to be modified after the deployment.
  • Assess any changes to the principles and framework which have been created in the previous phases of the Architecture Development Method.
  • To use and administer the Governance Framework.

It is worth understanding that Phase H or the Architecture Change Management Phase is extremely pertinent to the processes pertaining to architecture governance and management of the Architecture Contract.

Phase G – Implementation Governance

The main objective of Phase G or the Implementation Governance Phase is to bring together all of the relevant information pertaining to the various implementation projects – specifically:

  • Ensure that the deployed architecture conforms with the implementation projects
  • Ensure that the actual solution is deployed successfully
  • Generate suggestions for each of the implementation projects
  • Manage and govern an Architecture Contract for the actual implementation and deployment
  • Implement the appropriate governance functions pertaining to the system while it is being deployed and implemented
  • Ensure that any future supporting operations are started.

Phase G or the Implementation Governance Phase is where the association between the architecture and the implementation organisation occurs; this connection is via the Architecture Contract.

To make certain that the Architecture Contract is both competent and effective there are five main aspects of the Governance Framework which should be introduced during Phase G; they are:

  1. Communication
  2. Ensuring processes are as straight forward as necessary
  3. Authority is centered around people
  4. Any responses should be timely with an effective and efficient escalation process.
  5. Aspects should support the organisation structures

Phase F – Migration Planning

The main objective of Phase F or the Migration Planning Phase is to place the varying implementation projects into order based on their priority.

The main activities of Phase F are to assess the costs, benefits and dependencies of the varying migration projects.

All of the projects in the priority list will then become the basis for the Migration Plan and the implementation Plan. It is at this point that an Architecture Evolution Cycle is established which will ensure the architecture remains relevant. Any lessons learnt or feedback should be documented for future reference to enable a more streamlined approach moving forward.

Phase E – Opportunities and Solutions

The objective of Phase E or the Opportunities and Solutions Phase is to:

  • Identify the important phases of change
  • Any known parameters
  • High-level projects / Work packages
  • Any new business opportunities that arise from architecture work during previous phases

That will need to be undertaken when moving from the current environment to the new environment. Any outputs from the Opportunities and Solutions phase will be the initial step in modelling the implementation plan for the target architecture.

Other objectives during the Opportunities and Solutions phase are to perform a gap analysis between phase B (Business Architecture Phase) through to phase D (Technology Phase). In addition, during this phase it is important for the architect to review the capabilities and objectives of the business.

A full review (And confirmation) of the organisation or enterprises current parameters should be taken in order to see the effect of any proposed changes.

The definition of the solution building blocks should also be done and a set of transition architectures should also be derived.

Finally, an overall strategy outlining the Migration and Implementation should be generated and agreed upon with the relevant stakeholders.

When implementing Phase E or the Opportunities and Solutions Phase it is important to understand that this phase is the first phase which is directly concerned with the actual implementation.

On occasion, when identifying any new implementation opportunities a new application may be identified. If and when this occurs, it may be necessary for an architect to revisit and iterate over the previous phases.

Phase D – Technology Architecture

The objective of Phase D or the Technology Architecture Phase is to define and develop the Technology Architecture that will:

  • Identify any candidate Architecture Road-map components using a gap analysis based on differences between Baseline and Target technology architectures.
  • Enable any physical and logical data and application components as well as the Architecture Vision
  • Address any stakeholder concerns and requests for architecture work

Specifically, the Technology Architecture should be able to describe the current and target views of the technology portfolio. These views should identify the key work components and build a road-map toward the proposed Target Architecture.

When implementing Phase D or the Technology Architecture Phase the architecture team will need to acknowledge any Technology Architecture Resources that are available via the Architecture repository and most importantly, are these resources relevant?

There are a vast array of existing Information Technology Services resources already available – these resources include:

Finally, it is important to understand that new emerging technologies can be a major catalyst for organisations or enterprises seeking to improve their business operations.

Any Technology Architecture should be able to understand and implement any new opportunities that may arise via the adoption of new technology.

Phase C – Information Systems Architecture

The main objective of Phase C or the Information Systems Architecture is to develop the target architecture for any Information Systems.

The Information Systems Architecture can be broken down into two separate architectures:

  1. Data Architecture
  2. Application Architecture

The Information Systems Architecture should be able to describe in detail how the enterprise or organisations Information Systems Architecture will facilitate:

  • The Identification of any Architecture Road-map Components based on a gap analysis
  • The Business Architecture
  • The Architecture Vision

Data Architecutre

The main objective of the Data Architecture is to determine the sources and types of data that will be required to support the organisation or business. It is imperative that the Data Architecture should be able to be easily understood by any stakeholders.

Application Architecture

The main objective of the Application Architecture is to determine the specific types of systems that will be required to process any data and to support the organisation or business.

Phase B – Business Architecture

The main objective of Phase B or the Business Architecture Phase is to develop the business architecture that will describe how the enterprise or organisation will need to function in order to reach the business goals that have been specified.

In addition, another objective is to identify the candidate architecture road-map components which are based on any gaps between the target business architectures and the baseline business architectures.

Other key objectives pertaining to Phase B or the Business Architecture Phase are:

  • Elicit any business requirements and identify any existing material that may be able to be reused.
  • To demonstrate to stakeholders the business value of any subsequent work and what return on investment they should expect to see.
  • Describe the baseline Business Architecture
  • Analyse any gaps between the Target Business Architecture and the Baseline Business Architecture.
  • Identify and develop the architecture viewpoints that are relevant.
  • Demonstrate how end stakeholder requirements and concerns are addressed in the Business Architecture
  • Identify and select any techniques and tools that are relevant and can be utilised within the selected viewpoints
  • Identify any existing architecture definitions that may be able to be used as a starting point when creating the architecture

The key aspects when approaching the Business Architecture Phase are:

Approach one -The most common approach

  • An architect must understand that the extent of work in the Business Architecture Phase will directly depend on the the enterprise environment. It is important to be aware that in some instances important elements pertaining to the Business Architecture may be completed within other activities
  • Where the key element may be completed in other activities the architect may be required to verify and update any current or ongoing business plans and strategies. In addition there may be the requirement for the architect to connect between business strategies, business drivers (At a high level) and goals on one-hand and the specific requirements of the business on the other.
  • Where none or a small amount of Business Architecture work has been completed the architect must analyse and research, verify and achieve buy-in to the main business objectives and processes that the architecture must support.

A secondary approach

Establishing the Baseline Description

Where the business has existing descriptions of the architecture. In this scenario, then these descriptions should form the basis for the Baseline Description. Where no architecture descriptions exists, then information should be obtained and the relevant Business Architecture Models developed.

Implementing Business Capabilities

Use the the business capability map that was either found or developed during the Architecture Vision phase. The business capability map should provide a self contained overview of the current business or enterprise organisational structure, IT systems, applications and any other business processes.

A third approach

Using the organisation map – An organisation map displays any key organisational partners, units and stakeholder groups the form the ecosystem of the enterprise or organisation. The organisation map should also display any working relationships between these entities.

Mapping and modelling techniques which may be provided are extensions that will implement the business capabilities, organisational maps and any value streams into actual business practice.

In addition to any value streams, business capabilities and organisational maps a assortment of other techniques may be employed. These techniques may be Class Models, Use-Case Models and Business Process Models (Commonly referred to as Activity Models).

Phase A – The Architecture Vision

The main objective of the Architecture Vision Phase is to develop a high-level vision of capabilities and the business value that will be delivered to organisation as a result of the proposed architecture. In addition, there needs to be approval for a Statement of Architecture Work which will define the program of works to be developed.

Other objectives within the Architecture Vision Phase are:

  • Creation of a comprehensive work plan
  • Obtain commitment of management and obtain formal approval and go-ahead.
  • Validation of the business drivers, goals and principles
  • Identify stakeholders their concerns and objectives
  • Define any business constraints and business requirements
  • Define the scope of and priortise architectural tasks
  • Describe any appropriate solutions
  • Organise and define an architecture development life cycle
  • Provide and describe an Architecture Vision

The key aspects when approaching the Architecture Vision Phase are:

  • Provide a formal definition of what falls both inside and outside the scope of the architecture effort and any constraints. It is important to understand that constrains are informed by business goals, strategic drivers and principles.
  • Create an Architecture Vision document and clarify and agree on the purpose of the Architecture.
  • Provide a high-level description of the Target and Baseline architectures.
  • Determine which Business Scenario Technique will be utilised in order to develop the Architecture Vision.

The Preliminary Phase

The main objective of the preliminary phase is to provide the definition of how an organisation will develop its architecture. A key objective within the Preliminary Phase is to get the buy-in of all the relevant stakeholders.

Other objectives within the Preliminary Phase are:

  • Developing an “Architecture Footprint” which consists of the people who will be performing the architectural work, their specific responsibilities and their location.
  • Defining and understanding the scope and any assumptions that are being made
  • Define the method and any frameworks that will be utilised throughout the ADM
  • Confirmation of any support framework that will be used and also to confirm a governance
  • Selection and implementation of any supporting tools that may be used
  • Define any architecture principles that may limit the architecture work.

The Preliminary Phase should be thought of in terms of defining the following in the enterprise:

  • Where
  • What
  • Why
  • Who
  • How

The key aspects when approaching the Preliminary Phase are:

  • Evaluating the architecture maturity of the enterprise
  • Defining any relationships that exist between management frameworks
  • Defining the framework that will be utilised
  • Defining architecture principles that will drive the architecture work
  • Define the actual requirements for the architecture work
  • Defining the Enterprise
  • Identifying key elements and drivers in the context of the organisation.