Understanding the structure of an enterprise

When you first approach enterprise architecture for a large organisation it can seem like an impossible mess. The usual situation that happens is discovery of a mess. The closest things to architecture available are a few process diagrams, some out-of-date procedures in Visio diagrams, an org chart and a long list of IT systems. The board or the key stakeholders have started to devise a strategy for the enterprise but no one seems quite sure what it is or how much it will cost.

That’s where you come in. There’s a big chunk of stuff that has grown up in an organic fashion over decades and you’re the only one with any idea of architecture. Surprisingly, the approach you need is quite simple. You don’t know the architecture and neither do they but they know the important people involved. So you get your initial list of stakeholders.

If there has never been any serious attempt at enterprise architecture in the organisation, the stakeholders will have no idea what’s about to happen and you can seem like a magician.

The trick is to understand that all enterprises are based on a sets of categories. Everything that any organisation does, owns, uses or produces can be broken down into categories. If you choose the categories well, you can describe an organisation in a way that will help the stakeholders achieve the strategic goals and they will understand their part in that achievement. In enterprise architecture terms, these categories are the Architectural Artefacts.

As an example, recently a client of ours needed some help. They’re an old finance company with very little in the way of enterprise architecture. Some new EU legislation (Solvency II) was coming into effect and they needed to provide the regulator with a big chunk of accurate data or they could be closed down. They’d already spent a lot of money with one of the big consultancy firms and they’d had more than twenty people on site building a big solution.

Only that work didn’t deliver. After a year, the only thing they had was a £2m+ bill. The programme delivered nothing to help them achieve compliance with the new regulations.

As part of the restart, we were brought in to help. For us, the most important thing was to get the artefacts right. To put parts of the business into categories. Thankfully, that’s a well-worn path. So we just selected a subset of the standard architectural artefacts that are used within the finance industry. In this case: Procedure, Process, Application, Repository, Data, Report, Role, Technology, Goal, Indicator, Regulation, Control, Risk and Document (as in legal document).

Had we just gone in and asked the stakeholders what they were going to do to achieve compliance, the answer would have been a mishmash of requirements. Instead, by dividing the enterprise into a set of artefacts, we got the answers that the stakeholders needed and understood.

The whole programme was based on legislation so we knew the architecture had to be based on the Regulation artefacts. However, a big list of artefacts doesn’t do much good. There needed to be some structure for them to be useful. Thankfully, most artefacts are very easy to organise into hierarchies. A set of procedures form a process; a set of applications form a parent application; and so on.

The artefacts within the hierarchies often link to artefacts of the same type. Applications talk to other applications; procedures pass data to each other. Most importantly, artefacts often link to other types of artefact. A Procedure artefact uses an Application; a Goal artefact might use an Indicator that gets information from a Report; a Risk artefact needs one or more Control artefacts; a Procedure often has a Role responsible for it; etc.

The hierarchies of artefacts and links between them are the enterprise architecture. If you understand them, you understand the enterprise.

In the case of our client, the Regulation artefacts needed other business artefacts to achieve compliance. Because we helped them understand the artefacts and how they related, it meant they were able to rebuild the programme with far more focus. They didn’t need a team of twenty and a big consulting firm. They were able to achieve full compliance with the people they had. They could do this because the links between the artefacts showed which teams needed to work together to achieve it. The architecture showed what existing artefacts were used and what new ones needed to be built.

Enterprise architects help the key stakeholders understand the implications of proposed strategies. Then they help to design, plan and oversee the construction of an enterprise to realise the chosen strategy. All of this comes through understanding the artefacts.