Target Operating Model (TOM) and Enterprise Architecture (EA) comparison

So what is the difference between a Target Operating Model and Enterprise Architecture?

TOM simply tells Businesses the direction in which it needs to go, based on very high level SWOT Analysis, financial modelling etc. whereas EA provides you the vehicle to go in that direction.

TOM typically, is a term used by management consulting firms; looks at the high level levers of an organisation to show how an Organisation can be improved strategically. At the end of their 1-3 months engagement consulting firms lay down a big picture of the Current Operating Model (COM) a Target Operating Model (TOM) and a business case of how to reach the target state. There is no detail how each project, program suggested as part of the TOM interfaces with each other, no details of how you can measure the outcomes of programs; all in all I have seen TOMs can give you high level direction of where to fix problems, details of how to do it is something that the organisation has to think of. If a company engages the same consultancy to execute the TOM then it’s a different story. Without an Enterprise Architecture in place a TOM can’t deliver much.

Enterprise Architecture is the thing where the rubber hits the road. Once you start to implement the Programs, projects suggested in TOM you need a framework to execute them effectively. Enterprise Architecture provides that framework.

While TOM is transitional, EA stays with the organisation for years together. The Enterprise Architects are full time folks working and staying with your organisation and continuously building and improving your organisations Enterprise Blueprint.

While TOM works at Business strategy Level, EA works at Business Management Level.

TOM is liked by the CFO, EA is liked by CIO.

Till date the most famous Operating model framework I have seen is described in the book "Enterprise Architecture as Strategy: Creating a Foundation for Business Execution" where it describes four TOM models.

1. Low Integration, Low Standardization - the Diversification Operating Model 

2. High Integration, Low Standardization - the Coordination Operating Model 

3. Low Integration, High Standardization - the Replication Operating Model

4. High Integration, High Standardization - the Unification Operating Model 

Not much work has been done in open space about Operating Models. Most of the work on TOM is embedded in Management Consultancies power-point slides and it never comes out in the open.

I have noticed EA communities opening up and speaking about EA in public domain but most Management Consultancies don’t speak about TOM in the open.

But both TOM and EA are there to positively impact businesses so there is an urgent need for Businesses to ask Mgmt. Consultancies to develop their TOMs based on an enterprise’s EA.

In fact it’s only in organisations where Enterprise Architecture (EA) does not exist that TOM survives. If a business has decent EA practice then there may not be a need for TOM as the Business Architecture (BA) part of EA covers what TOM can do.

Most Enterprise Architects I have seen come from IT background (including myself) and hence they focus on the Application, Data, Technology part of the Enterprise Architecture, they mostly forget about the Business, Organisational-Unit, Finance architectures and that is why all non-IT communities being completely unaware of Enterprise Architecture support the TOM concept.

(I have read somewhere that most decision makers agree that they don’t have the relevant data at hand to make decisions but they have to make decisions every-time; which leads to another lengthy discussion on the ad-hoc way in which Information is managed as an Asset today and this can be the topic of separate blog later on)

Limitations of TOM
TOM Design comes from Finance, HR world and is mostly targeted to deliver something on a quarterly basis, mostly taken up in an organisation on a Business Case Level. It can at best provide incremental improvements where-as it’s looked upon by Businesses as something that can provide strategic improvements. No way in 2-3 months time you can assess the situation of an enterprise and recommend improvements. Consultants doing a 2-3 months analysis of an enterprises’ Current Operating Model and recommending a Target Operating Model is very much like a doctor checking a patient’s temperature with a thermometer (Pareto, SWOT, PEST, Excel) and recommending (on a PowerPoint) him a heart-transplant.

While Business-Clients might rightly agree the need for their enterprise getting a heart-transplant because the temperature is showing up as so high (the as-is analysis shows so) they may be wrongly doing a heart-transplant where a brain-transplant is required.

But till the time the enterprise recovers from the major operation neither the Consultant nor their clients can prove or dis-prove if it solved the problem; and by then another new quarter comes up and the time to do another TOM re-design.

Limitations of Enterprise Architecture
Enterprise architecture today is in a state where the Systems Integrators or IT consulting companies come to the Business-Clients and provide them with point-solutions very much akin to a doctor knowing the patient for many years and based on their knowledge of patient suggesting him to take a paracetamol to get over a fever.

The real limitation of Enterprise-Architecture as a science is that it’s thought of as IT folk’s gadgetry. In actuality, it should be exercised as a tool that reflects an Enterprises’ situation from a Systems (or holistic) Perspective. Without Finance, HR, Organisation-Units etc. included in an Enterprise Architecture it will always be in-complete and will never get a buy-in from the CFOs and CEOs.

Enterprise Architecture is the, lesser known, body-part of an Enterprise into which a consultant should actually probe-in his diagnostic tools to assess the Enterprise Current Operating Model. Until Businesses develop Enterprise Architecture they have to rely on Management consultants’ major-transplants or System Integrators quack-treatments to get the illusion of getting rid of their ails.

Whether it’s the limitation of the Enterprise-Architecture approach or that of the Operating Models approach, Businesses are going to keep on suffering the till a combined approach on EA and TOM is adopted.

Conclusion
If due diligence is done to Finance, Organisational-Unit, Supply-Chain, Regulatory Architecture as part of company wide EA adoption then it will become very easy to develop real TOMs.

Most EA product vendors can then support TOM dashboards which can provide businesses right-info (based on real hard facts and not based on the board room discussions) at right-time to take decisions to go into the right-direction from an ailing enterprise towards a healthy prospering profitable business.