In 5 Tips to Automate Your Cloud Infrastructure I mentioned automated compliance testing. This is the idea that once your entire solution (both infrastructure and software) is defined using artefacts under version control, then the way is open to checking those artefacts for compliance against an enterprise-wide set of rules… in an automated workflow… not in meetings with an “enterprise architecture team” who wield the fiery blame hammer to punish teams ignorant of the latest Powerpoint edict from on high.
That’s a bit of a harsh characterisation. Harsh, but unfortunately true for some of the large businesses I’ve worked with over the years, where it seems that the traditional enterprise architecture role has managed to avoid the magnetic pull towards automation that drives efficient solution delivery. Things are sometimes so toxic that EA is seen as an optional extra, or worse, an impediment for delivery teams.
And so there may be an unhealthy tension between delivery teams who see themselves as “actually doing stuff” and the EA team, which is often far removed from the concerns of project teams working with specific business units to automate their processes.
But there is a useful role for a central authority that understands a wide landscape and its history. This is the context in which the totality of IT solutions supports the business as efficiently as possible right now, with a view to the need to support a likely path of flight for the future.
The EA role can be a helpful force for project teams when it becomes integrated into the automated workflows that modern delivery uses. When it sits outside the automation of infrastructure build and deployment then it becomes a cumbersome obstacle, but what if compliance against the enterprise architecture was simply a part of the automated testing? A build that failed the EA tests would instantly make visible an issue that could be addressed immediately. The alternative of non-compliance going unnoticed until the next ‘architecture review board’ months in the future looks barbaric and not very helpful at all.
Of course this approach depends entirely on automation of the entire project delivery from infrastructure through build and deployment, which only a “cloud” approach (i.e. API-driven infrastructure) can bring.
How can compliance be automated? By building and maintaining common “recipes” (to use a Chef term) that projects use, which are regularly audited and tweaked by the EA function. By attaching metadata to project repositories that bespoke tools can scrape and analyse. By running tools such as Amazon Inspector and any one of the myriad third-party tools. By using AWS Config to ensure that infrastructure changes are compliant. And on it goes. We’ll return to this topic in the future.
This is a brave new world in which EA is a helpful enabler not a grumpy librarian. A world in which EA is intimitely bound to the project teams and their processes. An aid for projects, able to bring relief to stretched teams by identifying potential for reuse of existing solutions (infrastructure recipes, micro-services, APIs, components, COTS). And a source of compliance to ensure that teams are building value within the growing IT estate.