Enterprise Architecture Management (EAM) in digital transformation
How do you move from a waterfall-based approach to agile Enterprise Architecture Management?
The digital transformation does not stop at Enterprise Architecture Management (EAM). But how do you teach agility and DevOps to the bureaucratic waterfall approach in traditional EAM? How do you create win-win situations? Changing the corporate culture is just as much an issue as dusting off the hierarchical structures! Mutual benefits only come with the acceptance of the views of all stakeholders involved and thus with trust.
Index
Was ist Enterprise Architecture Management?
Nowadays, almost everyone in an IT company is an architect. One of the tasks of Enterprise Architecture Management (EAM for short) is the creation of a uniform corporate language when it comes to … yes, what are they called, these “things” … applications, systems, software products, ….
Why? The point is to accompany these “things” throughout their entire life cycle on the basis of a coherent technology vision, to recognise innovation potential, to identify technology risks, to derive a technology strategy.
And often EAM already fails because of this corporate language, because the mostly abstract orders, including abstract or economic business language, come directly from the board and “have to be implemented”. There is usually no budgeting, because “everyone has to participate”. This is the reality, and EAM is ground between the board and development and operations.
Ask your board how many application “things” exist in the group! And then ask a second decision-maker. The delta often reflects the unofficial level of confusion!
It’s a pity, really, because aging IT groups need an overview of innovations like a morsel of bread in order not to end up on the siding. Being overtaken by one of the much more nimble fintechs is not uncommon.
So how can enterprise architecture management get its act together to be the promised lever for digital transformation?
Loose-lose: what does Enterprise Architecture Management (EAM) currently look like?
To illustrate the incompatibility between the worlds of the board and the “real” operational world of the product teams, I would like to “model” a few typical striking conversations between enterprise architects and other IT roles. John is the Enterprise Architect, Larry comes from a product team (e.g. a Scrum Master, a Product Manager, a Test Manager).
John: Hey Larry, the board gave me an order yesterday at 11:34pm to do a survey of all Java applications. Target: 5 slides by 12:00 noon today. I’ll send you the form in a minute, OK?
Larry: John, I have go-live of the new release at the end of the week, it won’t be ….
John: Thanks, Larry, I’m afraid it has to be!
Does this sound familiar? Neither of them will have any lasting advantage from this task. Pity, really. Lose-lose.
At the same time, of course, the two of them are worried.
Larry’s thoughts: Man, again. This is the third such job this month that steals my time. Can’t they do it more sensibly and create a repository with all the information? Then I’d get something out of it, I’d also like an overview of the Java applications, then I wouldn’t have to collect this information myself like everyone else!
John’s thoughts: Quickly away. I know anyway that this was the third such job this month. They’re really busy, and actually I’d like to help them. But how? We don’t have a consistent approach, budget for a useful EA tool and resources. And actually I don’t quite understand the Java question from the board? Have to report something to the board again, probably. It would be really cool if we could establish real agile EAM! This way, somehow no one gets anything out of it…”
Why does EAM so often end up in the loose-lose one-way street?
Win-win: where could EAM levers be applied?
Sustainability, stakeholder benefit and finding common ground: the enterprise architect is actually support for the product teams. If he is clever, he therefore tries to achieve win-win situations. To do this, he must know the wishes of all stakeholders well, and sometimes remain persistent with tact. Look proactively into the future instead of reactively rehashing the past.
What could the conversation look like so that everyone gets something out of it? A try …
Larry: Hey John, good to see you. Last time we agreed to manage technology information better and more transparently. Very cool that you gave all the product teams an opportunity to do that. There have already been two situations where we were able to use the information from the other product teams and get the right information faster in the start-up phase of the project!
John: I’m glad about that! Our joint discussions do bring something after all! Fortunately, your wishes were well received by the board. Since then, I can also give the board a monthly report that they can use in the supervisory board. And the best thing about it: I didn’t just suck the information out of my fingers, it’s real, thank you!
Very rarely have I been able to experience such positive effects myself. Effects that result from calmness and attentiveness, from listening to each other and responding to each other. What does agility or self-responsibility mean here – a combination that I like to classify in the mindset of the so-called “New Work”? The people who should know best can participate in the creative joint process. The so-called management function is actually “only” a “positive waste product”.
How do you manage to live EAM in a win-win mindset?
Benefits of EAM
Before we get to New Work with a positive mindset and radical transparency, some pragmatic thoughts. What could be a benefit of EAM?
You always have to think about this question in the context of your own company! A TOGAF copy of the EAM goals or principles is not helpful, e.g. “The primary goal of EAM is cost reduction”. Has never worked. Yes, it may be that costs can be reduced. But EAM always brings more quality, and the cost savings are not accounting, they always go straight into new methods or procedures: a better overview of the applications enables projects to start faster, the time gained and the less effort is immediately put into sensible other efforts.
So what does the company want to achieve with EAM?
About a year ago, I formulated a goal: “To make people happy”. Yes, perhaps too generally formulated! But in essence, it could be about this.
The following “generic target candidates” spontaneously come to mind:
- Promoting cooperation in the course of projects: if you have a good overview of all applications in the company based on common terminology, it is easy to have a discussion with different stakeholders. If everyone is clear about what is meant by “application X”, then you can talk about solutions right away. It’s also more fun!
- Provision of “DevOps belly shops”: For me, DevOps belly shops are tool stacks with many degrees of freedom, e.g. for the developers of applications. Freedom where creativity is required from developers (each developer works best with his known frameworks), and “belly shops” where developers would like to accept help (provision of sophisticated testing tools connected to requirement tools, autotest frameworks; actually all tools that are “at the edge” necessary for the quality of applications).
- Life of radical transparency: game theory and behavioural economics … here I always think of James Bond and double agents. The agent world is all about secrets, concealment of information and misdirection. But it’s not so untypical for corporate communication. But who keeps track of truth and deceptive information? With true “radical transparency” you get straight to the point!
- Creating bold innovative products: probably a consequence of the first three candidates (or vice versa) is the creation of bold applications that are also beneficial to customers, e.g. blockchains in the banking world.
The crisis as an opportunity! Building bridges! – New Enterprise Architecture Management (EAM)
Radical transparency, changing the mindset of the corporate culture, mindfulness in dealing with colleagues, allowing multiple opinions, consciously using diversity, dismantling hierarchies, building bridges instead of walls! Concepts that are seen as problematic in traditional hierarchically structured companies.
All these concepts take time and are different for each company. Deal with it, allow it, go new ways! New Work and EAM. New EAM …
In any case, a combination that has it all. And the crisis shows that it is technically possible. Home office has become the de facto standard. But is it really practised sensibly everywhere? And what happens when the crisis is over? Do we stick with the newly won gains?
I am looking forward to the new future!
Comments are closed.