Disciplined Agile Enterprise Architecture: Workflow

In this blog posting, the latest in our ongoing disciplined agile enterprise architecture (EA) series,  overviews the workflow of a disciplined agile EA team.  We look at two views of this workflow, from within the team and with other IT teams.

Workflow Within the Team

The workflow within a disciplined agile enterprise architecture team is depicted in the following diagram.

Agile Enterprise Architecture Process

There are four major activities:

  1. Envision initial architecture.  The enterprise architects will spend several days developing initial, high-level models of the enterprise architecture.  This will be a face-to-face, initial architecture envisioning session where the scope is the entire organization, not just a single IT solution.  Ideally this is done in an agile modelling room so as to streamline the communication and collaborative modelling efforts.  Such a room is large with lots of whiteboard space, enabling the team to work on several models in parallel (each of which has its own section of wall space).  The primary purpose of this session is for the EA team to develop a common understanding, at least a high level, of the current state of the enterprise architecture and a vision for how the team would like to see it evolve.  Secondary outcomes include creating some initial artifacts which the enterprise architects will evolve over time, (potentially) meeting one another for the first time, and building bonds between the team members.  Potential challenges to this activity include getting an agile modeling room (you may have to convert an existing room, or accept lower productivity if you can’t get access to such a room) and the logistics of getting the right people together at the same time.
  2. Collaborate with business stakeholders.  On a regular basis enterprise architects work with business stakeholders to understand their needs, work with them to envision the future, and help educate them on the possibilities and constraints of technology.  This collaboration may be in the form of working sessions, presentations, or one-on-one conversations.  These sessions occur as needed and at times it can be difficult to gain access to stakeholders as they are often very busy people.
  3. Collaborate with IT stakeholders.  Disciplined agile EAs will spend the majority of their time, 80 to 90% of it typically, working as members of IT delivery teams.  By doing this they bring their knowledge, vision, and skills to the team in a pragmatic, hands-on manner. On Disciplined Agile Delivery (DAD) teams they will often take on the role of architecture owner (AO).  Enterprise architects will also work with other IT stakeholders, including operations engineers, support staff, the data management team and so on so as to understand their needs.  More on this in the next section.
  4. Evolve architecture assets.  The enterprise architecture team, or at least the portion of the team who is currently available, will meet on a regular basis to evolve the enterprise architecture assets based on their learnings.  A common pattern we’ve seen it for the team to meet every Friday afternoon for two hours where they discuss what they’ve learned that week from working on delivery teams and working with their various stakeholders.  As the result of the meeting several of the enterprise architects may take on action items to update existing EA artifacts.  These artifacts may include EA models, reference architectures, development guidelines, white papers, and so on.  When a new major topic arises, such as the potential adoption of a new platform or a merger with another organization, the EA may choose to schedule agile modelling sessions to explore the topic.

Workflow With Other IT Teams

The following diagram overviews the major workflows that your disciplined agile enterprise architecture activities are associated with.  Note that feedback is implied in the diagram.  For example, where you see the Technology Roadmap and Guidance flow from Enterprise Architecture to Reuse Engineering there is an implied feedback loop from the reuse engineers to the enterprise architects.  Also note that the workflows do not necessarily imply that artifacts exist.  For example, some of the guidance provided by enterprise architects may be discussions with their stakeholders.

Disciplined Agile Enterprise Architecture Workflow

The following table summarizes the workflows depicted in the diagram.

