The central idea is a two-axis grid. One axis measures how much the business units need to share data; the other, how much they need to do things the same way. Four combinations produce four operating models, and each model produces systems decisions that contradict the others.
What I took from it
That this question comes before any software decision. Two companies of the same size in the same sector can need opposite answers: if the units share customers, the data has to be integrated even where processes differ; if all they share is an owner, forcing unification means paying dearly for a complication nobody asked for. Half the implementations that go wrong were decided at this point, before any product was chosen.
The single-page core diagram, the one a board can discuss without a translator: the process that carries the business, the data that is shared, the key technologies and the customers. That is what I want left at the end of an architecture map, because a forty-page document does not get discussed in a committee.
And the maturity ladder, with a warning that still holds: you do not jump from silos to an optimised core. Attempting the jump is where the big budgets burn.
What I left out
The cases, which are twenty years old, drawn from very large firms, and set in a world without cloud services or public interfaces. And the fourth stage, business modularity, presented as the destination and not reached that way: what arrived was something else. The opening question is excellent; the ladder needs reading at a historical distance.