You are an Enterprise Architect in an organization learning agile practices, and you are feeling a bit lost. You have worked hard to get where you are. You probably wrote most of the critical system software keeping your enterprise running. You helped design the architecture. You know some of it is bit fragile, but with too few resources and too little time, compromises have to be made. In fact, your own ability to keep up with the latest trends have suffered because only you know how to keep things working. To help manage time, you have implemented universal standards and tried to funnel requests to architecture review boards or other planned meetings. Developers complain about all of the process, but you are just trying to keep control over the chaos that would certainly take over without it.
In an agile organization, good architecture is just as important as in a traditional enterprise. The role of the architect, however, is very different. The development teams have the freedom to make more impactful decisions, but also the responsibility to keep everything running. Heavyweight processes and centralized decision-making interfere with the short feedback loops required to make agile development successful. You have to adapt to this new environment by adjusting how you ensure that the chaos is held back and enabling the teams to make good decisions
To be successful, you focus on three key areas:
- Know the code
- Make the architecture visible to everyone
- Build bridges between teams
Keep Coding
When I first wrote about the role of an Enterprise Architect in 2015, I did not mention code at all. At the time, I was not convinced that architects needed to code frequently to be successful. I know better now.
As an architect, your relationship with code is different from a developer or even a tech lead. You should not be responsible for delivering features or contributing to team velocity. Instead, you should be writing code to help share ideas, learn new skills, and develop empathy with the development teams. This means that you should be familiar with every tool and framework that you recommend by spending some time with it. This goes double for internally developed frameworks and tools. These are often purpose built, then promoted broadly. Blind adoption can lead to project delays, bugs, and unhappy developers.
Take time to pair periodically with members of each team. Developers believe, often with good reason, that architects are “post-technical” and no longer able to understand the world that they live in. Showing developers that you are interested in their work, and that you can still keep up, will strengthen your relationship with them. It will also help you understand their pain points and learn about weaknesses in the architecture. This knowledge will make you a better architect and help you to better serve your organization.
Vision and Visibility
In a traditional enterprise, architects define the architecture and expect the development teams to implement solutions conform to that architecture. Agile development teams cannot thrive with those tight constraints. At the same time, agile teams tend to be laser focused on solving their own problem with little visibility or regard for the rest of the enterprise.
As an architect, it is your responsibility to find a balance between guiding teams and stifling them with constraints. The time you spend in the code will position you to know both what exists in the enterprise and what each team is working on. Be on the lookout for potential conflicts. Often, teams will build incompatibilities unintentionally because they do not have visibility into the work other teams have done. At the same time, look for overlap and opportunities for teams to leverage new and existing solutions. Sometimes a team may be struggling to find a solution to a solved problem simply because they do not know that it has already been solved.
To avoid being the only source of this knowledge, make the architecture visible to everybody. Periodically create posters of all or parts of the architecture, and display them prominently. Leave materials for people to mark up the posters and leave feedback. As the architecture evolves, update the displays so that everyone can always see what is being built and changed. Digital artifacts like wikis and slide decks are fine, but they are easily ignored or forgotten. I personally have written hundreds of pages of documents that were never read, but a 3’ x 4’ poster in the team room cannot be ignored.
Build bridges
Agile teams naturally build strong relationships with their product owners, stakeholders, and customers, but also become isolated from each other. Your job as an architect is to build bridges across these natural divides. By spending time in the code and pairing with developers, you can find the best people and teams to bridge together. Find teams that are solving similar problems and make sure that they are collaborating on a common solution. Identify developers who are passionate about a technology, platform or technique and help them teach and reinforce each other. Facilitate communities of practice to both share learnings and generate new ideas.
Your organization will not become agile overnight. Legacy systems, often the core of the enterprise, tend to lag behind in technology and methodology. These systems and the teams that maintain them are essential to the success of new products. Make sure that the legacy maintainers and agile developers are partnering to build high quality solutions. When necessary, help lobby the business to upgrade or replace legacy systems, and leverage the deep knowledge of those teams to choose or design them.
Same but Different
The goals and responsibilities of architects in agile organizations are not all that different from traditional enterprises. Your job is still to provide guidance to development teams and keep your enterprise ecosystem from descending into chaos. If you stay engaged with the code and the teams, keep the architecture visible, and make sure the right people are collaborating, your teams can thrive in an agile environment. The teams will start to delivery new, innovative products and features faster and faster. The architecture will evolve in ways that you never thought possible. Everyone’s job will become easier and, most importantly, your users and customers will benefit in new and exciting ways.
