To be effective at enterprise architecture, we embrace these philosophies:
- Work closely with others. First and foremost, Disciplined Agile enterprise architects (EAs) collaborate closely with their stakeholders. These stakeholders include senior leaders, business teams, and of course solution delivery teams. Disciplined Agile EAs will spend the majority of their time working with stakeholders. The aim is to guide people in leveraging the architectural vision, rather than policing teams to force them to follow it.
- Transfer skills and knowledge. Disciplined Agile EAs, and Disciplined Agilists in general, constantly look for opportunities to share their skills and knowledge with others. An important part of an EA’s job is to help those around them to get better at adding value.
- Balance domain and technology. Disciplined Agile EAs must have an understanding and appreciation of your organization’s domain (the “business”) and the way that it operates to effectively interact with, and support, senior leaders. Disciplined Agile EAs must have a technical background so that they understand the implications of the technologies in use (either now or in the future) within their organization.
- Be multi-disciplinary. Enterprise architects will often start their architecture career as a solution architect, a data architect, a business architect, or some other architecture specialty. Although these are good starting points, enterprise architects need to consider a wider range of issues than those focused on by each of these specialties. Just as enterprise architecture frameworks such as TOGAF, Zachman, DODAF and others all take a multi-view approach, Disciplined Agile EAs must have the skills, or be in the process of gaining them, to address a wide range of views.
- Architects also implement. An important part of working closely with others is to actually work with them, not just tell them what to do. The implication is that if you’re working with solution delivery teams, perhaps in the role of architecture owner (AO) on the team, that you would be prepared to be involved with the development effort. This enables better collaboration with the team, improved learning for everyone involved (including the EAs), and it provides concrete experience for the EAs to bring back into their architectural artifacts.
- Provide concrete examples. Not everyone likes to read, and not everyone thinks abstractly. Many people prefer real-world, concrete examples rather than detailed documents. For example, many people will want to hear stories about how other organizations are doing something similar to what the EAs are proposing. Software developers tend to be even more demanding, preferring to work with (and then copy) high-quality working code than they are to read a detailed white paper or detailed model.
- Think about the future, but wait to act. Disciplined Agile EAs will think through the future needs and direction of their organization, but realizing that strategies and their environment evolves over time they will wait until the last-most responsible moment to commit to acting. Furthermore, effective EAs know when to trade-off short and long-term gains and more importantly can help guide their stakeholders through these decisions while coaching them on the implications of what they’re doing.
- Flexibly evolve the architecture. Disciplined Agile EAs work in an evolutionary and context-sensitive manner. They recognize that details will emerge, that they cannot work through everything up front and that even if they could that their strategies must change with the times. Because teams work in unique manners, and because they interact with many teams, effective enterprise architects are sufficiently flexible and skilled to work in a manner that reflects the needs of the teams that they work with.
- Relentlessly address technical debt. Disciplined Agile EAs should be a driving force within your organization for addressing technical debt. They will guide and coach solution delivery teams on both avoiding new debt and on removing existing debt. In parallel they will work with business leaders to understand the implications of technical debt and help guide them in supporting solution delivery teams in addressing it.