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.