Enterprise architecture is dead

I wrote this piece in April, suggested by some friends who used to work as enterprise architects. Agree or disagree with the post? I’d love to hear your feedback!

When I rejoined the federal government in 2016, our team’s desks were (for a few months) around the corner from a large team working on a financial management transformation project. The walls in their area were covered in mesmerizing, plotter-printed posters detailing a web of interconnected IT systems, SAP S/4HANA icons in abundance. This was my first introduction to enterprise architecture (EA). If you haven’t worked in government IT, it can be hard to describe, but if you’ve seen business capability models, target state architectures, TOGAF frameworks, or architecture review committee presentation decks, hello. You’ve met enterprise architecture.

Coming from a tech startup, I found this all fascinating. We had architecture, we just didn’t have the posters and paperwork and processes that “enterprise” architecture had. In fact, we had a lot of architecture: building a mobile phone-based communications platform (voice/IVR and SMS) for use in developing countries around the world, you needed it.

We had our product’s online platform and interface running on AWS infrastructure in North America, and then we had in-country servers in almost a dozen countries in sub-Saharan Africa and parts of Asia (by time I wrapped up) that could interface with local telecom operator systems and APIs. Servers located in data centres in some of those countries had days-long network outages on a regular basis (“two nines” would have been a major improvement, as overseas network cables or centralized national telecom infrastructure sporadically went down). In 2014, we re-engineered our entire tech stack (splitting our platform into two software products) so that our in-country servers could operate fully independently of our AWS infrastructure, working locally and queuing up survey responses and system notifications to send back once the network came online.

None of this was standalone “architecture” work, even though in hindsight we could have made some cool plotter-printed posters. It was just a normal part of doing full-stack software development. You have infrastructure of different types in different places, and part of writing good code (and using managed services thoughtfully) is making sure it can reliably work together. To the extent that this is architecture work, it certainly isn’t a siloed, distinct role that’s separate from software development.

Promoted out of “doing” and into “watching”

In government tech work, standalone roles are all too common. Full-time enterprise architecture roles are an example of this, made more complicated by how they fit in the (now IT) CS classification framework. Here’s what a typical career progression might look like as a software developer in the federal government:

• CS-01 (now IT-01) Junior developer, writing software or web applications with a lot of supervision.
• CS-02 Developer, writing software as part of a team.
• CS-03 Team lead (managing a small team of software developers), or technical advisor, or enterprise architect. (There’s some variety both in how these roles are labelled and in the types of work they entail.)
• CS-04 Senior enterprise architect (or other specialist field, like IT security or database administration, as a senior technical advisor).
• CS-05 Director-equivalent management role in an IT division.

In practice there might be years or a decade at each of these steps, partly because of limited internal career progression opportunities. (In many departments, you’ll need 10 years’ experience to qualify for CS-03 pools, let alone progressing to CS-04 roles and beyond.)

What that means is that, by time someone reaches the CS-04 level and is working as a senior enterprise architect, five or ten years might have gone by since they last wrote software code on a regular basis.

Life as an EA

What do people then do as an enterprise architect? By and large, they act as a reviewer or gatekeeper of other teams’ IT projects and solutions:

• Do the projects adhere to the department’s standard set of technology choices and frameworks?
• Did the project team sufficiently map out how they fulfill the organization’s business capabilities?
• Does the project create some kind of org-wide redundancy that could be resolved if they used a different set of technology solutions?

In between reviewing projects, enterprise architects might work to map out the existing technology solutions in their department, identify systems that could be consolidated, do market research on IT solutions and trends, model the organization and its systems using bespoke EA diagramming tools, and in some cases write IT strategy documents. In a typical department, an enterprise architecture group’s close proximity to departmental CIOs gives them a lot of influence or veto power over the work of other programs and teams.

Enterprise architecture’s focus on standardization and consistency (or “alignment”), in government tech settings, often leads to consistency with outdated ideas and solutions, because these are already widely-established in the organization. Enterprise architecture then acts as a persistent barrier to modernization efforts. If a small dev team is trying to adopt a modern tech stack, using software and tools widely-used in the private sector, it will be seen as inconsistent with EA-led efforts to standardize which technology solutions are used in the department. Once again, things are made mandatory before they are good, or, in this case, kept mandatory for years after they are no longer the best choice.

Overall, enterprise architecture reinforces a larger world of waterfall software development, heavy upfront planning, and IT project gating, all of which have largely been rejected by the technology world outside of government. These processes have stuck around long after they’re useful, in a self-reinforcing cycle, because people’s specific jobs and roles depend on the processes existing. I’d also guess that enterprise architecture – with its models and poster-sized system diagrams – also contributes to the government’s addiction to large software projects that are correspondingly more likely to fail (along with other incentives, like budget and program approvals).

In all these areas, enterprise architect work involves making the switch from “doing” to “watching” (to use Mark Schwartz’s terms) alongside other reviewing and gatekeeping roles. That lack of “doing”, combined with the insularity of the public service, leads over time to a lack of knowledge of how technology work (particularly software development) is done outside of government institutions. Because EA roles are fairly far up the CS/IT hierarchy, it’s difficult for more up-to-date (but correspondingly more junior) software developers and teams to push back on or appeal decisions made by EA gatekeepers. Enterprise architects are more likely to be informed by trade publications and conferences (from a small number of highly-recognizable vendors) than by the day-to-day realities of “hands on keyboards” software development work.

There are exceptions; some of the best government tech folks I know have found themselves in EA roles partly by accident or partly as an unavoidable stepping stone to IT leadership roles. At best, working in an EA role or on an EA committee is a chance to shape a department’s technology choices for the better. In large part, though, this involves reducing the potential damage of EA gatekeeping processes themselves, by promoting autonomy and empowered decision-making for the software development and product teams who are much closer to actual users and their needs.

