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.
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.
The book’s core premise (summarized on pages 8-9) is that every company should
build a foundation for execution composed of:
- Operating model – business process integration and standardization across business units in a company
(e.g. where do you select technologies for a business unit?)
- Enterprise architecture – organizing logic for business process and IT infrastructure.
Essentially, how do you service shared concerns (e.g. customer database)
- 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.)
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.
- Coordination (low standardiation, high integration) – few shared implementations, but highly shared data
- Unification (high standardization, high integration) – shared implementation and heavy coupling of data across business units
- Diversification (low standardization, low integration) – very little alignment across business units, maybe some shared services
- 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.
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
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.
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.