Business Knowledge

A manufacturing client want to understand how its equipment was performing and how its buildings were being used. With twelve sites and hundreds of pieces of equipment, this was going to be interesting.

The board wanted to answer questions about the impact ageing infrastructure has on the business model. The usual way was to instigate a large piece of work to gather the data, but this isn’t sustainable. It costs money and specially commissioned resources. They wanted to know if it were possible to automate something to make important decisions on a regular and ad-hoc basis.

The first place we started was with what reports were needed. Workshops were held the gather the reporting needs, which were used to create user stories, grouped by persona. Armed with what reports were needed, we embarked on an initial fact-finding exercise to discover what data already existed. This revealed a lot of data already existed in automated repositories such as CMDBs and Jira.

Firstly, we looked at the existing business model and ensuring the business capabilities and business functions are up to date and approved by the business. This was an important step because this is where the performance of the business is going to be measured. With the business model agreed, we began building a meta model to hang the data off.

Next, we began with pulling the data together from the CMDBs. With it in a central location. it enabled us to work out how it can be related back to the business model. Using the meta model, we were able to begin showing how the business model is affected by the ‘enablers’ – the business processes, roles, people, technology, infrastructure, software, data, and so on. 

At this point, a tool was used to keep the data in order and to ensure relationships were properly formed. At this stage we had other problems arising. Multiple repositories used different names for the same thing. This caused problems when importing and relating.

This problem needed a framework to ensure they use the same names. As none existed, we developed one. Each repository had to balance up on the same names. It took time, but the result was a total game changer. Suddenly separate groups who would struggle to talk could now communicate with confidence because they all knew something they were talking about was the same across the board.

This name balancing improved the quality of the data being imported, enriching the business model with data about the enablers. From here, things started to heat up. We could now hook up Power BI to the tool and got some really interesting results.

The initial scope was to look at how ageing infrastructure affects the business model. But it was clear much more to be seen. Product Owners, for example, have to be seen to be looking after the applications under their care. Stats produced revealed some Product Owners had so many applications to look after, it wouldn’t be possible for them to effectively perform the role. Meanwhile, the problem of which applications could do with looking at still remained.

We looked at the question from a different angle. The aim was to reduce the number of applications, but they didn’t know how to prioritise the task. The important set of data was the business model. Having a Business Impact Assessment on each business function gave us part of the different angle. The other part was in fact gathered from the service desk system.

The service desk was another repository and after the names had been levelled up, we were now able to gauge the reliability of each application. There were now three main dimensions we could use to determine the priority:

1. Age of the infrastructure the application sits on.
2. The BIA score of the business functions the application supports.
3. The reliability of the application based on the number of calls raised over a two-year period.

We determined that if an application sits on infrastructure over five years old, supports high-scoring business functions, AND has a large number of support calls, then this makes it a high priority for attention. However, if it is on a low-scoring business function and has a small number of calls, then perhaps this application can remain for a while. The old adage of ‘if it ain’t broke don’t fix it’ stands true. We brought in another dimension, which was the number of calls on the infrastructure applications was hosted upon. This raised the priority of some application, but not all.

The results were encouraging. Senior management could now answer many questions immediately, rather than wait weeks or months for the results of expensive discovery projects. It now meant projects could perform discovery work and get most of the answers they needed straight away. 

Carrying on from this, Product Owners now had a central location to go and keep data on their applications up to date on a more regular basis, rather than the once a year or even never as previous. Automation served an important function. Each repository had to keep feeding the service automatically and with as little fuss as possible.

Business architects also had a role to play to keep the business model up to date and fresh. Other important factors for Business Knowledge is controlling development. It’s vital that investment is taking place in the right places. Using Business Knowledge, the first thing a developer must ask is what business functions is my application supporting? If the answer is ‘none’ then development must stop.

Users now get instant answers to their business questions, rather than waiting months. The data is accurate and automated.

Because the data is automatically updated from validated repositories, the outputs from Business Knowledge can also be fully trusted.

Automated collection services ensure the data is delivered in a timely manner, further reducing human error.

Reports obtained will be using data which is no more than 24 hours old. This real-time aspect means the snapshot you take, is the reality at that moment.