What should we do instead?

If you’re an enterprise architect in government, you’re probably reading this with a mix of resentment and dread. (Or anger! I’m so sorry.) None of this is your fault; it’s a structural issue in how the public service has designed the CS/IT career progression framework, in how government IT projects are managed and reviewed, and in how slow we’ve collectively been to adapt to how IT and software development work is done outside of government. Not to mention, how far we’ve tilted the focus of government tech towards internal rule- and process-following and away from user needs.

The future is empowered, multidisciplinary product teams that deliver services using modern tech approaches and tools, learn from their users, and iterate and deploy frequently, the same way that product teams in leading tech companies would. Actually making that happen, in government departments, involves removing external gatekeepers and dependencies wherever possible.

Individually

At an individual level, if you’re currently an enterprise architect, there’s a few directions you could go in. One approach is to refresh your software development skills and plan to move into an individual contributor software dev role, as these begin to emerge in government. If you do that, do it with a lot of humility and openness to learning from much more junior public service developers. Another approach is to move into other specialized senior roles, like IT security or cloud infrastructure, if you have expertise in these areas. Modelling and mapping systems might also be a useful stepping stone to data science and analytics fields, if it’s of interest. (Making a change like this can be scary, and it’s made more difficult by the lack of senior-level individual contributor roles in departments. Moving back into hands-on, higher-impact work is really fulfilling, though.)

Few companies outside public sector institutions still have enterprise architecture roles, but many have a small number of technology strategy roles. There’s a lot of overlap here with EA work, identifying tech solutions and approaches that organizations might benefit from early on. Departments could continue to hire technology strategists (and to be honest, they’d benefit from this expertise in a lot of areas outside traditional IT divisions) even as enterprise architecture roles are slowly deprecated. The work remains relevant – how to help organizations make good technology choices – even if the terminology and specific methods of EA may no longer be useful.

The recent CS-to-IT classification update didn’t make any significant changes to the public service’s tech career progression framework (outside of formalizing education requirements in a counter-productive way). The classification and its collective bargaining union includes software developers along with other IT roles (IT help desk staff, database administrators, and so on). Many of these other roles are paid well compared to market rates, while software developers in government are significantly underpaid. Until there are non-management/individual contributor senior software developer roles available across the public service, and until these are offered compensation closer to market rates, this will continue to be a problem.

Institutionally

Enterprise architecture is baked into government IT processes all over. Departments have EA committees and architecture review boards that gatekeep new or redesigned technology solutions and the public launch of new projects. The government as a whole has a Government of Canada Enterprise Architecture Review Board (GC EARB), chaired by senior leadership from the Office of the CIO and Shared Services Canada. Each of these are mandated by the TBS Policy on Service and Digital.

Do these committees add value? Do they help avoid expensive IT project failures? It’s unclear. Part of the inspiration at least for the GC EARB may have been the United Kingdom’s spend control process, which between 2011 and 2016 saved the UK government an estimated £1.3 billion ($2.1 billion CAD). The spend control function exercised by GDS in the UK was “bloody and ruthless”, as a friend described it once, with years-long, multi-million £ projects from departments getting axed mid-flight because they were considered wasteful or didn’t sufficiently meet users’ needs.

Achieving those kinds of savings involves a willingness to (metaphorically) burn bridges, absorb hits, and disappoint senior colleagues that I haven’t seen in Canadian senior public servants. Certainly if GC EARB had saved millions of dollars by cancelling ill-fated IT projects, we’d have heard about it publicly by now. As is, shaky-looking IT projects were probably asked to come back with more extensive documentation; the punishment is (at best, and at worst) more paperwork.

The goals of these review processes are laudable; the federal government has a history of large IT project failures that certainly merits more scrutiny. But if enterprise architecture review boards aren’t actually stopping bad projects, then at best, they’re just adding delays and performative paperwork requirements to the good projects. At worst, they’re likely enforcing outdated standards and poor technology choices in the name of consistency.

The key theme of government IT project failures is that the projects are big. If you want an IT project to succeed, scope out something useful you can do – useful to actual users – in six months or less, and for less than a couple million dollars. (Waldo Jaquith’s tech procurement advice to the Michigan state government is a great summary.) Ship it, get feedback, and then decide what to do next. If we did this in government on a regular basis, we wouldn’t need giant architecture diagrams plotter-printed and put up on the walls, and we wouldn’t need architecture review committees either.

I’ve always considered the existence of software architects to be an organizational failure. They are way too often people who no longer write code that have outdated ideas of how systems should work.

I’m more in favor of tech lead/senior ICs who actually do the work in trenches

— Dare Obasanjo🐀 (@Carnage4Life) June 10, 2022

It’s dead, Jim

I’m not the first to write this; I’m not even the first to title a blog post with this. (Google brings up 18 million hits.) Enterprise architecture roles – both in the CS/IT career progression framework and in departmental IT processes – aren’t going to go away anytime soon. But they’re a relic of another time, and if you’re currently in one, it’d be good to start planning for the future.

My old company now has offices and staff in 95 countries on 5 continents; the technology choices our team made and software code we wrote (and continued iterating on) made that scale-up possible. I’m not sure how many more places it has in-country servers in nowadays, or if data centre connections in sub-Saharan Africa have since become more reliable.

Years later and after spending $59 million, the financial management transformation project from the team around the corner was quietly paused.

If you found this interesting, be sure to read Marianne Bellotti’s piece, Five Koans of Software Architecture. As always, really grateful for any feedback!