Three Architectures for IT Architects to Enable Agile and DevOps

DZone 's Guide to

Three Architectures for IT Architects to Enable Agile and DevOps

A software architect identifies and explains three architectural patterns that can allow dev teams to enable DevOps processes with greater ease.

· DevOps Zone ·
Free Resource

I have been a technology architect for a long time and have worked with many different technologies. And there is something satisfying about coming up with "the architecture solution" for a business problem. The ideal end-state that, once implemented, will be perfect.

Unfortunately, I had to come to the realization that this is not true. There is no end-state architecture anymore and there never was. All those diagrams I drew with the name end-state in it — they are all obsolete by now.

Knowing that architecture will continue to evolve (just look at the evolution of the architecture of Amazon or any other internet companies over the years) means that, as architects, we need to think differently about architecture. We need to build architectures and, before they even implemented, start considering how parts will be replaced in the future. No stone will remain unturned, no matter how good they seem at the moment. So rather than spending time on defining the end-state, we need to spend more time understanding and defining the right principles of architecture for our organizations and managing the evolution of the architecture — how technical debt is paid down and systems are being decoupled for the eventual replacement.

This would be difficult if we had to deal just with the architecture of business systems. Reality is that in the current IT world we have to deal with three different architectures: the business systems architecture, the IT tools architecture, and the QA and Data architecture.

Let's quickly define these:

  • Business Systems Architecture - this is usually well defined in organizations. How do your CRM, ERP, and billing systems work together to achieve business outcomes?
  • IT Tools architecture - this is the architecture of all your tools that make IT delivery possible: configuration management, container management, deployment, defect management, Agile lifecycle, etc.
  • QA and Data architecture - how do we validate that systems are working correctly both in production and in new development and how data is flowing across systems and environments?

All three of these architectures need to be managed with the same rigor and focus on continuous evolution as the business system's architecture. This will make the job of architects a little bit more complicated. At the moment, I see many organizations not having architects focused on all three architectures, as they are not perceived as being of equal importance.

Let me give you some examples from my past to highlight why that is foolish:

  • One of my clients was already pretty mature in their automation so that all deployments to production were fully automated. Unfortunately their deployment architecture was basically a single Jenkins server that was manually maintained. When this server was wiped out by mistake it took weeks to get the capability back up to deploy to production — in the meantime, very risky manual deployments had to be performed by people who had not done this in months
  • Another client of mine had built a test automation framework that was too tightly coupled so that it took a lot of effort to replace one of the components and maintenance had become so expensive that they had stopped using it — ultimately there was too much technical debt in the tests and the QA and data architecture

The answer, of course, is that all three architectures need to be managed by architects in similar ways (e.g. failover and availability need to be considered for IT tools and QA tools too) and that the principles of decoupling and continuous evolution need to be aspects of all three.

The architect function is one that will see a lot of change as we come to terms with managing three interconnected architectures and the evolving nature of architecture. But I think it will make the job more interesting and will allow architectures to climb down from the proverbial ivory tower to engage with the Agile delivery teams in a more meaningful way.

agile ,devops ,devops approach ,devops processes ,software architecture

Published at DZone with permission of Mirco Hering , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}