In the current series of posts on areas of possible overlap between architecture modeling tools and other initiatives, we looked at interfaces to technology (CMDB integration), project management (project planning integration) and the strategic level (strategy maps and business models). In this post I’m going to return to an area that is more the ‘home turf’ of architects – applications, and in particular application inventory management (also known as application portfolio management).
Most organizations that need to engage in architecture modeling will also have some level of management of their installed applications. Usually, there’s an effort to assess the operating costs of the applications in question, and to rate them on various measures such as:
- Business fit - how well does the application meet the needs of the business?
- Technical fit – how well does the application meet the technical needs of the organization?
- Criticality – how badly would the organization be affected in the event of downtime or security breach
Establishing and tracking these measures then acts as an input into recommendations for improvements and consolidations to the application landscape.
It turns out that there are particular synergies between these two areas – in particular, the information contained within the architecture model can inform these specific ratings with a much greater degree of rigor than simple estimation. The key to our approach depends on the way that architecture modeling is, to a large extent, about mapping different elements to each other; the more mappings an application has, the higher it should score in that area.
We can start by assessing business fit for the application. Now, business fit is a measure of how well the application supports the operations of the business – and one measure of this is going to be how many business processes use the application. By examining this metric, we can gain an estimation of the extent to which the business depends on the application.
Now let’s consider technical fit. At first glance, this seems almost impossible to estimate, but it turns out that we can assess how well an application meets technical needs by examining technical compliance. I can’t recall an organization that did not have a certain number of architectural principles. Indeed, it’s hard to imagine any form of architectural governance that could operate without technical principles and still show a level of rigor in decision-making. We can examine the level of compliance to our architectural principles for a given application as input into our estimation of a technical fit score.
Last of all we’ll consider how our architecture models can help score our applications for criticality. Criticality can be assessed in two ways. For the first, we can examine the business processes that the application supports and consider how critical the process is to ongoing operations. The more critical the processes mapped to an application are, the more critical the application is. Second, we can examine the data entities that the application accesses. The more critical the data accessed by the application is, the more critical the application.
There’s an element of opinion when estimating any score, but in this post I’ve outlined how the architecture model can influence the scoring of application inventories.