Will McKinsey be the first ‘big consultancy’ that gets (enterprise) architecture right?

I’ve experienced and seen quite a bit of what the ‘big consultancies’ tell organisations about (enterprise) architecture and over the years I’ve seen quite a bit that in my observation does more harm than good, sometimes even serious harm, hundreds of millions of dollars wasted kind of harm. The approaches promoted by ‘big consultancy’ are generally based on assumptions that will not withstand a bit of scrutiny, let alone the confrontation with the actual reality of complex Business-IT landscapes in larger organisations. There is an overabundance of simplistic and logically sounding advise which often has little impact on the problems at hand.

Advise that sells better than harsh realism, though.

The situation in academia is not much better. Here we sometimes even see even more impractical approaches, which look really ‘sciency’, formulas and all, which are about as useful as applying Einstein’s relativity theory to the problem of, say, technical debt (which isn’t debt at all, but I digress, as usual).

And the typical dedicated EA firms (often direct or indirect tool vendors) have, let we say, often strong ties to the previous millennium.

So imagine my amazement when I ran across a blog post from McKinsey (Crafting the optimal model for the IT architecture organization) which was not the usual (mostly) drivel, but that actually contained several worthwhile statements about (enterprise) architecture and architects. And what was even more, the blog post linked to an article (How enterprise architects need to evolve to survive in a digital world) which had even more good points.

[Note: the ‘featured image’ above is from their article. It might lead you to think that the names there are the ones that wrote this post, but that is not the case. So far, I’ve written everything on this site myself – Gerben]

McKinsey starts the article with:

With CIOs increasingly moving their organizations to an agile DevOps operating model, that discovery has prompted much questioning about whether they still need architects […]. The reality is that most organizations still need architects. In fact, our research with Henley Business School is clear: digital transformations suffer when architects are not involved”.

McKinsey, 2021

Agreed, but frankly, it would be utterly amazing if the naive idea that “the best architectures come from self-organising teams” (as stated in the principles underlying the Agile Manifesto) was simply true. It is misleading. It is still widely believed, though.

So, what are the notable positive elements, I think, that McKinsey mentions?

• The specific mention of the importance of fighting/preventing technical debt (which is probably the most important factor in establishing agility and robustness in your organisation);
• A refreshing lack of ‘the speedup of change’ nonsense (in reality, change becomes ever more challenging and we are in the fight of our lives to keep momentum);
• “Architects should facilitate the discussion between product teams around features and solutions.” Yep: the only way we can make sound architectural discussions is in the interaction with those who have the knowledge — there are relatively few design decisions made at the top that have a real effect. But a caveat, see below;
• “The flexibility and responsiveness of a […] business are severely hampered if those traits aren’t also reflected in the tech foundation layer” (my emphasis). Those that came from the classical top-down alignment approach to EA (which still is the ‘best practice’ — nope — sold by many consultancies) seem to be in a slow learning process about the fact that agility works bottom-up. The reality is: agility is ‘all the way down’ or it isn’t. It is nonsense to think you can have an agile outside without an agile foundation. Give it another 10 years and that insight will be common wisdom;
• Architects must change (that is, for those that haven’t already or never were in the first place…):
  • “From […] theorist to pragmatic communicator”;
  • “From system advocate to engineer”;

In the new world of agile and DevOps, many architects are unhelpful—and sometimes worse. That’s often because their coding knowledge is outdated or based on a theoretical understanding of IT issues, so their advice and recommendations are often wrong. (article)

In the past, the architecture function focused on conceptual thinking and the aggregation of refined artifacts to drive the company’s architecture discussions. In the new federated model, the architecture function must also have strong engineering skills in architecture and coding. (blog)

McKinsey, 2021, 2022

• Architects “need to think and operate more like engineers. […] Those who think this kind of “get-your-hands-dirty” problem solving and action is beneath them may find their usefulness to the organization dwindling”;
• How do you get good architects? Because the combination of being able to interact both on a deep technological level and on a higher organisational level is extremely rare. Money, according to McKinsey/Henley research, is important, but only ranks 6th. What these good architects want is “a meaningful role”. And that, I think, requires commitment to the role of architecture from the top.

The bottom line is this: McKinsey is apparently the first ‘big consultancy’ that recognises the importance of ‘engineering skills’ for ‘(enterprise) architecture’. Gone are the days of PowerPoint slides with a few boxes and arrows and simplistic principles and getting by with ‘understanding the business’. The days of meaningful technical-architectural discussions about design decisions are here. That doesn’t mean every (enterprise) architect needs to be a code geek (I know decent architects who aren’t). What the architect must be able to do is dig in and understand what is happening. And there, a bit of code-geekiness or other technical hands-on really, really helps. And don’t forget: use it or lose it.

Note about ‘understanding the business’:

For good IT advisors, the kind that actually really understand the technology, the phrase ‘we need an IT advisor who above all understands the business’ is a warning sign that can easily mean an environment […] where being an IT advisor is like being a farmer sowing seeds on hard rock.

Wanted: IT advisor. No real IT insight required

Actually, the ‘business side of things’ has become a pretty suspect phrase, given that the time that IT was ‘support’ for ‘the business’ is decades behind us, and these days the separation is becoming less and less meaningful.

So, is there nothing to criticise here? If that were only true. Let’s address a few of the weak points.

Not everything McKinsey writes is up to par. E.g. the article even starts with popular nonsense about ‘digital natives’, such as the mistaken assumption that the difference between the incumbents and the ‘digital natives’ is that the latter have “the benefits of a highly skilled and experienced workforce operating in a start-up culture”. Or the statements that the ‘digital natives’ do not have ‘enterprise architects’ (which is probably because they are generally called ‘founder’ or eventually ‘chief technology officer’).

Most incumbents I know are very ‘digital’. They do often have complex established landscapes, but that only shows that the ‘two-speed or bimodal’ IT exists, but not as most people think, namely: adding to a landscape is relatively easy, changing what is there already is hard. The root cause of all the difficulties in IT is in the end rather basic: IT is fundamentally brittle and scaling that up leads in the end to a sort of ‘complexity crunch‘. The IT revolution means we are in a constant fight to maintain the combination of ‘agility, robustness, and efficiency’ in the context of ever more complex landscapes. So, the most important reason start-ups have it easy, for instance, is because they are… startups. But I digress, as usual, once more.

Then there is this statement from McKinsey: “enterprise architects need to manage a consistent technology stack that comes as a “batteries included,” ready-to-use platform for new development teams”. The phrases often in my discussions are about the “DevOps-Ready Data Center” (DRDC: offering platforms ‘as a service’ to the development teams where a lot of the requirements are guaranteed as Infra/Configuration as Code, such as controls, monitoring, logging, security baselines, etc., both on-premises and in the cloud) and the “DevOps Ready Development Pipelines” (DRDP). The combination of agility and robustness as being the ultimate challenge in ever more complex Business-IT landscapes. So, yes, we need such stacks. My beef is with the ‘enterprise architects need to manage‘ part of McKinsey’s statement. What does that entail? The blog post and article are a bit hazy on the subject. At one time they speak about a mandate, the other about architecture being more of a coach.

I agree that the orthodox ideas of principles and ‘paper’ laws doesn’t work (see Chess and the Art of Enterprise Architecture as book or keynote) and that interaction on design decisions is key. But McKinsey seems to underestimate the remaining importance of checks & balances on design decisions, and a decent ownership and governance structure for assessing those design decisions. This does not mean going back to Big Upfront Design (BUFD) and lots of rules and regulations, but the puzzle of ownership on design decisions in the Business IT landscape (at all levels) will remain, regardless of decisions being ‘on paper’ or embedded ‘in code’. We need interaction and checks & balances.

There is also a bit of oversimplification and demagoguery here and there. “In most digital-native companies, everyone is either an architect or thinks like one”. Nope. With the opposite demagoguery I could easily state that the digital-native companies, especially the small startups, are often frightfully naive about complexity. The way McKinsey describes the ‘old’ enterprise architecture is also a bit of a red herring, nobody has worked like that for a long time now. And when McKinsey writes: “with more flexible systems and automation taking over many architecture-related policies, there is no longer the need for “laws” documented on paper. Rather, rules and guidelines need to be integrated into the deployment mechanism” they are naive. Yes, we should not work too much with ‘laws’, design is an art more than a science, and we should implement a lot ‘in code’ (like security baselines etc.), but thinking that because rules and guidelines “[are] integrated into the deployment mechanism [so] the developer receives feedback and a suggestion for good practices on the respective topic in a timely, helpful way.” is frightfully naive about the feasibility of it all.

But, having said that, and noting that there are more aspects than this for getting it right, well done, McKinsey! It was high time that one of the ‘big consultancies’ took the message about enterprise architecture being a practical, pragmatic, interactive, and above all technology-intensive discipline to the board room. Thank you.

PS. Architects are not the only ones that after all do require engineering (such as coding) skills to add value. The same will be true for others as well. Think security specialists who may be well grounded in vulnerability management, prevention, detection, and remediation of cybersecurity risks and breaches, but who will require the same engineering skills as modern enterprise architects so they understand IT well enough to help create actual usable security design decisions in complex landscapes. There too, an impractical ‘Dr. No’ attitude may be why they often had (and still have) so much trouble of being listened to. The importance of security (think: ransomware nightmare scenarios keeping CEO’s awake) currently forces organisations to listen, so they may get away with it for a long time still. McKinsey advises “Build an architecture mindset across the company” and I think that is important too. But let’s make that “Build an architecture and security mindset across the company”. Or maybe better: “Build a healthy landscape mindset across the company”. That was the last digression today. Promised.