Enterprise Architecture

Disciplined Agile Enterprise Architecture

The Agile Enterprise Architecture process blade overviews how a disciplined agile EA team will work. An agile enterprise architecture is flexible, easily extended, and easily evolved collection of structures and processes upon which your organization is built.  The act of agile enterprise architecture is the collaborative and evolutionary exploration and potential modelling of an organization’s architectural ecosystem in a context-sensitive manner.  The implications are that enterprise architects must be willing to work in a collaborative and flexible manner AND IT delivery teams must be willing to work closely with enterprise architects.

This article is organized into the following topics:


Why Enterprise Architecture?

Enterprise architecture, when performed in a disciplined agile manner, is an important enabler of agile software delivery.  This is true for several reasons:

  1. Common architecture enables agile teams to focus on value creation.  A common enterprise architecture enables reuse across delivery teams.  When agile teams have high-quality assets – such as micro-services, legacy data sources, and frameworks – available to reuse they are able to focus on creating new value for their stakeholders and not on reinventing new versions of existing infrastructure.
  2. Common technical guidance enables greater consistency.  When team follow effective, common conventions it results in greater quality.   This makes it easier to learn about assets that are new to them, in particular existing source code, and to evolve those assets as needed.  Greater consistency also makes it easier for people to move between teams because it will be easier for them to come up to speed on what the new team is doing and to share their skills with those team members.
  3. Agile architectures enable disaggregation.  When your solutions are built from loosely coupled, highly cohesive components it is easier to spread development work across smaller teams.  This reduces overall risk and organizational complexity, which in turn reduces time-to-delivery.
  4. Common infrastructure enables continuous delivery.  When there is a common technical infrastructure to IT delivery teams to deploy into it is easier to deploy.  The easier it is to deploy, the more often it makes sense to deploy.
  5. Enterprise architecture scales agile.  A disciplined agile approach to enterprise architecture enables organizations to scale agile strategies “horizontally” across their entire IT department.


The EA Process

Some methods will choose to prescribe a single approach, such as capturing architectural requirements in the form of epics or pre-building “architectural runways,” but the Disciplined Agile Delivery (DAD) framework promotes an adaptive, context-sensitive strategy.  DAD does this via its goal-driven approach that indicates the process factors you need to consider, a range of techniques or strategies for you to address each process factor, and the advantages and disadvantages of each technique.  In this section we present the goal diagram for the Enterprise Architecture process blade and overview its process factors.

The following diagram overviews the potential activities associated with disciplined enterprise architecture.

Disciplined Agile Enterprise ArchitectureThe process factors that you need to consider for enterprise architecture are:

  1. Support stakeholders. Enterprise architects will work with business and IT stakeholders on a regular basis to understand their needs and to help them develop a vision for the organization.
  2. Support delivery teams.  Enterprise architects will work with IT delivery teams, and ideally be active members of IT delivery teams, on a regular basis.  They may guide the teams in the business and technical roadmaps, help them to identify potentially reusable assets, to identify technical debt, and transfer their skills and knowledge to team members.
  3. Negotiate technical dependencies.  Like it or not, there are dependencies between the solutions that we create.  For example, if your system invokes a web service, or calls an API, provided by another system then you have a dependency on that system.  Enterprise architects will often find that they need to negotiate these dependencies with other teams, either at a high-level in their role of Enterprise Architect or sometimes at a detailed level in their role of Architecture Owner on a delivery team.
  4. Explore architectural views. Organizations are complex and as a result they must be understood from a variety of view points.  It’s not just a matter of writing “architectural epics” on a collection of index cards.
  5. Tailor architectural framework.  The enterprise architecture team may choose to adopt, and likely tailor, an existing enterprise architecture framework.  These frameworks typically suggest a multi-view collection of artifacts to create and techniques for doing so.
  6. Evolve enterprise architecture. Enterprise architects will collaborate with one another, and with their stakeholders, in a variety of ways.  They may choose to hold architecture envisioning/modeling sessions or regular meetings where they share learnings with one another.  They will often work together, or with IT delivery teams, to investigate new technologies or identify candidate architecture strategies.
  7. Evolve roadmap(s).  An important output of your enterprise architecture effort will be one or more roadmaps describing your technology strategies and/or your architectural strategies.  In agile organizations this roadmapping occurs in a rolling wave approach where the roadmap(s) are updated regularly.
  8. Capture enterprise architecture.  There are two broad categories for how enterprise architects can capture their work: as documents or as working/executable examples.  High-level models work well for documentation, although sometimes you may find the need for detailed documentation as well.  Executable artifacts, such as executable reference architectures or architectural runways, are usually preferred over documentation by delivery teams.
  9. Govern architecture. Architectural activities within your organization should be governed in a lightweight, collaborative manner.  This is an important activity for enterprise architects as well as for your IT governance team.


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 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 the DAD framework 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 management 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.


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.
  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.

Related Readings

Leave a Reply

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