Tooling up with AI to get a grip on your architecture

“Legacy” is a term often applied to IT, and it brings up connotations of complexity, fragility, rigidity. Architects need to remediate this situation, whilst actively supporting the delivery of cost savings, rationalization, simplification, business outcomes – without making the problem worse by bolting on more components and continually implementing tactical fixes. It’s almost impossible to do this without deterministic knowledge of the current landscape.

Can you comprehend your architecture?

What’s the fundamental prerequisite for understanding architecture? Data. The root of the problem – and it’s a deep tap root – is (at best) patchy, incoherent descriptions of architecture and technology:

• Solution designs are impacted due to the lack of a coherently documented current state, and the problem gets progressively worse: every new solution design adds to the shifting, unstable edifice of all the previous ones
• Architecture is manifested as static, analogue diagrams – these are usually created by hand from scratch in visual UIs, and are both resource-intensive and unlikely to be correct (and drift from reality only increases over time)
• Delivery diverges from the specification: sometimes for good reason, but these changes are usually not tracked – and therefore remain undocumented
• Proliferation of direct implementation of ungoverned solutions with a combination of end-user office applications and SaaS platforms (“shadow IT”)
• New technologies are added to an already cluttered environment without consideration of coherent, rational implementation of capabilities
• The drivers for change (risks, issues, goals) as well as the mechanism for change (line items, work packages, financial allocations) are often undocumented

All the above are compounded into a toxic cocktail when the impact on strategic decision-making is considered. Without correct, comprehensive data that is free from subjectivity, one is reduced to estimation when trying to prioritize the most urgent work to address the most serious IT risks, rationalize to a common set of technologies, or simplify the application landscape.

Why you need to codify your architecture

To reach and maintain appropriate levels of objectivity, quality and correctness in the data describing architecture, a level of rigour is needed that is normally associated with software engineering. This is known as “Architecture as Code” – applying the same levels of control to the data that describes your architecture as you would to the code that implements it. The architecture data is versioned, managed and tested (committed, peer-reviewed, branched) in a code management tool such as Git. Fundamentally, the Architecture is the Data – the architecture is explicitly not frozen in analogue diagrams.

There’s something of a mindset shift here – challenging but ultimately bringing significant benefits. Evolving the Practice of Architecture away from human-centric analogue processes brings about generation of diagrams from data, automated governance with testing for consistency and standards, and direct integration of the architecture code into delivery pipelines. Imagine that: architects become integrated into the end-to-end engineering team, directly enabling positive change rather than frustrating or obfuscating delivery.

Populating the central store of your architecture data is also not trivial, in much the same way as other business-critical aggregated datasets: customer data, transactional data, data about individuals connected to the organisation. Whilst this is a tough nut to crack, the good news is that there has been some interesting thinking and tool deployment in this domain. The raw material is a jumble of hand-written documents, confluence spaces, stores of domain knowledge, application catalogues, production telemetry… the list goes on. What’s the common factor here? All this data is human language – and so you can immediately deploy modern LLM-based tools to process and evaluate it.  AI-augmented data discovery can take on a lot of the grunt work in generating the codified data you need – and there’s a crucial role for domain experts and architects in reviewing and polishing that generated data. Furthermore, referentially linking those disparate datasets (e.g. which technologies implement which applications, or which applications support which business capabilities) can also be achieved using the same approach: AI doing the heavy lifting, with human experts reviewing the output. It’s a powerful combination.

AI-augmented tools for architecture modelling

Once you’ve got some decent data describing your architecture and IT – even if it’s an evolving landscape – you can start to get some value out of it. We’ve been experimenting with architecture data at Icon Solutions, and whilst it’s entirely possible to do this by building static SQL queries, we’ve found that once you’ve worked out how to expose your Architecture as Code in appropriate data frames and format it into JSON, LLMs can be used to evaluate it.

We had good results when wrapping a model (defined in, say, PlantUML) around the LLM output using a small amount of Python code – producing a data-driven visualization, which automatically updates as the underlying data does. AI is somewhat constrained due to its output being textual (especially on larger datasets), but judiciously prompting the LLM produces filtered views of the data. These can then be piped into a diagram generator, to produce a view of whatever the stakeholder needs: non-strategic technology usage in a particular domain, for example, or projected cost savings from applications which are slated for decommissioning. We also found that the currently-available models for Architecture as Code don’t quite “fit” in some way or other: a view or perspective is either over-emphasized or missing – but using data-generation approach gives you the option of choosing the most appropriate model from all those available – all generated on-demand from the same underlying data.

For those of us who have legacy IT to curate and improve, AI-augmented tooling can greatly assist with harvesting and evaluating the data which underpins Architecture as Code. In the second half of this blog series, we’ll look at the wider vision of Architecture augmented with AI – for which Architecture as Code is an absolute prerequisite, and which makes architects as much a part of end-to-end value delivery as engineers.

If you would like to find out more, get in touch today.