Co-Author: Puneet Dua
Organizations all over the world are dealing with the challenges of an ever-changing business architecture landscape and are in search of business strategies, tools, and applications to overcome these challenges. From modernizing their legacy systems to creating new applications to identifying the right business strategies, the architects are looking to align enterprise architecture (EA) with IT in search for right answers. This enterprise architecture approach is seemingly more significant and relevant to today’s world but at the same time is intricate and possesses a tough challenge for many organizations.
The enterprise architects along with the business strategy and solution architects are trying to define enterprise architecture landscape by solving either one architecture layer at a time or creating a cross functional mapping involving multiple architecture layers. The most common way to define architecture elements is via standard architecture frameworks such as TOGAF, Zachman, DODAF, BIZBOK, FEAF etc., guiding architects in their first step of defining a robust meta model. The definition of the meta model is very significant from architecture landscape definition and works like a heart to a body.
Although all organizations try to adhere to the guidelines set by standard architecture frameworks, there are always deviations because of the changing landscape and unique architectural environment that exists within each business landscape. Thus, necessary changes are made to the meta model to accommodate the architectural changes which might be a need from organizations’ standpoint and cannot be avoided. In such a scenario, it is highly imperative that the architecture remains relevant with the right meta model changes and proper roadmap is followed in order to avoid unnecessary changes to the meta model and achieve the goals set out at the start of the journey.
Most organizations start by mapping the enterprise landscape via business architecture elements like strategy map containing vision and mission, enterprise capability map, value stream map, and business processes etc. and do not face too many problems. But the architects start facing issues when they initiate aligning business processes with IT to understand the impact, and the cross-functional mapping of architecture elements start becoming highly complex and convoluted. Sometimes, the business architecture meta model loses its structure and is not robust anymore with the business processes.
The pit falls for not having a healthy architecture is detrimental to an organization’s architecture initiative and might raise many issues in the long term. Issues arising due to an unhealthy architecture include:
- Leads to incorrect meta model
- Unstructured data
- Data redundancy due to architecture overlap
- Alignment to standard frameworks not known
- Undefined architecture roadmap (next steps)
The measurement of the architecture health is one of the most important factors to guide an organization or the architecture team in realizing the current state and to determine the road ahead.
The measurement of architecture health can be done by measuring the meta model and data currently in use and referencing the same across standard architecture or multiple architecture frameworks.
The architecture health at any point can be determined by collecting the following data points:
- Number of architecture elements in use
- Number of relationships in use between architectural elements
- Number of attributes used to define the architectural elements
- Data available for the architecture elements
After identifying the architecture data points, an evaluation can be done against the ‘architecture database’ which contains information from various architecture frameworks. The referencing will enable the architect to understand and take the right steps to improve the architecture database health by monitoring certain key metrics continuously.
Key metrics for monitoring architecture health
- Percentage of completeness of the meta model
- Architecture health (low, medium, high) along with improvement potential
- Percentage of data completeness of each architecture element
- Automated architecture roadmap
The metrics listed above can provide an insight into the current architecture database health and help the architects to identify next steps. This will also help the architects to properly map out the architecture roadmap by identifying the next architecture element that needs to be defined and data to be collected for further analysis. The benefits of monitoring the architecture health continuously results in:
- Clearly defined roadmap
- Properly mapped architecture elements across different architecture layers
- Structured data
- Reduction in rework
- Define value for architecture work
One of the most important aspects is to be able to determine the value of the architecture work that has been done over the months or years by measuring the architecture health continuously. This will help the architects to identify the potential improvement areas in the legacy systems and improve the architecture iteratively. The chances of rework and data inconsistencies will also be greatly reduced if the architecture health is monitored and managed properly through continuous improvement.
The need of the hour is to understand the heart beat of the architecture and manage the heart in a proper way so that the architecture body does not fail in the long run.