Notes on Enterprise Architecture as Strategy

Enterprise Architecture as Strategy by Jeanne W. Ross, Peter Weill, and David C Robertson is an interesting read on how integrating technology across business units shifts the company’sstrategy landscape. Written in 2006, case studies are not particularly current but the ideas remains relevant.

The technology industry is simultaneously grasped by the optimism that things are changing constantly–your skills from last year are already out of date!–and the worry that nothing particularly important has changed since the 1970s when the unix epoch began. I opened Enterprise Architecture as Strategy by Jeanne W. Ross, Peter Weill, and David C Robertson, published in 2006, with both of those ideas firmly in mind.

Despite the age, I think this is one of the better strategy books I’ve read recently. In oarticular, it has some very relevant, structured thoughts on managing coordination across business units within a given company, which is something I’ve been thinking about quite a bit as the CTO for a company with a number of sophsticated business lines.

Core concepts

The book’s core premise (summarized on pages 8-9) is that every company should build a foundation for execution composed of:

1. Operating model – business process integration and standardization across business units in a company (e.g. where do you select technologies for a business unit?)
2. Enterprise architecture – organizing logic for business process and IT infrastructure. Essentially, how do you service shared concerns (e.g. customer database)
3. IT engagement model – the system of governance mechanisms that dictate how the business and IT work together to solve problems

This isn’t groundbreaking, but it is a useful framework. Most companies that I’ve worked within fail to set the rules for decision making, and instead allow ambiguous, semi-political systems to drive outcomes. That’s less true for companies as they grow larger, and the ongoing friction within multi-business unit companies eventually forces clearer rules, but this book suggests we could just specify the answers to these predictable problems instead of discovering them anew at each company.

These ideas are relatively less interesting in the context of a single business line company, where most of these concerns don’t show up nearly as often. (Although, any acquisition does introduce the questions, sometimes very abruptly.)

Operating models

The book proposes four operating models, based on a 2 by 2 grid of two concepts: high and low standardization, and high and low integration. Standardization is running different business units in the same way. Integration is depending on the availability, accuracy and timeliness of other business units’ data.

1. Coordination (low standardiation, high integration) – few shared implementations, but highly shared data
2. Unification (high standardization, high integration) – shared implementation and heavy coupling of data across business units
3. Diversification (low standardization, low integration) – very little alignment across business units, maybe some shared services
4. Replication (high standardization, low integration) – shared implementation but little shared data across business units that serve distinct and unshared customers

I’d never seen this breakdown before reading this book, and I find it a very useful vocabulary to discuss some of the challenges I have seen across business units in a company. Specifically, it’s helpful for diagnosing why two pairs of business units behave so differently from one another. One pair has low integration, and the other has high integration, but we’ve been hoping to reason about them in the same way. The friction was obvious, but how we might modify the playbook was less obvious without this vocabulary.

I particularly appreciated this quote (p43):

A poor choice of operating model–one that is not viable in a given market–will have dire consequences. But not choosing an operating model is just as risky.

Many leadership teams are so failure-averse that they try to preserve optionality by not making decisions, but generally those decisions get made anyway, at lower levels of your organization, while you sit around and pretend that you’re studying the situation at hand.

Four stages of maturity

The book introduces (p71) four stage of enterprsie architecture maturity: business silos, standardized technology, optimized core, and business modularity. I find the stages specifically a bit hard to map into my experience, likely due to the sorts of companies I’ve worked in, but it’s an interesting lens. Further, they introduce the concept of these four stages as a progression, and their belief that it’s impossible to skip phases: you most go phase by phase from left to right.

They also introduce (p105-109) a series of practices to adopt within each phase. For example, IT ownership is decentralized in phase 2 (business silos), but should be own by a single executive in phase 3 (standardized technology).

Potentially my issue is that most startups and scaleups operate in phase 3 doing their early years, and only reach phase 4 late (if ever). That said, I’m not particularly convinced that the 4th phase is an improvement over the 3rd. More generally, I didn’t find this vocabulary particularly helpful.

Leadership agenda

This sort of book inevitably feels obligated to end with recommended steps for leaders to implement their ideas, and this book is no exception. Towards the end (p195), it proposes a set of common steps such as " Analyze your existing foundation for execution." I don’t find those super helpful, as they largely recap the previous sections of the book.

They also have a handful of principles to keep in mind while implementing these changes. The three of those principles that I find most usefula re:

• “Initiate Change From the Top” – the politics and stakeholder management to make these changes is immense. Conversely, many technical leaders–and even many engineers–want to anchor on the concept of bottoms-up leadership, that rejects making these sorts of top-down decisions. That, in my experience, simply doesn’t work beyond a couple hundred people, and we should focus more on good top-down leadership instead for larger teams. Don’t get me wrong – bottoms up leadership is extremely desirable when it works, but I think the industry spends too much time pretending we’re supporting bottoms-up leadership when infact we’re just absconding from our professional duties
• “Don’t Skip Stages” – in the maturity model (e.g. from business silos to business modularity), there’s a natural desire to simply skip to the last stage of maturity. The observation that skipping stages generally doesn’t work is an interesting one, and something I’ll need to ponder a bit
• “Implement the Foundation One Project at a Time” – the desire for transformational change often overpowers our senses, leading us to concurrent migrations that we know are very unlikely to succeed. Throttling the approach to ensure it succeeds is a recurring leadership lesson for me, and certainly resonates

Altogether, this section is worth a quick skim. It was notably less dense than the preceeding ones, but I recognize how they get edited in to make the research “more actionable.”

Case studies & surveys

This thing that impresses me the most about this book is how much data it’s built on (page ix), relying on 50+ case studies and 200+ surveys, and operating in a field of study the three authors focused on for a decade-plus.

Beyond simply the number of case studies, there’s the quality and level of detail in the case studies as well, which is very high. There simply aren’t enough books written this way, because they take so much effort to write, and I find it very inspiring to see the extent of research that went into the book.

Final thoughts

This was a facsinating read. Some of its biggest focuses were slightly dated by being almost 20 years old, but many of the core challenges still resonate, particularly needing an explicit operating model to navigate decisions across business units.