If you ask an engineer, "Do me need to know all details", the answer is probably yes. If you put forward the same question to an entrepreneur will the answer often be no. If you ask an Enterprise Architect, his answer should be "It depends".

What do I mean with this?

It depends on the problem, the available time to find the out the details and the available resources to do the work. In order to make a business decision, we need to be aware of both opportunities and threats. One such threat could be that we don't know all consequences at the time for the decision, but we have to take a calculated risk based on what we know today.

The level of detail is dependent of the size of the transformation. A common situation is where one cannot see the wood for the trees. To much detail can also give a false sense of exactness. If it's a large transformation, then will the time and effort to document all details not be acceptable for the management. The question is therefore what is the right level of detail.

If you have done it before several times, you learned it the hard way. If not, you have to find somebody who have done it before and that can help you. The third option is to find a reference architecture for the specific sector and problem situation that could guide you.

Let's take some examples.

We need to improve our sales process and our IT-systems and our task is now to make a initial road-map and an estimate of the costs on a high level.

To sell something is rather simple. The sales process is more or less the same for all companies. Therefore would the IT-solution for supporting sales be the same for all companies. Do you agree with this approach?

I don't. There is a very huge difference between selling a bottle of milk and to sell a manufacturing plan that produce the bottle of milk. We need to describe the processes on such a detailed level that we can see the differences that depends on type of products being sold, type of customers, channels and other stuff from the Business Model Canvas. But we don´t need to describe differences in processes that depends of different types of milk or diverse sizes of packaging. But if we are going to sell juice as a complement? The sales process is probably the same, but the production process may differ.

Another recent example is from a manufacturing plant. Production planning would be the same for types of manufacturing, isn't that right?

But what if you have different types of orders as:

Make to engineer
Make to configure
Make to stock

This, together with how you produce your products and the volumes of products, will have a huge impact on the production planning process. Therefore must the level of detail be granular enough so that you can identify these differences in the processes between different types of orders and different types of production.

Example of an extract of a manufacturing process on level 1 to level 3 from CHROME reference model at Capgemini.

Based on my experience, if you need to do a road-map for a transformation program within one area, you have to go down to level 3 process. Not less not more.

If you are going to do an plan for an application rationalization, then this level is also sufficient.

But if you are working in an implementation project within a program, then you need much more detail. Probably down to level 5 processes, data-model, all affected interfaces etc.

The devil is in the details. Heard it before?

Yes, but we need to find them using our experiences and some common sense. No by detailing everything in the first stages in a transformation program. This is why you need architects with experiences and their reference models.

Disruptive architecture