A Vision for Architecture in the New AI-augmented World

AI is in the mainstream: there is no refuge or bastion to defend. As with every paradigm-shifting technology, AI brings with it both game-changing opportunities, but also well-founded concerns: inflated or spurious expectations, unethical usage, loss of human control, opacity of operation.

In our previous blog, we looked at why you need to codify and manage your architecture, the benefits that can bring (objectivity, consistency, transparency, testability), and mentioned some of the AI-enabled use cases for improving architecture, for which architecture-as-code is an absolute pre-requisite. We’re now going to extend that view and take a broader look at the architecture discipline: its purpose and fitness for the future, where AI augmentation can genuinely have a positive impact, and therefore why architects need to have hands-on experience of AI capabilities.

Remember why architecture is needed

Take a step back and consider the bigger picture: what is architecture for? Clearly, without architecture, there is chaos: in IT terms, architecture describes the technology landscape and its relationship to the businesses which it implements. Architecture describes the current state – with all its inherent legacy issues – together with the progression towards the utopian target: it guides strategic planning and technical direction. Architecture therefore must be scientific: architects, in common with other scientists, must hypothesise (question and experiment) and apply rigour (proof) in the interests of furthering knowledge and understanding.

Comprehension, of both your IT architecture and the processes around it, will highlight areas of redundancy or inefficiency that can be removed or mechanised. Codification is a pre-requisite for automation – but to automate what? If the current processes of architecture have been neglected, or have evolved organically, then look to improve and reengineer the processes to take advantage of new technologies and techniques, whilst retaining the reason for their existence.

So, the relevance of architecture does not fade; indeed, with an ever-changing technology landscape, architectural governance to retain coherence and control would appear to be needed more than ever.

Embrace AI – there’s no avoiding it

Resistance is futile. There’s no point being an AI-Luddite: as individuals, everyone needs to have a working user knowledge of the technology. As well as using AI capabilities day-to-day – as a tool, in the same way one uses a spreadsheet – a working understanding of AI will mean that as architects, we’ll also be much better able to determine its applicability to the architecture discipline.

One key AI technique is RAG: retrieval-augmented generation. In summary, RAG is providing a generic LLM with a content store of specific knowledge, and then carefully constructing prompts for the LLM to interpret the data in the content store. Using the architecture-as-code repo as the RAG content store makes the architecture transparent and accessible: understandable and open to interrogation, either through code or natural language.

As hinted earlier, generating the architecture data is not trivial: the data sources are diverse and contain data in unstructured and heterogeneous human-readable formats. Parsing these, and referentially linking and reconciling them, isn’t possible without machine-assist: indeed, for a large organisation, imagine attempting to manually parse and distil the incoherent edifice of documents, web pages and other collateral in which “the architecture” is indistinctly manifest! But AI can also be used to process this melange, the output of which can then be much more readily checked for veracity by SMEs from the relevant domains.

There are various opportunities for AI-augmentation of architecture, when a RAG solution is fed with a content store populated with architecture data:

• Generating filtered views of your architecture: your entire architecture can’t be shown realistically in a single diagram (unless you’re in the market for some distinctly unfashionable wallpaper), and creating a meaningful filter on the dataset is something a well-constructed prompt can do very well, especially if the requestor is not fully conversant in the terminology of the architecture dataset. The output of that filter can then be driven into whichever representation is required: quite likely a diagram (in any appropriate model), but just as easily in any consumable format to aid a decision-making process.
• Automating architecture processes: agentic AI (orchestration of services with some level of AI autonomy) can be used in automation of processes, and the processes or architecture are ripe for overhaul with these tools. Creation of architecture deliverables, quality and content validation, process control gates – it’s rare to find any of these that are not entirely manual, and the associated wastage and inefficiency can certainly be remediated, whilst retaining appropriate human oversight: management by exception.
• Deriving tests of the architecture: architecture-as-code incorporates the concept of ‘policy-as-code’, and enterprise-wide consistency and quality can be improved via the use of assertable tests based on documented architecture constraints and patterns. As well as leveraging RAG to generate codified tests from human-readable definitions and then running those tests automatically (see previous point), AI can also be used to find further undocumented patterns (and indeed deviations) – and to then specify further tests which embody them.
• Modelling scenarios to support strategic decision-making: AI can also be asked to make projections about future change: “what if” questioning can determine, for example: the impact of a proposed architectural change, the costs of technology re-platforming, or to fully quantify the risks associated with a critical business service. This technique adds greater empiricism to strategic decision-making, and if architecture-as-code is fully implemented, branching to create a sandbox for experimenting can add even further confidence.

There is an important observation across all the above: AI does the heavy lifting, followed by human experts validating and refining the generated material. We’d assert that this is always AI best practice: AIs do hallucinate, and produce well-formed and therefore convincing prose, so their output should always be carefully scrutinised. AIs can only act based on the model they have internally constructed, and therefore human operators will be continually required to monitor and correct them. Quis custodiet ipsos custodes? Alert governance and active oversight is, and will remain, crucial.

Get your hands dirty – but dig in the right place

Architects are obviously best placed to know where the most significant problems are with the architecture processes in the organisations we work for – and as with most situations, it’s advisable to get a handle on the “biggest rocks” first. AI tools are very powerful, but they need good data to produce results, and therefore the slice of the architecture-as-code data model which supports the chosen use case will determine the data that needs to be codified initially. Also, don’t fall into the trap of coalescing the storage of architecture data with a specific representation: keep the capabilities separate, to avoid constraining the possible benefits – or recreating the same problems (e.g. opacity of data) that exist in traditional architecture tools.