Posted: 14th Feb 2021
Author: Eden Yorke

Most businesses will know about their products, how they are made, who buys them, and where they are sold across the world. In most cases, knowledge of the business capabilities is ingrained into the psyche of the senior management and the board. Each business unit knows its place, knows what it needs to do to fulfil the mission, so where is the problem?

To answer this, we need to ask some questions:

• What Business Capabilities do you have?
• Do you know what Business Functions you have and how do they relate to the Business Capabilities?
• Is there a catalogue of Applications and what Business Functions do they support?
• How old are your Applications?
• Can you list all the Business Processes?
• Do you know what Applications are sitting on burning platforms?
• Are all your core Business Capabilities supported by sound Business Functions?
• Are any core Business Capabilities being supported by end of life Applications?

If you cannot answer any of these questions immediately, then how do you? One approach we have seen over the years is for a task force to be set up, usually consisting of expensive consultants. They would run about, having meetings, interrupting the working day, digging into repositories, and would come up with a comprehensive report – after three months. But what if you wanted to create a new Business Capability to move into a new market? What would be the impact if you needed to move quickly or miss a lucrative opportunity?

Enter Business Intelligence Data. This shows you in an instant what the business does and how it does it.

If you’ve not read our article on how important is a meta model, then click here and have a look. This is a framework for you to build your business intelligence data onto. Using the meta model, you can build a repository which will start to answer the questions above.

Below is an example of a business intelligence data model. This is the top half, what constitutes the business model and its enablers. 

While this is a simplified view, how does this compare with a large expensive PowerPoint presentation, or a bunch of catalogues such as Applications or Data? Imagine if you had access to this sort of data? It is very powerful knowledge and all at your fingertips.

The model above is the top part of the model, which I see as the most important. The top boxes are the Business Capabilities. They are provided by the Business Functions across the middle, and they are in turn supported by the Applications across the bottom. 

With the relationships in place, we can see exactly what Applications support what Business Functions, and what Business Functions provide what Business Capabilities. So, why is this interesting? Why would anyone want to do a load of data collection and get this into an ordered state?

The secret lies in the attributes (the small font) in each object. It’s these that will show effect on the rest of the model. If you look at the BIA (Business Impact Analysis score) for Monitoring & Collection, this is quite high and we would interpret this as something that could be lost for a long time. Failure due to a local incident, loss of a service, or prevention from using a building will be fine for a couple of days. However, the New Customers Business Function has a very low score. At 1, it demonstrates every effort should be put into getting the function back up and running as soon as possible, if not immediately. Using this simple measure will determine the threat and risk for the Business Capabilities they deliver.

If we start looking at the Applications, we can see there are more attributes to gain insights with. As with the BIA on the Business Functions can show the risks to Business Capabilities, we can use the attributes on the Applications to show the risk they pose to the Business Functions.

For example, the Agent Processor Application is in production (Lifecycle: Prod) and went into production on January 2017. That makes the Application four years old (at the time of writing) and might need some attention. It is also a useful measure if one of your architecture principles is not to have applications that are over three years old, then this could be a measurement for you to show a slight degrade in the Business Functions it supports.

If we look at the SalesForce Application, we can see it went EOL (End-Of-Life) in January 2020. Any EOL Application will dramatically any measurement of the Business Functions they support. However, in this case, a new application is coming along, SAP, which is in pre-production. But as SAP isn’t in production, this, coupled with the EOL status of SalesForce degrades the measurement of the New Customers Business Function.

That was quite a mouthful. The intention is to show how the attributes of Applications can degrade the Business Functions, by being EOL, or even being ready for decommissioning. 

Now you can see how your applications effect your business model, lets now explore what makes up the application. This provides another angle to which to explore risk. Data and applications sitting on burning platforms, software modules with out of date updates, test or trial licenses which may suddenly prevent an application working, and adversely effect important parts of the business. Down at this level, expect to automate as much as possible. New infrastructure, especially with cloud deployments coming and going by the second, will rapidly change. 

