Is Enterprise Architecture just Semantics?
How does one balance the need for strategic technology direction across a large enterprise with enabling agility in exploiting fast evolving new technology? Historically, this role has fallen to Enterprise Architecture. Enterprise Architecture (EA) as a discipline and function has had a tough run of it for the last few years. It is forever caught in the balance between theory from a height and practice on the ground. Or, as Alfred Korzybski said, “The map is not the territory.” The irony of him being an expert in semantics won’t be lost on anybody who’s ever had an argument with an Enterprise Architect.
Comprehensive Enterprise Architecture
Classically, following some of the well-known frameworks such as Zachman and TOGAF, EA links a business’ strategy, formally mapping strategic business objectivesto the technologies and processes required to fulfill thoseobjectives.This is a time consuming piece of work that is very difficult to keep up to date if it’s completed at all. But it sounds like a good idea. Who wouldn’t want to ensure their strategy is effectively being implemented?
At some point they make a leap into technology choice where, usually, the business stakeholders look away in confusion, Enterprise Architects rub their hands in glee and the engineers who will be left implementing the decisions run for the hills
Business Strategy for any large industry is not a secret across the participants and in (mostly) fair markets is (mostly) the same. It comes down to getting more customers more efficiently. This means that the articulation of the strategy is likely to be generic inside the organisation and Enterprise Architects battle to get at the ‘secret sauce’ of the company in discussions with senior executives. This results in very worthy documents describing what everyone thinks is obvious. At some point they make a leap into technology choice where, usually, the business stakeholders look away in confusion, Enterprise Architects rub their hands in glee and the engineers who will be left implementing the decisions run for the hills. It turns out that PowerPoint doesn’t run on a server… but it can grow dust.
Governing Enterprise Architecture
As the grand strategy grows dust many EA functions are pushed into governing or enforcing the technology standards that resulted from this analysis. Although, it is also fair to note that some just skip step 1 and go straight for the standards. It is more efficient.
Enforcing standards without credibility with the practitioners who must implement them is not a very relaxing job. For every raised eye-brow you get to implement another process gate or supervisor. The usual argument around standards refers to the efficiency strategy from before – more technologies are bad and fewer are better. This is true. It also misses the point. Bad design is expensive. Complex processes to govern the what and not the how is expensive.
It can work though.
Put a group of architects from across your business in a room and ask them, “How would you build this business FROM NOW ON?” They will produce some principles (how) and standards (what) that reflect what they think. Don’t worry, the odd one or two who think mainframes are making a comeback or that automated testing is just witchcraft will be sidelined. Govern that. And encourage the outliers to re-skill. You will find that the architects keep each other honest. Although a Chief Architect trusted across the businesses who can play tie-breaker is helpful. I have seen it done across 30+ businesses.
Transformational Enterprise Architecture
All is not lost. Talk to any EA and they will tell you they are looking for a deep understanding of what technology investments will best serve the business. Believe me, they’re not intentionally wasting their time. The quality of conversation an organization has about its strategy and what it means for all functions (not just technology) is really what is at issue. That’s what makes the self-governance work.
Many organisations have embarked on technology transformations. Exactly what these entail often may only be communicated using great quantities of powerpoint. So we will have to “pass over it in silence” (as Wittgenstein, another expert in semantics said). The implications for organisations changing structure & process to exploit new technologies are profound though, resulting in renewed focus on customer experience, changing how teams work and adopting the technologies and practices that the perceived leaders use… like cloud, devops etc.
An organisation dealing with something it sees as a new existential threat which galvanizes action and transformation is a great opportunity for pragmatic EA:
“What does improved customer experience mean for how we develop and deploy code?”
“What are the INTERNAL technology barriers to driving digital adoption?”
Those would be useful conversations to have and your EA function can help you get to an answer.
In situations such as this, EA functions should focus on the new and how to build the future. The alternative is EA seen as applying arbitrary governance from a (mistrusted) legacy source and opposed at every turn. Given the likely importance of the strategic initiative they are unlikely to win.
Platform Enterprise Architecture
At Scotiabank, we decided to design a platformthat implementsall of the standards that matter.It is called PLATO.
We took into account our digital transformation objectives, the fact that we operate in more than 50 markets and have heavy retail presence in South America. We realized that security was our number one priority. We also realized that any set of technologies that would be relevant would not only enable the future but also the transformation of the past.
We built a platform based on continuous delivery, policy-as-code and cloud native development, backed by a world class secure data and analytics platform on the cloud.
Today, we have over 450 applications running on PLATO and the conversation isn’t about standards but about how to move faster to get the benefits of the platform.
Good EA is about knowing what matters to those who build your solutions and how to help them all do it the same way. That isn’t semantics, it’s creating a common grammar for how everybody talks about technology.