“Divide et Impera” – break down a problem into two or more sub-problems of the same or related type, until these become simple enough to be solved directly.

Because enterprise is usually very big and complex system, we need to decompose it – divide it into manageable pieces for any analysis or design activity, and for efficiently organizing and managing the multitude of the elements that are identified and used for describing the enterprise from various viewpoints.

It is usual, that different disciplines, which deal with the analysis and design activities of an enterprise from different viewpoints and for different purposes, divide the whole enterprise based on their primary interests and according to the main methodologies in their area, organizing the elements that describe the enterprise according to different criteria.

This could be illustrated for couple of such disciplines (process modeling/management, information modeling/management and applications modeling/management) for example as follows:

Because for both analysis and design these elements are usually needed to be viewed/described in their context(s) (e.g. processes create and use some information and are supported by certain applications; applications master, provide and consume certain information; etc.), this leads to the need of connecting the elements identified/used by different disciplines, to avoid creating several separate and possibly inconsistent views on the same enterprise.

This all leads to the following problems:

• Multiple different decomposition hierarchies will be created, from different viewpoints, for different purposes, and by using different methodologies, and these are usually created/maintained by separate communities of practice – this tends to lead to multiple inconsistent and non-reconciled views on the (same) enterprise.
• It will be difficult to decide upon the primary decomposition hierarchy, which should be used to organize the whole picture (and all its elements), because of the different interest groups / stakeholders, different communities of practice and different methodologies used to create these decomposition hierarchies – this will lead to the situation, where each of these disciplines tend to maintain their own context(s) needed for their primary elements, creating duplicate representations, neither of which provide the holistic view of the enterprise.
• Due to the need for context, multiple different type of relationships will be crossing the various decomposition hierarchies to connect things on right hierarchy levels – such relationships are usually difficult to maintain, as different ends need to be agreed by different communities of practice and there’s no natural master/owner for the relationship.
• Because the relationships that cross the different hierarchies are most often connected to the leaf elements of these hierarchies, all decomposition hierarchies need to be fully developed until the relationships that cross the decomposition hierarchies can be created – which leads to the need of coordinating large efforts between the different communities of practice and difficulties in sequencing these efforts (e.g., due to the circular dependencies).
• In several of the disciplines of analyzing and developing the enterprise, there is an additional problem, making creation and maintenance of these decomposition hierarchies difficult – from certain decomposition level the main element and sometimes also criteria for decomposition change.
  For example:
  • processes on different decomposition levels are rather different things (therefore apart of the name also the level number becomes important to understand what we are dealing with) and the leafs of process hierarchies are usually tasks and other elements, which are not processes at all;
  • information decomposition starts usually with the subject areas, progresses to entities and ends with the attributes;
  • application decomposition also starts with the groups of applications, progresses to the applications and depending on the needs and methods might end with several levels of application components;
  • etc.

To avoid all these problems ...

Only at the final level of decomposition, in the leafs of such decomposition hierarchy other elements, that describe the enterprise (or parts of an enterprise), appear. Therefore such decomposition will collect together and organize according to the same schema all the various elements used in the analysis and design of the enterprise.

Such decomposition could be represented as follows:

And this leads to the following benefits:

• Only single decomposition hierarchy to maintain – easier governance, and on every level of decomposition we will have a holistic view of the particular part of the enterprise, containing all the necessary elements for analysis and design.
  Same single decomposition could also be used to conduct and present strategic analyses on the enterprise (e.g., using “heat-mapping” to identify places where the changes are needed and will provide most strategic value, etc.).
• Only the relationships of single type “serving” are crossing the decomposition hierarchy levels (i.e., are showing how various parts of the enterprise are serving each other), and all the other relationships between the elements are nicely contained within the particular part of the enterprise – which leads to easier maintenance of such relationships.
  Such networks of parts inside the enterprise form a value network (as opposite to the set of linear value streams used by many other methodologies), which gives a more realistic picture of the value creation inside the enterprise.
• The decomposition hierarchy doesn’t need to be fully developed for describing:
  
  • the relationships between the “leaf” elements, as these all are contained in a single part of the enterprise, and
  • the relationships that cross the decomposition hierarchy levels, as it would be possible to start from the derived/compound relationships between the higher level parts and decompose such relationships according to same criterion as the whole enterprise is decomposed.
  Due to that it will be possible to organize the work so that detailed representations of both the parts of the enterprise and the relationships between those parts are developed “on-demand” (i.e., only for these places in the enterprise that need it due to the analysis needs or planned change).
• The task of coordination between the different communities of practice and stakeholders is simpler and analysis and design tasks themselves become smaller due to the division of work following the decomposition of the enterprise – because all different interest groups / stakeholders and different methodologies work together on the holistic picture on every level of hierarchy, and due to smaller tasks/efforts concerning single parts of the enterprise.
• When created, such hierarchical decomposition becomes a “blueprint” for the ideal organization for the given enterprise, which would give hints for and could drive the development of overall organization.

Such decomposition method has been earlier described and employed for example by:

• IBM as Component Business Model, where the self-contained parts of enterprise are name “business components” (see IBM Component Business Models. Making Specialization Real and IBM banking Architecture) and
• BIAN as Service Landscape, where the self-contained parts of the enterprise are named “service domains” (see BIAN Semantic API Practicioners' Guide).

Although in some cases business capabilities are defined nearly the same way (see Archimate 3.2 Capability and TOGAF Business Capability), many business capability models are built in such a way that business capabilities in these models cannot be viewed as self-contained parts of the enterprise (which could be possibly outsourced), therefore not representing holistic parts in the recursive decomposition of whole enterprise.

A good description of the problems involved by negotiating such business capability model with the decomposition of the enterprise done according to the way, described above (i.e., Service Landscape) is provided lately by BIAN (see BIAN BCM Relationship with BIAN Service Landscape).