Failing to plan is planning to fail is the saying, but to what degree is a plan relevant in a dynamic environment with multiple stakeholders and multiple sources that can impact the organization and strategic plan. The organization’s environment is adding to complexity and the bigger the organization, the more likely the decision makers will experience a high degree of complexity when it comes to the decision-making processes.

A roadmap is in other words a great artefact to use, when the decision makers need an overview of how the individual activities and decisions impact the organization and its possibility to deliver on the decided strategy, and likewise can roadmaps deliver the relevant “framework” for making the relevant decisions. But what is needed in order to build a roadmap that can deliver the overview? And is the roadmap the most important delivery?

Complexity in Decision-Making Processes

Medium-sized and major organizations will eventually experience that decision making processes are becoming increasingly complex, which has impacts the time for when and how the decisions are made. The delay of implementing the decisions does the added complexity e.g., in the layers of the organization impacts the organization’s ability to adjust to its environment.

The sources of complexity in organizations are many, but you will most likely experience complexity increase when:

New hierarchies are introduced, meaning decisions have to be made by people far away from actual production of the organization.
New comprehensive rulesets are implemented and enforced.
New structures of the organization e.g., the enforcement of new department structures and new ways of communication.
New services, products and processes are introduced and leads to new ways of working where limited existing knowledge is available.

The increasing level of complexity in organizations cater for the establishment of roles like enterprise architect, business architects and solution architects who can coach the different stakeholders of the organization to navigate the complexities and to enable coherences. One method to assist with the guidance of the stakeholders is the use of roadmaps.

Roadmaps

A roadmap has to be individualized for the specific organization and its specific industry. A good roadmap includes perspective for market orientation, business related themes and technical deliverables. It is almost needless to say, but the roadmap must include a time perspective and the perspectives, those earlier mentioned, have to be connected.

The enterprise architect would have to consider a few different themes before the development of the roadmap takes place, and the primary concern to address during the planning is to consider that the roadmap itself is not the value adding component. The primary value adding component of the roadmap is the process of delivering it. The artefact as such is valuable for communication to different groups of stakeholders, though the value of creating clarity is mainly developed during the roadmapping process, since the activities in most cases would involve executive stakeholders.

The Roadmapping Process

The enterprise architect will have to act as the facilitator and as a subject matter expert, when or if, questions are asked during the sessions in the process by the different stakeholders. Likewise, the enterprise architect can as such not own the roadmap, except, if he or she is a member of the executive committee of the organization.

First and foremost the enterprise architect has to ensure executive sponsorship for the process. When the sponsorship has been ensured, then the relevant stakeholders have to be identified and engaged. The first meetings will likely have to be done individually with the stakeholders, so they are prepared for what will be done during the workshops where groups of the stakeholders are engaged. One of these group workshops would include the kick-off session, which will have to provide alignment and commitment to the process, since without the “geist” or “spirit” to take part in the process for developing the roadmap, then it is likely very little will happen.

The enterprise architect will also have to work on ensuring a vision is articulated as part of the roadmapping process, and the vision is captured, so the participants in the process can support the mapping of the roadmap towards achieving the vision. The vision and the prework to the roadmapping process can be captured by using scenarios and undergo a specific process for this with the executive committee, so they have an aligned view of the vision, before the roadmapping process is commenced.

During the roadmapping process the enterprise architect has to ensure that the participants do not begin to suffer from group thinking, since the best possible outcome of the process will be produced by a diverse group of stakeholders, who can challenge different hypotheses and perspectives in the roadmap. This is to be done through the first round of workshops. The enterprise architect will also have to consider engaging the stakeholders individually before the second round of workshops is commenced, since there likely will be a different group of stakeholders involved in these.

The second round of workshops will usually include the subject matter experts e.g., software engineers, solution architects, logistics specialists, sourcing specialists, operations specialists, security specialists and a like. The specialists will during these workshops provide clarifications on how the different deliverables are interconnected, and what impediments have to be dealt with as-well.

The third and last round of workshops in the process of developing the roadmap will be concluded by a presentation for the members of the executive committee. They will have to commit to the roadmap before the organization as such can begin executing as according to it. Before the presentation to the executive committee the deliverables in the roadmap will have to be described as a portfolio of projects (in some cases as portfolios) so program managers and project managers can assist in delivering the projects.

After the last round of workshops have been completed, then it is time to involve the stakeholders in the organization that did not take part in the workshops. This can be done creating a few rounds of presentations so the stakeholders are informed and they can ask questions regarding how to proceed with the roadmap. The stakeholders can prove to be regular employees as well as middle managers like head of departments and senior vice-presidents. Besides the presentations, then “company town hall” meetings can be made use of in-order to spread the knowledge of the roadmap, and in the case of this, the enterprise architect should take part of these to assist answering the questions.

The roadmap has to be published, e.g., at the organization’s intranet, so the executives, middle managers and the employees can look information and “navigate” accordingly. Afterwards, the enterprise architect will have to pivot to a “Plan – Do – Check – Act” approach to make sure the roadmap is kept updated and implemented through the project portfolios.

Conclusions

The primary value adding activity of developing the roadmap is the process where the different stakeholders take part in developing the roadmap. The roadmap will have to include a market perspective, include business related themes and technical deliverables.

The second most important outcome of the process is the roadmap, which can be communicated to the relevant stakeholders in the company, and in some situations to stakeholders outside of the company. With the roadmap in hand it will become easier for the stakeholders in the company and its environment to navigate the complexity.

