To crowd-source ideas for his next session at Forrester’s Enterprise Architecture Forum, Principal Analyst and blogger Jeff Scott indulged in the age-old ‘What is Enterprise Architecture?’ debate. Definition debates have been aired in online forums so many times it’s a wonder anyone bothers to post, but each time a new crop of wannabes pop up to trot out the same semantic debates. Not so this time. To Jeff’s credit, his post pulled 3 recommendations and 14 comments, significant not so much numerically but for who responded and the thoughtfulness of the respondents.
To be fair, Jeff asked for more than ‘what EA means to me’. First, he states the essential elements of the as-is EA paradigm – governance, principles, current state, reference architecture, target state and solutions architecture, each with an uncontentious definition. No arguments there. Then he steps out into the void…
I have been doing a lot of reflecting lately about the state of EA and what it means as we move forward into business architecture… It seems to me that we are stuck in an outdated– and I will go out on a limb here and say not very successful – paradigm.
So what’s the problem? We seem to adhere to this model even though it is at best only moderately successful. For example, most EAs have established a governance process, but very few describe it as being impactful. Almost all EA teams have a set of principles, but almost none actually live by them – they are more like a set of good intentions. And who has actually attained a reasonable facsimile of their target state?
But what is really nagging at me is this: Is this the best paradigm for creating a business architecture that business types will appreciate and engage with?
Assuming the mantel of great orators from history, respondents waxed lyrical on interrogo centricus (‘all of architecture really comes down to a single idea: that things work better when they work together’ – Tom Graves), on interrogo debitus (‘at the end of the day, it is the responsibility of the executive to steer the organisation towards the vision’ – Michael Lambrellis) and on interrogo mortalis (‘the reality is that businesses, as extensions of human beings, don’t always fit into the paradigms that we dream up’ – Chris Lockhart).
But the most prominent theme in the comment stream was efficiency versus effectiveness of EA. The argument goes like this. Most EAs let themselves be technology-bound and end up delivering improvements to the efficiency of current technology, because that is what they know and that is what they are comfortable doing. They are prone to fixing what they can fix, not what needs fixing. The subtext is that meaningful business transformation is too messy, too hard, and too dependent on unpredictable and obnoxious people for the average EA to entertain. The theme depicts the EA as uber-technician, grown up from bug and box-fixing but not sufficiently grown up to engage with the business powerbrokers. Tom Graves’ summary says it neatly – ‘Enterprise-architecture is literally the architecture of the enterprise as a whole – not solely the architecture of the enterprise-IT’.
The orators on Jeff’s comment-stream argued coherently for pursuit of technology effectiveness, not efficiency. If that means changing your business machinery to meet changed customer and market conditions then change it, don’t waste time making it run 10% better, faster or cheaper. If only real-world EA were so simple.
Effective Enterprise Architecture (let’s call it EEA) is delivered on a foundation of business-centricity and whole-of-enterprise awareness. EEA needs engagement and establishment of a level of trust across the top of the organisation, with the business executives who shape strategy, control budgets and expenditure, and steer the largest and most business-critical projects. This takes a broad understanding of the business, including a propensity to think in business terms first and technology second, as well as a singular focus on using technology to support the organisation’s goals and objectives.
To achieve this, EEA practitioners must develop mindshare with their CIOs and program leaders, without neglecting the essential foundation of maintaining eye-to-eye trust with the organisation’s enterprise application, platform and SaaS champions and vendors. Care-factor must be high and business-focussed. EEA practitioners should wake in the middle of the night and start instant-messaging at about the same time their CIOs do. This is a big change for people who have been paid all their careers for fixing technology.
Business architecture, Jeff’s current platform for EA happiness, involves handling the technology implications of business futures at the most fundamental level. Would this acquisition help us meet our business strategy? Should we outsource this function? Should we restructure around customer segments? The EA concerns that fill the pages of magazines – virtualisation, ERP upgrade, licensing an enterprise service bus – continue to be important choices but they do not define the business. This is the space where EEA plays.
My answer to Jeff’s question (‘…is this the best paradigm for creating a business architecture that business types will appreciate and engage with?’) is a qualified ‘maybe’. Coaxing busy executives to give more than lip-service to IT governance processes, EA principles and target states will continue to challenge EAs. And there is no argument that attention to these factors can provide the foundation for effective EA.
But grinding out the machinery of EA will increasingly take second place to EA influence in vivo, in the moment, at the highest levels, where EEAs shape the business vision in the collective mind-share of the influencers.
Tomorrow’s EEAs will not be sourced from today’s EA pool, and they are unlikely to identify with the technology-infused ‘EA’ label. They may call themselves ‘business strategists’, ‘shapers’, ‘mavens’ or ‘connectors’, leaving the architecture analogy in the dust of twentieth century structuralism. In the mean time, opportunities for EAs to become EEAs abound. Play in that space if you can.