The progressive Enterprise Architect (EA) needs to track many trends in their field. This includes but is not limited to moving from project-centric to product-centric organizations, composable business capabilities, semi-autonomous teams, BizDevOps, Digital Twins, inverse Conway maneuvers, from plan-build-run to continuous value creation, agile EA, etc. Tracking all of these requires the modern EA to look beyond the traditional structural elements of an organization – capabilities, processes, applications, information, etc. – and be better at incorporating people.
The architecture of the enterprise represents the design of more than one system. For those systems, EAs today need to consider the importance of including people in their designs. We all know and understand the traditional enterprise architecture work of the first system: business architecture represented by business capabilities, capabilities realized using processes, applications, information, and people, etc.
The second system is often overlooked. It’s the way-of-working of the organization responsible for building the organization’s capabilities, especially the IT solutions. This can also be considered a system because it can be designed and its architecture provides wanted qualities in an analogous way to traditional architecture design. For instance, the throughput of change, the quality of its operation, its resilience when encountering unexpected events, and its ability to scale in terms of numbers of people and geographical distribution. This is the system that builds the system.
Some may consider the second to be a subset of the first, but I make it explicit. While it’s not something we usually discuss, it’s increasingly important for delivering the emerging trends mentioned in the introduction.
Enterprise Architecture Trends Build on Open Systems Theory
EA frameworks have always considered people, but now we need to consider the systems that incorporate those people; both in terms of how people impact system design and in terms of how continuous system change impacts those same people. Open Systems Theory and Socio-technical System Design discusses much of this theoretical foundation. Trond Hjorteland provides a good summary of the background in terms that are relevant for IT organizations. One of the key points is the fundamental design principles of organizations defined by Fred Emery in his Open Systems Theory. EAs need to understand this basic theory in order to understand why it’s so important to include people in their enterprise architecture.
Emery defines Design Principle 1 (DP1) where the organization is designed so that each part – including the people – is so simple that it can easily and cheaply be replaced. That means the parts need to be coordinated or supervised in order to complete a whole task. This design principle results in the classic bureaucratic hierarchy with maximum division of labour. The critical feature of DP1 is that responsibility for coordination and control is located at least one level above where the work is being performed.
Design Principle 2 (DP2) is where the organization is designed into overlapping functions. Each part – including the people – can do many things and can fill in for any missing parts. Responsibility for the coordination and control is then moved down to the group. This is known as the semi-autonomous team with minimum division of labour; where the group is self-managing and can encompass varying levels of autonomy.
The trends mentioned above – i.e., project-centric to product-centric organizations, composable business capabilities, semi-autonomous teams, BizDevOps, etc. – all require a move from DP1 to DP2. Therefore, it’s necessary for EAs to understand the consequences of Open Systems Theory and how it impacts our work.
We have long discussed the role of people in EA; from the Zachmann framework with its whole column dedicated to the “Who” of the organization, to EAs’ well-discussed need for soft-skills to communicate with relevant stakeholders in an organization. Those emerging EA techniques will not help a business if the organization as a whole is stuck in DP1.
Incorporating People into Your EA approach
There’s a trend in the industry of moving from plan-build-run projects to value streams that deliver continuously using semi-autonomous teams and can take many of their own decisions. In practice, enterprises are trying to get the benefits of moving from DP1 to DP2.
Naturally, these EA trends do not remove the need for common enterprise architecture. However, they do impact enterprise architecture’s purpose and how it is produced. Semi-autonomous teams are not fully autonomous and they need to know where they fit into the enterprise model as a whole. They need to know the scope within which they can make their own decisions, where to make decisions in collaboration with others, and with whom they need to collaborate.
Let’s consider 3 aspects of enterprise architecture work and how incorporating people can help with:
1. Maintaining the AS-IS – Business-IT transparency and governance.
2. Delivering the TO-BE – Designing future states and delivering change.
3. Improving the Way-of-Working – Continuous improvement.
Maintaining the AS-IS
One of EA’s main tasks is maintaining a usable enterprise model, including the process model, capability map, application landscape, etc. These models provide transparency into how the business operates through IT as well as governing that work to minimize risk and unexpected costs. We are familiar with building views – considering stakeholders and their particular viewpoints. However, these are traditionally created for decision makers in the hierarchy of a DP1-style organization – CISO, CIO, etc. Now decision-makers increasingly exist in individual teams and EAs need to consider viewpoints that support these people.
The purpose of an architecture model for a semi-autonomous set of teams is to allow them to understand the complexity of the enterprise and their role within it. Supporting their role requires including people and teams into the architecture model. When making the model, first include the operational aspects – i.e., people and teams that realize the capabilities or own the processes. Next, address the development aspects – the people and teams responsible for building applications or developing entire value-streams.
These trends require a more democratized approach to enterprise architecture. It becomes harder to maintain an up-to-date model of the enterprise because as teams become more autonomous, decisions get distributed, the rate of change increases, and less work gets coordinated through a central bureaucracy. The amount of work needed to maintain these models in the face of continuous change becomes so high for a central EA team that they spend all their time trying to keep up rather than performing strategic, enterprise-level design. Maintenance of the enterprise model needs to be as automated as possible. Additionally, EAs need to empower teams to update their parts of the enterprise model on their own. Democratization and automation of updates to the AS-IS enterprise model allows it to always be up-to-date and improves the quality by ensuring the people with the most knowledge of their part of the enterprise are the ones who maintain its representation within the whole.
Central EA teams become enablers and curators of the overall model in addition to designing the relationships between the respective domains. Representing people and teams within the enterprise model allows the architecture repository to be the source of information that drives that automation and democratization.
Deliver the TO-BE
Defining the TO-BE direction (rather than destination) is about defining future-state architectures for those design decisions that span multiple domains and help shape and prioritize the initiatives that move the company in the TO-BE direction.
The three trends – BizDevOps, project- to product-centric, and composable business model – build on the same principle: to have each team be responsible for the operation, realization, and future-state direction of their own area. Unfortunately, not all strategic plans map nicely along capability boundaries. Moreover, it may be that your enterprise is still navigating the transition from a hierarchic bureaucracy to a semi-autonomous one. As a consequence, there will always be a need for future-state design decisions that span the enterprise.
The move to product-centric and semi-autonomous teams is driven by the goal to involve the developers of a capability earlier and to bring greater collaboration between business and IT. This allows the team to understand the problem and shape its solution rather than simply receiving an implementation task. Research in DP2 shows this approach makes employees far happier and more productive. All employees want to be treated as competent participants in the enterprise and not just robotic replaceable parts.
All the employees in the organization should have a shared understanding of the overarching future state and be empowered to update the future state for their part of the whole. The communication and democratization discussed in the AS-IS section is also necessary for TO-BE. People need regular, self-service access to a continuously evolving future-state architecture description. Each person should have access that provides views specific to that person, their role, and links to other people who will collaborate to promote that understanding and evolve the design.
Progressive companies are moving away from the plan-build-run mentality and this is changing the role of the architecture review board (ARB) that is operated by a central EA team. These traditionally act as a bureaucratic toll-gate, performing their role after the design is finished to ensure all system qualities are accounted for and the design is aligned with the future state approach. However, democratizing the enterprise architecture role and sharing design autonomy now requires collaboration on the initial phase of design at the start of an increment. This collaboration is to ensure the reasoning behind the enterprise-wide future-state is understood, and the desired system qualities are carefully evaluated. The central EA team and EA model now take on an advisory function. As advisors, they create a shared understanding of the design and capabilities of the future-state, so that individual teams can then be trusted to create their design within the whole. The design still needs to be verified, but providing the right level of information and collaboration can make the EA practice operate less as a toll-gate and more as a collaboration point. The enterprise architecture model that includes people, their relevant perspectives, and the necessary design reasoning act as the source of collaboration rather than a handed down blueprint.
The second part of delivering the TO-BE is prioritization of change initiatives that cross multiple domains. EAs understand how to create design proposals. Prioritization requires cost-benefit-time analysis of those proposals to determine the when and how of making them happen. There is always a tradeoff when designing how to move the AS-IS towards a desired future state – between strategic and tactical approaches – especially when cost and time-to-market are significant factors. Enterprise-level design is not just a standalone design task. It’s a collaboration and negotiation that requires the EA to bring together people and information.
EAs use the enterprise model to understand the impact of design proposals. The model shows them which applications, processes, information, etc. will be impacted and what the ripple-effects are. However, it’s people on the teams that need to determine how big the change is for each area and when that change can happen among competing prioritizations. Including people and teams in the enterprise architecture model allows you to use that model to automate and democratize the process to collect where proposals will impact the architecture and estimates of the size of those impacts and when they can be prioritized. The EA model provides the information necessary to make prioritization decisions.
Finally, the EA model that incorporates people and their relationship to applications, processes, and domains can also support change management. People in the enterprise architecture are both the people building the capabilities (systems) and those using the systems to perform the capabilities. These people are all affected by change and the enterprise architecture can be used to plan the change management process in addition to the development work.
Improve the Way-of-Working
Continuous improvement is a cornerstone of agile enterprise architecture and an increasing number of progressive EAs work on adjusting the enterprise design to continuously improve how to deliver change. That means designing and refactoring the operating model – the system that builds the system. This also requires incorporating people into your enterprise architecture.
Conway Law is an oft-quoted maxim and the inverse Conway maneuver an increasingly utilized technique to adjust the organizational model to match the architecture model. Adding people, teams, and departments to your enterprise architecture is the simplest step to visualize the (mis)alignment between those two aspects.
Subsequent steps require adding more operational aspects of your business to the enterprise architecture – this is the basis of the Digital Twin of the Organization. Large change initiatives can’t always be broken down into independent pieces. Cross-team coordination, handoffs, and prioritization all create friction that reduces throughput in an organization and delays time-to-value. A design goal of semi-autonomous teams is to allow them to analyze, design, and deliver a change initiative with minimal cross-team coordination. Nevertheless not all change initiatives map neatly to a capability or value stream model. EAs can track the history of change initiatives and their impact across capabilities – the applications, processes, and information that are affected. This can show patterns of where change occurs. Those patterns, combined with including people and teams in the enterprise architecture, can provide the basis for team reorganization. Seeing the patterns can maximize change isolation and allows teams to work as independently as possible. It won’t remove the need for cross-team coordination and prioritization but it can improve it.
Including people in your enterprise architecture opens up other opportunities for improving the way-of-working by identifying the need for cross-team knowledge-sharing which can be costly when time-to-market is important. Your enterprise model can be used as the basis for organizational network analysis to identify the flow of information in your organization which, combined with the preceding information about change, can also allow the EA to improve enterprise design to enable better time-to-value.
The final technique you can utilize to improve the way-of-working and include people in your enterprise model is to understand how each team’s work relates to architecture. A useful idea introduced in Team Topologies is the concept of cognitive load. For instance, how much effort does a team use to deliver customer-value versus building IT infrastructure or enabling technology – the “IT plumbing.” Having people and teams in the enterprise architecture can provide the information you need to rearrange team responsibilities so that some can be more focused on delivering customer-value while others can focus on IT platform enablement. Including people in the enterprise model allows you to use that model to capture this type of information and continuously improve your way-of-working.
Conclusion
Progressive EAs understand the need to consider the enterprise as an open, socio-technical architecture. Using progressive enterprise architecture requires representing people two ways in enterprise architecture models: as a way of modeling the organization as a whole and using that enterprise model to drive the democratization of EA work. The result facilitates the move to semi-autonomous teams that enable many of the trends in our industry.
This article has highlighted multiple trends and techniques that can be supported by including people in your enterprise architecture. Traditional EAs model people in the enterprise architecture as a way of defining what they should do. Progressive EAs model people in the enterprise architecture to enable them to define what they should do themselves.
