A digital backbone supports the idea of a resource-based view of an enterprise[2] and relates to the approach of Michael Porter’s value chain.[3] In essence, there is a focus on the interactions between the corporate business functions and resources in order to achieve a competitive advantage. Therefore, each building block represents a corporate business function, made available within the company through the digital backbone.

It has to be noted that there is no universal backbone spanning all sectors of industry; in fact, each enterprise must carefully design its own individual backbone based on its specific market needs and derived digitalisation strategy.

Reusability is one of the main attributes of a building block. For this reason, it is a common practice to define the so-called entity building blocks based on the fundamental business objects. The entity building blocks are the basis for nearly all business functions and ensure that these can fulfil their defined output. That is why, as a next step, these functions should be defined in the digital backbone as process building blocks. Process building blocks represent concrete business actions, such as solvency checks or invoicing, which can be located in a process service for banking. In a best-case scenario, the digital backbone comprises all the business functions of a company. To guarantee a high quality of building blocks and their corresponding specifications, the SOA (service-oriented architecture) principles of service design[4] have to be applied. Technical building blocks may additionally be defined in the backbone in order to cover matters concerning adapters, logging and security. When working with building blocks, it is important to consider that they can have interactions or even interdependencies between them. For example, process building blocks almost always require entity building blocks and, in some cases, technical building blocks – e.g., the sales service requires the customer and the contract.

When defining entity building blocks, master data management[5] – including a definition of relevant business objects and their corresponding responsibilities within the enterprise – serves as an excellent basis. By using the existing structures, entity building blocks can be identified efficiently. It is also easier to assign responsibilities to the corresponding teams or business lines. In general, all building blocks have to be allocated to a domain within the domain model of the enterprise. The domain model acts as a stable classification framework for building blocks, which is always independent of the current organisational structures and existing applications. This means that neither organisational changes nor changes in IT systems lead to a transformation of the domain model. Using this stability, responsibilities for building blocks can be defined in a future-proof way.

Process building blocks embody one or more business functions. When defining them, the business capability management approach can be of great help.[5] Here, all business functions (called business capabilities) within the enterprise are identified, specified and structured using a business capability map.

‘A business capability defines the organisation’s capacity to successfully perform a unique business activity.’[7]

It can be said that capabilities: (a) are the building blocks of the business, (b) represent stable business functions, (c) are unique and independent from each other, (d) are abstracted from the organisational model and (e) capture the business’s interests. In the field of business capability management there is also a variety of analytical methods and tools which can be used to obtain insights into several economic and technical topics. These insights can be used to validate KPIs and collect information from which further actions can be deduced – examples include statistics about the business value, the frequency of use or the technical implementation of a capability.

This particularly helps planning and prioritising the implementation of building blocks. Other criteria when prioritising building blocks should be their contributions towards the degree of the digitalisation, a positive customer experience or the possibility of achieving a unique selling proposition (USP).

Within the context of a two-speed architecture,[8] the elements of a digital backbone are usually provided by the ‘slow’ speed, transaction-focused, legacy back end, and used by the ‘fast’ speed, customer-centric, front-end applications. Therefore, the design and implementation of building blocks tend to be slower and more complex. This is a consequence of important requirements such as security, scalability and flexibility. For this reason, the building blocks should be assigned to specific implementation and maintenance teams. 

To guarantee a continuous and target-oriented development of the digital backbone, these teams must also be part of the line organisation. 

This is important from an enterprise architecture viewpoint, because architectural governance structures can now be integrated more efficiently.