In a recent blog posting I showed how semantic models can be used to take a number of regulatory submissions from banks and normalise them to make systematic comparisons of their Risk Data Architectures without getting lost in the weeds of vendor specialisations and technical preferences.
Let’s now expand on this approach and look at how we might broaden the use of this technique for more general architectural activities, applicable in all business sectors.
A background to TOGAF
TOGAF is the de facto global standard for Enterprise Architecture. It offers a framework for defining what an IT-related architecture should comprise, and whether a practitioner is competent, based on a well-supported certification programme.
The key artefacts produced by TOGAF are Catalogues, Matrices and Diagrams. While Catalogues and Matrices are well understood structural concepts, Diagrams are where the weaknesses really lie. Currently, Diagrams are classified as follows: Vision, Business Structure/Processes, Data, Application Estate, Technology Estate, Opportunities and Solutions.
You can download the sample set here.
So what’s the problem with a TOGAF Architecture diagram?
A diagram is probably best defined as ‘a graphic design that explains rather than represents’.
I spent my childhood living in a house that doubled as an Architect’s office. In the pre-CAD era of the 1960/70s, everyone had an A0 (841mm by 1,189 mm [33.1 in × 46.8 in]) paper-size drawing board so the drawings naturally were high resolution, created with 0.5mm Rotring pens and Letraset, which had just replaced bow pens and inkwells.
Sadly in the IT architecture “profession” the CAD tool of choice tends to be Powerpoint (because it is bundled in MS Office on most PCs) and the maximum resolution used is typically 1024x768, so being able to explain things is naturally weakened due to the lack of canvas space. More detailed diagrams are conducted in Visio (which is licensed separately) but the largest size these tend to be drawn to is A3, which most corporate laser printers/copiers can handle.
As a result we have evolved a cadre of IT architects who are lauded more for their graphic design skills, working on a small visual canvas, rather than any real grasp of the core subject matter or the engineering and process techniques needed to solve large scale information problems.
As an aside, ‘real’ architects take five years to gain their qualifications in the UK and have a formal curriculum of continuous professional development as they are a regulated safety critical profession.
More worryingly, there are also many cases of Chief Architects and CTOs in Financial and related information services refusing to accept architecture diagrams unless they are authored in Powerpoint!
It can be reasonably argued that trying to shoehorn the illustration of complex business and technical concepts onto a piece of A4 paper 1/16th the size of A0 poses a significant risk to any transfer of knowledge in an IT project.
So how do we make things better?
The answer is to focus on the information content and model, and worry about rendering separately. BCBS 239 marks a turning point in the banking industry because it is designed to help enforce completeness and tries to measure and classify complexity. We now also have Reg-SCI to contend with, to ensure operational stability. Measures like these have already been implemented in the construction and engineering industries, driven by economics and safety concerns.
Today there is now a direct tool chain from the CAD tool (Revit, Solidworks etc.) through to the laser cutters, 3D printers and CNC lathes that produce finished goods. To achieve this you need to have a complete information model that enables the automation software (CAM) to interpret the drawing and generate the G-Code that actually performs the printing (aka additive) or cutting (aka reductive) manufacturing process.
As I mentioned above, real architecture is a safety-critical industry so not only is there a straight-through manufacturing chain, but also a range of simulation and stress calculations that can be applied to the architecture before committing a design to be manufactured and built. When did a bank last do that?
It’s pretty clear that our industry needs to do better in this area. So where should we start?
The answer is to start with the output: the XBRL. Every commercial enterprise has to report its results in XBRL to its national corporate reporting and tax authorities (In the UK, this is Companies House and HMRC).
It is the summary of what the business does, for example, how it is organised, its income and expenditure. When you think about it, every function in a company contributes to the final outcome, even if it might be regarded as some form of overhead.
We need to look more deeply at the Who, What, When, Where, Why, and How components of a data point in a report rather than just the data entities’ applications and flows that are really at the heart of the BCBS 239 Risk Data Architecture regulations.
So Org charts (Who), Policies (Why), Minutes (When), Regulations (What/How), Contracts (Where), and Process (How) specs must all now become linked entities and artefacts in an Enterprise Architecture – a change to one affects the behaviour of others, and that change needs to be kept and recorded just like we do in a version control system for software development.
This all sounds rather Orwellian – how will it work in reality?
What is actually happening here is a bit like joining the dots or painting by numbers: We have the XBRL output that must exist for the company to meet its regulatory and tax obligations. The architect’s job is to ensure that he can explain how those obligations are met and what new documents will have to be produced if the company seeks to change its goals/objectives/mission.
The mechanism used to join the dots is Semantics: all the documents that are the key artefacts that capture how a business operates and evolves are nowadays stored by default in Microsoft or Open Office equivalents as XML and can have semantic linkages embedded within them. The result is that no business document can be considered an island any more – everything must have a reason to exist.
So why hasn’t TOGAF gone the semantic route already?
There have been a number of academic papers published that have considered the possibility of defining semantics-based Enterprise architecture models, including this one.
What has been lacking up to now is something concrete to orient these models towards, and be able to show value rather than just being a science experiment. The standardisation of XBRL for both financial and regulatory reporting will, I believe, be the catalyst for change as it provides a foundational Rosetta Stone-like document from which to build out references to the architectural artefacts of the systems that deliver its component datasets.
Clearly there will be a lot of resistance from the ‘finger-paint and crayon’ architecture and consulting community who have made a healthy living from drawing nice Powerpoint slides. But the scale and complexity of business challenges in an era of ever increasing digitally processed regulations requires a rethink, along the lines of what the physical engineering professions have done.
The creation of a global corporate reporting standard for all companies, not just those in the financial sector, has enabled the definition of a clear goal of what an Enterprise Architecture function within a corporation must achieve i.e. to be able to explain how the company achieves its goals, rather than merely using graphical representations.
By using semantics as the foundational technique to denote explanations in a consistent fashion, organisations are now able to analyse at scale the artefacts that comprise the mandatory financial and regulatory outputs. They are also better able to guide and alert users to prioritise business enablement work versus ensuring completeness, or rectify errors or anomalies.
TOGAF has done a reasonable job in trying to define a framework that helps explain what a system or overall IT architecture does, but there is a gaping chasm between the naïve sketches that are produced by most practitioners today and CAD CAM CNC toolchains that are the norm in physical engineering industries.
We need to move beyond the text-based definition of architectural ‘completeness’ to actual measurement of conformance. Only then will we be able to compare and drive evolution rationally and systematically. Using semantic technologies enables this to occur at scale and quickly.
Just as ‘real’ architects replaced the Rotring pens and Drawing boards with CAD software, my guess is it won’t be too long before today’s IT architects ditch the Powerpoint slides.
By Rupert D.E. Brown, CTO, Financial Services, MarkLogic Corporation