EN 
NL 
This Whitepaper is for those who wish to understand more about the stakeholder approach to high level Business Service Design. In most respects it relates to the BiSL® Next ‘Governance’ level in terms of providing a ‘design of the design’ prior to getting into requirements gathering. It is an extract from the book ‘Collaborative business design; Improving and innovating the design of IT driven business services’ to be published shortly by IT Governance Press (ITGP).
1. Needs of Business articulated in a Design Reference
All IT-intensive services that are being developed in an enterprise must contribute in one way or another, either as a primary activity, as part of the core or as part of a necessary secondary process to the enterprise business goals. In the last few years the distinction between primary and secondary processes has become more diffuse as execution of work and supporting processes becomes more difficult to separate.
It therefore does not come as a surprise that service development or services changes attract the attention of stakeholders within an enterprise. Questions they have include what information must be collected, how is it processed, what is automated, what can be automated, what can never be automated, what is the result we are looking for, how will the new service be paid for and what (if any…) income is required from it……. Enterprise stakeholders want to be involved in the development and implementation or adaptation of highly IT driven business services and ensure that different perspectives, interests and principles are included.
Governance and business requirements, functional and non-functional requirements are equally important to enterprise stakeholders, as is the choice of technology. Technology selections cannot be left to the judgement of the IT provider, in house or external. By understanding IT driven business services and anchoring them in a Service Design Statement or Terms of Design Reference you will be able to accelerate the translation of the needs of the business to the delivery of IT intensive business services.
A Business Service Design then must integrate ALL aspects of a service; thus a business service driven by IT will almost certainly involve applications development; an engineered device, a radar installation or car for example, will involve engineers as well as applications developers; and both will need to understand software development lifecycles and the service lifecycle principles as described in ITIL®. Business Information Management (BIM) needs to ensure that whatever service design method or lifecycle is selected, the needs of the business are properly realized. Do you imagine Ferrari would allow their IT director design their cars? One such method developed in conjunction with BIM is Collaborative Business Service Design.
2. Collaborative Business Service Design
Collaborative Business Service Design has been developed to improve alignment of business and IT before you start designing, prototyping and developing. This practice is aligned to BiSL Next and uses the role titles and principles widely found and used in PRINCE2®.
Collaborative Business Service Design merges the pragmatism and logic of the UK government Gateway method, the method of service blueprinting and that of the stakeholder approach.
Gateway method: The Gateway Process defines review gates or points throughout the lifecycle of acquisition and/or implementation of products and/or services. Gateway originated in the private sector and was adapted (and adopted) first in UK government and then in the Netherlands.
Service blueprinting: Service blueprinting is a customer focused approach for service innovation and service improvement. The service processes are visualized, points of contact and accompanying actions and processes and their relations are made explicit. Stakeholder approach: The stakeholders approach posits the exploration of enterprise needs from the perspective of the stakeholders within the enterprise and where (increasingly) appropriate from the perspective of the external networks, information or supply chain partners.
Perspectives require awareness of both the demand side and also the suppliers of services. The stakeholder approach emphasizes the importance of investing in relationships with those who have an interest in the stability of these relationships. Collaborative Business Service Design in enterprises thus promotes:
• An agile (i.e. one that adapts quickly to changing circumstance), structured working method; beware of people throwing ‘agile’ into a conversation without explanation, it might well be a meaningless attempt to be trendy!
• Simultaneous requirement analysis and synthesis
The focus is on required outcome and output involving all stakeholders.
First it must be made clear who owns the business service? This role is the Senior Responsible Owner (SRO), The SRO should have a position at Board/GM level and must be responsible for the commission of a Gateway review of a major project (common in both UK and Dutch government), a survey or a feasibility study, or a complete service design. In this way we can position the Collaborative Business Service Design as the overall architectural specification; the plumbers, electricians, landscape gardeners and related trades will get involved once we know what the house (the service) is going to look like.
3. Understanding the service offering
Essentially Collaborative Business Service Design dictates that you iterate through four phases. The phases comprise:
1. Preparation
2. Service/ service outcome assessment
3. Analysis and synthesis; this comprises four iterations or cycles.
4. Finally, the output from the first three phases is translated into the Service Design Statement, Architectural description, agreements and allocation, sometimes called the Terms of Design Reference.
Following analysis and synthesis you should be in the position to draw together all the necessary requirements to make up the desired service design or the feasibility study of the service design. The complete summary must be presented to, and signed off by the SRO. Accountability is key.
Collaborative Business Service Design accelerates and strengthens the process of delivery and development of services. The approach is therefore a practical and powerful tool for BIM professionals to:
• help to promote coherent design
• provide insight into stakeholders needs and questions
• reflect on the roadmap of development or release management
• and explore ideas or problems that are in need of intervention.
Coherent Design
The approach supports portfolio, programme and project management by identifying key questions. Collaborative Business Service Design structures the creative process of designing services and supports reflection on all aspects of a service design (a service in the context of the enterprise or group). The goal is to derive all of the necessary requirements of the needed service, to provide transparency throughout development and maintenance and maintain control over service quality and cost.
The dynamics between stakeholders
Most often business units or departments must cooperate to deliver successful services. If their mutual interests conflict however, successful implementation can be a problem. It is important to consider the likely motivations (and associated emotions) and possible behaviors of various parties with regard to a new or modified service offering (or when a service is discontinued). Adopting the persona of the parties involved will make it easier to understand how a feasibility study should be undertaken. It also eases composing approaches to successful implementations.
What stakeholders ask
Most often business units or departments must cooperate to deliver successful services. If their mutual interests conflict however, successful implementation can be a problem. It is important to examine motivation at this time.
Roadmap service offering
Collaborative Business Service Design recommends the creation of a roadmap of the service offering once the design is realized. Consider it a roadmap because you can create a detailed picture of the stop signs, directions, interfaces, speed traps and most efficient route that is easy to explain to key stakeholders. A roadmap for a service offering is the schedule indicating a period of time throughout which the service will evolve to a full and complete package. The advantage provided by a roadmap is in understanding the underlying processes and providing support for discussions and involvement of the different stakeholders in the process of development.
4. Business Service Design Deliverables
The result is a design description that you will take forward into the development of a service. After working through what is described in the ITGP book as ‘the service constellation’ you should have gathered all the information needed. Success depends on whether all the information is available to cover all the information in the design and development stages. From a business point of view, you should have all the business information needs to justify further investment and sign off.
Description and justification of the service offering
Justification (and therefore the value) of the service offering is clear. Now, BIM will focus on;
• Insight about motivations, needs and expectations of customers and users and of course suppliers
• How the delivery of the service will be managed and coordinated and any dependencies on support processes that must be managed
• Answering the requirement questions that stakeholders have in the four areas of Operational insight and requirements; Functional requirements, Specifications and External interfaces.
• Attention to issues of Quality (BIM will be responsible for the quality of information service supply and the associated software quality issues over which they will have oversight).
• Governance: ensuring the requirements of Executive, Line of Business strategy, Business information requirements and Business rules have been addressed.
Demand side
BIM and service design professionals will also provide a comprehensive check on whether suppliers are capable of delivering the needed service offering together with a comprehensive check about whether and to what extent the service offering complies with market standards and commercial off the shelf solutions (COTS) or if it is essentially to be ‘custom made’.
5. Enterprise IT is business IT
Enterprise IT is business IT. Small, medium or large, founded on COTS and apps or long standing services designed and developed in the middle ages, enterprises depend on IT and would go out of business if unavailable for more than a week, or even a few days (or if we think of government services, provoke civil unrest if essential services were unavailable for any length of time)
IT then is too important to leave to IT. IT can be outsourced (with safeguards), enterprise business cannot. Thus it makes sense to take more control over design and delivery of new IT services or changes to major services. After all, who knows the enterprise like the people who work in the LoBs?
You can expand this sort of thinking by using an illustration (Figure 1) of the major planning activities of software developers, software programmers, maintainers and IT operations and infrastructure managers.
Figure 1 Overview of major process elements in designing services
It also sets out the complexity of interactions, who to involve at what time and for what purpose, for example to bring to bear for good effect the enterprise choice of a project management method, or a development method or even ITIL. And it shows clearly that good design relies on someone holding the line on information processing throughout every stage, advising and guiding in some circumstances and taking the lead in others; this will be one of the roles of experienced BiSL next practitioners.
What is a lifecycle?
There are many definitions of lifecycle used in the world of IT and business. It is used for services (service lifecycle), planning (a project lifecycle can be used for planning purposes, or development might be using a rapid application method) and so on. It is therefore worthwhile focusing on the interaction between lifecycles from different perspectives within the enterprise and understand the interactions.
In this section we specifically focus on the software life cycle. A simple definition of the word ‘lifecycle’ is that of the time period between starting and finishing an activity of some sort; however, a software lifecycle is usually defined in a more fundamental (or comprehensive) way. The latest ITIL book (ITIL and the Information Lifecycle) discusses this issue in detail. A brief introduction is included here.
A software lifecycle is a representation of the complete lifetime of a software system from initial proposal to final decommissioning. A projected lifecycle can be used for planning purposes. It is the sequence of stages through which software systems pass. The lifecycle covers the following stages:
• the starting point – when the software specification is first composed
• the software development lifecycle – the period of time that begins with the decision to develop a software product and ends when an acceptable product is delivered for implementation as part of operational IT services (this period includes testing and acceptance of the software)
• maintenance, which is the modification of a software product after delivery, to correct faults, improve performance or other attributes (enhancement) or to adapt the product to a changed environment (adaptive, corrective, perfective, and preventive maintenance techniques will apply as appropriate). Application of effective quality management processes ensuring the quality of the delivered software will ameliorate the maintenance burden.
• decommissioning – the point at which the software is no longer useful to the enterprise and is to be taken out of service.
6. Practical Business and IT alliance in the case of software development
How can you position the IT software lifecycle elements appropriately in any scenario relating to design of services that arises from different domains, from business to internal IT?
Minding the gap between business and IT will require liaison between many people and roles. There must be effective communication between:
• Information service planners and IT infrastructure planners (and you will hear this from DevOps and Agile practitioners everywhere), plans for a new or revised IT infrastructure, which interface with plans for software development, may well be part of a programme of
work and it is essential that the overall impact on the current IT infrastructure is assessed together with the BIM requirement to ensure the integrity of information service processing
• Information service planners and IT planners in the IT Planning Unit and/or Architecture Unit, where they exist, so that appropriate software lifecycle models can be selected for use in the resulting projects that meet the needs of business information services
• IT Planning Unit and software developers – to participate in selection of the appropriate software lifecycle models and to identify key milestones for measurement of progress and fitness for purpose of the information services
• IT Planning Unit and IT infrastructure planners – to agree appropriate milestones and the interfaces between software lifecycle support models and IT infrastructure plans (most likely using ITIL guidance on the IT service Lifecycle) so that all dependencies have been identified and addressed, including external dependencies where they exist
• IT infrastructure managers and software developers – to identify in detail the key interfaces and how best to coordinate software lifecycle support activities (primarily a technical liaison, though BIM professionals should be part of any discussions).
Figure 2 BiSL® Next and the service design lifecycle
Figure 2 provides us with an overview of where the BiSL Next good practices are aligned (or should be aligned) with business (information) software development.
The creation of useful and reliable information services relies on cooperation between users, the BIM/ BiSL next team, developers and IT (application software builders and infrastructure managers, possibly internal and external).
Most design techniques (modern and traditional) distinguish between logical and physical design, even where agile/rapid application development is in use. Logical design is what you want to do and physical design is how you do it. Logical design is in turn based on a Master Data Model/enterprise data model and cannot ‘create’ new entities.
Physical design has practical considerations such as operational efficiency (for example a decision about what data should be used as a key for accessing physical records. MDM is not a substitute for physical design; physical design is centred on obtaining a workable solution that performs at an acceptable set of criteria. Agreed requirements must serve the needs of the users of the information services; keep in mind that users will sometimes be customers, at other times they may be dealing with customers or partners using the developed or purchased services.
It is likely that there will be a number of Service options, and Service models from which to select a preferred option; rapid application development techniques such as Agile might be used to allow users to get a picture of how the agreed logical service specification is translated into a useable information service. The service models and the underlying data models will likely be beyond their expertise, and BIM skills will be needed to ensure that the models will support all information requirements. Depending on the scale of the new service, BIM might need to assist with estimation of all of the resources that will be needed (see Whitepaper ‘Estimation techniques’) and obtain executive approval from the appropriate steering committees (see Whitepaper ’ToR for Structural bodies for managing information services development’). BIM professionals may also need to spend time with programme and project management and possibly directly with the SRO to assist them with the management tasks that will include reporting necessary information to management.
Workload models must be applied early in the design process to ensure that information data models are designed to cater for the necessary processing; data dependencies that are not tested can cause operational performance problems. Once the most practical service option has been selected, tested and the performance is assured, the BIM team will oversee the service build to ensure quality, security and performance continue to be addressed.
The impact on users should be apparent even before the physical build; planning for the knowledge base that will support calls made to the service desk about new or improved services and ensuring training is not only available, but has been actioned must be managed. BIM must liaise on the behalf of users with those in IT operations and infrastructure management, internal or external, so that the services will operate as required (and possibly specified in SLA or contracts).
7. Conclusion
You need to understand IT driven business services from the perspective of all stakeholders, demand and supply alike, and anchor them into a service design statement or Terms of Design Reference created in a shared language; in this way you are be able to accelerate the translation of the needs of the business to the delivery of the business services. The total service life cycle lead time is reduced which leads to faster time to market and strategic agility, reduced cost and to improved customer relations. Collaborative Business Service Design is a practice aligned with BiSL Next allowing BIM professionals to take the lead and support the business executives in understanding the impact of IT on business services. After all, who knows the enterprise better than the business executives?
Bibliography
Rouw L P de, and B C Johnson, Collaborative business design; Improving and innovating the design of IT driven business services, London: IT Governance Press (ITGP), 2017
Johnson B C, c.s., BiSL® Next, a framework for business information management, Van Haren Publishing, 2017
Title: BiSL® Next
ISBN: 9789401800396
Author: Brian Johnson, Gerard Wijers, Lucille van der Hagen
Price: € 42.35