Agility is the word of the decade, and your organization’s approach to enterprise architecture should support that. Going agile is not the same as going versatile for the enterprise architect, or is it?

The Role of the Enterprise Architect

The enterprise architect is a strategic role in many organizations. The role is strategic in the sense that the enterprise architect designs the strategies and facilitates the implementation of strategies through a series of activities like program, projects and investments. The enterprise architect will therefore be in dialogue with a wide-range of stakeholders and conduct a wide-range of tasks in order to support the strategic part of the role.

Among the wide-range of tasks are empowering the translation of the strategy to strategic plans and to specific products (or services) that have to be implemented. This includes different approaches to ensure the implementation of the desired products. In this case products can be customer-oriented as well as internally oriented in order to enhance specific capabilities (processes, people, tasks and knowledge). When there is a digital edition of the product, then different delivery methods can be applied e.g., agile process models can be used, and in this case the different agile process models require different inputs and coaching from the enterprise architect in order to ensure the best possible products are delivered.

Why is the versatility of tasks needed? The enterprise architect has to go versatile in how he/she approach tasks. In order to succeed with this the enterprise architect has to apply a Plan – Do – Check – Act approach, which is known from the systems thinking paradigm. This approach empowers the enterprise architect with defining the strategies and ensure the implementation of them afterwards:

The enterprise architect has to be involved in the planning process.
The enterprise architect has to be involved in implementation processes.
The enterprise architect has to be involved in the check-up on the implementation.
The enterprise architect has to be able to correct any deviation.

The agile frameworks can empower the enterprise architects to fulfill this role by applying the frequent planning, commitment and follow-up. This means the enterprise architect can ensure progress by being versatile in how to deal with the tasks at hand and integrate with the agile processes applied for the digital deliverables. Additionally, it has become more and more apparent that physical products can be improved by having a digital twin and it supports the need for the enterprise architect to take part in agile processes and to take part in the design processes.

Agile Process Models

There are many different agile process models to ensure the development of digital products, though the process models most likely also can be used to develop other types of deliverables, providing different possibilities for the enterprise architect to facilitate the right products and services being developed. I will briefly walk through three different agile process models that can empower the enterprise architects to implement the strategies and design superior products.

LEAN Development:

The LEAN development model is based upon seven principles for how to structure the development process of digital products. One of the principles states that “Decide as late as possible”, which also indicates that different alternative solution designs have to be made available and presented for the stakeholder (product owner) who can decide what features to include in the product. The enterprise architect will in this particular process model act as the product owner or alternatively as the designer of the different designs that could be implemented.

The second principle that can prove to be interesting for an enterprise architect by using this process model is the “Optimize the whole”. This would mean the enterprise architect would have to guide the development team on how the “whole” of the software solution should be optimized and to what level. This can be done by the enterprise architect e.g., in the role as the product owner, but if needed the enterprise architect can to some extent provide guidance for the solution blueprint on what to be optimized.

The last principle in LEAN development that proves to be relevant for the enterprise architect is “Empower the team”, which means that the enterprise architect has to provide the relevant organizational structure and the relevant patterns in order to provide the team the ability to develop the relevant digital deliverables.

Scrum Development:

The Scrum Agile Framework (scrum) consists of a process framework that involves sprints of two to four weeks, depending on the setup the organization wants, though the most normal sprint length is two weeks, which includes testing of the new features. In addition to the sprints a daily scrum is hold were the development team and the scrum master will facilitate the a meeting on where only three things are on the agenda:

What has the individual developer done the previous day?
What is the individual developer planning to do during the present day?
Do any of the individual developers experience problems?

The development team demonstrates the delivered software features in the end of the sprint, and this empowers feedback from the product owner (the role which the enterprise architect can take). The product owner is also responsible for coaching the development team in-order to make them understand what features are to be developed. Likewise, is it the product owner that decides if the features have been delivered as planned. On the other hand, the product owner is responsible for providing the clarifications required by the software developers.

The scrum methodology does also include an approach that includes to some extent autonomous teams, which means the enterprise architect in this case would have to empower the developers to choose the right tools, frameworks and standards, but also to clarify how the different digital deliverables fits together and works well together. In other words, in this particular approach it is relevant that the enterprise architect is able to provide the blueprint for the content as well as the patterns to be used to deliver upon the content.

Extreme Programming:

The last approach to conduct agile software development is known as Extreme Programming (XP). This approach can also be used by organizations and enterprise architects. The “XP” approach is slightly different from an enterprise architecture perspective than the other approaches. From an enterprise architecture perspective, then the different deliverables have to be organized according to each-other and to provide coherence in the solution portfolio. This is where the enterprise architect is able to provide value of the team. Extreme programming does also include a principle about “listening” and by having engagement with the customer, and in this case the enterprise architect can act as the stand-in and ensure the features are translated for the development team. The problem regarding structure and optimization is also apparent with the extreme programming approach and in this particular context the enterprise architect will be able to provide the overall roadmap and the development framework for the development team e.g., through patterns and standards.

Conclusions

The enterprise architect will have to be versatile in his/her approach to deal with tasks in the relation to “translate” for the business strategy into relevant activities and products. This means the possibility to deal with (software) product management is one of the tasks that the enterprise architect has to be prepared to deal with effectively. Hereto, the enterprise architect has to ensure the roadmaps for the products are planned and available. Lastly, the development framework has to be setup and governed by the enterprise architect in order to ensure the empowerment of the different development teams, so they are able to deliver maximum velocity and deliver the digital deliverables.