The enterprise architect’s ecosystem in an agile enterprise
Too many enterprise architects are still limiting themselves to writing hermetic “solution architecture definition documents” and hiding from the real action. Yet, we’re seeing a new trend picking up. More and more business and enterprise architecture teams are participating and blending into their organization’s business prioritization strategic planning, portfolio management, roadmap optimization, product management, customer-centric initiatives, agile project fine tuning, newer and more modern business-oriented KPI definitions, etc.
In brief, we are assisting at the emergence of a new breed of enterprise architects that are becoming very instrumental in making their corporation more agile.
Agile organizations are becoming more common because of the increased appreciation for their transformational gains. But getting to an agile operating model is difficult, particularly for established and more traditional companies. The article “The journey to an agile organization” explains very well how successful agile transformations share common elements into their agile transformation:
“Traditional organizations are built around a static, siloed, structural hierarchy, whereas agile organizations are characterized as a network of teams operating in rapid learning and decision-making cycles. Traditional organizations place their governance bodies at their apex, and decision rights flow down the hierarchy; conversely, agile organizations instill a common purpose and use new data to give decision rights to the teams closest to the information. An agile organization can ideally combine velocity and adaptability with stability and efficiency.”
Such transformations comprise several elements set across two wide-ranging stages:
- Aspire, design and pilot
- Scale and improve
Enterprise architects are usually mostly involved with the first stage.
At this stage, transformations begin with the top management’s strategic understanding and ambitions (Aspire), producing a blueprint to detect how agility will provide value (Design) and learn using agile pilots (Pilot), usually by providing at minimum a feasible product developed at a rapid and iterative manner that provides enough indications for the organization to proceed with testing its design.
Figure 1 below describes the Agile Operating Model at the Enterprise Level in more detail, with five dimensions:
- Goals and value
- Agile teams
- The backbone
- The elaboration of a roadmap and projects
First, the ‘Goals and Value’ dimension should include clear strategies and measurable goals, explain where value can be created and how the organization can be distinct from its competition. Second, an iterative ‘Structure’ of an agile operating model is not delivered according to a classic organization chart, but rather through several teams with clear reporting lines grouped around a common mission and measurable objectives. Third, iterative ‘Agile Teams’ need to be identified and built, making certain that each team have clear objectives and that they have defined their optimal workflows. Fourth, an iterative ‘Backbone’ needs to include its outlined requirements on the essential processes, people, and technology for maximum agility. Fifth, a high level ‘Roadmap’ needs to be elaborated with a backlog list of projects and where they are prioritized for immediate next steps.
Enterprise architecture and agile organizations
In “Fine tuning SAFe with architecture,” I show how harmonization between architecture and agile teams can contribute to the delivery of successful projects for the Scaled Agile Framework (SAFe) in particular. It demonstrated how enterprise architects and agile teams should stop working in silos. Their approaches are complementary, not conflictual. The harmonization between architecture and agile teams can contribute to the delivery of successful projects aligned to corporate strategies.
“Being on the SAFe side: how business architecture and agile fit together,” also demonstrates that:
“Business architecture doesn’t get in the way of the Agile team, but rather works alongside to help them be best focused and prepared – which speeds things up rather than slowing them down. And, it ensures that the agility and the success of the team is applied to the highest value parts of the business.”
Figure 1 above also describes the implications of enterprise architecture at each phase of the Agile Operating Model of an enterprise in more details. First, during the ‘Goals and Value’ at minimum the critical value streams need to be elaborated. A business motivation model would also be very helpful to identify strategies, tactics and their corresponding goals and objectives. As for a business model canvas, it is often the shortest path to identify how an organization is distinct from its competitors.
Second, during the ‘Structure’ phase, critical value streams are grouped by teams with a common mission. The enabling and problematic capabilities of each critical value stream/stage are identified. The organizational unit that owns an enabling capability of a critical value stream needs to be identified.
Third, enterprise architects should be included in ‘Agile Teams’. They should define key strategic initiatives with their measurable outcomes, based on strategic goals and objectives.
Fourth, at the ‘Backbone’ stage, enterprise architects can assist in the definition of requirements and fine tune business processes using their business architecture model elements. The enabling capabilities of targeted value streams/stages are linked to their relevant applications and databases.
Fifth, enterprise architects will link agile ‘Roadmap & Projects’ to strategic initiatives, that are based on the critical and targeted value streams/stages with their enabling and problematic capabilities. Projects will be prioritized on financial ratios & risk factors.
The enterprise architecture’s new ecosystem
In an agile enterprise, enterprise architects need to cooperate with many different types of collaborators during the planning, architecture and delivery of digital transformation initiatives. As explained in “Digital transformation using business architecture,” five steps can describe how agile digital transformation can be accomplished using enterprise architecture, as shown in Figure 2 below. These steps include:
- Develop goals and strategy
- Business and enterprise architecture
- Develop roadmap
- Agile delivery of solutions
- Measuring performance
For each of these steps, enterprise architects will need to interact with different types of internal and external collaborators.
In the first step, ‘Develop Goals & Strategy,’ enterprise architects need to gather corporate goals and strategies to disseminate them into meaningful objectives and tactics at lower levels of their organization. They may interact with CXOs, head office strategists, business unit managers, business managers and/or change managers. A few initiatives at a time, enterprise architects need to build a detailed business and enterprise architecture model that reflects as much as possible the current state of their enterprise and their desired future state regarding the contemplated initiative(s).
At this second stage, enterprise architects will usually need to cooperate with at least some of these stakeholders: clients/partners, subject matter experts, business managers, change managers, product managers, marketers, applications architects, solutions architects, data architects, business intelligence architects, IT architects and/or software architects. At this stage, the main objective of enterprise architects is to find the enabling and problematic capabilities that need to be addressed to optimize the critical strategic value streams and make the desired future state a reality.
In step 3, enterprise architects should assist CIOs, program managers, and/or portfolio managers with alongside financial analysts in the delivery of a high-level roadmap that can be decomposed in fine details for later delivery.
Once a roadmap is chosen, enterprise architects should also get involved in step 4, ‘Agile Delivery of Solutions’ with usually clients, partners, users, agile experts, business process experts, business analysts, software developers, IT architects, and/or software architects.
Finally, in step 5 enterprise architects may be involved in the measurements that need to be completed to examine if goals, objectives and outcomes have been reached.
For many enterprise architects, this requires a major culture shift where their tasks become much more diversified and where they need be able to collaborate and communicate at a much greater frequency with external and internal stakeholders within their organization.
It involves knowing how to establish a technical dialogue with those that are delivering solutions and talk business to those that require strategic changes, as explained in “7 compelling qualities of business and enterprise architects.” This is and will not be easy. To stay relevant, more and more enterprise architects will need to adapt, become more versatile, and accept this challenge.
Recommended for you: How a Service Mesh Helps Manage Distributed Microservices
This blog is provided for informational purposes only and may require additional research and substantiation by the end user. In addition, the information is provided “as is” without any warranty or condition of any kind, either express or implied. Use of this information is at the end user’s own risk. CenturyLink does not warrant that the information will meet the end user’s requirements or that the implementation or usage of this information will result in the desired outcome of the end user.