As more IT organizations transform to an Agile workflow, architecture must transform its workflow as well. As architects, we must do a better job of recognizing trends and proactively researching technologies for future adoption. While looking toward the future, we must (simultaneously) catalog, approve and govern the enterprise technology stack.
Certain elements of the Agile Manifesto are sometimes interpreted to contradict even the leanest and most agile architectural governance.
- Individuals and interactions over processes and tools
- I’ve seen this to be used as an argument against any process for performing due-diligence prior to adopting or updating technologies.
- Working software over comprehensive documentation
- I’ve observed this to be used as an argument against cataloging the technical stack to facilitate the EA process of monitoring and governing when a technology must be upgraded or replaced altogether.
The Agile Manifesto provides excellent guidance for efficient development of quality software. The minute your organization grows to more that one team, some level of structure and process becomes necessary to manage the scaling of Agile. This process helps to avoid the “my favorite tool is better than your favorite tool” mentality. A compromise can sometimes prevent the introduction of ‘n’ number of tools that provide the same capability. At other times, mediation and governance are required.
A leaner approach to architecture doesn’t have to preclude EA governance. On the contrary, they can complement each another nicely. It allows us to monitor our existing technical stack to update or upgrade as required. It also allows us to look to the future to decide where we should be going with our design choices.