Process Blade Process Blade Overview Workflow with EA
IT Delivery Addresses how to develop solutions in a disciplined agile manner.  This includes the four lifecycles – basis/agile, advanced/lean, continuous delivery, and exploratory – supported but DAD plus the program management blade (effectively a large team following one or more of the lifecycles). Enterprise architecture will provide guidance to the IT delivery teams in the form of coaching and mentoring the teams in architectural issues, providing the technology roadmap, and providing development guidelines (such as coding conventions, security conventions, database guidelines, and so on).
Continuous Improvement Addresses how to support process and organizational structure improvement across teams in a lightweight, collaborative manner; how to support improvement experiments within teams; and how to govern process improvement with your IT department. The continuous improvement activities will provide potential improvement suggestions for improving enterprise architecture efforts.  Similarly, the EA team may have insights to share with the rest of the organization.
Data Management Addresses how to improve data quality, evolve data assets such as master data and test data, and govern data activities within your organization. Enterprise architecture will provide guidance to the data management activities.  Operational intelligence pertaining to production data sources and data activities will be made available to the EA team to support their long-term planning efforts.
IT Governance Addresses strategies for consolidating various governance views, defining metrics, taking measurements, monitoring and reporting on measurements, developing and capturing guidance, defining roles and responsibilities, sharing knowledge within your organization, managing IT risk, and coordinating the various governance efforts (including EA governance). The IT governance efforts will provide guidance to the EA team.
Operations Addresses how to run systems, evolve the IT infrastructure, manage change within the operational ecosystem, mitigate disasters, and govern IT operations. Enterprise architecture will provide a technology roadmap and guidance to the operations efforts so that their efforts to evolve the IT infrastructure reflect the overall organizational strategy.  Operational intelligence will be used by the EA team to provide insights into the effective of various architectural strategies.
Portfolio Management Addresses how to identify potential business value that could be supported by IT endeavors, explore those potential endeavors to understand them in greater detail, prioritize those potential endeavours, initiate the endeavours, manage vendors, and govern the IT  portfolio. Enterprise architecture provides the technology roadmap to portfolio management.  The roadmap is used as input into identifying potential business value that could be supported by IT and into prioritization decisions.
Product Management Addresses strategies for managing a product, including allocating features to a product, evolving the business vision for a product, managing functional dependencies, and marketing the product line. Enterprise architecture will provide the technology roadmap to product management which is an input into evolving the vision for a product and identifying new potential features for products.  Product management provides the business roadmap and stakeholder priorities to enterprise architecture which is used as input into evolve the enterprise architecture.
Program Management Addresses strategies for managing large product/project teams, allocating requirements between sub teams, managing dependencies between sub teams, coordinating the sub teams, and governing a program. Enterprise architecture will provide guidance to large IT delivery teams (programs) in the form of coaching and mentoring the teams in architectural issues, providing the technology roadmap, and providing development guidelines (such as coding conventions, security conventions, database guidelines, and so on).
Release Management Addresses strategies for planning the IT release schedule, coordinating releases of solutions, managing the release infrastructure, supporting delivery teams, and governing the release management efforts. Enterprise architecture will provide the technology roadmap and guidance to the release management efforts so that their planning efforts reflect the direction of the overall organization.  Operational intelligence will be used by the EA team to provide insights into the impact of current architectural strategies on the overall release effort.
Reuse Engineering Addresses how to identify and obtain reusable assets, publish the assets so that they are available to be reused, support delivery teams in reusing the assets, evolving those assets over time, and governing the reuse efforts. Enterprise architecture will provide the technology roadmap and guidance to the reuse engineering efforts so that they can better identify potentially reusable assets.  Reuse intelligence will be used by the EA team to provide insights into where to focus technical debt pay down efforts.
Support Addresses how to adopt an IT support strategy, to escalate incidents, to effectively address the incidents, and govern the IT support effort. Enterprise architecture will provide the technology roadmap and guidance to the support team so that they can better understand the overall IT ecosystem and the direction it is going in.  Operational intelligence will be used by the EA team to provide insights into the supportability of the various solutions in production.

The activities associated with these process blades are often very highly related. For example, in some organizations the activities associated with enterprise architecture and reuse management are fulfilled by a single group.  In other organizations some product management activities are performed by the portfolio management team and some by the enterprise architecture team.  Some organizations may choose to have a separate group for each process blade.  And of course the organizational structure will evolve over time as your various teams learn how to work with one another.  Every organization is different.

Related Postings



Have any Question or Comment?

Leave a Reply

Your email address will not be published. Required fields are marked *