22 October 2020
By Thomas Rischbeck and Zsolt Czinkan
How does a Swiss health insurance company manage to set up an enterprise architecture (EA) without becoming more bureaucratic? This article describes along a real-life project at SWICA how EA can support digitalization as an instrument for dialogue and guideline for projects.
EA plays the dual role of "motorator" in digitalization and has a twofold effect:
1. as a "moderator" for overarching dialogues that promote a common understanding
2. as a "motor" that activates the stakeholders to cooperate in the guideline development
A pragmatic company in transition
SWICA has a distinct "startup-like" culture. The unbureaucratic way of working and the rapid decision-making processes at the highest level have always been conducive to the insurer's steady organic growth. This was essential in becoming market leader in customer satisfaction. However, growth pains have become apparent in the meantime: project managers increasingly expressed a need for orientation and guidance, and departments began to solve similar problems independently in different ways. There was no mechanism to provide stakeholders with the necessary contextual information.
The company is organised in functional silos. What used to be an advantageous and efficient model for decades, is now an impediment. In the digital age, customers see companies as a whole. They expect frictionless customer journeys and consistent information across all analogue or digital channels.
Digitalization requires interdisciplinary cooperation, holistic planning and coordination. Silos must be dismantled. A classic use case for EA.
Developing clear principles and creating transparency
SWICA was keen to keep the organisation’s inherent pragmatism. Creating a central EA department was not desired. Hence it was clear for us consultants from the beginning: we would not develop the EA in a quiet chamber, but in the middle of the project business. It should bring tangible benefits continuously and iteratively in pilot projects and in the departments.
In the beginning, the project partners have jointly formulated the following principles and expectations for the EA. The EA should...
...create enthusiasm and ongoing benefits in the projects.
...foster integration across all planning levels.
...arise iteratively and remain alive.
We have established a simple visual representation of the business and IT architecture and thereby created stakeholder-friendly illustrations. The high-level process map promoted interdepartmental dialogue and mutual understanding of working methods and capabilities. The map also revealed duplications and inconsistencies. In order to keep the effort low, we only analysed details in depth where it was essential for projects and decisions. For example, of the 600 IT systems used by the health insurer, only around 60 especially business-relevant applications were captured in the model.
Dependencies and connections between the different architecture levels have also been visualised: for example, business processes with organisational affiliation, assigned ICS controls and supporting business applications; customer journeys with the involved departments and activities; data with their protection requirements and categorisation, handling processes and ICT systems.
From supporter to motorator
For the implementation of these principles in the well-functioning organisation we have chosen a committee-based approach. In this approach, the appropriate composition of an interdisciplinary team is crucial. It must consist of representatives from all relevant departments.
This team will initially work as supporters and reviewers under the leadership of an adept leader. At first this leader develops architecture results by himself showing the way. Gradually, the team takes on more responsibility and thus becomes a self-runner.
In several phases, a decentralised architecture committee is thus created with an experienced flag bearer as "servant leader" and an active "change-willing" team. In order to become a motorator for cross-divisional change, the committee must be given the necessary decision-making power and be integrated into the strategy and project portfolio management processes.
By this means EA becomes the place to go for project managers and departments for architectural and prioritisation questions. It provides insights from the organisation for strategy development, for example by showing which processes are running suboptimal and why. In addition, it breaks down strategic measures into transformation steps and thus shows, among other things, how an organisational change affects processes. Furthermore, EA moderates the development of solutions between departments with competing goals, thereby clarifying responsibilities in overlapping customer journeys. The EA also answers questions from various departments, such as on the classification of processes according to business criticality.
Three critical success factors
For the success of EA’s development, top management commitment is necessary. At SWICA, this was given from the beginning. Top management also signalled that the project was not only about IT, but an important company-wide initiative.
With the EA introduced, more transparency emerged - on the one hand across all levels, on the other hand between the departments. This enabled open and constructive dialogues.
The committee-based approach ultimately resulted in a discipline that operates on its own. With clear guidelines, it creates the space for decentralised decisions and thus supports agility in projects and teams. This is how modern and pragmatic enterprise architecture works.
(Photo by Aaron Burson on Unsplash)
