In the article, Scott makes the case to the enterprise architect that agile software development teams work differently, and an EA needs to know how to engage with such teams "in a manner that reflects agile approaches to software development." Scott first identifies what agile teams need from the EA:
- Hands-on involvement. Not just designing but actually coding too.
- Straightforward guidance on common standards and guidelines. Agile teams believe in coding and similar standards, but EA's "must be prepared to maintain and collaboratively support it."
- Overview diagrams. "I personally find that a high-level enterprise domain model, a UML deployment diagram providing a high-level overview of the technical infrastructure, a free-form “architectural stack” diagram, and a high-level enterprise business process model are very useful for business applications."
- Reference architectures. Reference implementations to illustrate desired standards and implementation approaches.
- Mentoring. "architectural concepts, modeling, design, and in other systems within your organization."
- Detailed documentation. Hands-on access is much better.
- Authoritative governance. "Agile teams work best with a collaborative approach to governance, not a command and control one."
- Reviews. "Reviews are “process smells”; if holding a review makes sense, then it’s an indication that you’ve very likely made a serious mistake earlier in the development process. "
Enterprise architects have it really tough these days because they have to support traditional, agile, and even hybrid development teams. The implication is that enterprise architects need to be flexible and to be prepared to adapt to the situation at hand. Development teams should not be required to adapt, at least not significantly, to meet the needs of enterprise architects. In my experience, the surest way to failure is to have the enterprise architecture tail wag the development dog.The Cutter Consortium report is free as a downloadable PDF with registration required.