Powerful Analysis Techniques (5) – Business and Technical Value Analysis


Subscribe
Marc Lankhorst
Posted by Marc Lankhorst on Aug 29, 2017

Enterprise Architecture

In the previous installment in this blog series, we looked into planning and analyzing change in the enterprise by linking the life cycles of elements such as applications and projects. But how do you decide what to do with, for example, your application landscape? Which applications need to be improved, re-platformed, functionally upgraded, or phased out?

The common approach for this is application portfolio management, which we have described in several previous blogs. Here, I want to focus on the analytics behind charts such as the one below, with the typical business value and technical value axes, the bubble sizes denoting cost and their color showing risk. This type of chart is often used in deciding on the future of applications, and in this example we see four options: Invest (red), Tolerate (blue), Migrate (yellow), and Eliminate (green). This is rather coarse-grained and you might want to use a more detailed set of options, but for this blog I want to focus on how you calculate these values for business value, technical value and risk in Enterprise Studio.

Blog5-Analysis Techniques - image1.png

Of course, there are many factors that you may want to consider in determining the fate of your applications, so the example below is just that – an example – but realistic nevertheless, since it is based on an actual customer situation.

As you will see below, several of the metrics we use to assess business value, technical value and risk are calculated from the structure of your architecture. This really shows the power of using models as a basis for your analyses, something you would never be able to do using simple spreadsheet calculations.

Business value

Let’s start with business value. In the screenshot below, we see how the business value metric is constructed as a weighted average of several sub-metrics:

  • Strategic importance, determined by calculating an application’s contribution to business outcomes, via the business processes it supports, the capabilities it enables, and the business goals these satisfy. This can be done in various ways, from high-level assessments that only determine whether an application has any influence on an outcome, to fine-grained calculations with weighted priorities on goals and strength attributes on relationships. This can all be calculated using Enterprise Studio’s built-in scripting language.
  • Importance for users is itself a weighted average of the number if effective users (those who use an application for their daily work) and the potential users (those that can use it but don’t need it, who get a much lower weight of course). Both these numbers are imported from an external source (in this case an ITSM application). The result is normalized into a [0,10] range.
  • Business criticality, determined by counting and normalizing the number of business-critical processes supported by that application, where process criticality itself is another metric., applied to the business processes in the architecture. This metric is calculated with a script, traversing the model structure to find all the processes directly or indirectly supported by an application and taking the maximum of their criticality metric.
  • Importance for other applications, also a scripted metric, based on the number of outgoing relationships (the ArchiMate triggering, flow and serving relationships, plus write access to data read by other applications).
  • The regulatory compliance level of an application, determined by counting the number of known violations of applicable regulations, normalized to a [0,10] scale. This metric requires a manual assessment by compliance officers.
  • The SLA compliance level of the application is the percentage of time that it is within expected performance limits (e.g. 99.9%). Like the number of users, this is based on information from an ITSM suite. This provides a percentage value that is normalized into a [0, 10] range as well.

Blog5-Analysis Techniques - image2.png


Technical value

The technical value of applications is determined in similar ways. The most important aspect of technical value is the technical quality of an application. This is determined by the various ‘ ilities’ known from standards such as the ISO/IEC 25010 standard for software quality. Some of these will be based on operational measurements of the application landscape. For example, the stability of an application can be based on the number and severity of incidents; its maintainability can be measured based on the relative effort per change.

Other technical value metrics are based on the structure of the architecture and can be calculated using scripts. The (external) complexity of an application, for instance, can be determined by the number of incoming and outgoing relationships (fan-in and fan-out) of the applications. Still other metrics require an expert opinion, for example the architectural fit of an application, the maturity of the technology used, or the quality of the documentation. Data quality is another important metric, which also requires external assessment. And metrics such as usability may be evaluated via a user survey.

Automated analysis of software code quality is performed by specialists such as CAST, one of our partners. The outputs of such an analysis can be imported in Enterprise Studio and used in your application portfolio and lifecycle management as well.

Technology risk

Another highly relevant metric for assessing applications is their technology risk, depicted with the color of the bubbles above. This aggregates a number of risk types such as:

  • End-of-support risk: Risk of an application or technology element going out of support with the vendor. The shorter the remaining lifetime, the higher this risk. This kind of data is typically provided by external sources such as Technopedia.
  • Skill risk: the future availability of personnel with the requisite technical knowledge and skills to maintain an application.
  • Dependency risk: the worst-case value of the end-of-support risk over all the technology on which an application depends. If an application itself is still supported by its vendor, but requires, say, Windows XP to run on, that constitutes a dependency risk.
Next to these metrics, in deciding on an application’s lifecycle you typically also use attributes like size (shown with the size of the bubbles in the figure above), age and cost. This last one, cost, will be addressed in the next installment in this blog series, which deals with financial analyses. Stay tuned!
New Call-to-action

SUBSCRIBE TO BIZZDESIGN'S BLOG

Join 10.000+ others! Get BiZZdesign's latest articles straight
to your inbox. Enter your email address below:

 

Subscribe to Email Updates

comments powered by Disqus