Future proofing: putting architecture into action

IT architecture has evolved significantly since it first emerged in the late 1980s and early 1990s, becoming crucial in modern organisations. Today, more companies are forming dedicated architecture teams within their IT departments, recognising the pivotal role these teams play in designing solutions and governing implementations that align with business strategies.

Hopefully you caught the previous article, Forward thinking: future-proofing through architecture and IT strategy? We explored how IT architecture and strategic planning support not just a robust IT department, but also drive overall business success by future-proofing.

In this follow-up, we’ll dive deeper into how IT architecture can be practically executed. Central to this is the role of a design authority, which ensures that your architectural decisions are sound, sustainable and aligned with your organisation’s long term goals. Whether you already have architecture processes in place but are seeking to optimise them, or you're operating without formal processes and want to establish them, this article will discuss what works well (or less well) based on real world experience.

Setting off on the right foot

Having architecture processes is great. Do you have templates, a list of deliverables and maybe even a roles and responsibilities matrix? Even better. But sometimes, however formal (or informal) our ways of working may be, the process can be too rigid and we get caught up in adhering to these ways of working rather than amending it based on what we’re delivering.

Typically, when delivering large foundational technology like a brand new system, a waterfall or hybrid style methodology is used to get things moving. Other implementations might be delivered in a more Agile or Dev-Ops type approach; iteratively. Getting too caught up in our architecture processes may lead us to having several processes defined depending on the delivery model of the project, and too many variations on a process just causes confusion — and an overhead to maintain them — when the fundamental elements shouldn’t differ that much. 

Experience on a large digital transformation project delivered via hybrid style methodology prompted me to consider the architecture process. It was impossible to create a comprehensive high level design for the entire project whilst also executing multiple implementations iteratively within tight deadlines. Having a traditional design phase didn’t work, particularly with the defined sprints and the countless unknowns. As lead architect, I tailored the process to fit this specific project, since one size doesn’t fit all.

New or reuse

Instead of writing a new process, I bent the current one to suit. I treated the project like a jigsaw, where the high level blueprint acted as the jigsaw lid, showing us the final outcome. Then each implementation was like a piece, diving deeper into specific components of the overall solution as a chapter within the design.

This experience demonstrates you need to let your lead architect actually lead. At the start of a project, they can use their experience to determine how the architecture process will align to the overall project delivery and implementations. Instead of having multiple processes defined for every eventuality, they can flex the standard process to suit the individual needs of a project whilst making sure they achieve the fundamentals: designing and building a solution that aligns to organisational needs. We still applied the TOGAF framework to ensure that even in an iterative development process, the architecture vision remained consistent with enterprise objectives. This meant defining the blueprint early, allowing us to maintain alignment throughout each sprint. This was also approved (and then subject to change control) before any build work started and the individual chapters for each component had to be agreed and signed off before build work could begin on that element. This meant we still could govern the development work against a signed off design as we typically would, but it didn’t delay the project as we didn’t wait for a full end-to-end design to be completed before development work could commence.

Another technique adopted on this project was to keep a log of design gaps, which is something we hadn’t done before. Given aspects of the solution would be getting built before a full derailed design was completed, keeping a log of the gaps in the design that would block certain components from getting built allowed for targeted sessions with the key technical teams. We could resolve the gaps and it was an effective way to communicate to stakeholders what some of the issues were that could cause potential delays. We used JIRA and Confluence to log these, meaning we could assign to the right teams and set priorities based on the sprints ahead, making the design process align to the delivery of the solution.

Design authority

A design authority was also crucial to this transformation project. Ever heard the phrase ‘you’re only as strong as your weakest link’? That’s how I see IT architecture without a design authority. You may have good processes or ways of working, but without this forum to get decisions made or documents approved you might find the build of a solution isn’t in line with the vision or strategy. It governs design choices, ensuring alignment with strategic objectives and architectural standards. On this project in particular, it allowed key decisions to be made quickly, such as which components should be integrated via our middleware so integration design and build could quickly commence or to determine where data should be mastered before we contract with a new vendor.

For you

Be part of something bigger, join BCS, The Chartered Institute for IT.

Our design authority is made up of all key IT decision makers. Before we implemented this forum, decisions would get made on projects for potentially the wrong reasons or wouldn’t consider the impacts to other implementations or to the strategy. By having this forum, pros and cons of various options or decisions can be debated and on the digital transformation project, this meant we could quickly make key decisions — for example, stating we’d use a standard set of APIs as opposed to bespoke, or which component would house certain functionality before we got into low level detail. Waiting to make these decisions can lead to rushing into a decision or making them unconsciously.

In conclusion, flexible architecture processes, supported by a strong design authority, are essential to futureproofing both IT and the wider organisation. By tailoring architectural practices to suit the unique demands of each project, whether iterative or traditional, you create a framework that not only supports immediate goals but also scales with long term business objectives. Leveraging frameworks like TOGAF and tools like JIRA can provide structure, while a design authority ensures that key decisions remain aligned with strategic goals. As IT landscapes evolve, so must your architecture processes; adapting to change without compromising on governance and quality.