Part II Agile EAM …
In the
first part of this article I tried to demonstrate that mankind is trying to manage complexity in enterprises for more than a hundred years and most of those processes, tools and techniques that we nowadays use to summarize under the discipline “enterprise architecture management” have been there before. My intention behind that was to demystify Enterprise Architecture Management by explaining the ideas behind it from a historic perspective.
Part I stopped with explaining the shift of Gartner’s Enterprise Architecture definition.
Gartner’s new definition of Enterprise Architecture Management is an implication of two main effects we have experienced in the last ten years.
EAM’s Reputation
First one is the sobering insight that actual results of EAM do not match the hopes enterprises put into that topic. Well, that doesn’t sound very surprising. That happens every time a new thing goes through the hype cycle. But in case of EAM it was a bit more than that. Enterprise Architects were known to be sitting in an ivory tower without any deeper knowledge neither of business nor technology. The governance concentrated approach and the concentration on frameworks was meant to be responsible for slowing down innovation and hinder usage of latest technologies to bring forward business.
New Digital Business Models
The second effect which forced a rethinking of the role of EAM was the rise of new technologies like cloud computing, mobile, big data, internet of things, artificial intelligence and distributed ledgers (aka Blockchain). Each these new trends created a whole universe of possible new so call digital business models. The impact of the latter we can even read directly in Gartner’s new definition.
In the same time agile software development and DevOps models brought more flexibility and increased time to market in software projects. Design Thinking and Business Model Canvas brought new interdisciplinary and lean ways of invention, innovation and business development for digital customer communications in particular.
Bimodal IT
But that’s not enough … Enterprises started to ramp up so called bimodal IT organizations to have a proper answer for digital challenges.
EAM’s suffering from its reputation, new digital challenges and new methods, tools and techniques and the challenge to bring together requirements of bimodal IT organizations motivated people to rethink the way EAM defined itself in the past.
Is Agile EAM the Answer?
There are several approaches to make EAM more lean, agile and pragmatic. Nearly all of those postulate to focus on business values rather than putting architecture frameworks into the foreground. Enterprise architects need to have closer communication with agile teams to understand their demand and to get informed about latest architecture developments earlier. Another pragmatic proposal is to create an artefact only, if there is a stakeholder for it.
In terms of tools and techniques it is no surprise that new approaches try to integrate design thinking and business model canvas tool set into enterprise architecture management.
Interestingly some initiatives coming from Germany criticize the framework centric approach of the past but then again they try to introduce new process models and method toolsets they call “Business Architecture” or “Architecture Engineering”. Those tool sets try to integrate design thinking and business model canvas elements. These initiatives hope that new processes will deliver better results than processes came before with those exiting frameworks.
This might have to do with the traditional way the discipline called “Wirtschaftsinformatik” has created results in Germany. I still do not know how to translate it properly. Is it “Information Systems” or “business informatics”? I really don’t know. What I do know is that creating process models, methods and toolsets for a certain class of enterprises challenges have always been the core of it in Germany.
To me this doesn’t sound like a pragmatic lean agile approach though.
What’s agile EAM to me?
To me a more pragmatic approach sounds reasonable. Agile core principles must be put into front not processes or methods:
- Define your goals and have them in mind. Keep in mind that your goals must create a measurable value!
- Check your set of actions against your goals continuously. Do not things because a process definition tells you to do so. Do things only if it helps you to achieve your goals.
- You’re not done when an artefact is created; you’re done when you have reached your goals.
- Always consider risks. You have to live with a high level of uncertainty and dynamics. Make use of anything that helps you reduce or mitigate risk. E.g. do things iteratively, communicate often and make things transparent.
- Make use of common sense!
Enterprise Architects and EAM organizations have to consider these simple rules to follow a reasonable agile and pragmatic approach. In that case they can use processes and frameworks whenever it really make sense. It really doesn’t matter if they use TOGAF or any of those new agile process models then.
Enterprise Architecture Management has always been a matter of soft skills not a matter of processes and frameworks.
