Originally posted in German language on September 19, 2020 on redblog

By: Dr. Christoph Moser, Boris K.A. Reinhard

In the following example, we show a way of thinking to master this challenge with the agile framework, OKR, and the Enterprise Architecture Management (EAM) standard, ArchiMate. We demonstrate that agility and architecture go hand-in-hand.

Our Case Study

The progressive development of electric drive technologies and battery systems has opened up a new business model for the fictitious energy supplier GreenEnergy: eMobility. In this context GreenEnergy is planning a partnership with the eRoaming specialist, Plug & Charge.

Plug & Charge enables eDrivers to charge their vehicles in a user-friendly way. This takes place without administrative effort, i.e. “plug and charge” (cable). Billing is conveniently done via the electricity bill. Automatic authentication and authorization at the charging station makes prior registration (e.g. RFID card systems, credit cards, and mobile apps) obsolete. The customer experience is massively increased, thereby boosting demand.

With the decision to introduce the new model, a decision about the future architecture of the company is made at the same time. When implementing and providing the required capabilities, business processes are adapted by GreenEnergy, new systems are introduced, information flows and interfaces are adapted and the “digital” capability “plug in and load” is provided.

The OKR & ArchiMate Approach

The introduction of this new sales channel is based on an agile approach. For the time being, the focus will be on early customer feedback. Only in the later phases will the focus be on the technical infrastructure. Central to each cycle of the project are the “Objectives & Key Results” (OKR), which will generate a measurable added value for GreenEnergy and its customers (Note: Basics of OKR are not discussed further here, please contact us for more information).

At the end of an OKR cycle there is a target state, in ArchiMate, “plateaus”. Objectives can be represented in ArchiMate by Goals, Key Results by Outcomes.
The first cycle (Plateau 1) is formulated in OKR Planning. For each OKR set, the responsible teams must make a commitment. Our first cycle includes subsequent OKRs.

Objective (Example)

Test customers charge their car via Plug & Charge service.

Key Results (Excerpt)

  • The interim process for the semi-automatic data transfer of accounting data is introduced.
  • A prototype is provided for 10 selected stations.
  • The Plug & Charge prototype is available for 30 test customers.

Further Planning Cycles/Plateaus

The OKR sets for the further plateaus are defined at the beginning of each new cycle in the planning process when the findings from the previous cycle are available (keywords: “review”, “retro”; in practice the cycles slightly overlap).

In further plateaus, the roadmap maps out initial rough ideas that need to be adjusted or reformulated after each cycle.

The view below shows the roadmap, in an ArchiMate view, commonly used in architecture management. In OKR planning, the OKRs for the company, divisions and teams are adjusted for the current cycle. The current OKRs are aimed at reaching the next plateau.

Key results can be implemented in the OKR team depending on the preferred approach (e.g. Scrum, Kanban etc.) as OKR does not make any specifications in this regard. We assign exemplary to one of the Key Results sprints (i.e. work packages). With the realization of the Key Results or Sprints, elements of the enterprise architecture are introduced, modified or replaced:

The business process, “Billing eCharging services”, is defined within the sprint, “eCharging billing processes”.

The necessary adjustments to the “Settlement Platform” settlement platform, for the manual import of the settlement data, is made in the sprint “eCharging Enablement”, etc.

Risks arise from the partial automation and media discontinuities, “Settlement errors due to incorrect data transfer” and “Delayed settlement”. These are mapped in ArchiMate as assessments. The risks are accepted for Plateau 1. Before implementing Plateau 2, they must be evaluated again regarding their effects.

Depending on their importance, the risks are addressed either directly in Plateau 2 or in one of the subsequent plateaus.

Small iterations instead of a large master plan: Instead of setting long-term, big goals, we concentrate on short-term planning and implementation intervals. Plateau 2 is not yet being modeled in detail. This allows us to react flexibly to the findings from the previous Plateau. Key results and sprints are therefore not yet defined.

Outcome-Driven Architecture: OKRs as a mandatory part of the transformation roadmap

The aggregated progress of the Key Results reflects the overall progress in relation to the associated objective. For each Key Result, the confidence level is also continuously assessed. The Confidence Level reflects how likely it is that a Key Result can actually be achieved in the current cycle.

In the subsequent transformation cockpit, in addition to the OKRs, the architecture-relevant aspects are communicated in a way that is relevant to all stakeholder groups (end customer, product owner, scrum master, enterprise architect, etc.).

Screenshot: ADOIT, www.boc-group.com/adoit

Conclusion

Our approach shows how the two worlds can be integrated through OKRs and ArchiMate.
We address this architectural challenge by allocating OKRs from the agile world of architectural platforms, which will be used to design the roadmap, step by step.

The Authors

Boris K.A. Reinhard – Dipl.-Ing. & M.Sc.
Boris sees his task as empowering organizations to change. He is an entrepreneur, management coach, lecturer, trainer and a mentor (https://redminds.co).

Dr. Christoph Moser
Christoph is Product Manager of ADOIT, the EA suite classified as a leader by analyst firms.

Share This Story!

Subscribe to our free newsletter

Expert articles on trending topics, monthly information on our free webinars & announcements of new product versions.