The perils of architecture governance
We start with architecture governance because it's the easiest part to solve.
In private enterprises is it very simple. The man or woman with the money decides, i.e. architecture governance is based on responsibility for P&L in each business unit.
But what about cross BU initiatives and common company solutions? This means that we have to look at the operating model of the company, and adjust the architecture from this viewpoint.
Small companies are functional, but when the company grows, as a rule, they tend to be organized by lines of business, i.e. from a perspective of product groups, geographical boundaries or customer segments. We could also add matrices in the organization to make the decision-making and reporting even more complicated. A notorious exception from this rule of organization is Apple, (who still have a functional organization).
The operating model for a large organization could be centralized, decentralized or federated. Each of these three models will influence how the architecture model is implemented. This is why there isn't a single best practice for how an enterprise architecture should look like.
We talk about enterprise wide architecture and domain architecture, i.e. segment architectures in TOGAF. The less centralized the operating model of the company is, the thinner is the enterprise wide architecture. This in contrast to a more centralized organizations where enterprise wide architecture is more in-depth compared to decentralized organizations.
Compare General Electric as a very large conglomerate with McDonalds or Coca-Cola. The latter companies have a few products, presence all over the world and nearly the same type of customers, regardless of geography.
GE's enterprise wide architecture is probably very thin and limited to a set of principles. For the other companies, their enterprise wide architecture is probably more detailed in order to give the same customer experience and branding across the world. (Disclaimer: I have no actual experience from neither of these three companies, but from other large global companies with different lines of business in several continents.)
The challenge with architecture governance is not responsibility, it's when responsibility shifts during time. Large organizations re-organize at regular intervals in order to improve their operation and adjust to outside threats.
This means in practice that if you have created a domain architecture based on line of business and your company currently is a product focused organization, you are in trouble if the management decides to change responsibility to customer segments or geographies. Your problem gets even deeper when they change responsibility a third time as computer systems never dies, they just gets older.
The final nail in the coffin for your architecture governance efforts are that changes to business is far more rapid today then in the past. Do you remember when a physical keyboard was state of the art in mobile phones? It's only seven years ago and it feels like ages.
We now have a moment 22 in our organization. The decision-makers are rewarded on a their P&L performance, but the long term investments in IT need to be agile to manage future changes in the organization. Something that costs more money and take longer time to implement compared to fixes for their current business.
This leaves the board with difficult problem that could be solved in three different ways:
- Abandon P&L responsibility per BU and go for a functional organization the same way as Microsoft in their latest re-organization
- Limit P&L responsibility per BU and create a more agile enterprise architecture. Easier said than done
- Business as usual, but much higher cost when they need to change the business. Hopefully they will survive one more disruption.
Remember, the average lifespan of a company is already less than the expected lifespan for a woman in western hemisphere, and the forecast for organizations will not be better in the future.