There are 14 practices under General Management practices. And the architecture management practice is the first practice under it.
If you are familiar with ITIL V3, then you would know about the configuration management database (CMDB) and configuration management system. Architecture management practice is an extension of CMDB. It’s scope stretches well beyond what the CMDB was catering to.
Abridged Version of this Article Available HERE
Understanding the Objective
Let’s take a look at the purpose of the architecture management practice.
The purpose of the architecture management practice is to provide an understanding of all the different elements that make up an organization and how those elements interrelate, enabling the organization to effectively achieve its current and future objectives. It provides the principles, standards, and tools that enable an organization to manage complex change in a structured and Agile way.ITIL 4 Publication
Let me break this definition down further.
The architecture management practice provides an understanding of all the different elements that make up an organization and how those elements interrelate.
In this, if we replace elements by configuration items and organization with service, this is the definition or objective of a CMDB. So here in the architecture management practice, we are going beyond services, so you have the organizational elements as a major driver rather than services. And since we are going beyond services, the make-up can well and truly be beyond configuration items (CIs), so they have referred to it as elements instead.
Interrelating the elements or configuration items is an inherent feature of CMDB and it remains unchanged here.
The second part of the definition reads:
…enabling the organization to effectively achieve its current and future objectives.
It’s talking about the why. What is the benefit that we derive out of understanding the different elements – which is basically helps the organization in reaching their objectives, both current and future.
The final part of the definition reads:
…it provides the principles, standards, and tools that enable an organization to management complex change in a structured and Agile way.
This is the change that comes in ITIL 4 where the architecture management practice provides guidance on the principles of various service management activities, the practice acts as a capability for setting standards and choosing the tools that are necessary for the organization to function.
To be more specific, for the organization to meet the current and future objectives. How do we do it? We do it in a structured and Agile way. In other words, the setting up of principles, standards and tooling decisions doesn’t happen in a big bang approach. They will be done over a period of time, in an iterative manner, which is indicated by the Agile way.
Sub-Practices of Architecture Management
There are 5 sub-practices in the architecture management practice. They are:
- Business Architecture
- Service Architecture
- Information Systems Architecture
- Technology Architecture
- Environment Architecture
Let me explain each of the sub-practices in some detail.
An organization’s purpose is to deliver value and meet customer’s expectations. To do this, they would need certain capabilities. Examples of capabilities can be AWS management, Python scripting, Banking, Creating Interior Designs among others.
These capabilities are inherently within the people in an organization. So the organization must have the data points, means and mechanisms to keep a database of all their capabilities and the organization has to build a system to check if the capabilities that are on hand are sufficient to deliver value or do they need to build more capabilities.
For example, an organization may not have Big Data capability which potentially adds value to one of the customer’s processes.
The business architecture sub-practice is partly like a HR function. They exist to strategize the capabilities that are needed to deliver value. And then to identify the capabilities that currently exist.
Based on the shortfall, a plan to meet the goals are some of the responsibilities of this sub-practice.
The service architecture sub-practice is the service model or the CMDB that we are familiar with through ITIL V3.
This sub-practice ensures that all the services that are delivered to the customer are known and their dependencies between services and with third parties is also mapped out.
This will help organizations plan for redundancies and to map out strategies for managing vendors and service providers.
Information Systems Architecture
We are in the information age. And not to be cheesy, but it is true that information is power. For something as important as information, can you imagine that we did not have a process in ITIL V3 for its management. Well, that part is covered here in ITIL 4 which is great news.
The information systems architecture sub-practice identifies the various physical and logical data stores, and comes up with a database, a map if I could say so to search for the required information as and when needed.
Think about it like Google indexing. Google knows exactly where the data based on keywords exist. Within a fraction of a second it can retrieve the data. And this is exactly what the information systems architecture sub-practice intends to do. Not build a google like system but more in terms of indexing the information stores.
While data retrieval is paramount, the other part of information systems is the data itself. How does the data get formed, how is it managed, how do we ensure its integrity and who can access it. These are some of the information management activities that the sub-practice takes responsibility of.
In the CMDB, we had various layers starting with business processes, IT services, applications, infrastructure and so on. The technology architecture sub-practice takes care of two specific layers of the CMDB – the application and infrastructure layers.
Basically, the sub-practice like the other sub-practices needs to get a handle on the existing technology assets be it infrastructure or software. Then the other management activities like upgrading, patching, accessing among others kick in. Pretty basic stuff that is in practice.
The environmental sub-practice is more outward looking rather than looking at what the organization has internally. It deals with the various external dependencies.
No organization can indigenous when it comes to serving their customers. The value created is possible with the help of service providers, vendors, governmental agencies among others. The target of this sub-practice is to understand all the external dependencies and create a blueprint for its management.
The various environments or external dependencies can be there for technology as in depending on COTS products or infrastructure vendors, other businesses, service providers like setting up optic cables, regulatory for complying with the law of the land, legal, political, economic and ecological are some of the other external factors that matter. This list is not comprehensive by any means.
The architecture management practice is key and foundation practice. It helps organizations find feet and stay in control. This practice is one of the first practices that I would recommend for implementation first.
[…] may have read the text version of the unabridged version of architecture management practice earlier this […]