On agile teams, architects do more than design and implement the interesting tricky bits. They typically balance a wide range of concerns: short-term goals, overall system design integrity, risks versus efforts, design expediency.

The successful agile architects I know aren’t ivory tower experts. They take a leadership role in defining how the system is structured, organized and implemented, as well as how it evolves. They make sure there isn’t a hairball of component dependencies. They are hands-on and engaged in day-to-day development work. They actively ensure that the system is designed in a way that will sustain ongoing, incremental development. They are comfortable writing and refactoring code and figuring out how to fix things and improve the architecture. When things are “broken”, they often step in to help. An example of this that stands out for me is the story an architect told of how he helped improve the performance of an underperforming website. It was way too slow, and doomed to be even slower unless they reworked the architecture. Over the period of two weeks he worked with a small team to analyze the performance and then refactor the design. He wasn’t a superhero, he just applied his know how, working with the team who knew the deep technical bits. He succeeded in turning this design around because he knew they could improve things once they measured performance, found out where the real bottlenecks were and worked to clean them up (using good design principles and practices). After finding out where bottlenecks were, they first restructured some of the JavaScript code to eliminate several extraneous trips to the server. Then, they cleaned up a couple of service interfaces, cached some data on the service, and eliminated some of the more complex queries. Same functionality; only now the website performed up to snuff. He didn’t view himself as a superhero; just as someone who did what was needed get things back on track. He believed that they could clean things up if he spurred this activity with the right mindset and a fresh pair of eyes; and they did. (Not every attempt at architecture rework has such immediate payoffs....I recognize this, yet still admire his attitude and skill).

The definition of a steward is “someone who manages another’s property or financial affairs; one who administers anything as the agent of another or others”. I like this definition. To me, stewardship has deep implications about the role an architect ideally plays on a team. It means you pay attention, take care, and are responsible for the creation and upkeep of the software. You are responsible for safekeeping the architecture, yet you don’t own the architecture. Sure, you may work out key design details of the architecture, but you are a team player. The system’s success and sustainable development is more important than your own individual technical contributions. While being a technical leader, you also value teamwork. You don’t expect to be the only one coding or designing the challenging or interesting parts. You do what you can each and every day to sustain the system’s architecture.