Above is a representation of one of the applications, broken down to it’s constituent parts. Expiration dates, owners moving, and over-worked product owners, all can put the business capability model at risk. While the application can be deemed as end of life in the last few months, it should have been decommissioned a few years back.

I can hear you all saying so what? You have collected this data, related all the objects, so now what do you do? First off, identify the gaps:

• Where do you have Business Functions without Applications?
• Do you have Applications that don’t provide at least one Business Function?
• Are there any Applications you don’t have Software Modules?
• Have as many attributes been gathered as possible?

You will find that as the gathering process matures, the data will get easier and quicker to collect. To begin with, we have found gathering as many objects as possible, without concentrating too much on attributes, sets out a canvass into which more details can be added later. Attributes are important, obviously, but they can clutter the collection in the beginning. Getting a good relationship with the owners of these objects to begin with will bring more benefits later when you need those important details..

Now that you have gathered all the objects, related them, got as many attributes as needed, again, so what?

You have at your disposal a set of data that will give an insight into your business, which before this, you would have had to rely on hearsay, old reports, large-scale data gathering exercises, and endless PowerPoint presentations.

Anyone can now look at the data and using different viewpoints, gain an instant understanding of areas of interest.

• The board can be ensured that the investments in process and technology are going to the places that need it.
• Cloud migrations become simpler.
• Migration to Zero Trust is simplified because you know where everything is.
• The board can see if a new market they want to enter can be supported.
• Business Architects can see where changes are needed to adapt for new markets and products.
• Application teams can be warned of impending end of life software.
• Better deals for licensing can be obtained when you know exactly what software is being used.

And also you can now answer the questions I opened the article with:

• What Business Capabilities do you have?
• Do you know what Business Functions you have and how do they relate to the Business Capabilities?
• Is there a catalogue of Applications and what Business Functions do they support?
• How old are your Applications?
• Can you list all the Business Processes?
• Do you know what Applications are sitting on burning platforms?
• Are all your core Business Capabilities supported by sound Business Functions?
• Are any core Business Capabilities being supported by end of life Applications?

These types of relationships are where there are two objects linked by a third. It works a little like this: A is related to B, B to C, so A must be related to C. If you look at the two diagrams above, we can follow this logic from the Asset Management business capability down to the Oracle Enterprise software module. Therefore, there is an inferred relationship between the two. It is then possible to discover what business capabilities are supported by a particular piece of software. If the software is out of date, it can sow these business capabilities are at risk.

One of the simplest inferred relationships is to show the applications supporting business capabilities. The application is the highest level of technology you can use to discover risks to the business capability model. End of life and decommissioned applications are of most interest when deciding where to invest. Pumping money into parts of the business which are not core is okay, but when the deciding factor is how loud someone can shout, it can result in core business capabilities losing out and the business suffering.

This is just the beginning. The model we have shown here is a sort of core; the bits you need to get value from the exercise. As more stakeholders get value, the model can be expanded to include other elements of the business. You can show how data is effected and how data effects the business model. Epics created from goals set by the board’s vision can be related to the objects they are going to create, alter, or remove.

Keeping any repository such as this needs constant updating, pruning, and management. Automation where possible is key to success. Tools designed to manage business knowledge know this and provide interfaces to do much of the heavy lifting for you. These tools also give you a secure API (Application Programming Interface) through which external systems can send updates automatically. When data is sitting in an external system, the tool can go out and collect and sort the data for you.

There will always parts of the model which will need to be manually updated. The business capabilities for example, unless modelled in another tool, will need manual intervention. Otherwise, automation will bring together information from disparate repositories to give you valuable insights by joining things you might not necessarily think don’t naturally join together.

We hope you found this article interesting. There is so much more to capturing business intelligence than what we have laid out here. There are software which can manage this data for you, and others which can work in the portfolio and strategic space, which then generates the Epics, relating them automatically to the objects they are effecting.

If you would like to know more, then please don’t hesitate to get in touch.