At the heart of the TOGAF standard is the Architecture Development Method or the ADM. The ADM is a generic framework designed to be used every time there is a requirement for Architectural work within the organisation. The ADM is broken up into phases that represent logical areas and these phases are further broken down in steps.
This blog post will cover the phases A-D. The Preliminary and Phase A, and Phases E-H will be covered in future blogs.
This blog will talk about the details of the phases in turn, but it’s important to note that the ADM is designed to be flexible in its use and consideration should be made during the preliminary phase about which phases are appropriate to complete and in which order. Don’t feel like you have to follow this rigidly if it doesn’t fit your business model, mix it up and make it work for you.
B. Business Architecture
The Business Architecture Phase is the first of the Architecture Phases and follows immediately from the Architecture Vision. It is important to define the Baseline in order to establish the starting point of the work requested. Depending on what Artefacts have previously been created for and stored for reuse within the Business Repository you may need to create a fair amount of baseline documents, including:
- Business Capability Mapping: decomposes the capabilities required for the business to deliver value to the stakeholders
- Organization Mapping: a view of the organizational structure of the business, depicting business areas, and dividing them into core functions. Finally define the relationships between the areas and their functions.
- Value Stream Mapping: the activities that are performed to create the value to the stakeholders
- Structured Analysis: identifies the business processes affected by the architecture, and maps those into the relevant business areas
- Use-case Analysis: the breakdown of business-level functions showing how different users consume and interact with proposed architecture
- Process Modeling: the breakdown of a business service through process modelling
You can use Business Catalogs, collections of available resources ordered by actors to create new Business Building Blocks for the architecture. Matrices, showing the way that things interact with each and diagrams that show the architecture from different views are also important ways of describing and documenting the architecture. Business Process Modelling is a common and important output of these steps. Whether through UML, Class Diagrams, Sequence Diagrams, the use cases should be documented dissected and understood. The activities that users needs to complete the process and add value back into the organisation are crucial to enabling future steps.
From these you can define the target architecture and complete a Gap Analysis to identify areas that may have been missed or highlight areas that need to be developed to complete the solution. At this point, you can review across the existing Architecture landscape to understand whether your architecture impacts any other existing architectures and begin to identify how to reconcile these differences.
C. Information Systems Architecture
This Phase consists of separate sub phases, one for Data and one for Applications.
Data
As with all phases, start by going back to the Repositories and identifying existing artefacts like the Business Architecture and Data Principles defined by the business. Create appropriate Matrices, Diagrams and Catalogs Rationalize data requirements and align with any existing enterprise data catalogs and models; this allows the development of a data inventory and entity relationship
Update and develop matrices across the architecture by relating data to business service, business function, access rights, and application ensuring a focus on examining how data is created, distributed, migrated, secured, and archived throughout the organisation.
With Data the significant factors to consider are, is this a master record or a reference record? How will the data be consumed by the rest of the organisation? And how is that data secured? (Interestingly this is a people question as much as technology, consider rbac etc).
Application
Again, start by going back to the Repositories and identifying existing artefacts to support with this design. Consider the viewpoints that need to be considered, i.e. is this a customer facing or internal system and pick out the tools to capture the data, model it and analyse it for best structure. Diagrams and Catalogs Rationalize data requirements and align with any existing enterprise data catalogs and models; this allows the development of a data inventory and entity relationship
Update and develop matrices across the architecture by relating data to business service, business function, access rights, and application ensuring a focus on examining how data is created, distributed, migrated, secured, and archived throughout the organisation.
The recommended process for developing an Application Architecture is as follows: (shamelessly taken from TOGAF Standard 9.2, I can’t explain this better).
- Understand the list of applications or application components that are required, based on the baseline Application Portfolio, what the requirements are, and the Business Architecture scope
- Simplify complicated applications by decomposing them into two or more applications
- Ensure that the set of application definitions is internally consistent, by removing duplicate functionality as far as possible, and combining similar applications into one
- Identify logical applications and the most appropriate physical applications
- Develop matrices across the architecture by relating applications to business service, business function, data, process, etc.
- Elaborate a set of Application Architecture views by examining how the application will function, capturing integration, migration, development, and operational concerns
The important point about the Data and Application sub phases is that they will often be completed alongside each other. You may find you start with data, continue with application, then repeat several times until the application definition is refined to a point that you have your target architecture.
Once you have it, complete your Gap Analysis, compare the the existing landscape to resolve impacts before committing back to the requirements management.
D. Technology Architecture
Make one more trip back to the Repositories and identifying existing artefacts to support with this design. Create Diagrams and Catalogs and Matrices as required, focusing on the Technology aspect of the Architecture. When we talk about Technology in this context, we are usually referring to the shared infrastructure that powers IT solutions. Think Cloud, Servers, Licences, PCs etc. You want to consider these requirements in line with Location of deployment, performance requirements, costs, professional standards and best practices and look at impact of installing, maintaining and fixing it if it breaks. You may need to hop back to the business stream for some of this if you need new processes for any of this.
Next, make your Target Architecture and Gap Analysis, compare to the existing landscape to resolve impacts.
The importance of this phase is about determining the principles of emergent technologies and whether that invalidate your existing Technology principles. Think about installing a Web Application and how it has evolved over the years. In the past you’d have had your own physical server with an IIS instance in it (or Apache) and need to maintain the server and application separately. Then virtualization came along and we started to see single servers hosting many instances. More recently we have seen Serverless Compute or Applications as a Service through providers like Azure or AWS and finally, we see the most recent development is containerising applications through things like Kubernetes. It would be reasonable to assume most companies have not embraced the latest technologies due to lack of skillsets or costs to migrate and this is entirely acceptable for the business to choose, but they should be aware of the wider evolving landscape to be able to identify and potentially embrace opportunities for streamlining or cost reduction (or mitigate risks like systems going LTS or removed).
Masters Development 