New regulations can seem like a major hurdle in any industry. The problems come from a lot of directions. Take the existing regulations. The Compliance team is often the only place where you’ll find certainty that what you’re doing at the moment is within the regulations. The operational staff only think they’re compliant because that’s what they were told by Compliance. The IT staff have no idea because they’ve never spoken to Compliance. Yet the whole business could be fined or worse if Compliance is wrong. New regulations can pour a whole lot of extra trouble into that mix.

The Head of Compliance often carries the weight of all that trouble but good enterprise architecture can remove some of the burden. The key to understanding how that is possible is a simple realisation: if new regulations are coming into force, the only reason you are changing the business is to meet those regulations and that makes them the top-level requirements. No ifs. No buts. You might use it as an excuse to tack some process improvement on or put a new application into service. Take away the new regulations and you might do those anyway.

That might sound a bit basic but you’d be surprised how easy it is for an organisation to lose track of that. Even when the programme is named after the legislation, the people involved rarely have any idea if what they are doing has any regulatory implication. A junior project manager might never know whether the database they are upgrading is genuinely important or just one of the process improvements. Good enterprise architecture can also change that.

The regulations are the reason you’re changing the enterprise so they’re the point that the architecture team should start. That means sitting with the Compliance team and working through the legislation. It might sound like it has nothing to do with architecture but think of the regulations as the top-level requirements. You should think of them that way because they are the top-level requirements. By recognising them as such, you can base the architecture on the regulations.

The main conceptual leap that an architect must make when working with Compliance is to realise that almost all legislation can be directly expressed through architectural artefacts. Take the following from Solvency II:

“The risk margin shall be such as to ensure that the value of the technical provisions is equivalent to the amount that insurance and reinsurance undertakings would be expected to require in order to take over and meet the insurance and reinsurance obligations.”

That can be expressed as Report and Control artefacts. An architect can get to that by working with a Compliance officer or analyst.

You can even take it a step further and do as ClassiQ has done. We built a compliance framework so that the Compliance team can work with Business Analysts to produce a list of the artefacts needed to achieve perfect regulatory compliance. When the artefacts are built, the compliance team gets a matrix of the legislative clause directly to a business artefact. That means the Head of Compliance never has to fear a visit from the regulator. Compliance with any clause can be proved beyond a doubt within seconds.

The architecture team can also communicate the fact that some artefacts are absolutely required by the legislation. So the Programme Director knows exactly what is critical to success. The operational staff can understand that a boring spreadsheet that takes three days to produce keeps their team in a job. The IT staff can know that a particular database that only gets used once a year is actually proving something to the regulator.

Some might fear that building compliance in from the start could lead to the architecture becoming bogged-down by the legislation. In fact the opposite happens. Building it in gives the architecture more flexibility because it allows architects to understand instantly whether there are any legal ramifications in making a change. That in turn allows the architects to give better advice when the next strategic change options are being considered.