With businesses struggling to get tangible value from EA, we share our expert advice to help you efficiently maximize the benefits.
Want to drive down the total cost of IT without damaging strategic business initiatives? Want to better connect your business operations to IT? Want to get an overview of how people, processes, data, and applications interconnect that can be shared with all stakeholders to empower them to make better decisions daily? To all the above, enterprise architecture (EA) promises the solution.
With EA being proclaimed as the closest proxy to The Holy Grail for the digital enterprise, how is it that, according to Gartner (June 2018):
Only “50% of companies succeeded on their first attempt at implementation”?
Only an appalling “16% of all companies surveyed actually gained measurable business value" from their EA practice?
And all this with EA standing firmly at an astonishing-for-any-technology 30-year maturity landmark!
To unlock this EA value paradox, you need to address the core architecture of EA: the frameworks and methodologies that underpin the practice as well as the vast majority of supporting tooling.
The notation of a Enterprise Architecture Framework is not the goal, it is the problem
As a technology business executive, a conversation with most old-school EAs is quite an experience. Rarely can you find yourself listening to such ivory-tower, abstract conceptualizing that’s so clearly disconnected from anything business unit leaders can be expected to understand (or care for). Adherence to, and perfect implementation of, an architecture notation standard is clearly the focal point. To many old-school EA practitioners, it feels like the goal.
“To drive successful EA in the ecosystem age, chief enterprise architects should do the exact opposite: they should forgo notation standards entirely, and focus on the business questions (in a prioritized order) they want to solve.”
To those less intimate with EA frameworks and notations, there are several being used as industry standard at the moment. Each and every one of them claims that by following our notation everyone will understand it, because it’s a language. But it’s easy to forget that languages have to be learned, and in order for it to be efficient every nuance needs to be understood by all parties. The investment in time alone to learn those nuances is incredible large. Time you don’t have in this age of Ecosystem Architectures.
While it’s undoubtedly possible to invest man years into implementing Enterprise Architecture Frameworks for even a mid-sized enterprise, tracking completion of the architecture work,and discussing the process with fellow EAs in the community is the path to ruin. To drive successful EA in the ecosystem age, chief enterprise architects should do the exact opposite: they should forgo notation standards entirely, and focus on the business questions (in a prioritized order) they want to solve.
Does this mean that architecture, or models, is of no importance to EA? Quite the opposite. An EA model that truly underpins the business questions you want to solve is vital to EA success. The standardized notations simply fail to deliver this critical need. Also, Enterprise Architecture Frameworks struggle to reflect the complexity of today’s IT world. Just ask yourself: can your IT landscape be divided strictly into platforms and applications only? Surely this is both an oversimplification as well as a gross restriction on flexibility at the same time.
This reminds me of a statement by a former colleague, Brian Jacobs, (whose blog on all things media/agency is well worth the read) that: “media is too important to leave to media people.” When it comes to EA, your EA architecture too is simply far too important to leave to the shiny Enterprise Architecture Frameworks standard at the moment.
Don’t use a hammer when a screwdriver is needed
They say that ‘less is more’. While perhaps a very contrarian statement to Enterprise Architecture Frameworks supporters, it applies perfectly to EA.
When following Enterprise Architecture Frameworks, a lot of work is required before you can even start addressing any business question. Interestingly, however, we see across our customers that when they start with the business question (the goal, or better yet the ROI case) and then work their way backwards to what type of an architectural (mini) model is needed, they’re able to solve the business need in a fraction of the time, and do so in a way that business stakeholders can also understand. This understanding of the process by business stakeholders creates trust towards the outcome — something which in a Enterprise Architecture Framework setting is borderline impossible to obtain.
We’ve summarized our thesis for value-driven EA into three principles, and encourage everyone to review their EA notation and EA practice against these three principles.
Perfect is the enemy of good
Agile (fast iteration and incrementalism) trumps waterfall (pedantic and towards Big Bang) every time
Focus on the business question(s), in a prioritized order, you want to solve
To summarize, start by asking yourself what is the problem you want to solve? Then work your way back to what data do you need, and which models are required/best fit the need. Again, keep the model simple, you can always expand on it later. Last, remember that perfect is the enemy of good, and that in today’s turbulent business landscape the road to perfection can be never-ending. (Those familiar with Data Lake projects for example will certainly find many parallels here.)
Stepping outside of Enterprise Architecture Frameworks is not your biggest risk – it’s your biggest opportunity.
Get in touch to schedule a demo and see how Ardoq could benefit your organization.
Download now the New Enterprise Architecture Magazines by Ardoq: