In the previous sections, we have described how to analyse the overall business model and business benefit of digitalisation, and respectively a specific digital project. Starting from the value proposition, the required business services are derived at the highest level. Subsequently, the analysis becomes more detailed and the business services are broken down into discrete services using a service-oriented analysis.
It is crucial to design manual as well as automated services with one common comprehensive approach.
This avoids both a split between the analogue and the digital world, and between a business and an IT perspective. Ultimately, we want to ensure that the business purpose is decomposed into implementable components, both in the business organisation and in the IT application landscape. The determination of the business service building blocks must be done quite quickly, using a light and agile approach in the first step. This requires an informal ‘whiteboard-enabled’ methodology that allows for seamless collaboration among different stakeholders. From there, matters are made more concrete in subsequent iterations including classical use-case descriptions and process modelling. In the later iterations, we apply more formal methodologies that would be too costly and cumbersome in the early stages.
Similar to the analysis of the business model, the business analysts and functional architects are responsible for the service modelling. Their team, however, must be expanded; while the analysis of the business model tends to focus on the input of business owners and customers, we now need to bring on board additional expertise. The target is close collaboration between business and IT experts, and therefore the IT architects should already be included at this stage, including data and security professionals. However, IT is not yet in the lead. Only once the core building blocks and their functional scope have been identified do the IT architects begin to define the software components.
In the first step, business services are derived from the value proposition. For example, in the last section, we defined the value proposition of the Lead Management business capability (e.g., ‘Cost-effective way to obtain leads’). The following diagram demonstrates how Lead Management is decomposed into its capabilities in order to back up the aspired value.
In this next step, business services are derived from the capabilities. In the example above, we design the services ‘Campaign Administration’ and ‘Lead Administration’ to fulfil the ‘Campaign Management’ capability. The decomposition can be done in multiple layers that build on each other.
Proceeding along these lines, a hierarchical tree appears. Finally, individual process steps are derived that can be executed by humans or algorithms. We proceed with the decomposition up to a point where one can clearly recognise which stakeholder is consuming what services and how benefits are created in the process (see diagram below). At this moment, we can also associate business objects with process steps that are necessary to deliver the required service. We proceed with the decomposition up to a point where one can clearly recognise which stakeholder is consuming what services and how benefits are created in the process. At this moment, we can also associate business objects with process steps that are necessary to deliver the required service.
Once we have determined the functional structure, the purpose of the next phase is to compare this solution with the overall strategic direction, the standardised domain model, and the as-is system landscape. It is immensely important to apply best practice service design principles and verify which aspects of the business services have possibly already been implemented as building blocks in the business organisation and IT landscape, and thus can be reused. It is also important to carefully cross-check whether individual building blocks are only relevant to the specific project at hand or whether they carry relevance beyond this project for a variety of business scenarios.
For example, starting from the object ‘Person’, one could realise that the organisational unit ‘Customer Management’ is already engaged in diverse processes dealing with ‘Person’ and that there are already systems and services available on the IT landscape for customer management which can be utilised.
Based on the functional target structure, once it is aligned within the enterprise, the IT services are modelled. This includes mapping onto existing or new back-end systems, data and security architecture, and message design.
We recommend distinguishing between the layers ‘Front End’, ‘Process’, ‘Composition’, ‘Basic’ and ‘Back End’ due to different characteristics of artefacts within those layers.
