Business

Technology
Standard
1
 Business
Technology
Standard

The Business Technology Standard is subject to copyright protection. However, you are entitled to use all of this publication or parts of this publication for non-commercial
purposes in private or in organisations under the open-source license provided by Business Technology Forum. Commercial use of the model including but not limited to
training, consulting and publishing of the model or material is subject to partnership with or written permission by the Business Technology Forum.

Any copies or material referred herein or used thereto must be furnished with the following copyright reference: “Source: The Business Technology Standard.
Copyright by Business Technology Forum. All rights reserved.”

Please note that the Business Technology Standard includes material and content that may be protected by intellectual property rights of third parties.
Any use of such material may be subject to approvals or licenses of such third parties, including but not limited to material on CMMI, ISO/IEC 20000, ISO 21500,
ISO 38500, COBIT, DevOps, IT4IT, ITIL, PMBOK, PRINCE2, SAFe, SFIA, and TOGAF.

ISBN 978-952-94-6391-6
Table of contents

1.0 Preface 7 2.7 Data Assets and Integration 39

1.1 Introduction to Business Technology 9 Key success factors
What is business technology? Elements of a data-driven company
Business capabilities and transformation Data as an asset
Digital frontline Data analytics
Technology backbone Data integration
Technology domains Data capability model
Customer interfacing technology Data roles
Product technology Data governance
Operational technology 2.8 Service Portfolio 46
Business process technology Measuring the business value
The future of business is technology Service catalogue
1.2 Introduction to Business Technology Standard 13 3.0 Introduction to Strategy and
Operating model Governance Discipline 51
Capability model Strategic intention, guidelines and motivation
Roles and responsibilities model Operating model, organisation and competence
2.0 Introduction to Demand Discipline 21 Managing risk, compliance, quality and security
2.1 Strategic Planning 23 Data regulation and protection
Strategic viewpoints on information 3.1 Objectives, Scorecard and Steering 53
technology management Business technology related objectives
2.2 Enterprise Architecture 25 Steering
Enterprise architecture governance Enterprise level
2.3 Service Planning 28 End-to-end flow level
2.4 Ecosystem Development 29 3.2 Operating Model and Tools 59
Developing the ecosystems Business technology operating model
2.5 Innovations and Concepts 31 Operating model enhances realisation of
Innovation business targets
Innovation leadership and culture Value creation perspective
Concepts Tools
Innovation management process 3.3 Competence, Roles and Organisation 62
Ideation Competence and professional identity
Concept design Roles
Innovation management process dashboard Business excellence identity roles and key
Financial steering characteristics
2.6 Development Portfolio 35 Business and process development identity
Development Management Office (DMO) roles and key characteristics
Value stream portfolio views Product and service development identity
Business value realisation roles and key characteristics
Optimised throughput

3
 Service excellence identity roles and key 4.4 Financial Planning and Control 90
characteristics Financial transparency and planning
Smart governance identity roles and Financial feasibility
key characteristics Financial steering
Organisation 4.5 Resource and Asset Management 92
Key Positions Resource management
3.4 Risks, Quality, Compliance and Ethics 69 Moving from individual resources to functional teams
Risks 5.0 Introduction to Development Discipline 97
Quality Selecting the right development methodology
Compliance Assigning resources for the delivery phase
Ethics What are the core components of the
3.5 Security and Data Protection 72 development discipline?
Security Applying Minimal Viable Governance
Cybersecurity awareness Embedding industry development practices
Classification of information and compliance 5.1 Requirements and Feasibility 102
Security in development and project management Sequential development
Digital and physical access rights Incremental development
Addressing security within supplier agreements Feasibility
Data protection Business feasibility
Characteristics of the EU GDPR Technical feasibility
Data protection roles Deliverability feasibility
Lean approach to data protection 5.2 Prioritisation, Commitment and Backlog 107
Benefits from implementing data protection Development request evaluation
4.0 Introduction to Sourcing and Portfolio-level management of
Optimisation Discipline 77 development requests
Digitalisation requirements for speed and agility Development request prioritisation
4.1 Commercial and Property Rights 79 Sequential development prioritisation
Intellectual property rights (IPR) Incremental development prioritisation
IP sharing policy Changes
Commercial models 5.3 Design, Development and Validation 111
4.2 Sourcing, Purchasing and Contracts 81 Using DevOps methodology
Sourcing strategy Selecting the best development methodology
Sequential RFP sourcing process Design
Incremental sourcing process Validation
Purchase-to-pay process Industry recognised Development Methodologies
Vendor and contract management 5.4 Deployment and Training 116
4.3 Supplier Relationship and Business impact
Performance Management 85 Deployment and training components
Supplier relationship management Project handover and completion
Supplier categorisation Service Release Automation
Performance management Governance
Market watch and innovation 5.5 Business Value Realisation 121
Contract lifecycle management 6.0 Introduction to Services Discipline 125
Global megatrends impact the services

4
 What is a business technology service?
Core elements of the services discipline
Embedding industry development practices
6.1 Service Integration and Quality Assurance 128
Horizontal and vertical service integration
Standard operational procedures and tools
Service integration team/centre
Responsibilities, objectives and governance
6.2 Service Release and Operational Readiness 132
Service release
Operational readiness
6.3 Service Operation and Automation 134
Measurement and analytics in
service operations
Service automation
6.4 Support and Service to Users 137
Four types of user request
Digital service desk
6.5 Continual Improvement and Retirement 140
Retirement of services
Appendix - International Models and Standards
7.0 Appendix - International Models
and Standards 143
ITIL
CMMI
COBIT
PMBOK
PRINCE2
ISO/IEC 20000
ISO 21500
ISO/IEC 38500
TOGAF
SAFe
DevOps
IT4IT
SIAM
Who We Are

5
 Preface

6
 1. Introduction

1.0 Preface
Every business leader today is looking for speed and agility when developing new products, processes, and services.
By leading with data, gaining customer loyalty, and balancing development and operational costs, companies can
achieve a competitive edge and remain strong through disruptive times.

Organisations are going through a significant cultural transformation as they need to become more agile in order to
fully utilise the innovation potential created by digitalisation. The task is not easy as utilising existing systems, processes
and ways of working are still valid and need to co-exist together with new digital solutions.

The Business Technology Standard (or BT Standard) is an open-source management framework to plan, build
and run information technology in today’s technology-driven business world. It has been constantly developed and
renewed during the past 10 years with global companies and public organisations. It is recognised today as one of
the leading best practices and used in hundreds of globally operating companies and public organisations, especially
in Nordic countries.

This fourth edition has been completely rewritten and upgraded, and the scope of technology management has been
extended from information technology to business technology.

4th edition
2019
BUSINESS TECHNOLOGY
3rd edition STANDARD
2015
IT STANDARD
2nd edition FOR BUSINESS
2012
ICT STANDARD BUSINESS
1st edition
BUSINESS

FOR MANAGEMENT TECHNOLOGY

STANDARD
TECHNOLOGY
2009 A Model for
Business driven
STANDARD
IT Management
ICT STANDARD
FOR MANAGEMENT
TRANSFORM BUSINESS CAPABILITIES
A Model for Business driven Innovation and data leadership

IT Management
BUILD MODERNISE
DIGITAL TECHNOLOGY
FRONTLINE BACKBONE
Customer experience Cost, quality and
and loyalty leadership performance leadership

Align IT with business Run IT like a business Develop business capabilities Make business with technology

Figure 1.0.1 Business Technology Standard development stages

Business Technology Standard
[Link]

Business technology covers the use of information technology anywhere in business; in the digital frontline and
technology backbone. It includes all key aspects of modern information technology management ranging from
digital and product development to industrial internet and IT. The Business Technology Standard provides a unified
management model overlaying different technology management areas. It utilises specific management models such
as SAFe® and DevOps for product and service development and ITIL and IT4IT for service management in new and
innovative ways.

7
1. Introduction

The Business Technology Standard has been developed by the Business Technology Forum, a community of
forerunner companies and organisations collaborating based on a platform economy model where every company
can benefit from each other’s development input and efforts.

The Business Technology Standard is written in everyday language and its audience includes all business and
technology leaders and experts who want to understand how to better manage the company’s technology assets and
potential.

We at Business Technology Forum believe that the Business Technology Standard can significantly improve every
company’s and organisation’s opportunities to make the most out of digital innovations. Using it as a company-wide
technology management guidebook, will give a unified understanding and a common language to everyone in the
organisation, thus facilitating the company to create more value for customers and owners with technology.

Juha Huovinen
Chairman of the Board
Business Technology Forum

Katri Kolesnik
President, Business Technology Forum

Business Technology Standard Publication

The Business Technology Standard framework, which is the foundation for the BT Standard, is published on the
website [Link]. In addition to that, there are guidebooks which are providing more information to support
the implementation of the certain subject areas. The guidebooks are made available through adequate competence
gained through certifications. Further information on training and certifications is available at [Link].

Editorial Team
Juha Huovinen (Editor in Chief), Katri Kolesnik (Managing Editor), Elena Van Leemput (Product Manager), Tobias
Eckstein (Sofigate), Nick Russel (Xonetic), Salla Maijala (Sofigate), Timo Savolainen (Sofigate), Pia Pitkänen (Kaski
Agency)

The Business Technology Standard is developed in association with a large ecosystem of private and public
organisations and commented by the university development partners King’s College London and Aalto university.

8
 1. Introduction

1.1 Introduction to Business Technology

Businesses, regardless of sector, are living, breathing, and operating in an environment where information technology
is changing the landscape around them, transitioning from the back room of an organisation into the hands of
customers, employees, and society. There is a continual shift towards a service economy, with services ever more
tailored and personalised for the customer.

As technology has advanced over the last 10 years, several phenomena have emerged that, when combined,
have rapidly and radically transformed the ability of businesses to construct customer services and products. Most
importantly, the speed at which innovation and incremental improvement can occur has also increased.

What is business technology?

Business technology is a strategy for organising and coordinating technology management across the entire
enterprise. It is a set of management practices, tools, organisational structures, and technology governance designed
to ensure that the use of technology is optimised across the enterprise with the overarching aim of satisfying customer
needs and expectations. Most businesses understand that they need to challenge not only their competitors but also
themselves in order to constantly improve their customer’s view and their ability to meet market demand.

When information technology was introduced to businesses over 30 years ago, it was such a specialised topic that
organisations created new departments with the remit and responsibility for managing it. This resulted in the birth of
the IT department, which was seen by many as a pure support function and separate from the business.

Large amounts of effort have been spent since in trying to “contain” information technology, ensure that it is under
the watchful eye of IT teams and that spend is controlled. Of course, cost control is still a major required discipline,
however, digital has unleashed technology and made it widely available, meaning it can no longer be efficiently
controlled by a single department.

Today’s technology function should work alongside all business areas to make their skills available, whilst
embracing those disciplines of customer focus, revenue generation, and product development from other parts of the
organisation. This is not a one-way conversation – marketing teams, for example, need to embrace the technology
management skills available to them to prevent runaway costs or the implementation of solutions that cannot interact
with others across the internal ecosystem.

Many organisations have found themselves in limbo – somewhere between the digital revolution and the status
quo. They lack the capability to integrate incremental improvement with disruptive digital innovation. To frame the
challenge, business technology introduces three core elements as illustrated in the picture below.

9
1. Introduction

TRANSFORM BUSINESS CAPABILITIES

Innovation and data leadership

BUILD MODERNISE
DIGITAL TECHNOLOGY
FRONTLINE BACKBONE
Customer experience Cost, quality and
and loyalty leadership performance leadership

Business Technology Standard

Figure 1.1.1 Business Technology mindset model with three dimensions
[Link]

Business capabilities and transformation

Emerging technologies are accelerating digital transformation, requiring business and process development and
forward-looking governance. Business capabilities are the sum of all processes and assets (systems and data)
within the company and comprise the entire business organisation, including any supporting functions within the
organisation. Business capabilities are the key to developing the business and utilising technology in the best possible
way. Transformation comprises the parts and processes of an organisation that are engaged in improving business
capabilities.

Digital frontline
Digitalisation provides new business opportunities and requires consistent design thinking on how to face customers,
partners, and employees in a networked multi-channel world.

The digital frontline can be defined as any digital means that connects the company to the user and is visible to the
user, whether the user is a customer or a partner, or whether the customer is internal or external.

Customer experience is at the heart of all digital frontline activities. Digital frontline is a crucial area as it is the key
area where the emerging business focus and growth possibilities reside and where digital transformation happens
through speed and agility. Digital apps and web, as well as digital enterprises, enable the creation of new business
possibilities around customer experience, digital business, and internet of things (IoT) services.

10
 1. Introduction

Technology backbone
Traditional information technology management function (or IT) should be the technology backbone that is
responsible for the development, and management of digital and administrative solutions in a professional way.
The technology backbone consists of all information technology systems and processes that support the running of
the businesses operations, through the management of end-user services, plus enterprise and business applications.
It is where the essential business asset of a company resides, and the purpose is to provide operational efficiency to
the company through reliability, security, and scalability.

Technology domains
Technology exists within many areas of the enterprise today. Often this technology is outside of the influence of the
traditional CIO and technology function. Every business is different, and the type, location, and amount of technology
will rightly vary within each area.

We define four distinct categories of technology: customer interfacing technology, product technology, operational
technology, and business process technology.

Each of the four technology areas contain a wide variety of technologies, some overlapping and some discrete.
These are underpinned by infrastructure, data, and security.

PRODUCT
TECHNOLOGY

CUSTOMER DATA, BUSINESS

INTERFACING SECURITY AND PROCESS
INFRASTRUCTURE
TECHNOLOGY TECHNOLOGY

OPERATIONAL
TECHNOLOGY

Figure 1.1.2 Business Technology domains

Business Technology Standard
[Link]
11
1. Introduction

Customer interfacing technology

The key characteristic of this technology type is interaction with the customer and the technology centres around the
customer experience. Customer interfacing technology is all about the digitalisation of customer-facing processes and
services. Thus, it is in this area where digital initiatives have an obvious and direct impact. Improving or implementing
these technologies drives a need to review end-to-end customer journeys. When these solutions are developed, the
business should ensure that its strategy is not constrained to digital channels only. This constraint can be acceptable
as a short-term strategy. However, as previously discussed, digitalisation is a much broader topic and needs to be
viewed as a broader strategy.

Product technology
This area consists of information technology embedded within the products the company sells: technology that can
be operated, monitored, and/or interfaced remotely and can interact with its environment 24/7. Thus, only the
technology component of the product that fulfills these criteria can be seen as product technology, not necessarily
the whole product itself. For example, a lawnmower itself does not fulfil these criteria, but in a robot lawnmower, the
embedded technology enabling its remote control and operation fits the product technology definition.

Whilst customer interfacing technology provides the gateway for interaction with your customers, it is often the
technology within your product, whether it be a banking product, electronic goods, or professional services to name
a few, that provides the real value to customers. Technology innovations within this area are fast-moving with new rich
sources of data and new techniques such as rapid prototyping, agile development, and new business models such as
the “as-a-Service” model often used.

Operational technology
Operational technology contains all information systems used for managing, operating, and monitoring automation
systems and other “shop floor” systems. Information technology is expanding into this area even more than before.
Many previously low-tech or even manual operations today start with an information technology-enabled check,
such as the servicing of a car. What used to be a purely manual operation is now assisted by operational technology
such as a laser-assisted wheel alignment machine as an example.

Business process technology

Business Process Technology consists of information technology and solutions that are used for managing business
processes and executing business transactions, i.e. systems that support day-to-day business operations. Classic
examples of business process technology are the enterprise resource planning (ERP) and customer relationship
management (CRM) systems used in organisations.

The future of business is technology

In today’s business world, information technology penetrates organisations from an increasing number of angles. This
trend will continue to accelerate, a traditional technology department can no longer act as the only gatekeeper to an
organisations’ technology.

12
 1. Introduction

In many organisations, the cooperation between the business and technology functions is not optimal and could
enable greater business outcomes. To overcome this, business leaders must embed a culture of cooperation within
the organisation so that technology management skills are fully applied as needed across all business units.

This shifting landscape demands that your business is organised in a way that allows you to maximise business
potential, reacting rapidly to opportunities, and driving continuous improvement and change.

Transforming from traditional, siloed business and technology functions into business technology organisation also
presents a fantastic opportunity to leverage technology management practices directly in the business teams where
it can have the largest impact. Business technology will ensure that businesses are able to derive real value from
technology, and ultimately, to better serve their customers.

1.2 Introduction to Business Technology Standard

The Business Technology Standard is a concise, consistent and straight-forward framework for managing technology
to bring value to business. Business Technology Standard provides a thorough understanding of the overall
technology management landscape and helps to build the needed capability for managing digital transformations.
It also offers expert-level practices for end-to-end development of technology products, solutions and services.

Developing new technology-enabled products, solutions and services quickly for the market has become one of
the key success factors for every company in all industries. Many organisations are, however, facing challenges
combining traditional information technology operations with new digital development. Traditional information
technology management has difficulty keeping up with the pace that new digital development requires. In addition,
the latter struggles to reach the required enterprise-level optimisation and service management maturity for new
digital services.

The Business Technology Standard provides clear guidance on how to fit these two worlds together. It gives a
comprehensive picture of how to manage the overall business technology organisation with pragmatic governance
without compromising speed and agility. Using the Business Technology Standard on top of expert-level best practices
such as SAFe and DevOps for agile development and ITIL for service management, enables holistic management of
different technology management functions.

13
1. Introduction

MINDSET MODEL OPERATING MODEL CAPABILITY MODEL ROLES AND RESPONSIBILITIES MODEL

Business Technology Standard

[Link]

Figure 1.2.1 Business Technology Standard perspectives

The Business Technology Standard consists of three complementary and consistent models and perspectives
for unified information and digitalisation management:
• Operating model to define value creating flows and disciplines
• Capability model to define disciplines and associated capabilities
• Roles and responsibilities model to define identities, roles and responsibilities.

The Business Technology Standard introduces several unique elements addressing the current challenges
many organisations are facing with the digital development such as:
• Value streams to cope with business diversity and differences in speed, agility and culture
• Minimum viable governance to balance flexibility and governance in decision-making
• Multi-speed development flows to respect development method differences
• Unified roles to clarify the roles and responsibilities in a unified way.

The Business Technology Standard serves the needs of many kinds of organisations. Organisations implementing and
running pure agile methodology benefit from the Business Technology Standard as it provides simplicity and clarity
for the business. As all services and solutions are not optimal for sprint-based development, usage of the Business
Technology Standard provides a framework to utilize different approaches without compromising the agile culture. In
addition, the Business Technology Standard proposes a consistent and systematic approach in service management
for agile-minded companies.

Organisations that are using gate-based development and process-driven service management can utilise the
Business Technology Standard to broaden the methodologies they use towards agile and DevOps types of
development practices. Overall, the Business Technology Standard aims to challenge the status quo in order to inspire
organisations to continuously search for more pragmatic and innovative development and management practices.

The Business Technology Standard is developed together with several global companies and public organisations.
It was first introduced a decade ago and has been proven to work well for real business use especially because of
its clarity, consistency and simplicity. This fourth edition follows the same foundation, but has been fully rewritten and
renewed to respond to information technology and digitalisation management challenges in the 2020s.

14
 1. Introduction

Unlike many other methodologies, the Business Technology Standard is available as an open-source provided by
a non-profit community, called the Business Technology Forum, for the benefit of the entire information technology
society. The model is constantly renewed and developed with dozens of companies and organisations ensuring
that it is up-to-date and in alignment with the latest real-life challenges. The Business Technology Forum runs several
development sprints per year and publishes two releases annually.

The Business Technology Standard is compliant with the most popular expert-level global best practices such as SAFe,
DevOps, IT4IT and ITIL. Irrespective of the use of other standards, the Business Technology Standard provides a top-
level perspective, framework and clarity for managing information technology and digital transformation.

Operating model
The Business Technology Standard operating model defines how business value can be created with technology
management. The operating model has five value adding disciplines: demand, development and services,
complemented with the two overarching disciplines: strategy and governance, and sourcing and optimisation
(see the picture below). Specifically, it consists of planning, building and running the value streams with common
strategy, governance, sourcing and optimisation.

INCREASE DIGITALISATION

STRATEGY AND GOVERNANCE

DEMAND DEVELOPMENT SERVICES

PLAN BUILD RUN
VALUE STREAMS

ENSURE BUSINESS VALUE

VALUE DRIVERS
REDUCE RISKS

EXPERIENCE
Design Solution Service and Support
REQUEST

RELEASE
Portfolios and
Roadmaps

Develop Solution
Service Operation

Innovations and
Concepts
Operational Readiness Service Integration

SOURCING AND OPTIMISATION

IMPROVE EFFICIENCY

Business Technology Standard

[Link]

Figure 1.2.2 Business Technology Standard operating model

Value streams have end-to-end objectives to create business value via the operating model. Each value stream has
a business owner, mission statement, financial plan and portfolio visibility to Demand, Development and Service
disciplines as below:
• Demand captured in development initiatives

15
1. Introduction

• Development implementing products, solutions and services based on development requests

• Services keeping business running by managing service releases and operations.

Value streams tend to sub-optimise the plan-build-run flow to achieve their business objectives which is acceptable as
long as they follow the disciplines set by the operating model. The disciplines define unified control points for the sake
of transparency and common steering to ensure that enterprise-level business objectives are met. The more the value
streams are relying on shared human and financial resources, the more decisions are taken on enterprise-level and
vice versa. If the value streams are willing and able to invest money and resources and follow the given guidelines
and transparency requirements, they can become fairly autonomous in their decision-making and value-creation.
Minimum Viable Governance (MVG) within the business technology operating model is implemented by defining a
minimum number of control points, evaluation criteria and by expecting value streams to follow the commonly defined
disciplines. At each control point, people running a value flow must evaluate whether they can make the decisions by
themselves or if it should be escalated to the enterprise level.

The Business Technology Standard sets three mandatory development control points:
• Development initiative to capture the demand
• Development request to commit to the development
• Service release to make the product, solution or service available.

For example, consider a case where a value stream focuses on developing the digital frontline and is given resources
(money and people) to do it efficiently with the DevOps methodology. This value stream can, in practice, use the
morning to plan a user story, implement it in the afternoon and release the service in the evening without asking any
permission from an enterprise-level governance body. However, this can only happen if the answer is YES in all three
evaluation points.

The value stream documents the user story (or the development initiative), adds the development request into a
backlog and keeps a log of the service releases. When stored in a business technology management system, the
control points and decisions become transparent and, in this way, the self-evaluation can be controlled and the
possible misuse traced, if necessary.

The Business Technology Standard defines sequential and incremental development flows and four sources
of demand:
i. Capability planning
ii. Ideas and concepts
iii. Increments and improvements
iv. Service changes.

A value stream can decide to focus on certain sources of demand or development flows only. For example,
a dedicated digital innovation stream can take input from the ideas-and-concepts source, enable fast prototyping
and develop the solution within the incremental development flow. On the other hand, an enterprise architecture-
driven stream can take input from the capability planning and follow a sequential development flow. In reality,
however, the value streams use several sources of demand and development flows.

16
 1. Introduction

Capability model
The Business Technology Standard capability model defines five disciplines and 28 related capabilities in the form
of a standardised framework. The framework consists of four horizontal disciplines (strategy and governance,
sourcing and optimisation, development and services) and a vertical demand discipline intersecting with the other
four disciplines. The demand discipline defines strategy-to-plans capabilities, while the other four disciplines define
capabilities for plans-to-capability and plans-to-benefits progress flows. The outcome-to-insights is a progress flow
closing the loop and provides input back to the demand.

The purpose of demand capabilities is to define the strategic intention, capture the business demand, turn them into
plans and make development initiatives. Strategy and governance as well as sourcing and optimisation take the plans
as an input and implement the required capability and capacity to implement them. They also provide guidance and
steering to development and services disciplines which deliver the actual business benefits.

The capability model and its 28 standardised capability elements or blocks form a good foundation for self-
assessment and identify the strengths and weaknesses of an organisation in a holistic way. The chapters in the
Business Technology Standard are based on the capability model.

Figure 1.2.3 Business Technology Standard capability model

Roles and responsibilities model

The Business Technology Standard roles and responsibilities define over 70 standardised roles with the related
accountability and contribution on capabilities. The roles are split in five career identities each defining passion,
mission and key measurements. In agile terms, the identities can be described as tribes consisting of people with a
similar type of passion and competence and sharing best practices and experiences.
17
1. Introduction

The roles in Business Technology Standard fall into three categories: owners who ensure the business value,
implementers who deliver the outcome for business value, and orchestrators who create the capability to
deliver the value.

The business technology organisation is led by Business Technology Officers, orchestrators each having their unique
BTxO or xxO acronyms, such as Business Technology Governance Officer (BTGO) or Business Information
Officer (BIO).

The owner’s role owns a business-related matter such as business, process, capability, product, function, or service.
The role has an end-to-end mandate and is responsible for the business value. It defines the business need and is
responsible for ensuring its development from the initial state into business benefits realisation. The roles with an
“owner” definition are for example service owner, business owner or product owner.

Leads, managers and experts as implementers have more specific responsibility areas and are the key people to
deliver the business value and execute the operating model and disciplines in practice.

SMART
CIO
GOVERNANCE

SOURCING BTGO CISO

LEAD

BTMO BTPO GOV LEAD

BIO / PROJECT
SERVICE BTSO BTOO
MANAGER
OWNER
BUSINESS
BUSINESS ENTERPRISE AND PROCESS SERVICE OPS LEAD
CAPABILITY ARCHITECT DEVELOPMENT MANAGER / EXPERT
OWNER
BUSINESS BUSINESS SOLUTION SERVICE
CDO
EXCELLENCE OWNER LEAD / EXCELLENCE
EXPERT
PRODUCT PRODUCT SERVICE
INNOVATION TECH /
OWNER / AND SERVICE INTEGRATION
LEAD SERVICE
BUSINESS DEVELOPMENT LEAD / AGENT
ANALYST EXPERT
BTDO / SCRUM SOLUTION
MASTER / KEY USER
DATA LEAD ARCHITECT
/ EXPERT DEV LEAD

Business Technology Standard

[Link]

Figure 1.2.4 Business Technology Standard roles and responsibilities model

Roles differ from organisational positions. Many roles have a one-to-one relationship in an organisation, and one
person may have multiple roles. The Business Technology Standard role model can thus be applied to different-
size organisations. The Standard, however, recommends aiming at a culture of horizontal or collaborative working,
regardless of actual organisation structures or formal reporting lines in the organisation chart.

18
 1. Introduction

The Business Technology Standard breaks the traditional organisational silos in two ways:
i. By defining co-operational teams and steering bodies instead of organisational
counterparties and governance structures
ii. By using the same role names for business and process development
as well as for product and service development.

The Business Technology Standard proposes working co-operatively across organisational boundaries using joint
identities, teams and steering bodies as a replacement for relationship management-specific roles (such as Business
Relationship Manager). Poorly managed demand is usually not a consequence of a gap between business and
technology organisations, but rather a sign of missing roles and practices in business excellence identity and demand
discipline. With this approach, it is easier to identify and implement the improvement actions as it is no longer an
abstract gap between two organisations not belonging to any individual.

The Business Technology Standard breaks the silos between enterprise-level information technology management
and product and service development by unifying the role names. The Business Technology Standard uses DEV, OPS
and GOV prefixes for role names. For example, a DEV lead is a role in gate-based development as well as in sprint-
based development. While the development methodology used is different, the competence and skills required are
close to each other which encourages people to work across the value streams.

The Business Technology Standard can be implemented with several alternative organisational structures. Value
streams can for example, be line organisations or virtual entities. In both cases, the flows, capabilities, and roles are
equal and independent from the organisation. Large global organisations may have some additional layers and
dimensions in their operations, but the big picture remains essentially the same.

19
 Demand
Discipline

20
 2. Demand

2.0 Introduction to Demand Discipline

The demand discipline intersects between four other disciplines (strategy and governance, sourcing and optimisation,
development and services) and its main objective is to turn business intention into concrete business technology
actions. The execution is mainly accomplished by managing two flows: strategy-to-plans and demand-to-request.

Strategy-to-plans flow complements the business strategy by adding essential aspects of business technology
such as:
• Technology platform and partner selections to enable business transformation
• Enterprise architecture to provide a systematic and consistent view on business capabilities and underlying
technology solutions
• Roadmap planning and development initiatives for portfolio steering
• Service planning to bridge the enterprise architecture planning with concrete plans for service development
• Ecosystem development to focus on building strategic technology and business relations as well as cooperation
opportunities
• Service portfolio management to ensure that services are reliable and fit for their business purpose.

Demand-to-request flow captures the business needs and turns them into a prototype or a concept if needed.
It analyses business feasibility and prepares a development request to be prioritised and approved for development.
The actual flow is dependent on the type of the demand:
• Capability planning – Major business capability development planning
• Ideas and concepts – Idea generation and challenging the status quo
• Increments and improvements – Existing business solutions or capability uplift/enhancement
• Service changes – Continual service improvement.

CAPABILITY PLANNING
Plan major business
DEMAND | PLAN capability development.
IDEAS & CONCEPTS CONCEPT PORTFOLIO
Generate new ideas and IDEATION DESIGN & ROADMAP
challenge the status quo.

DEVELOPMENT | BUILD
INCREMENTS &
COMMITMENT IMPLEMEN- BENEFITS
IMPROVEMENTS & BACKLOG TATION REALISATION
Uplift to existing business
solutions or capability.

SERVICES | RUN
SERVICE SERVICE SERVICE
SERVICE CHANGES
RELEASE DELIVERY RETIREMENT
Continual service
improvement.

Business Technology Standard

Figure 2.0.1 Four sources of demand [Link]

21
2. Demand

The demand that is derived from one of the four sources is transformed into development requests and is evolved via
different development paths as illustrated in the picture below.

STRATEGY-to-PLANS DEMAND PORTFOLIO STEERING

BUSINESS IMPERATIVES, GUIDELINES, POLICIES, ROADMAPS, INSIGHTS AND DATA ANALYTICS

EVALUATION

Portfolio
CAPABILITY PLANNING Approval

DEV Initiative

DEV Request
Portfolio
Steering GATE-BASED
SEQUENTIAL Group
FLOW Enterprise
Architecture

IDEAS & CONCEPTS

DEV Flow
EVALUATION Approval

DEV Request
SPRINT-BASED

INCREMENTS / IMPROVEMENTS
EVALUATION
DEV Flow
INCREMENTAL Approval

CHANGE Req
FLOW

SERVICE CHANGES ITIL-BASED

Single Source of Truth and Platform for Actions – REQ Management System DEV Management System

Business Technology Standard

[Link]

Figure 2.0.2 Demand-to-commitment governance

Capability planning is an enterprise architecture planning practice. It is best suited for planning major business
capability development and transformation programmes that require portfolio steering decisions. Capability planning
is by its nature a time-consuming activity.

Ideas and concepts form a fast-moving flow from idea to concept which ideally takes just a few weeks. The concrete
outcome usually consists of prototypes and other ideas. Concepts can be moved into the development directly or after
some capability planning or enhancements for existing solutions.

Increments and improvements are composed of enhancements for existing products, solutions or services. This type
of demand is easier to define than the two mentioned above. Increments and improvements can be moved on to the
development via portfolio steering or directly.

The service change flow is the most straightforward flow of the four sources of demand. There are three change
variations: standard, normal and emergency changes. Service change is a pragmatic way to make smaller additions,
modifications or deletions to existing services.

Data analytics and integrations are also included into the demand discipline as they directly respond to requirements
for better use of information. In most organisations, data analytics and integrations are used as a service for the
business and therefore they are composed of a mixture of demand and service.

22
 2. Demand

G-1 Authorise initiation

BTPO GO Ready for planning

CAPABILITY
PLANNING BT Portfolio Officer
G1 Authorise execution

PROCESSED DEMAND DEMAND Portfolio Steering DEVELOPMENT

PORTFOLIO Approve development request PORTFOLIO

IDEAS &

DEV Initiative

DEV Request
CONCEPTS
APPROVED
G-1 GO G1 PROJECT
PLAN AND
Requires
Requires BUSINESS CASE
portfolio
processing decision
NO
YES, approved APPROVED

DEV Request
INCREMENTS / DEVELOPMENT
IMPROVEMENTS Initial evaluation and routing: YES, make request and go to evaluation REQUEST
Is it likely to pass evaluation?
DIRECT DEMAND

YES, make request

CHANGE Req
and go to evaluation YES, approved APPROVED
SERVICE
CHANGES CHANGE
REQUEST
NO, has to go back to initial evaluation

Business Technology Standard

Figure 2.0.3 Demand management [Link]

2.1 Strategic Planning

Strategic planning is based on a long-term vision and short-term objectives defined in the business technology
strategy. The strategy outlines the key requirements for a period varying typically between two to five years and
the steps needed to reach the target state. The strategy is approved by the business technology steering group.
The strategic imperatives are further broken into action plans within a shorter period (e.g. 12 months). The execution
of the plans will then be carried out in various levels of the organisation and in the governance bodies.

Strategy and action plans typically provide guidelines on the following topics:
• Financial and resource allocations
• Platform and vendor preferences
• People and competence strategies
• Transformation agendas and roadmaps
• Strategic partnerships and objectives.

An effective implementation of the strategy typically requires:

• Operating model to have clarity in terms of roles, responsibilities and governance bodies
• Service plans to outline the short-term (6 to 12 months) steps to implement the strategy
• Annual objectives and scorecards to ensure that the key leaders are aligned and committed
• Portfolio steering to manage the implementation of the strategic decisions.

23
2. Demand

Strategic viewpoints on information technology management

Today, the success of any business depends on the effective exploitation of information technology. Therefore,
harnessing the potential of information technology to create value for the business should be in the core of every
company’s business strategy.

Value streams define business, technology or other domain focus for value creation. Business technology can
have an ideal amount of five to ten value streams.

Each value stream should have:

• Mission statement to define the business purpose
• Value driver(s) to make mission statement measurable
• Value stream owner either in business or in business technology
• Portfolio steering based on value stream’s development vision and roadmap
• Roadmap to implement business capability development
• Financial mandate to make the development flow decisions within the value stream
• Domain architecture to plan business capabilities efficiently

The picture below illustrates some alternative ways to organise value streams in retail business. While each of the
perspectives are viable value streams candidates, the combined value streams perspective enhances co-creation
and co-development with multiple viewpoints and topics.

Customer perspective
Business A Marketing
Store experience
Business B Store operations
Digital experience
Business C Merchandising

Operations perspective
Group functions Logistics and supply chain
Inbound excellence
1. Business structure perspective 3. Value chain perspective
Outbound excellence

Win loyalty with customer experience ERP platform Business enabler perspective

Do business with happy employees CRM platform Employee experience

Improve quality of life with sustainable business HRM platform Common capabilities

Stay competitive with continual transformation mindset eCommerce platform 5. Combined perspective for co-creative
business development that uses multiple
2. Strategy perspective 4. Solution platform perspective perspectives and embeds many key topics

Figure 2.1.1 Value streams examples in retail business

Business Technology Standard
[Link]

24
 2. Demand

Another viewpoint for the strategy alignment is based on the role of the information technology for the company as
shown in the illustration below:

What is the meaning of How to do How to do How to How to do

information technology? Strategic Solution do GO Steering?
Planning? Design? Decisions?

Business PRODUCT Business Service Self-governed Self-governed

planning and design and P/L based by business
product epics user stories decisions by and a product
business owner

Business ASSET Business Solution Portfolio Self-governed

capability design or governed and by a program
planning and business business case or project
EA roadmaps technology based; or steering
design self-governed if group
budgeted

Business ENABLER Strategy Solution Portfolio Self-governed

planning design and governed and by a service
and service technical business case owner or by
roadmaps design based; or a project
self-governed if steering
budgeted group

When information technology is seen as a business product, the strategic planning is performed as for any other
business product: studying and defining the requirements for the product, determining the prioritised features, pricing
and distribution channels. In agile development methodology, the strategic intention is broken into user stories with
business requirements, customer requests, and product features.

When information technology is seen as a business asset, the strategic planning focus is based on identifying the
investments, capacity and expertise needed to meet business needs. This is usually supported by the enterprise
architecture (EA) roadmaps that contain a plan on how to move from the current state to the target state and meet the
company’s strategic intent.

When information technology is considered as a business enabler, there can be a more traditional strategy defining
how information technology supports the business strategy and objectives. The strategic plan is completed by service
roadmaps defining concrete action plans on how to carry out the development of the services within the defined
strategy period.

2.2 Enterprise Architecture

Enterprise architecture defines the business capabilities that are required to achieve an organisation’s long-term
strategic goals. It is about ensuring good fit for business imperatives by defining the process, data solution layers and
the ”must wins” in a continuously evolving market. Changes such as mergers and acquisitions, major organisational
changes, changes in business ecosystem and increasing regulation all set additional demands on the flexibility of
enterprise architecture.

25
2. Demand

The purpose of enterprise architecture is to:

• Define business capabilities including processes, data, information technology solutions and
overarching ecosystems
• Plan transformation from current state to target state by defining domain specific roadmaps
• Execute transformation by taking roadmap-based development initiatives into portfolio steering
• Support programmes and projects in implementing the development initiatives
• Introduce architecture principles defining favoured solution platforms and other guiding principles
for development request evaluation
• Ensure data and process consistency with mandatory governance practices.

Digitalisation challenges traditional enterprise architecture planning by having fast development sprints and
incremental progress-based planning. It also introduces many new solutions and vendors, resulting in a more
fragmented enterprise architecture. Digitalisation employs ecosystems as a playground and uses processes and data
that flow over enterprise boundaries.

A traditional monolithic architecture does not support the ecosystem approach and therefore is not optimal for
planning digitalisation. The Business Technology Standard proposes an extended capability planning approach,
placing ecosystem planning in a central role. The modularity of this approach allows a more agile development of
architecture for different business areas.

STRATEGIC PLANNING

ECOSYSTEM PROCESS PEOPLE TECHNOLOGY DATA COST

BUSINESS CHANGES
• Acquisitions and carveouts Strategy
• New business structure Governed
• Business programs Impact architecture Impact roadmaps Impact initiatives
CORE ENTERPRISE ARCHITECTURE

BUSINESS ECOSYSTEM

Market BUSINESS PROCESSES

Development Initiative
Trends
BUSINESS CAPABILITIES

Portfolio
Business Portfolio Governed
DATA AND DATAFLOWS Steering
Technology Group
Vision and Enterprise
Strategy PLATFORMS AND TECHNOLOGIES Architecture

Business
Strategy
SOLUTION SOLUTION SOLUTION
DOMAIN DOMAIN DOMAIN

ENTERPRISE ARCHITECTURE DOMAIN ROADMAPS

Business Technology Standard

Figure 2.2.1 The enterprise architecture centric capability planning [Link]

The figure above presents the modularity and dynamics of the enterprise architecture. The model is compliant with
traditional enterprise architecture by The Open Group Architecture Framework (TOGAF) encompassing four aspects
of architecture: business, information, application and technology architectures. The Business Technology Standard
defines a core architecture complemented with more specific business domain architectures with the business
ecosystem layer on top of everything.

A set of tightly interconnected business solutions form a separate solution domain entity. Each entity has a set of
common elements and guidelines which are called the core architecture. Companies usually have from four to six
solution domain entities that enable the flexibility required to design the architecture within each domain separately.
26
 2. Demand

The focus in this approach is in planning the enterprise architecture at a level high enough to cover the interfaces
between an organisation and the players in ecosystems and, at the same time, plan business capabilities supported
by data and platforms.

Business ecosystems architecture defines how the company integrates to various ecosystems, such as customer and
partner ecosystems. The company itself is formed by a corporate ecosystem with dependencies in between the
business units. It also incorporates a business support ecosystem that consists of all vendors and partners related
to business support (i.e. HR, finance, IT, legal). The vendor ecosystem could encompass business subcontractors,
component suppliers, service suppliers, etc. The partner ecosystem also defines the dependencies between business
partners who, in turn, have a peer role towards the customers.

Enterprise architecture governance

Enterprise architecture requires a clear governance and an active role in projects to facilitate architecture related
decisions. The goal is to help the company to reach its vision and the desired architecture target state. The Chief
Enterprise Architect is responsible for the enterprise architecture governance with the support of Business Technology
Management Officer (BTMO) for roadmap planning and with Business Technology Portfolio Officer (BTPO) for
programme and project steering related tasks.

ENTERPRISE ARCHITECTURE EA SUPPORT

GOVERNANCE CYCLE TO PROJECTS

EA Target State EA Updates

2 and Roadmap 3.2 Architecture

Focus Guidance Focus

Strategy on Strategy Development Project Goals / on Projects EA Updates
1 Process and Enterprise 3 Projects EA Updates 3.1 Business Case and EA Updates 3.3 Implementation
Architecture Architecture

New Current State Business Value

4 and Business Impact 3.4 Realisation

Figure 2.2.2 Enterprise architecture governance

Business Technology Standard
[Link]

Efficient governance requires clear roles, responsibilities and co-operation forums regarding the architecture
content (i.e. description of the current and target state, goals, roadmaps, plans, etc.). It also defines how enterprise
architecture content is continuously and systematically updated, published and communicated. Continual updating is
necessary to ensure the alignment with the changing strategy and market situation, and to meet the requirements of the
varying solution and service landscape.

Enterprise architecture related decisions in projects are done in cooperation between the business capability owners
(i.e. process owners) and the project organisation. Enterprise architecture needs to be reviewed in different phases of
the project as defined by the project model. Projects cause changes in the architectural landscape and thus projects
need to give input to enterprise architecture to make sure it reflects the on-going business changes. The aim is to
27
2. Demand

keep enterprise architecture holistic, up-to-date and related to the development of business concepts, processes and
solutions.

A good enterprise architecture practice is to proactively give input to concepts and projects before making too many
decisions. In addition, it is essential to systematically maintain and communicate the target state with visual images to
all relevant stakeholders.

2.3 Service Planning

Service planning has an essential role in implementing the business technology strategy. It contributes to strategic
planning and co-operates with enterprise architecture planning.

Service owners and Business Information Officers (BIO) have service planning accountability with the support of
service managers under the guidance of the Business Technology Management Officer (BTMO).

Typical organisations have dozens or hundreds of business technology products, solutions and services which are
split to logical domains. BIOs are responsible for business domain specific products, solutions and services while
service owners’ responsibility covers business function specifics and common services.

Service planning begins by defining the purpose of the service domain. There should always be a valid reason for an
organisation to spend money on a specific service domain and invest on further development. This is valuable input to
strategic planning which decides on how the money is allocated.

The next step, going on in parallel with financial planning, is to plan the service offering. i.e., the products, solutions,
services, users, service promise and related costs. This is a continual activity and updating the service catalogue
accordingly is needed for efficient service portfolio management.

The third step is to plan the development roadmap in co-operation with Enterprise Architecture (EA). EA-centric
capability planning defines transformation from current state to target state in the form of service domain-specific
roadmaps. A roadmap is a portfolio of development initiatives in a timeline. Each domain usually has a named
domain architect who plans the logical order of development initiatives within the domain and with the corresponding
BIO or service owner. The Chief Enterprise Architect and the Business Technology Management Officer (BTMO)
ensure that domain and cross-domain development initiatives are prioritised sensibly.

28
 2. Demand

Service Domain 1 SERVICE CATALOGUE

DEVELOPMENT ROADMAP BUSINESS SOLUTIONS AND SERVICES END USER SERVICES

R&D Engineering
Innovation Management Modeling
Product Management Services Product Design
Product Information Services Conceptualisation Workstation Services
Research Data Processing Voice & Mobile Services

Service Domain 2 Production Supply chain

Printing Services

Production Management Services Order Management User Access Services

Factory Services Forecasting & Capacity Planning
Equipment Services
Production Planning
Warehousing
Order Delivery
Collaboration Services
Retirement
DEVELOPMENT ROADMAP Business Support
Remote Access Services

Sales & Marketing | Financial HR | Legal| Communications

User Support
Self-Service | Service Desk | Onsite Support | Key User Support

INFRASTRUCTURE & OPERATIONS
Service Domain 3
Data Center / Cloud Services Platforms Network Security & Access IT Operations
Server Capacity Application Platforms Corporate Network Security Assurance Maintanance Services
Storage Capacity Database Platforms Internet Identity and Access Services Monitoring Services

DEVELOPMENT ROADMAP
Back-up and recovery Integration Platforms Firewall Services

AVAILABLE SERVICES IN SERVICE OPERATIONS

Insights, Performance KPIs

Business Technology Standard

Figure 2.3.1 Service planning key elements [Link]

The planned development initiatives require financing and therefore, financial planning, service catalogue planning
and roadmap planning each form an iterative loop. The major sourcing activities and commercial breakpoints are
service planning topics as well. In some situations, a sourcing initiative is required to achieve a major improvement
in cost or quality or there is a need for the operational model to change in the form of insourcing or outsourcing.
Strategic planning and service planning have joint interest in selecting the prime service providers. Further on, service
planning drives more specific supplier portfolio planning and optimisation.

Yet another activity of service planning is to plan business continuity. Service is given adequate business criticality
classification which determines the target for the service availability and other standardised key SLAs and KPIs.
Service planning may define other more specific measurements and operational targets. These are typically related
to ramping up or down the service usage or making transition from one supplier to another or from one agreement to
another.

2.4 Ecosystem Development

Business is all about ecosystems. Customers are ecosystem networks rather than individual actors or separate
segments. Ecosystems can be complex and extremely powerful as they can multiply or shrink a company’s business
abruptly and exponentially.

For example, in the past, cities used coin and card machines to collect parking fees. Nowadays, payments are made
digitally by using apps provided by third parties. This was facilitated by cities establishing ecosystems to share data
and transactions, rather than sourcing a digital app solution and providing the service themselves.

The result today is a better service to citizens and faster transformation to digital services, which results in moneysaving
for the city. In other words, all parties in the ecosystem have benefitted.

29
2. Demand

PARKING ECOSYSTEM

Parking Navigation to Pay for Parking Value-add

Infrastructure Empty Parking Lot Parking Surveillance Services

Integrated Flexible Security and License Plate

Solutions Payment Payment Recognition

GOVERNMENT PARKING OPERATORS

Figure 2.4.1 Digital parking ecosystem Business Technology Standard

[Link]

Developing the ecosystems

Every organisation works with several ecosystems. Business technology ecosystems are technology related and have
some common characteristics like:
• Use of technology is protected with licence terms and intellectual property rights (IPR)
• The use of technology often generates a large amount of data (Big Data) that is a very valuable asset and
a solid foundation for additional business
• The custom software has a high development cost and low scaling cost providing commercial alternatives
for risk and benefit sharing
• Use of data is restricted with regulations, like the General Data Protection Regulation (GDPR)
• Services are connected globally and are vulnerable to security issues that may have a massive business impact
(cyber security).

Technology providers make extensive investments in ecosystem development and acquire new developers and
customers with a low entry cost, trusting that they will break-even by gaining critical mass. Technology providers that
succeed in building ecosystems make significant profit, which enables them to invest even more in technology and
ecosystem development and thus, become even stronger in the market. For that reason, there are only a few players
dominating the ecosystem market.

From a sourcing perspective, the organisation should be:

• Smart in selecting new ecosystems, as they will benefit from the early adopter pricing and publicity
• Rational in selecting the dominant ecosystems with high costs, as they might lose business and progress
with declining ecosystems

30
 2. Demand

• Careful in selecting the niche ecosystems that may turn out to be good enough (positive scenario) or that
cause them to fall badly behind and require replacement (negative scenario).

The most attractive scenario is the opportunity to build an ecosystem and become a dominant player in the market.
As building and developing an ecosystem can be very costly, organisations should be certain to have the required
competences, commitment and passionate people to make it happen.

When building or joining an ecosystem, an organisation should:

• Have a clear and bold vision to be communicated
• “Walk the talk” as vision, takes time to build, and is undermined if action is inconsistent
• Introduce a compelling commercial model with risks, costs and benefits in balance
• Acquire the best companies for the ecosystems, ensuring creativeness and interest
• Ensure clarity with clear commercial and intellectual property rights rules
• Celebrate the initial steps as well as the big achievements regularly to create a community.

2.5 Innovations and Concepts

Businesses today face the need to use technology to modernise their existing products and services, or to create
totally new ones. In order to remain competitive, every company must encourage employees to come up with and
bring forward new ideas, and have an easy, effective and fluid process that ensures a fast and agile development of
new ideas into working services.

Innovation
Innovations create bigger opportunities and are critical for the survival, economic growth, and success of a company.
Innovation means developing original concepts and is a driver of reimaging business. Companies that innovate are
able to set the organisation in a different paradigm in order to identify new opportunities and the best methods to
solve current problems.

Innovation is often misunderstood as mere ideation. Most companies have some systematic processes for ideation, but
do not fully utilise the opportunity of the collective brain power of smart people. What most companies struggle with
is converting ideas into value propositions and taking them to market, in other words, innovation in their go-to-market
products or customer offerings. Also, innovation is not always getting the biggest idea out of the door. It could be a
process of tactical ‘tinkering’, i.e. continuous process of identifying problems and solving them at an operational and
delivery level.

It boils down to how prepared we are to listen and watch our customers and stakeholders, understand their
behaviours, their innate and unexpressed needs and satisfy them. One way to do this is to leverage modern
technology and prepare prototypes and data analytics to get insights. However, in this case technology is only
as good as the insights it provides. More importantly, there needs to be a culture of continuous improvement and
experimentation, based on the insights we derive, to provide better experiences for internal and external customers.

31
2. Demand

In most cases, in order to secure the company’s competitiveness and encourage constant renewal, innovation activities
should be systematic and purposeful, and be part of the company’s core practices and culture.

Innovation leadership and culture

To realise innovation, leaders should be open-minded and collaborative. Feeling comfortable with uncertainty and
managing changes are behaviours supporting innovation. Innovative leaders are curious and are optimistic since they
dare to take risks.

Any idea or innovation may be valid for the company’s business. Therefore, it is important to create an organisational
culture which embraces creativity and openness when suggesting new ideas. At the same time, there should be a
process which examines whether the idea has a business case or not. Those ideas which do not have the required
business potential need to be terminated quickly and those with commercial potential should be immediately put
forward to the next development phase.

Concepts
During the innovation process, the term ‘concept’ refers to an outcome examining the realisation of the business
potential of an innovative idea.

The aim of concept design is to illustrate how to turn an idea into scalable and pragmatic business opportunities.
A concept defines, from a business perspective, how the idea can be realised by considering technical solutions,
organisational and business changes and ecosystem implications. When properly conducted, concept design
provides valuable and business-driven specifications to source, develop and deliver new services.

Even if the concept design goal is to ensure that an idea is realistic and worthy of being developed further, it is equally
essential to ensure that the innovation process remains creative and leaves room for the free flow of ideas throughout
the process. Therefore, concept design follows the design thinking principles by first enriching the idea during
brainstorming sessions and then rooting to reality during proofing sessions.

Innovation management process

The innovation management process defines the steps from creation of new ideas into realising the business value
of a concept. The process produces high quality input for demand management to be developed further into a ready-
made service.

Innovation management consists of two main phases:

• Ideation phase in which you create the initial idea
• Concept design phase in which you design build and test the first prototype/service/product.

This end-to-end process should be supported by data analytics in order to validate and increase the potential
outcome of the ideation and design phases.

32
 2. Demand

IDEATION CONCEPT DESIGN

ECOSYSTEM INSIGHTS Innovation ecosystem Business ecosystem Customer ecosystem

People driven Innovate

innovations Design Build Validate
with people with people with people with people

IDEA FUNNEL

DEV Initiative

DEV Request
SNAP VALIDATE DESIGN BUILD VALIDATE
AN IDEA IDEA CONCEPT CONCEPT CONCEPT

Verify with Prototype Test with

Data driven data with data data
innovations

DATA ANALYTICS Market data Customer data Asset data Enterprise data

Figure 2.5.1 Innovation management process Business Technology Standard

[Link]

Ideation
The ideation phase refers to the creation of new ideas in the very beginning of the innovation management process.
Ideation can be people, process and data-driven. Companies can foster people-driven ideation by creating a culture
that encourages people to bring in new ideas and offer an easy and clear process to take the ideas further.

Data-enhanced ideation requires systematic data analytics that allows the discovery of useful information to be used
for data analysis-based innovation.

Concept design
The concept design phase transforms the selected ideas into well-defined plans which give insights into the business
potential of the ideas.

The process of designing concepts is crucial as it efficiently translates initial business needs or ideas into accurate
concepts. Involving a variety of stakeholders at an early stage and working together using agile, human-centred
and design thinking principles is a good way to solidify new ideas and eventually define how to create value for the
business. Deepening the commitment level, i.e. spending more time and getting more people engaged at each phase,
supports the fail fast – scale fast strategy.

33
2. Demand

PUSH A BUTTON SNAP AN IDEA VALIDATE IDEA DESIGN CONCEPT

I come up with I want to use 2 hours If I feel good about If I still feel good about the idea,
an idea or identify to capture and sketch the idea, I use 24 hours I create the full concept until
a problem. the idea together. to hack the concept. it is ready for projectisation.
GO

Continue Continue Continue Continue

2h 24 h 2–3 sprints

Iterate or Stop Iterate or Stop Iterate or Stop Iterate or Stop

Figure 2.5.2 Concept design

Business Technology Standard
[Link]

The outcome of the concept design process is a description of the potential realisation of the innovative idea which
can also be materialised in the form of a proof-of-concept or a prototype. It describes the change for the business
and how to bring an idea to a tangible product, resulting in business benefits. As such, the concept does not address
the exact costs as those will be calculated when making the business case in requirements gathering and feasibility
evaluation.

Innovation management process dashboard

One important aspect of the innovation management process is to measure and communicate how much business
value has been created and how many ideas have been developed and rejected. The communication can be done,
for example, in the form of a dashboard visualising the innovation portfolio and development pipeline. The key
measurement is the realised business value in terms of business revenue or a similar realistic metric.

Financial steering
The innovation management process requires strong financial and commercial steering to ensure that the company’s
resources will be used in the best possible way.

Typically, companies have two alternative ways of deciding how to allocate money for innovations:

1. Allocate a certain amount of money for each value stream owner who will independently steer and make
prioritisation decisions for ideas.
2. Have a centralised decision-making forum which will make the prioritisation decisions for the demand portfolio.

No matter which financial strategy is selected, it is important to set the metrics to measure the business benefits
realisation throughout the service lifecycle.

IPR
Intellectual property rights (IPR) should be considered early in the innovation process especially when using partners
outside the company to take part in development. Chapter 4.1 Commercial and property rights presents the main
points in ensuring an adequate way of sharing benefits, property rights and risks within the ecosystem.
34
 2. Demand

2.6 Development Portfolio

Portfolio management ensures that organisations’ strategic intent is met in development. Initiatives with
better strategic fit and higher business value are given priority.

Portfolio management includes the following duties:

• Defining rules and guidelines on how initiatives are evaluated and prioritised
• Maintaining a list of portfolio level development initiatives and their status
• Approving and rejecting development initiatives
• Introducing best practice for development and providing relevant coaching
• Supporting development streams in value creation and problem solving
• Resolving conflicts of interest or dependency problems
• Creating a good development culture and continuous learning
• Organising business value realisation measures and sharing lessons learned
• Providing executive level reporting and dashboard on portfolio status.

The full list of development initiatives, either pending, committed or rejected, represent the demand portfolio.
Once the initiative gets approved by the portfolio steering, it proceeds to the development portfolio.

G-1 Authorise initiation

BTPO GO Ready for planning

BT Portfolio Officer
G1 Authorise execution

DEMAND Portfolio Steering DEVELOPMENT

PORTFOLIO Approve development request PORTFOLIO
DEV Initiative

DEV Request

APPROVED
G-1 GO G1 PROJECT
PLAN AND
BUSINESS CASE

Business Technology Standard

[Link]
Figure 2.6.1 Portfolio management

35
2. Demand

The development portfolio provides the visibility and guidance necessary to maximise the business value of the
development initiatives whilst minimising the administrative burden on those initiatives. This ensures the most efficient
path for the release.

In order to maximise efficiency, the Business Technology Standard uses an approach called minimal viable
governance that customises the portfolio management practices to suit the different types of initiatives. Whilst larger
capability developments can follow a traditional gate-based approach, incremental initiatives and minor changes are
usually handled in a dedicated self-managed workstream.

When an approved development initiative is put into the sequential track as a project, the development portfolio
follows it until project closure and beyond in the realisation of business value.

DEMAND DEVELOPMENT DEVELOPMENT DEVELOPMENT

PORTFOLIO PORTFOLIO PORTFOLIO PORTFOLIO

PORTFOLIO STEERING
G-1 G1 G5 G6

PRE INITIATION EXECUTION DEPLOYMENT POST

Notion Study Plan Design Development Validation Release Rollout

Benefit
Realisation

Identify an Assess Plan Design the Create the Test and Confirm Rollout and
Opportunity Options Execution Solution Solution Validate Solution Hand-over
the Solution Readiness

G-1 GO G1 G2 G3 G4 G5 G6

AUTHORISE READY FOR AUTHORISE SIGN OFF READY FOR APPROVE AUTHORISE APPROVE REVIEW
INITIATION PLANNING EXECUTION DESIGN VALIDATION SOLUTION ROLLOUT CLOSURE BENEFITS

Business Technology Standard

[Link]

Figure 2.6.2 Project portfolio steering

Development Management Office (DMO)

The development portfolio is coordinated by the Development Management Office (DMO). The DMO oversees the
resourcing, dependencies and the performance of major development initiatives, while providing the required support
and consultation in order to maximise business value creation and minimise risks. It facilitates the activities to validate
and prioritise development initiatives to be approved or rejected by the development portfolio steering. The DMO
also sets and promotes development practices for company-wide visibility and consistency.

In order to fulfil its responsibilities, it is critical that the DMO either has, or can call upon, the appropriate resources.
The DMO represents the technology side of the organisation in addition to business and service stakeholders.
In particular, senior representation is critical to making adequate prioritisation judgements and business benefit
realisation assessments.

36
 2. Demand

The portfolio steering group includes different stakeholders to cover all aspects of decision making including
the following:

• Business: Evaluate the strategic value of the request for the business, as well as impact on revenue, customer
experience, risks, etc. This perspective is represented by Business Information Officers (BIO) and Service
Owners
• Finance: Assess the business case credibility and help secure funding for the development. This perspective
is represented by Chief Financial Officer (CFO) or person with his/her mandate
• Architecture: Understand the impact of the request on the enterprise architecture model and if any changes
are to be made. This perspective is represented by Chief Enterprise Architect
• Security: Assess if the request is compliant with the organisation security policies and evaluate potential
security risks and threats related to the project. This perspective is represented by Chief Information Security
Officer (CISO)
• Legal and regulatory: Assess the potential legal and regulatory implications and requirements.
This perspective is represented by Business Technology Governance Officer (BTGO)
• Capability: Understand the development and operations skills required to deliver the request and operate
once released into service and allocate resources and manage dependencies. This perspective is represented
by Business Technology Portfolio Officer (BTPO), who is chairman of the steering group as well.

Most organisations hold a monthly portfolio steering group meeting, and in some rare occasions where the request
impacts the company strategy, escalate decisions to the business technology steering group. In most organisations,
programmes must be approved by the business technology steering group as well.

Value stream portfolio views

Value streams expect an end-to-end view on portfolios related to all development topics. Different value stream views
and consolidated enterprise views use the same data and require a centralised portfolio management tool to share
the same information efficiently and in an up-to-date manner.

Cross domain and cross value stream portfolio management and optimisation

DEMAND PORTFOLIO DEVELOPMENT PORTFOLIO SERVICE PORTFOLIO

Multiple value streams STEERING GROUP STEERING GROUP STEERING GROUP
and domains having
E2E portfolio views

Program and Project Service Integration

Steering Groups Steering Group
Value Stream and
Service Domain Development Flow Change Advisory
Steering Groups Steering Board (CAB)

REQ Management System DEV Management System OPS Management System

Single Source of Truth and Platform for Actions

Figure 2.6.3 Portfolio views Business Technology Standard
[Link]
37
2. Demand

While portfolio steering focuses on major development topics only, the value stream stakeholders have interest
to see full picture of all development topics including:

• The innovations and improvements that typically get an incremental approach, taking advantage of agile
or DevOps practices to adjust and adapt along the way and realising value with interim releases
• The larger capability developments are likely to benefit from a more structured approach and can therefore
be expected to mainly follow the sequential development route
• Particularly complex initiatives may need to be managed through a programme. A programme is usually
initiated when the desired outcome requires a co-ordinated implementation of number of projects and
other initiatives in order to achieve the intended business benefits. Although the programme provides a level
of management and governance to its constituent initiatives, the programme itself still sits within the
development portfolio and the DMO has the same responsibilities for it as it does to all other development
initiatives.

The demand portfolio guidelines establish the optimal approach for any given initiative to follow the sequential,
incremental or change channel as appropriate. The DMO is there to assist should the initiative need advice or if it
needs to change channel.

Once any initiative is approved via the appropriate channel, the channel’s sub-portfolio applies the relevant minimal
viable governance approach to ensure that the initiatives that can, and should, benefit from light-touch governance
can proceed quickly through to deployment so the business can start to realise the value.

Business value realisation

Regardless of the approach taken, it is the responsibility of the development portfolio to track the ultimate business
value realisation for all the initiatives. In this respect the DMO needs to track the initiatives well into the service
delivery. This overlaps in timescale with the service portfolio but the two have different focuses during this timeframe:
development portfolio on the business benefit realisation, and service portfolio on ensuring services are reliable and
constantly fit for their business purpose.

Optimised throughput
A secondary key role of the DMO is to optimise the number of initiatives being undertaken at any given time. In a
challenging business environment, it is essential to make prioritisation decisions that support value creation, and
to resist the temptation to simultaneously initiate too many projects coming from the demand funnel. This optimised
approach reduces the overall waiting time and shortens the business case realisation time.

38
 2. Demand

Strategy 1: Minimising waiting time Strategy 2: Maximising business value

Project 1 Project 1

Project 2 Project 2

Project 3 Project 3

Project 4 Project 4

Period 1 Period 2 Period 3 Period 4 Period 5 Period 6 Period 7 Period 8 Period 1 Period 2 Period 3 Period 4 Period 5 Period 6 Period 7 Period 8

Result: 8 periods of benefit realisation with 100 % utilisation Result: 16 periods of benefit realisation with 100 % utilisation

Figure 2.6.4 Maximise throughput with selective resourcing

Business Technology Standard
[Link]

2.7 Data Assets and Integration

Data is a strategic business asset and one of the most valuable resources a company has. But its value is dependent
on quality, relevance and scope. Turning data into a high value commodity requires a journey of transformation.
Indeed, as a company’s own levels of data management matures so the benefits of data grow too.

It takes a data centric vision, a value creation attitude, commitment from the management team and resources,
as well as clear data ownership, roles and responsibilities.

To drive real benefits, data assets can be utilised by different businesses and functions in a number of ways either
to create new revenue streams or deliver change, such as:

• New products and services

• New business models
• Fact-based decision making
• Data monetisation opportunities
• Operational and process excellence
• Customer experience.

VISION
KEY SUCCESS FACTORS
BUSINESS BENEFITS
Managing data as Data operating
strategic business asset model
New business New products
models and services
TURNING
People, culture
DATA INTO and competence
VALUE Data monetisation Fact-based
opportunities decision making
Cross-business data Focus on critical
management function business data
Operational and Customer
process excellence experience
Leading the data
transformation journey

Business Technology Standard

[Link]

Figure 2.7.1 Turning data into value 39

2. Demand

Key success factors

To become a data-driven company and turn data into value, it’s essential to have a company-wide vision.
Key success factors for leading the data transformation journey are:

• People, culture and competence

Focus particularly on the management of change: instilling the right mindset, emphasising
new opportunities and building up the new required competencies.
• Managing data as a strategic business asset
Ensure ownership, governance, data quality, solutions and tools, data usage and delivery,
data security and risks, as well as culture.
• Data capability model
Design the end-to-end process for managing the demand, development and operational models for data.
• Cross-business data management function
Help the business to manage and increase the value of data by organising data services, including the
design, development and operations, in a professional and cost-efficient manner.
• Focus on critical business data
Prioritise the data management according to how critical it is to the business.

Elements of a data-driven company

BUSINESS

CORPORATE VISION & STRATEGY

DATA STRATEGY & USE CASES DATA-DRIVEN BUSINESS EXECUTION

PEOPLE & ORGANISATION ANALYTICS EXECUTION

DATA ASSET MANAGEMENT

DATA GOVERNANCE

DATA IT
DATA PLATFORMS AND OPERATIONS

TURNING DATA INTO VALUE

Business Technology Standard

Figure 2.7.2 Elements of a data-driven company
[Link]

40
 2. Demand

The individual elements that distinguish a data-driven company are:

• Data strategy and use cases: These companies understand which data is needed to support the corporate
strategy, such as how it can be made available, and how it will deliver value.
• Data-driven business execution: They make decisions based on data as evidence.
• People and organisation: They build and organise data teams and equip their teams with the competencies
needed for success.
• Analytics execution: They develop insights, models and reports.
• Data asset management: They define the information architecture and improve data quality and operations
for greater business value.
• Data governance: They establish steering groups, decision making processes and ensure control in order
to guide and govern data’s business value. As part of this, they define clear roles, responsibilities and
governance bodies to ensure that data is well managed and processes and policies are followed.
• Data platforms and operations: They design information flows and systems in a way that ensures business
continuity.

Data as an asset
Corporate strategy sets the level of ambition a company has and informs the transformation strategy needed to
become a data-driven company.

However, data is only valuable for the business when it is well governed, managed and made available.
The data asset management model defines the following perspectives:

• Data usage and delivery

• Data quality
• Security and risks
• Ownership
• Governance and roles
• Culture
• Solution and tools.

These different perspectives can be illustrated as the seven facets of a diamond. When all the sides of the diamond
are in excellent shape the business can realise maximum benefit.

41
2. Demand

SECURITY
GE DA
USA AND RISK QUA TA
DATA LIVERY LIT Y
&D E

CULTURE

OW N
N UTIO
ERSH
IP GOVERNANCE SOL TOOLS
A N D
& ROLES

Figure 2.7.3 Perspectives of a data asset

Business Technology Standard
[Link]

Data analytics
Data analytics, based on analysing data from different sources, provides valuable business information. Typical
sources of data are varied and include business applications, data warehouses, publicly available data sources and
operational data from sensors.

DATA SOURCES DATA ANALYTICS

Overview 1.00 10 97.91 % 13 151 2/1/2018 8/1/2018

page Median of E2E (h) Median of Score SLA Compliance % MIM count Days since last MIM Q&A Analysis

Incident
21652
Tickets
1.00
Median of E2E
Tickets created & closed and backlog
Created tickets Closed tickets Backlog (Created & Closed)
Tickets by Priority

1 – Critical 343
INSIGHT
2 – High 135
111 10 3 – Moderate 2316
LongRunner Median
Count of Score
4 – Low 20024

Request Item Business Area & Service

1166
Tickets

56
2.00
Median of E2E

9
R&D
Factories
H&R 0.8 K
2.2 K
1.7 K DECISIONS
LongRunner Median Logistics 0.5 K
Count of Score Feb 2018 Mar 2018 Apr 2018 May 2018 Jun 2018 Jul 2018 Aug 2018

Response count and score Tickets per location

SLA Compliance % Response created Median of Score
Finland 8.7 K

PROBLEMS
100 % Sweden 0.7 K
98 %
China 0.5 K
USA 0.5 K
96 %
Feb 2018 Mar 2018 Apr 2018 May 2018 Jun 2018 Jul 2018 Aug 2018

Business Technology Standard

Figure 2.7.4 Overview of data analytics [Link]

Traditional business intelligence deals primarily with what is known as descriptive analytics. Using historical data, it
provides hindsight and explains what has happened and why.

Data science addresses predictive and prescriptive analytics. It reveals insights and foresights about the future based
on patterns in the data, such as what is likely to happen and which decisions and actions should be taken as a result
of the intelligence.
42
 2. Demand

Insights into customer behaviour can be gained by simultaneously testing two alternatives, known as A/B testing.
Data is collected through experimentation with one group of customers and correlated with a different service or
product. For instance, an internet store can divert one group of customers to a new version of the storefront and
compare their behaviour and actions to people using the default storefront.

As such, the real-time availability of data and sensor-based IoT data can support the decision to optimise operational
processes, services and assets.

Data integration
Business processes span across different business solutions and data sources. Therefore, data flows, how data moves
from one part of a system to another part, and data integrations, how data originating from different sources is
combined, are an essential part of business technology management. Data flows play an essential role in automating
data between multiple systems inside or outside the organisation. But without integration, the data remains in silos and
only serves the needs of a limited group of people or functions and restricts new views, especially from a reporting
and analysis point of view. So, it’s important to prioritise this.

There are several system-integration options:

• Manual integration is done as an integral part of a person’s job or as their main task. Many organisations
have numerous low-volume integrations of this nature, whereby people take data from one place and move
it to another place or system. Whereas high-volume manual integrations will often be automated or typically
done by low-cost labour.
• Software robotics automation (or Robotic Process Automation, RPA) is a manual integration done by a
software robot simulating a human. A lot of manual work can be replaced by software robots without making
any changes to the business solutions. This extends the lifecycle and cost-effectiveness of legacy solutions.
• Point-to-point integration is an integration between two business solutions with a defined protocol and data
structure. Implementing multiple point-to-point integrations can be costly and difficult to maintain but it enables
high performance.
• Hub-and-spoke integration establishes a central data hub, which provides access to consolidated, shared
data. All applications using this hub will receive consistent data. This approach is often used for master data
management.
• Enterprise integration traditionally covers Enterprise Service Bus (ESB) and Extract/Transform/Load (ETL)
functionalities and is implemented using an integration platform, which manages data structures and multiple
integrations. Changes in data flows and structures are easy to manage and any possible issues with the data
transitions can be monitored.
• Application Programming Interface (API) integrations enable a fuller process integration by interacting
and obtaining data in a controlled way from one system or process to another. APIs allow data to be used
safely by other systems without jeopardising the integrity of the data in the source system.

The complexity of integrations varies greatly and is often underestimated because integrations usually contain other
aspects than just the technical integration. For example, security, access rights and error handling requirements may
cause extra work for integrations. Furthermore, the data at hand and its meaning must be understood in a consistent
way by all the systems involved.

43
2. Demand

Data capability model

The data capability model is an action-based illustration on how a company can create business value with data.
It features the Business Technology Standard operating model principles and highlights the capabilities needed for
planning, building and running data products and data services. The identified capabilities are then used as the basis
for defining the roles that need to be in place across the organisation.

The data capability model follows the plan-build-run structure and is aligned with the other aspects of business
technology management. The dark grey elements in the illustration below are data focused and go hand-in-hand with
other elements. In many cases, the same people and governance bodies make decisions on business, technology and
data at the same time and is therefore an essential part of business value creation.

GOVERN

Implement data ownership Manage data roles & responsibilities Own data asset strategy Manage and develop data assets

INITIATE PLAN BUILD RUN, USE & ENHANCE

Manage data product Manage data service

Authorise data Manage data privacy and security rules

Design and manage Design business Create E2E flow Create solution Create rollout Realise business
enterprise architecture capabilities governance approval approval value owners Manage data flows and integrations
Secure and
Authorise E2E flow and development

Create and Keep data Access and

Analyse Prioritise, Design and manage manage validate data up-to-date use data
Manage innovation Design
Authorise DEV initiative and

requirements commit and iterations and Deploy and train access rights
pipeline concepts and feasibility make backlog progress Manage data maintenance operations
BUSINESS NEEDS

Manage data
Plan data use cases quality Manage business continuity and services
DEV request

and outcomes Make data Implement data Implement data Implement data
Manage data modeling and storage & integration and Monitor data privacy and security in systems
portfolio Design and manage security Manage access
design operations business rollout control
data architecture Monitor data flows and integrations in systems

Design and manage Design and Design and Design and Run service operation and automation
solution architecture Design user stories develop user develop develop data Validate solution
interaction functionality management
Provide support and service to users
Design and manage Create service Manage service Manage service Build operational
service architecture planning and solution changes configuration readiness Release service
management Manage continual improvement and service retirement

Key Data Capability Other Business Technology Capabilities

Business Technology Standard

[Link]

Figure 2.7.5 Data capabilities

Data roles
When establishing data ownership and governance it is important to define and assign the data roles. There are
eleven key data roles, which are distributed across the Business, Data and Technology side of the organisation.

44
 2. Demand

I am responsible for the data-related I lead our centralised data function.

development roadmap in my business division. I create data-related services and set
I nominate Data Owners in my business. structure for data asset.
HEAD OF BTDO/
DATA CHIEF DATA
OFFICER
I’m responsible for planning the data DATA I facilitate discussion and define data quality
use cases and outcomes and DATA OWNER DOMAIN across a data domain enabling data asset
I ensure the data quality. LEAD development across the business lines.

I know the data content and BUSINESS

DEVELOPMENT I define the data design: data collection,
DATA EXCELLENCE DATA
quality needs and implement MANAGER ARCHITECT data storage and data flows across
changes in the processes. the organisation.

I create, update and use data. SERVICE I work with data across business
I ensure that the data quality EXCELLENCE lines. I can be part of the service centre
DATA USER DATA EXPERT
follows the defined rules. as Data Administrator or Data Expert.

I’m an advanced user and I help others SERVICE I serve the end users. I work in
KEY USER
use solutions in a smart way. I initiate AGENT a service desk or as a technical
SERVICE
development and change requests. service expert.
MANAGER

I have E2E service accountability.

Figure 2.7.6 Data roles Business Technology Standard

[Link]

Head of Data – is responsible for the data-related development roadmap in the business division.
Head of Data nominates Data Owners in their business domain.

Data Owner – is responsible for planning the data use cases and outcomes. Data Owners ensure the data quality.

Data Manager - knows the data content and quality standards and implements changes in processes.

Data User – influences the data asset value by using data and creating new data. Data Users ensure that data
quality follows the defined rules.

BTDO / Chief Data Officer - leads the centralised data function. BTDO/Chief Data Officer leads data-related
services and sets structure for the data assets.

Data Domain Lead - facilitates discussions on development initiatives and defines data quality across a data
domain. A Data Domain Lead enables the data asset development across business lines.

Data Architect - defines the data design: data collection, data storage and data flows across the organisation.

Data Expert – implements data administration, data cleansing or other data services. A Data Scientist is one of the
Data Experts and analyses trends and patterns that can be used as insights in business operations and management.

Service Manager – is responsible for defining, building and managing data services for the business users.

Key User – is an advanced user, who helps other users use data solutions in a smart way. Key Users initiate the
development or change requests on behalf of user groups.

Service Agent – serves end users on a service desk or as a technical service expert.

45
2. Demand

Data governance
Data governance provides data management guidance and control. Corporate vision and strategy provide direction
for the data strategy. Data strategy sets the goals for managing data assets and introduces guiding principles on
how data should be managed. The organisational setup of data governance provides the decision-making structure
including forums, meetings, steering, control and escalation paths. Clear roles and ownership define accountability
and responsibilities. Policies state processes to be followed, establish standards and enable control.

BOARD OF DIRECTORS
Executive Team

DATA GOVERNANCE STEERING COMMITTEE

A dedicated data governance council is the highest data decision making forum. Chair: Chief Data Officer
It coordinates and approves data-related practices and instructions taking all perspectives Participants: BU Data Owners
(architecture, projects, processes, operations, services) into account.

Govern data Govern data Govern data Govern data

in design in development in processes in use
Ensure that data architecture Ensure that data development Govern the data coming Ensure regulatory
standards and data modeling projects follow the established from business processes and compliance, security,
principles are followed, principles, policies and transactions, as it serves as access control and business
leading to a consistent processes and are thus a basis for decision making. continuity with established
enterprise architecture. aligned with the data strategy. forums and processes.

Business
EA DMO processes OPS
steering
DATA SERVICES

Daily operations of individual data services throughout their lifecycle. Investigate, approve or decline updates and development activities
related to data services.

Business Technology Standard

Figure 2.7.7 Data governance and decision making [Link]

The Data function led by the Chief Data Officer helps businesses to manage and increase the value of the data by
organising data design, development, controls, governance and operations in a professional and cost-efficient
manner.

A centrally managed data function ensures a harmonised way of working, data consistency and the required
professional competencies. Depending on the structure and culture of an organisation, a replicated or federated
model may be suitable as well.

2.8 Service Portfolio

Service portfolio complements demand and development portfolios with a service operations perspective. Service
portfolio provides visibility on service status, lifecycle and business value. This kind of overview is required for
governance, optimisation and risk management purposes.

46
 2. Demand

Service portfolio steering reviews the service status and business value and makes lifecycle decisions such as
approving new services and service retirements. Service catalogue lists the major services and provides a structure
for service status reporting that makes sense for the business.

Service status includes the following information:

• Service Level Agreement (SLA) status: green / yellow / red or not known
• Cost status: in / over / under budget or not known
• Lifecycle phase: in pipeline / in production / retired / archived on not known
• Business criticality: low / moderate / high or not known
• Business continuity: high (mirrored) / normal (recovery) / low or not known.

Measuring the business value

Although it is sometimes difficult to measure the business value of information technology solutions, the following
three main categories can be used:

• Business product: Information technology is a key element (like a mobile application) in a customer
product or service with measurable business value such as revenue
• Business assets: Information technology is a key asset (like an enterprise management system) in
business operations and can be allocated a portion of the business value
• Business enabler: Information technology has an enabling role (like laptops and other user services)
in business. The business value is calculated based on the alternative cost of either not having it or replacing
with another solution or service.

The service lifecycle defines four phases as illustrated in the picture below. The service portfolio interest covers phases
from ‘in pipeline’ to ‘in production’ and ‘retired’. In some regulated businesses, the retired phase is followed by the
archive phase. The archive phase means that the service is kept accessible for regulatory traceability purposes even
when it is no longer in operational use.

IN FUNNEL IN PIPELINE IN PRODUCTION RETIRED ARCHIVE

Demand Development Service Retirement

Management Portfolio Operations Control
and Innovations Management

Figure 2.8.1 The service lifecycle

Business Technology Standard
[Link]

Service portfolio steering is chaired by the Business Technology Management Officer (BTMO).

Service catalogue
The purpose of the service catalogue is to describe the business technology services available for the business
and service users. The catalogue provides clarity on service (ownership) structure and is thereby an effective
communication tool in business relations. It illustrates the diversity of the services, which is usually wider than generally
assumed by the business leaders. The service catalogue also includes many service management topics explaining

47
2. Demand

full scope of the services, and as such, gives a better understanding of total costs of the services which is essential
information for the business.

Service catalogue:

• Forms a comprehensive picture of services provided to business and service users

• Improves communication by providing better understating of business technology scope
• Provides clarity in service ownership between different organisations and role holders
• Provides a structure to follow up and report business technology costs
• Helps to identify and remove unnecessary solutions and services
• Accelerates self-service and service automation.

A complete service catalogue consists of an overview of business technology services, service brochures for users and
service requests and order catalogue for self-service purposes.

BUSINESS SOLUTIONS AND SERVICES END USER SERVICES

R&D Engineering
Innovation Management Modeling
Product Management Services Product Design
Product Information Services Conceptualisation Workstation Services
Research Data Processing Voice & Mobile Services

Printing Services
Production Supply chain
Production Management Services Order Management User Access Services
Factory Services Forecasting & Capacity Planning
Equipment Services Warehousing Collaboration Services
Production Planning Order Delivery
Remote Access Services

Business Support
Sales & Marketing | Financial HR | Legal| Communications

User Support
Self-Service | Service Desk | Onsite Support | Key User Support

INFRASTRUCTURE & OPERATIONS

Data Centre / Cloud Services Platforms Network Security & Access IT Operations
Server Capacity Application Platforms Corporate Network Security Assurance Maintanance Services
Storage Capacity Database Platforms Internet Identity and Access Services Monitoring Services
Back-up and recovery Integration Platforms Firewall Services

OVERVIEW OF SERVICES

Figure 2.8.2 Different catalogue perspective

48
 2. Demand

Welcome, John Stone

WORKSTATION SERVICES My profile | Log out

Homepage

Incidents and Service Requests

Please make orders, report incidents and problems via
IT Portal or by contacting Service Desk

FAQ
What workstations can I order?
What applications can I order?
How do I order a workstation or an application?
Who approves my requests?
How do I follow the status of my requests?
Where do I get help if I have a problem with my workstation?
Service Description
Workstation services provide ICT equipment, applications and
services needed by company employees to successfully do their work. Contact Information
Workstation services improve employee satisfaction and productivity
by allowing employees to choose the devices that best fit their job from Service Desk (7:00 – 17:00)
the set of company approved devices. With the limited set of workstation [Link]@[Link]
options IT Services ensure cost efficiency, efficient hardware and +358402345678
application management, service availability and fast delivery. Service Owner
firstname. lastname
Service Content [Link]@[Link]
+{int} xxx xxx
– Company approved workstations
– Workstation applications including office software More Information
ns – Workstation software distribution service
– Workstation security service • Service Eligibility (Who is entitled to order the service)
vices
– Workstation lifecycle management service • Maintenance information (Planned service breaks)
ces
– Workstation user support • Service Availability (The availability which IT is striving to achieve)
• Knowledge Base

SERVICE BROCHURES

n Stone Welcome, John Stone

Log out SELF SERVICE CHANNEL – PERSONAL IT My profile | Log out

Homepage
Business Technology Standard
[Link]

Work productively Order new workstation Communicate with Order new mobile phone Work Anytime Request for remote
Order new application Order or replace access right
with best fit Order peripheral flexible Mobile SIM card Anywhere with Remote Request for 4G
Workstation Services. Order security filter Phone Services. Order peripheral Access Services. mobility connection
Ask for advice Order external NFC tag Ask for advice
Read more Read more Ask for advice Read more

Give feedback or idea Give feedback or idea Give feedback or idea

Stay in touch with Request for Skype Print and copy Request for printing card Find information Search
Reserve video Request for printer knowledge base
colleagues, clients and conferencing room electronic material Ask for advice and instructions on
partners with Messaging Request for internal with Printing and frequently asked
and Collaboration project site Copying Services. questions and common
Request for external
Services. project site Read more issues users often face.
Read more Ask for advice Read more

Give feedback or idea Give feedback or idea Give feedback or idea

chieve)
Contact IT Support
Call: +358202345678 | Open support ticket

ORDER AND SERVICE REQUEST CATALOGUE

49
 Strategy and
Governance
Discipline

50
 3. Strategy and Governance

3.0 Introduction to Strategy and

Governance Discipline
The strategy and governance discipline aims to optimise the ways of working for the business technology function by
defining the guidelines, rules, and framework. The strategy and governance discipline’s remit covers these three main
topics:

• Set the strategic intention, guidelines, and motivation for the organisation
• Implement an operating model and organisation that create value for the business
• Ensure proper management of risks, compliance, and security

BUSINESS EXCELLENCE

Business Business Business Business Business

Vision Strategy Roadmap Design Insights

Vision Strategy Business Business Performance

Review Alignment Alignment Initiatives Review

STRATEGY-to-PLANS

OUTCOME-to-INSIGHTS
STRATEGIC PLANNING
STRATEGY AND
GOVERNANCE ECOSYSTEM PROCESS PEOPLE TECHNOLOGY DATA COST

Enterprise Objectives, Operating Model Competence and Risks, Quality, Security and
Architecture Scorecard and Tools Organisation Compliance Data Protection
and Steering and Ethics

PLANS-to-CAPABILITY

DEMAND | PLAN DEVELOPMENT | BUILD SERVICES | RUN

Demand Development Service
Portfolio Portfolio Portfolio
Steering Steering Steering

Business Technology Standard

Figure 3.0.1 Strategy and governance discipline [Link]

Strategic intention, guidelines and motivation

As businesses are heavily reliant on technology today, the business strategy and business technology strategy cannot
be separated. The business perspective puts the focus on markets, offerings, competition, customer trends and business
models. The technology perspective considers the business platforms, technology opportunities and risks, core
competencies and critical vendors. Business Technology includes both the business development and the technology
management perspective. These two perspectives merge into one business technology strategy when planning
business capabilities, digital transformation, ecosystems and competency synergies.

Strategic planning sets the strategic intention and guidelines for everyone to follow. Objectives define how to reach
specific goals and measure progress. Scorecards are often used to build organisational, team level and individual
incentives to meet objectives and strategic goals. However, the best way to motivate people to achieve goals
is to make sure that the strategic intention has a meaningful purpose and is well communicated throughout the
organisation.

51
3. Strategy and Governance

Enterprise architecture enables the planning of capability transformations. A business capability consists of people,
processes, systems, data and ecosystems. Enterprise architecture focuses on business and technology, and covers
planning processes, systems and data, and usually has less focus on people, competencies or ways of working.
Enterprise architecture is a good tool for assessing the current business technology status, defining the target status
and planning the road maps from the current to target status.

Operating model, organisation and competence

People create change. Therefore, it is essential to have the right competencies, a logically structured organisation,
and an efficient operating model to create business value and drive the transformation. The operating model defines
how the value streams create the value and illustrates how the different disciplines and practices should interoperate
efficiently. This is reinforced by the relevant governance.

INCREASE DIGITALISATION

STRATEGY AND GOVERNANCE

DEMAND DEVELOPMENT SERVICES

PLAN BUILD RUN

ENSURE BUSINESS VALUE

REDUCE RISKS

EXPERIENCE
Design Solution Service and Support
REQUEST

RELEASE
Portfolios and
Roadmaps

Develop Solution
Service Operation

Innovations and
Concepts
Operational Readiness Service Integration

SOURCING AND OPTIMISATION

IMPROVE EFFICIENCY

Business Technology Standard

[Link]
Figure 3.0.2 Business Technology Standard operating model

The organisational structure and competencies strategy should be based on the operating model. You should be able
to see how the value is created from just a glance at the highest-level organisational chart. In an ideal world, teams
and titles reflect the operating model, disciplines and practices as well.

Business transformation and competencies development should be a constant activity because there will always
be new requirements continuously arising from the business environment, including the technology environment.
Organisations should make savvy decisions as to which competencies they need internally and which ones to acquire
from external organisations. Either way, they all should implement the same operating model, get training and have a
passion to create business value.
52
 3. Strategy and Governance

Managing risk, compliance, quality and security

Managing risk, compliance, quality and security is often about giving recommendations and instructions and
checking they are followed. However, when you raise the understanding and awareness of how to deal with or avoid
possible issues the impact you can have is far greater. Good guidelines and instructions, as well as security tools and
controls to detect the possible issues, are a good starting point, but you can only attain the desired security awareness
levels when a human centric approach to security is applied.

While it would be hard to gain a major competitive edge through good risk, compliance, quality and security
management, it is a crucial factor in preventing the loss of business, revenue, reputation and opportunities. Businesses
are more vulnerable than ever before and therefore managing risk, compliance, quality and security is fundamental to
staying competitive.

Data regulation and protection

Data has an important role in everything any company does today. While data is essential for a company to do
business, there are several rules that determine how, what and when the data can be collected and how to deal
with the collected data. Violating data regulation and protection rules presents a major risk to a company’s business
continuity. Therefore, it is essential that the company is aware of the different regulations that relate to the specific
industry the company operates in.

The General Data Protection Regulation (GDPR) is a regulation in EU law giving people more control over their
personal data. It forces the company to make sure that personal data is collected under strict conditions and protected
from misuse and exploitation. The GDPR addresses the export of personal data outside the EU and EEA areas and is
therefore applicable to any company processing the data of EU citizens.

3.1 Objectives, Scorecard and Steering

The business technology function should be evaluated like any other business unit. The business technology
organisation gets its mandate from the business technology steering group which, together with the CIO and the
business technology management team, decides what the targets are and how they will be measured.

Well-defined targets are specific, measurable and time-related. Targets are set separately for the entire business
technology organisation and for each team or unit, as well as for every individual.

Targets for the business technology organisation are set in line with the overall vision of the company and should
support the realisation of the company’s goals. The business technology management team is responsible for
achieving and measuring short and long-term targets and reporting results and any deviations to the business
technology steering group.

Business technology related objectives

The best practice method for defining incentive targets is the balanced scorecard approach. Incentive policies and
the scorecard structure are usually defined at a company level. In most cases, incentives are tied to company-level,
sub-organisation-level and individual-level targets.
53
3. Strategy and Governance

The table below provides a good set of useful measurements for the whole business technology organisation and for
each role, even if the actual targets are organisation and situation specific. The roles are explained in more details in
Chapter 3.3 Competence, Roles and Organisation.

IDENTITY MEASUREMENTS

Business Technology − Business stakeholder satisfaction; based on biannual survey

− End-user satisfaction; based on instant service rating
− Total cost and related cost saving targets

Business Excellence − Approved business value of new ideas and concepts

− Domain roadmap success index1

Business and process development − Project stakeholder satisfaction; based on project closing survey
− Project delivery accuracy (schedule and budget); success index1

Product and service development − Sprint flow stakeholder satisfaction; based on major release survey
− Backlog delivery success rate (value and time); success index1

Service Excellence − Number of major incidents or the cost of business down time
− Service delivery accuracy (SLA); based on success index1

Smart Governance − Number of major security and compliance issues

− Service cost and contract accuracy; based on success index1

1
Success index is calculated for the roadmap, development portfolio, service portfolio, backlog or service catalogue
with the following formula: [number of items on green (in target)] / [the total number of items].

Organisations with mature target setting and measurement practices can increase their ambition and measure the
business value along these lines:

• What was the business value created?

• How much business value was lost as a result of incidents?
• What is the business value of services?
• How many projects or sprint flows delivered business value?

These kinds of targets are difficult to measure but they set the right mindset for the business technology operations.

54
 3. Strategy and Governance

Steering
The Business Technology Standard introduces the principle of minimum viable governance. The minimum viable
governance aims to make the end-to-end process from demand to service operations as easy as possible, starting
from the business needs all the way up to the implementation and deployment of a solution.

The three key principles for a Minimum Viable Governance (MVG) are:

1. Smart top-down control and coordination to optimise portfolios

2. Strong leadership and mandate to make decisions and drive business value
3. Smooth end-to-end flow discipline to create value and escalate decisions only when needed.

The Business Technology Standard proposes three governance levels:

1. Enterprise level
2. Value Stream level
3. End-to-End Flow level

CHAIRMAN OF THE Business Technology Steering Group and Business Technology Management Team
ENTERPRISE

BUSINESS TECHNOLOGY
STEERING GROUP Portfolio Steering Group
Service Portfolio Steering Group
CAB and Service Integration Steering Group
CIO EA Steering Group Data Governance Steering Group
VALUE STREAM

HEAD OF VALUE STREAM STEERING GROUP Value Stream Steering Group

BIO Capture Allocate Coordinate Govern Create

Strategy Resources Demand Portfolio Biz Value
ENTERPRISE PORTFOLIO HEAD SECURITY SERVICE
ARCHITECT MANAGER OF DATA MANAGER OWNER

Authorise Approve Approve Approve Approve

flow Dev Initiative Dev Request Dev Delivery

E2E Flow Steering Group

END-TO-END FLOW

BUSINESS OWNER / PRODUCT OWNER

PROJECT Study Planning Design Development Validation

MANAGER
PROCESSED DEMAND

Service
operation
DIRECT AND

SCRUM Product Dev Dev Dev

MASTER Vision / Epic Sprint Sprint Sprint Train & Realise
Release Rollout Business
Value

Service
SERVICE Change support
MANAGER Design, development and validation
Request

Business Technology Standard

[Link]

Figure 3.1.1 Business Technology governance levels

55
3. Strategy and Governance

Enterprise level
On the enterprise level the governance bodies implement synergies across value streams. Each governance body has
a dedicated focus and role.
ENTERPRISE

CHAIRMAN OF THE Business Technology Steering Group and Business Technology Management Team
BUSINESS TECHNOLOGY
STEERING GROUP
Portfolio Steering Group
Service Portfolio Steering Group
CAB and Service Integration Steering Group
CIO EA Steering Group Data Governance Steering Group

Figure 3.1.2 Enterprise level governance steering bodies Business Technology Standard
[Link]

The Business Technology Steering Group is the highest decision-making body for strategies, budgets, policies
and guidelines all of which have an impact on value streams across the organisation. The purpose is to ensure top
executives take responsibility for and focus on the mandate given to them. The CIO organises the steering group and
ensures efficient preparation for and implementation of decisions.

The Business Technology Management Team forms the CIO’s management team with focus on people,
performance, capabilities, quality, risks and costs. It leads the business technology function and builds capabilities
and coordinates operations across all value streams.

The Portfolio Steering Group is the highest decision-making body for demand and development portfolios.
It provides governance practice guidelines and instructions for the development methodology as well as common
tools for end-to-end flows. The portfolio steering is chaired by the executive sponsor, while the business technology
portfolio officer (BTPO) organises and runs the steering.

The Service Portfolio Steering Group represents the highest decision-making body for service lifecycles.
It coordinates and steers the overall service performance and efficiency while providing governance practices and
common tools for service management.

Changes to the enterprise level core architecture are approved by the Enterprise Architecture Steering Group.
As the highest decision-making and coordination body for enterprise architecture, it also reviews the value stream
level architectures and roadmaps.

The Data Governance Steering Committee is the highest decision-making and coordination body for data
governance. It oversees all major data governance activities and is responsible for their support and coordination.
The committee coordinates and harmonises data related decisions and development initiatives. It is organised by the
Business Technology Data Officer (often called Chief Data Officer) and its members include the Head of Data roles
from value streams and contributing businesses.

The Service Integration Steering Group and Change Advisory Board (CAB) authorise service releases and
harmonise core service processes to improve service quality and ensure business [Link] stream level
On the value stream level individual value streams are characterised by having a specific business focus, for which

56
 3. Strategy and Governance

they create business value. The value stream steering group is led by the head of value stream who is a business
executive with the highest interest and responsibility on the value stream topic. The steering is organized by the
Business Information Officer (BIO) who is accountable for the end-to-end management of business technology from
the value stream perspective.
VALUE STREAM

HEAD OF VALUE STREAM STEERING GROUP Value Stream Steering Group

BIO Capture Allocate Coordinate Govern Create

Strategy Resources Demand Portfolio Biz Value
ENTERPRISE PORTFOLIO HEAD SECURITY SERVICE
ARCHITECT MANAGER OF DATA MANAGER OWNER

Figure 3.1.3 Value stream level governance Business Technology Standard

[Link]

According to the second minimum viable governance principle of strong leadership and mandate, they execute
their own portfolio governance based on the resources received from the Enterprise level above. Value streams are
therefore free to prioritise according to the tasks that present the most benefit to them.

The ultimate goal for value stream governance is to create business value and maximise business outcomes.
To achieve this goal the value stream needs to organise and implement five governance areas:

1. Capture strategy
2. Allocate resources
3. Coordinate demand
4. Govern the portfolio
5. Create business value.

End-to-end flow level

End-to-end flows are essentially the delivery engines for the expected business value. They can take the form of (i)
projects and programs, (ii) agile development teams and (iii) change request-based small development channels.
End-to-end flows receive the authority to consume resources from the value stream - the level directly above it.

57
3. Strategy and Governance

Authorise Approve Approve Approve Approve

flow Dev Initiative Dev Request Dev Delivery

BUSINESS OWNER / PRODUCT OWNER E2E Flow Steering Group

END-TO-END FLOW Study Planning Design Development Validation

PROJECT

PROCESSED DEMAND
MANAGER
Service
DIRECT AND
operation
SCRUM Product Dev Dev Dev
MASTER Vision / Epic Sprint Sprint Sprint Train & Realise
Release Rollout Business
Value
Service
SERVICE Change Design, development and validation support
MANAGER Request

Business Technology Standard

Figure 3.1.4 End-to-end flow governance

[Link]

The Business Technology Standard defines a generic model to govern the end-to-end flow steps: The steps are
distributed over the following four progress zones:

A zone: Capture demand

B zone: Build product / solution / service and its operational readiness
C zone: Release service
D zone: Rollout and realise business value.

A ZONE B ZONE C ZONE D ZONE

DEMAND PORTFOLIO DEVELOPMENT PORTFOLIO SERVICE PORTFOLIO

E2E GOVERNANCE

Authorise Learn from

E2E flow outcomes

Approve GO? Approve GO? Approve GO? Approve

DEV initiative DEV request development E2E delivery

DEVELOPMENT ROLLOUT
Strategic Realise
planning DEV Deploy and train business value
request iterate

Plan business
capabilities and
enterprise architecture Analyse Design, SERVICE RELEASE
DEV Prioritise,commit Release
initiative requirements develop and Solution
and make backlog service
and feasibility validate
Design ideas
and concepts
SERVICE OPS Ensure Run service SERVICE OPS
Plan service Change operational operation and Service
increments and request readiness automation
improvements
Run continual
improvements with SERVICE SUPPORT
Service service changes Integrate services Provide support
Planning and assure quality and service to users
DEMAND

E2E SERVICE MANAGEMENT

Business Technology Standard

[Link]

Figure 3.1.5 Business Technology Standard end-to-end flow steps

The end-to-end governance is depicted in the upper part of the diagram with its steps or decision points marked in
black. It ensures that the required business decisions and commitments are made at the right time. It integrates the end-
to-end flow with corporate governance either by having a decision mandate provided by the corporate governance
or by escalating the decision to the corporate governance level. Since the end-to-end governance operates at the
portfolio level it also provides coordination across the end-to-end flows.

End-to-end flows have unified governance roles to manage demand, development, service release and service
quality.
58
 3. Strategy and Governance

3.2 Operating Model and Tools

Business technology operating model
The business technology operating model is a high-level illustration on how a company can create business value with
information technology. It presents the company’s strategic excellence topics, value streams and business technology
value adding elements.

The target of the business technology operating model is to ensure that the technology management contributes to
business excellence. The target is achieved by having continuous focus on attempts to increase digitalisation efforts,
ensure business benefits, improve efficiency and reduce risk.

The business technology operating model captures business value to parallel value streams. The value streams reflect
the organisation’s key activities, and their purpose can be illustrated with three examples as shown in the picture
below.

The customer interfacing technology focuses on agility and new digital frontline solutions, whereas the business
process technology focuses on enterprise-level and backbone solutions. Operational technology value stream
focuses on specific solutions that are valuable for certain geographical regions or business domains only.

INCREASE DIGITALISATION

STRATEGY AND GOVERNANCE

CUSTOMER DEMAND DEVELOPMENT SERVICES

INTERFACING
PLAN BUILD RUN
TECHNOLOGY LOYALTY

ENSURE BUSINESS VALUE

LEADERSHIP
REDUCE RISKS

EXPERIENCE

Design Solution Service and Support

REQUEST

RELEASE

BUSINESS Portfolios and

PROCESS Roadmaps
TECHNOLOGY QUALITY & COST
LEADERSHIP
Develop Solution
Service Operation

Innovations and
OPERATIONAL Concepts
TECHNOLOGY Operational Readiness Service Integration DATA
LEADERSHIP
SOURCING AND OPTIMISATION

IMPROVE EFFICIENCY

Business Technology Standard

[Link]
Figure 3.2.1 Value creating streams

The business technology operating model consists of five disciplines:

Strategy and Governance discipline sets the guidelines and manages the whole business technology function.
It defines the organisational structure and ensures that the business technology strategy and operating model support
the business objectives. Strategy and governance discipline is led by the Business Technology Governance Officer
(BTGO).

Demand discipline captures the business needs and requirements and turns development initiatives into operational
actions. Demand discipline provides content to portfolios, plans roadmaps and facilitates the creation of innovations
and concepts as well as analysis of feasibility.
59
3. Strategy and Governance

Demand discipline is led by the Business Information Officers (BIO), Service Owners and Chief Digital Officer (CDO).

Development discipline comprises of building new solutions and improving current capabilities. It includes designing
and developing business initiatives and is responsible for building operational readiness and working solutions.
Development discipline is led by the Business Technology Development Officer (BTDO) together with project and
product owners.

Services discipline runs business services and provides service support. It is responsible for business continuity and is
led by the Business Technology Operations Officer (BTOO).

Sourcing and Optimisation discipline ensures that the company has the services that best fit its business purposes.
It constantly optimises the delivery ecosystem in order to provide services cost-efficiently and appropriately. Sourcing
and optimisation are led by the Business Technology Management Officer (BTMO), Service Owner and Sourcing
Lead who have the responsibility on end-to-end service excellence.

Operating model enhances realisation of business targets

The five disciplines of the business technology operating model support the realisation of the company’s business
targets by enabling the following:

Multi-speed: Combining the agility of digitalisation with the need for scalability and reliability in enterprise solutions.
The business requirements for both agility and governance are met through two separate value flows: incremental and
sequential. By selecting the best-fit partners and solutions, the business technology function can be agile and fast in
realising the expectations with a fit for purpose development approach.

Clarity with unified ways of working: Building a way of working that is understood and adopted by all relevant
stakeholders, including business executives and business technology partners. Creating a common culture of working
through common language, identity and unified roles, unified practices, transparency and well-communicated
decision-making models, will lead to reduced risks and improved efficiency.

Efficiency: Using tools that support the implementation of the operating model and enable industrial-like efficiency
such as process automation. The tools should reflect the agreed roles and responsibilities, support practices and guide
the organisation in the right direction. In order to improve efficiency and transparency, the tools should be deployed to
innovation, project, and service management as well as resource and cost management.

Value creation perspective

The business technology operating model splits the value creation in three value creation phases.

60
 3. Strategy and Governance

BUSINESS
DEMAND | PLAN TECHNOLOGY
SERVICE
CONCEPT PORTFOLIO Impression Process
IDEATION DESIGN & ROADMAP
NEED
Touchpoint Platform

DEVELOPMENT | BUILD Data Infra

COMMITMENT IMPLEMEN- BENEFITS
& BACKLOG TATION REALISATION
Integration

SERVICES | RUN
SERVICE SERVICE SERVICE
RELEASE DELIVERY RETIREMENT

VALUE STREAM SERVICE

Business Technology Standard

Figure 3.2.2 Value creating phases [Link]

Demand | Plan phase captures the business demand. It includes planning and concept design and is responsible for
introducing new initiatives into portfolio and roadmap.

Development | Build phase develops the business intiatives into products, solutions and services. It ensures business
commitment to development requests in portfolio and backlog. It is resposible for the implementation and the
realisation of business benefits.

Services | Run phase operate services. It ensures that service release, delivery and retirement doesn’t compromise
business continuty or service experience.

There are two different approaches on how to ensure the delivery of the value: sequential and incremental.

SEQUENTIAL DEVELOPMENT FLOW INCREMENTAL DEVELOPMENT FLOW

DEMAND | PLAN DEMAND | PLAN

DEVELOPMENT | BUILD DEVELOPMENT | BUILD

SERVICES | RUN SERVICES | RUN

Business Technology Standard

Figure 3.2.3 Sequential and incremental value creation
[Link]

Sequential approach considers development initiatives based on a business case.

The prioritisation and optimisation decisions are made based on an unified business case model which enables full
guidance and control, especially in the transition phases: from demand to development and from development to
services. The sequential approach fits well with business and process development needs where the control and
coordination of synergies and priorities is prevailing over speed and agility.

61
3. Strategy and Governance

Incremental approach aims to ensure the fastest development cycles.

The prioritisation and optimisation decisions are made within a specific focus area to ensure a short time to market.
The incremental approach fits well with digital and product development where the speed and agility prevails over
centralised decision-making and coordination of resources.

Tools
The business technology operating model should be connected to day-to-day operations with appropriate tools, such
as the following:

• A modern business technology management platform to provide a single source of information and end-to-end
visibility from idea and innovation management to development, ending up in service operations and retirement
• Digital time tracking, task management, work orders and resource allocation to connect the business Key
Performance Indicators (KPIs)to development and services
• Service integration / Service Level Agreements (SLAs) and dashboards to ensure effective vendor management
and optimisation
• Financial reporting and rolling forecast for budgeting and cost estimation
• Operational management tools to ensure business continuity and enforce information security
• Scenarios, insight, and strategic planning tools to compare the different business options
• Virtual and online workspaces to support decision-making and time and location independent collaboration
• Document and contract management systems to provide visibility to relevant information
• Kanban and other visual leadership tools to manage incremental value delivery
• Project management systems to support sequential value delivery.

3.3 Competence, Roles and Organisation

Business Technology Standard defines unified roles across business and technology management functions. The aim
is to abolish the traditional division between technology management functions and business, and thus enable a
seamless and fast end-to-end development of services.

Competence and professional identity

Successful implementation of the business technology principles requires building the cross-functional capability to
carry out the tasks and responsibilities regardless of formal organisational functions and reporting lines.

62
 3. Strategy and Governance

The required competence is achieved by defining the knowledge, skills and experience in each business technology
role and making sure that the people working in those roles understand what the expectations for the role are and
how they can best co-operate with other roles.

In the business technology context, the traditional gap between people working either in business or in technology
management is broken by forming teams consisting of people from different organisations. The teams consist of people
sharing the same professional identity. Professional identity defines the characteristics and competencies specific to
a group of people who, by working as a team, ensure successful execution of the duties within a given identity area.
The different identity groups together ensure that the business technology function can meet the expectations set by the
business.

The picture below outlines the main roles in the business technology function organised around the five identities:
business excellence, business and process development, product and service development, service excellence and
smart governance.

SMART
CIO
GOVERNANCE

SOURCING BTGO CISO

LEAD

BTMO BTPO GOV LEAD

BIO / PROJECT
SERVICE BTSO BTOO
MANAGER
OWNER
BUSINESS
BUSINESS ENTERPRISE AND PROCESS SERVICE OPS LEAD
CAPABILITY ARCHITECT DEVELOPMENT MANAGER / EXPERT
OWNER
BUSINESS BUSINESS SOLUTION SERVICE
CDO
EXCELLENCE OWNER LEAD / EXCELLENCE
EXPERT
PRODUCT PRODUCT SERVICE
INNOVATION TECH /
OWNER / AND SERVICE INTEGRATION
LEAD SERVICE
BUSINESS DEVELOPMENT LEAD / AGENT
ANALYST EXPERT
BTDO / SCRUM SOLUTION
MASTER / KEY USER
DATA LEAD ARCHITECT
/ EXPERT DEV LEAD

Business Technology Standard

Figure 3.3.1 Business Technology Standard roles and responsibilities model

[Link]

Besides the personal knowledge and skills, the identity also considers the motivational aspects of a person, for
example, social identity, personal interest and passion. The aim is to encourage people to find and use their strengths
and to promote the feeling of achievement. For example, a person working in the service excellence area takes pride
in ensuring that the existing services are up-to-date, reliable and stable, whereas another person in the same area
prefers the challenge of having to come up fast with an idea on how to ensure the scalability and robustness for a
completely new service.

Roles
Business technology roles are assigned to different teams based on the identities. The idea is to combine the roles in
such a way that the team has the capability to carry out the end-to-end tasks within the scope of the team. In the case
63
3. Strategy and Governance

of product and service development identity for example, the team consists of roles like:

• Business analyst who can articulate the business need or idea

• Innovation lead who can organise and facilitate a quick ideation and conceptualisation
process to refine the idea
• Solution lead who can bring the knowledge about existing solutions and platforms and affect the scalability
and time to market early on
• Development experts who can design the user interface, start coding the mock-ups, and run user tests from the
beginning of the development process
• Solution experts who can configure the new solution into existing platforms
• Service integration expert who can ensure a smooth transition from development to service operations with
automated process and build the service readiness with suppliers
• Operations expert who ensures that the service in properly maintained and runs without hick-ups.

The next paragraphs illustrate the key roles within each identity and their key characteristics.

Business excellence identity roles and key characteristics

I lead service
management and
service portfolio. BUSINESS Achieving competitive edge
I manage business EXCELLENCE with technology
technology E2E
for a business or
for a function. Develop business with information technology.
BTMO PASSION Challenge the status quo with innovative
I lead business I lead enterprise thinking.
capability development
development. BIO / planning.
SERVICE Turn business needs into well-defined
OWNER technology requirements.
I lead digital I steer KEY EFFECT
frontline development BUSINESS ENTERPRISE development Managing the business and people side
initiatives. CAPABILITY and implement of the development.
ARCHITECT
business benefits.
LEAD
BUSINESS Business value of information technology
CDO BUSINESS
EXCELLENCE KEY MEASURES and data.
OWNER
Business value of development initiatives.
PRODUCT
INNOVATION
OWNER /
I lead innovation LEAD Business knowledge.
BUSINESS
processes. ANALYST Conceptual thinking.
BTDO / I plan and
design business KEY COMPETENCIES Planning development steps.
DATA LEAD requirements.
I build data leadership / EXPERT Workshop facilitation skills.
with analytics and
smart flow of data. Enterprise architecture understanding.

Business Technology Standard

Figure 3.3.2 Business excellence identity roles and key characteristics [Link]

The purpose of the business excellence identity is to build the competitive advantage with information technology.
Ideally the team is built with people who are excited by experimenting with the unknown and seeing technology as an
opportunity to create something new.

64
 3. Strategy and Governance

Business and process development identity roles and key characteristics

I manage development BUSINESS
capability and portfolio. AND PROCESS Building the business capabilities
DEVELOPMENT
I manage projects
and programmes. I manage solutions.
BTPO Manage forward-looking business
transformation programmes.
PASSION
I lead enterprise I design, build Gain the competitive advantage by smartly
development PROJECT BTSO and manage combining the new with the existent.
planning. MANAGER service capability.

BUSINESS Capability to manage the complexity

ENTERPRISE AND PROCESS SERVICE and dependencies.
ARCHITECT DEVELOPMENT MANAGER KEY EFFECT
Throughput maximisation and risk
minimisation.
BUSINESS SOLUTION
OWNER LEAD /
I’m a solution Delivery accuracy
I plan and EXPERT configuration owner (costs, schedule and scope).
design business KEY MEASURES
PRODUCT and plan the business
requirements. I steer development
OWNER / fit with standard Time-to-market.
and implement solution elements.
BUSINESS business benefits.
ANALYST Project management.
SCRUM SOLUTION
MASTER / ARCHITECT Programme management.
I lead custom development I have deep knowledge
or am expert in writing code, DEV LEAD of applications or KEY COMPETENCIES Ecosystem management.
designing UX or testing. platforms in use.
Managing people side of change.
Expectations management.
Business Technology Standard
[Link]

Figure 3.3.3 Business and process development identity roles and key characteristics

The purpose of the business and process development identity is to ensure that the business has the best fit-for-purpose
solutions. Ideally the team is built with people who take pride in succeeding to manage the dependencies of multiple
projects and transformational programmes.

Product and service development identity roles and key characteristics

PRODUCT
I steer development and I know how to make best use of AND SERVICE Being digitally savvy
implement business benefits. standard solution in a product. DEVELOPMENT

Enable digital transformation.

PASSION Carry out numerous fast-paced
I’m an expert in I automate and development projects.
business needs. manage service
releases.
BUSINESS SOLUTION Factory-type of development capability.
OWNER LEAD / KEY EFFECT
EXPERT I run operations New business opportunities.
for a product
PRODUCT PRODUCT SERVICE or solution.
OWNER / AND SERVICE INTEGRATION Speed of delivery.
BUSINESS DEVELOPMENT LEAD / KEY MEASURES
ANALYST EXPERT The number of developed products.
SCRUM SOLUTION OPS LEAD
MASTER / ARCHITECT / EXPERT
DEV LEAD Agile development practices
(Scrum, SAFe and DevOps).
Concept planning.
KEY COMPETENCIES
I’m agile development I’m a dev expert writing code, I have deep knowledge Backlog management.
master and lead dev for designing UX, running testing of applications or
one or more products. or in some other expert role. platforms in use. Design thinking.
Service design.

Business Technology Standard

[Link]

Figure 3.3.4 Product and service development identity roles and key characteristics

The purpose of product and service development identity is to ensure that the company is constantly looking for and
developing new digital services to remain competitive in the market place. Ideally the team is built with visionary
people who enjoy fast-paced development sprints and are continuously challenged.

65
3. Strategy and Governance

Service excellence identity roles and key characteristics

SERVICE
Ensuring the business continuity
EXCELLENCE
I ensure business
continuity and delivery
performance of services.
Manage the complexity of cutting-edge
I manage delivery PASSION technology.
I have E2E service operations for application, Solve business continuity challenges.
accountability. infra and end-user services
BTOO and make continual
service improvements.
Orchestrating the ecosystem in order to
keep the promise.
SERVICE OPS LEAD KEY EFFECT
MANAGER / EXPERT End-to-end responsibility and reliability
of services.
I manage and improve I serve end-users
service processes and SERVICE in service desk
quality and expert EXCELLENCE or as a technical Number of major incidents
in managing cross service expert. KEY MEASURES (business downtime costs).
service processes.
SERVICE Satisfaction of service consumers.
TECH /
INTEGRATION SERVICE
LEAD /
AGENT Broad technical undestanding.
EXPERT
KEY USER Problem solving skills.
I’m an advanced user and help KEY COMPETENCIES Customer experience design.
others to use solutions smartly.
I initiate DEV and change requests. Ecosystem management.
Service mindset.

Business Technology Standard

[Link]

Figure 3.3.5 Service excellence identity roles and key characteristics

The purpose of the service excellence identity is to ensure that the services are maintained, secure and run without
interruption 24/7. Ideally the team is built for people who focus on securing business continuity. They are constantly
seeking ways to streamline and automate the processes utilising the latest operational technology.

Smart governance identity roles and key characteristics

I lead business
technology organisation. SMART
Streamlining the decision-making
GOVERNANCE
I source services
and manage frame I lead all governance I manage
agreements. functions. cyber security. Create structure to ensure
PASSION that things proceed as planned.
I lead service
management and Develop the disciplines.
service portfolio.
SMART
CIO GOVERNANCE
I manage business Well-functioning disciplines.
technology E2E for
a business or for KEY EFFECT Modernise ways of working by adding
a function. SOURCING transparency.
BTGO CISO
LEAD

Cost effectiveness.
BTMO GOV LEAD KEY MEASURES
People well-being.
I lead one
BIO / governance
function. Lean decision-making.
SERVICE
OWNER Broad range of communication skills.

SERVICE KEY COMPETENCIES Transformation management.

I have E2E service MANAGER
accountability. Leadership skills.
Financial management.

Business Technology Standard

[Link]

Figure 3.3.6 Smart governance identity roles and key characteristics

The purpose of the smart governance identity is to ensure that the operating and governance models as well as the
decision-making bodies, are reaching the company’s strategic goals. In addition, the roles taking care of end-to-
end service management and sourcing are included in this identity. Ideally the team is built with people who have a
66 thorough understanding of both the business imperatives as well as opportunities provided by the technology.
 3. Strategy and Governance

Organisation
Business technology organisational structure reflects the value creation stream principles set in the operating model
(plan/build/run) as shown in the illustration below:
Corporate Governance

Business Technology Steering Group • Communication and OCM

• HR / Competence Development
Head of Business Technology / CIO • Operating Model and Way of Working
• Security Management
BTGO • Data Protection Management
SOURCING GOVERNANCE • Quality Management

CAPTURE DEMAND BUILD SOLUTION RUN SERVICES

BTMO Service Planning – Service Management – Financial Management – Resource Management – Asset Management

CDO Digital Innovations Digital Development Digital Operations

ENTERPRISE DEMAND ENTERPRISE DEVELOPMENT BTOO ENTERPRISE SERVICES

Enterprise Architecture Development Management BTPO Service Integration

REQUEST

RELEASE
Business Excellence Solution Development Solution Operations
BIOs & SOs
Domain A Solution Area A Service Area A
Domain B Solution Area B BTSO Service Area B
Data Analytics & Integrations BTDO Platform Management End-User Services and Support
Infrastructure Operations

Local IT Management Local Application Development Local Service Operations

Business Technology Standard

[Link]

Figure 3.3.7 Business technology organisation

• The Head of Business Technology represents the business technology function in the corporate governance and
steering bodies
• Governance and sourcing provide control and builds the capabilities (BTGO)
• Service management has an end-to-end responsibility to plan, manage and integrate services (BTMO)
• Product and service development streams have end-to-end responsibility of selected digital products and
services (CDO)
• Business and process development contains handover phases in between demand-to-development and
development-to-services
• Local teams have the autonomy to organize as they like as long as they follow the same value creation
principles.

An alternative way to organise business technology is to have end-to-end responsibility for value streams. In these
cases, value streams are often called tribes according to the agile terminology. In many cases the tribes still utilize the
common infrastructure services such as networks and computing capacity.

67
3. Strategy and Governance

Corporate Governance

Business Technology Steering Group • Communication and OCM

• HR / Competence Development
Head of Business Technology / CIO • Operating Model and Way of Working
• Security Management
BTGO • Data Protection Management
SOURCING GOVERNANCE • Quality Management

CAPTURE DEMAND BUILD SOLUTION RUN SERVICES

CEA BTPO BTOO

ENTERPRISE DEMAND ENTERPRISE DEVELOPMENT ENTERPRISE SERVICES

Enterprise Development Service
Architecture Management Integration

BIO Value Stream / Tribe 1

BIO Value Stream / Tribe 2

BIO Value Stream / Tribe 3

BIO Value Stream / Tribe 4

BTMO Service Management – Financial Management – Resource Management – Asset Management Infrastructure Services BTOO

Figure 3.3.8 Alternative business technology organisation

Business Technology Standard
[Link]

Key Positions
The Chief Information Officer (CIO) is the head of the business technology organisation and has the overall
responsibility for the business value of information technology. The CIO leads the strategic planning and sets targets
and objectives for the business technology organisation.

The Business Technology Governance Officer (BTGO) leads all governance functions and ensures that the
guidance, instructions, and controls are effective.

The Business Technology Management Officer (BTMO) has the end-to-end accountability on service planning,
management and performance and they ensure the business continuity and business value of services together with
service owners.

The Chief Digital Officer (CDO) leads the digital frontline development initiatives and drives and executes the
organisation’s digital agenda together with Innovation and DEV Leads.

The Business Information Officer (BIO) has the end-to-end business benefits accountability and ensures the
business value of the information technology with help of the service owners.

The Business Technology Data Officer (BTDO) builds the data integration and analytics capabilities for the
business and takes care of improving and maintaining the business value of the data.

The Business Technology Portfolio/Programme Officer (BTPO) manages the business and process development
capability and portfolio and leads the Development Management Office (DMO).

The Business Technology Solution Officer (BTSO) has top-down accountability on all solutions and
solution development.
68
 3. Strategy and Governance

The Business Technology Operations Officer (BTOO) ensures the business continuity and delivery performance in
service operations.

3.4 Risks, Quality, Compliance and Ethics

Risks
Business technology management is about constantly balancing the opportunities brought by technological
innovations and dealing with the possible risks when deploying them. When selecting new technology to be
deployed, the choice can prove to be either successful or unsuccessful. Building organisation-specific solutions can
equally turn out to be a bad investment instead of bringing further business benefits. In the run phase, the risks can
concern solutions that are heavily used by the business but have severe security and maintenance issues. The level
and amount of risks the company is willing to accept is ultimately a decision that needs to be made by the business
management.

Organisations have many alternatives to deal with risks. They can mitigate the risk by taking actions that make risk
probability and impact smaller, therefore lowering the overall residual risk to an acceptable level. They can also
decide not to take the risk, accept to live with the risk or even transfer the risk somewhere else. Another good practice
is to calculate the costs of a risk and use the calculation as basis to either reduce an investment’s priority or boost the
implementation of an enhancement.

Business technology risks can be divided into three categories: quality, business continuity and compliance risks.

QUALITY RISK CONTINUITY RISK COMPLIANCE RISK

Non-vital technology usage Security threat Legal non-compliance
Bad implementation Operational failure Commercial non-compliance
Errors in technology Unsupported technology

Figure 3.4.1 Business technology risks Business Technology Standard

[Link]

Quality risks
• Non-vital technology usage: The organisation is dependent on technology that is no longer succeeding
in the market and is in decline. The risk is that an organisation falls behind the competitors in development and
functionality. The Business Technology Management Officer (BTMO) and Chief Enterprise Architect have the
risk governance accountability.
• Bad implementation: The organisation fails in efficiently implementing the technology into business, the
implementation runs heavily over budgets and leaves the business in a difficult situation living between old and
new. The Business Technology Portfolio Officer (BTPO) has the risk governance accountability.

69
3. Strategy and Governance

• Errors in technology: The technology, typically the software, has errors resulting in unwanted behaviour and/
or incorrect data. Errors in technology are costly to detect and correct, but more importantly, they may risk the
organisation’s reputation. Service owners have the risk governance accountability.

Business continuity risks

• Security threat: The organisation’s personnel, network, data, systems and devices are vulnerable to security
threats that may damage or even destroy some valuable assets. It should be noted that approximately 80%
of all security threats can be avoided with employees’ correct actions and only 20% with technology. The Chief
Information Security Officer (CISO) has the risk governance accountability.
• Operational failure: Includes major issues in technology operations that may cause business downtime which
in turn can cause a negative impact on costs, revenue and reputation. The Business Technology Operational
Officer (BTOO) has the risk governance accountability.
• Unsupported technology: Technology which is no longer supported and therefore more likely to have major
issues. Usually the recovery of unsupported technology takes more time than with supported technology. The
Business Technology Management Officer (BTMO) has the risk governance accountability.

Compliance risks
• Legal non-compliance: If the organisation is not compliant with legal and regulatory rules, it takes a major
risk of legal case or costly sanctions. The Sourcing Lead has the risk governance accountability.
• Commercial non-compliance: The organisation must have a licence to use the third party technology. If not,
the organisation is in a commercial non-compliance situation which might have costly effects. The Service
Owners and Sourcing Lead have the risk governance accountability.

Risk management is a wide-spread responsibility, and the Business Technology Governance Officer (BTGO)
should have an overarching accountability to organise adequate risk management control points.

Quality
Quality can be considered as an attempt to minimise waste. Anything exceeding the minimum amount of time,
required material and effort or certain level of costs is basically waste that could be eliminated. Using key suppliers,
empowering staff, having extra capacity and being patient, flexible and comprehensive is a good start for eliminating
the waste.

Quality problems usually stem from systemic faults, not from people or tools. Quality management implies good
communication between the stakeholder and the provider, resulting in delivering the solution that meets the
stakeholder’s expectation. A common way to ensure that the provided services are meeting the quality standard is to
use sanctions in case of deviation. However, positive reinforcement, such as rewarding positive accomplishments have
been proven to work even better.

For information systems and data processing, it is advisable to state and control the principles of business practices,
systems and data processing integrity and protection. Business practice principles describe how products and services
are delivered, and how to respond to claims and complaints. System and data processing integrity principles describe
the controls guaranteeing the correct completion and invoicing of orders. Information and data protection principles
describe controls to ensure that the information and data is available for the intended users and use only and
disposed securely when no longer relevant.
70
 3. Strategy and Governance

Products and services consist of supplier chains that require recurring reviews as agreements, processes and systems.
Formal change control is necessary to understand the impact and avoid waste in the implementation. It tells who
makes the changes, what changes, when, why, and how and where the changes effect and in that way, guides the
design and implementation of resources in the most optimal way.

As quality is about waste minimisation, it is about assessing effectiveness. In systems engineering, effectiveness is
assessed at each phase, from discovering the needs to implementing the system. It should not be a gate at the end of
the line but present at each phase and on everyone’s job description.

Compliance
Compliance refers not only to conformity in fulfilling official requirements, such as being compliant with laws and
regulations, but also to operations and processes to comply with policies, agreements and licence terms.

Regulatory compliance refers to the act of being compliant with a binding ruleset issued by a public or private
authority which also supervises the set rules and can apply sanctions in response to rule violations.

The rules and sanctions can vary a lot by country, location and industry. For example, there are different regulations
for financial, healthcare and manufacturing industry sectors and regulatory structures in one country may be similar
but with different nuances in another country.

As the guidelines can change from year to year, the compliance governance should be an ongoing process.
Larger enterprises usually have their own compliance structures built in their company structure. Small and mid-size
organisations should also establish corporate compliance programmes to help to govern policies and compliance
and to make sure that the company and its employees follow the laws, regulations, standards, and ethical practices
that apply to the organisation.

Commercial compliance is mainly related to licences and is typically carried out by:

• Licence compliance and management, which is an iterative process of maintaining processes and policies
making the assets controllable and manageable
• Clearly defined roles and responsibilities that outline who can authorise the purchase, how the licensing
arrangements are agreed, who carries out the implementation and how these processes are communicated
to the employees or users. If procurement is not centralised and businesses acquire services or solutions
independently, there is always a higher risk of being non-compliant
• Well-maintained documentation in order to efficiently maintain and optimise licences and acquire information
such as: business needs, purchased items, valid entitlements, solutions, services or software in use, lifecycle
data, usage policies, etc.

71
3. Strategy and Governance

Ethics
Ethics in business has become a popular discussion topic lately, especially because artificial intelligence (AI)
and machine learning are quickly becoming an integral part of many innovative solutions. The debate concerns
transparency, accountability and fairness, and how they are calculated and coded in the software and who
eventually makes decisions on how the algorithms operate, considering basic human values.

Responsible development of technology solutions and services requires clear processes and a formal code of ethics
from design to operating the services. In practice, the required transparency and better accountability of automated
tools can be addressed considering at least the following:

• Establishing ethical guidelines, including the principles and ways of handling ethical questions related to the
development of services
• Establishing a role that oversees that the ethical questions are raised and taken care of
• Proactively raising awareness and concerns related to ethical questions, across all businesses and
organisations
• Training stakeholders such as software developers or managers to consider the ethical stand in their respective
organisation
• Identifying possible harm or damage that could be caused by technology innovation and how to remediate its
consequences

Products, solutions, and services contain countless lines of code which make algorithm-based decisions difficult to
trace back. Clear and transparent processes with shared ethical stances promote responsible development of services
and help to reduce the risk of violating human rights or legislation.

3.5 Security and Data Protection

Information security means protecting the confidentiality, integrity and availability of any data that has business value.
The requirements for information security can be legal and regulatory in nature, or contractual, ethical, or related to
other business risks.

As all information progressively turns into digital data, traditional information security converges into cybersecurity.
Modern leadership should see cybersecurity rooted into organisation culture, not merely as a technical insurance
provided by a specialised security team.

Security
The ISO/IEC 27000-series provides best practice recommendations on information security management and ISO/
IEC 27001 outlines an information security management system. The standard comes with over a dozen domains,
amongst which the five main topics below should be considered as minimum.

72
 3. Strategy and Governance

Cybersecurity awareness
Decisions that impact security must be made daily by everyone in the organisation. Awareness of the rules is not
enough. Great decisions only happen when people are empowered, enabled and encouraged by the organisation to
act securely. One way to test the security-awareness of the organisation is to ask questions such as:

• Does the organisation reward secure behaviour and the reporting of risks?
• Are people encouraged to acknowledge mistakes that compromise security?
• Is there a culture of collaboration where business, IT and security, work and solve problems together?

Instead of a separate awareness programme for company policies, involving people in co-creating secure practices
often leads to better results. Incentivising the development of those practices can further promote continual learning
and innovations.

Classification of information and compliance

Classifying information is about identifying information assets that are sensitive to the business, individuals and/or
subjects to legal requirements. This allows an organisation to focus and prioritise security investments.

As information classification must become a routine for the entire organisation, it must be simple and intuitive. In
practice, this means keeping information classes to a minimum (e.g. open, confidential, secret) and binding these
classes to simple rules. Ensuring that appropriate legal and regulatory requirements are reflected in the definitions and
suitable help is provided, supports people in the correct classification. In addition, hands-on group training ensures
that everyone is motivated and able to classify information relevant to their roles.

Security in development and project management

Ensure all projects start with an early risk assessment and defined objectives. Regular reviews against the objectives
throughout the project minimises surprises and rework. Projects should be supported by guidance for secure
development of software and systems covering the entire project and development lifecycle.

Audit trails and change control processes are crucial for easy roll-backs if the changes fail. However, as these
processes must still enable agile and lean teamwork, co-creating these practices ensures motivation to follow them.
Effective change control is paramount to keeping the business running.

Digital and physical access rights

Digital and physical security requires verifying authorised access and denying unauthorised access. It is important
to ensure that access management, both digital and physical, is aligned with information classification and legal
requirements, as well as in alignment with each other. For example: it makes little sense to limit access to highly
confidential data systems, if the team that processes data work in an open office space accessible to anyone. Practical
guidance for designing access management can be found in ITIL and the OWASP Access Control Cheat Sheet.

73
3. Strategy and Governance

In a culture of collaboration, it is also worth considering what is the value of transparency and approach these
definitions by comparing the value of sharing against the risk of broader access.

Addressing security within supplier agreements

Developing innovative, scalable and user-friendly services typically means working with partners. In today’s world,
organisations share data and parts of their business with third parties ranging from cloud and IT suppliers, advisors,
sponsors, competitors to start-ups. Maintaining trust and ensuring business continuity, means also ensuring that the
partners also share the same security principles.

Done right and being diligent with the third parties is not only a mandatory compliance exercise, but a mechanism for
taking controlled risks that can lead to a faster go-to-market with a new service partner.

Data protection
The purpose of data protection (also known as information privacy and data privacy) is to define when and on what
conditions personal data can be processed. All data related to an identified or identifiable natural person (the data
subject) is personal data.

A controller is a person, company, authority or community that defines the purposes and methods of processing
personal data whereas a processor is a third-party processing personal data on behalf of a controller.

Data protection regulations have existed a relatively long time (e.g. the EU Directive 95/46/EC from October 1995)
and more attention was raised by the new EU Regulation (2016/679, also known as EU GDPR or EU General Data
Protection Regulation) that became binding in all EU member states on 25 May 2018.

Characteristics of the EU GDPR

The core document of the regulation is long (99 articles) and depending on the nature of the business and how much it
is related to processing personal data, there is potentially a lot of need for guidance and interpretation to fully comply
with it.

The main reason why the EU regulation has gained so much attention is the enforcement that enables the Data
Protection Authorities (DPA) to impose fines to businesses up to 20 million EUR or 4% of a company’s worldwide
turnover. In practice, the maximum fine is on a level that both imposes a huge risk for the whole business and justifies
any investment needed to comply with the regulation.

Data protection roles

Whether to appoint a Data Protection Officer (DPO) or not depends on what kind of personal data the company
is controlling and/or processing and on what scale. If the processing of personal data is not a core part of the
company’s business, and its activity is not on a large scale, there is usually no need to designate a Data Protection
Officer. Even when a DPO might be needed, it is a role that an existing employee can take. Or, it can also be
obtained from a provider as a service.

74
 3. Strategy and Governance

Regardless of having the role of DPO manned or not, if there is a data breach where personal data (that the company
is responsible for) is disclosed to unauthorised recipients or altered so that it poses a risk to individual rights and
freedoms, the company needs to provide a proper notification to its DPA within 72 hours after becoming aware of
the breach. To be able to react to a data breach or to any potential processes or technology related threats related to
personal data, the organisation must have a nominated person to take the responsibility when needed.

Lean approach to data protection

Taking data protection into account at an early stage when designing a new process, new products or services or
a new information system that is related to processing personal data is a good way of considering data protection
requirements in a lean way. The same applies to tendering or any other sourcing process going on and ensures that
the (potential) supplier and the contract are compliant with the EU GDPR. This approach is called data protection by
design.

Data protection by default is about ensuring that all processing related to personal data is limited to a minimum set
of data subjects (for example specifying every time what data records needs to be listed), access to the data is limited
to a minimum number of people (for example the key user needs to grant access separately for every user) and the
data storage time is limited to a minimum.

Benefits from implementing data protection

The companies operating in the EU benefit from implementing the data protection by default as it is cheaper and
easier for companies to do business in the EU area when the rules regarding data protection are the same.
The companies based outside of the EU must also apply the same rules when offering products and services to
individuals in the EU. GDPR is also technology neutral and applies to personal data processing the same way
regardless of whether the processing is done manually or automated.

When optimising the business processes and information systems related to handling personal data, the processes can
be streamlined to be more efficient and the requirement for systems and storage can be minimised to decrease costs.
At the same time, the related data can be consolidated so that it is easier to utilise for the business or even create new
services based on that information.

It is also possible to get competitive advantage from handling the personal data in a trustworthy and reliable manner
and providing enough transparency to the customers to gain more trust than company’s competitors.
 

75
 Sourcing and
Optimisation
Discipline

76
 4. Sourcing and Optimisation

4.0 Introduction to Sourcing and

Optimisation Discipline
Sourcing and optimisation is an end-to-end discipline that manages the whole lifecycle of business services and
vendor relations. It implements the strategy and the operating model by engaging vendors, contracts and resources to
deliver high quality products, solutions and services at appropriate cost levels.

DEMAND | PLAN DEVELOPMENT | BUILD SERVICES | RUN

Demand Development Service
Portfolio Portfolio Portfolio
Steering Steering Steering

OUTCOME-to-INSIGHTS
ECOSYSTEM PROCESS PEOPLE TECHNOLOGY DATA COST
SOURCING AND
OPTIMISATION SERVICE PLANNING

Supplier
Ecosystem Commercial and Sourcing, Relationship Financial Planning Resource
Development Property Rights Purchasing and Performance and Control and Asset
and Contracts Management Management

PLANS-to-CAPABILITY

HIGH SATISFACTION HIGH PRODUCTIVITY RIGHT COST HIGH QUALITY

World class ecosystems Co-operative planning Operational governance

to ensure fit for the future to ensure business fit to ensure process fit

SERVICE EXCELLENCE

Business Technology Standard

[Link]

Figure 4.0.1 Sourcing and optimisation discipline

Sourcing and optimisation has two purposes: to be creative and to optimise.

• The creativity purpose is about establishing, building and developing innovative ecosystems. Traditional
sourcing focuses on acquiring something well-defined with the lowest possible cost and without compromising
the quality. The creative sourcing approach focuses on building an innovative ecosystem to sell a vision of joint
business opportunities. Ecosystem partners invest their time and money to realise the vision and expect that the
benefits will be shared equally.
• The optimisation purpose means keeping the number of vendors, contract and terms variations at the correct
level. The use of internal and external persons and assets and the related fees should be optimal. Service level
and vendor management is required to keep the sense of urgency for continual improvement and cost
efficiency. Cost transparency and financial control, in best case real-time, is essential to analyse trends, cost
levels and deviations.

77
4. Sourcing and Optimisation

CREATE OPTIMISE

New ideas and technologies Service level management

Development roadmaps Financial control

Partner ecosystem Continual improvement

Figure 4.0.2 Create and optimise

Business Technology Standard
[Link]

Digitalisation requirements for speed and agility

Digitalisation challenges sourcing and optimisation with requirements for speed and agility. Making an agreement for
digital frontline application development should not take the same amount of time as the actual development process.
In addition, if all the ideas are shared before anything has been agreed on paper, agreeing the Intellectual Property
Rights (IPR) and commercial rights is already too late. Digitalisation requires incremental sourcing approach which
means agreeing the IPRs and commercial models at the very beginning with memorandum-of-understanding type of a
document and signing the agreements for development and services later on depending on the progress.

Optimising costs, resources and assets is also challenged by digitalisation. The tendency is to consume the services
rather than purchase a flat rate which may require real-time optimisation. For example, computing capacity from
a cloud can be optimised per hour, per week, per month or per year, depending on the procurement intensity.
Therefore, the purchasing becomes more automated: when someone orders something, they go to a self-service portal
to order it, gets it automatically and is charged only for the time the application or service in is use.

The use of external resources is a different story as the use of time is more difficult to optimise. The tendency is to source
operational teams instead of individual people. A team with well-defined roles, practices and tools is much more
productive than setting up a team consisting of individuals. In other words, there is a need to compare options for cost
and quality. Digitalisation emphasises quality and close cooperation to achieve speed and agility, challenging the
off-shoring and near-shoring cost focus.
78
 4. Sourcing and Optimisation

4.1 Commercial and Property Rights

In a modern world, technology is business and business is technology and therefore the ownership of technology and
data related intellectual property rights and commercial rights are a valuable business asset.

The question of who owns which part of the invention can today be blurry because digitalisation brings in new
components on top of existing business, solutions and data. Therefore, agreeing the rights and commercial models
clearly from the beginning of the innovation process with memorandum-of-understanding type of a document is
important as it protects the organisation’s property and commercial rights.

Intellectual property rights (IPR)

Intellectual property (IP) primarily encompasses copyrights, patents, trademarks and trade secrets. Traditionally
it is considered to be intangible creations of the human intellect, but it also includes what is created by artificial
intelligence. From the business technology function point of view this means that software, configurations, processes,
ways of working, patents, algorithms, data, etc. are all considered as IP. To which extent the data is considered an IP
can vary between different legal systems but can be considered under IP in the context of the Business Technology
Standard.

For a technology company, the value of intellectual properties is in general far greater than the value of the tangible
properties which should be clearly understood especially by people working in close cooperation with suppliers.

A typical general understanding is that unless anything else is specified, the IP is owned by the party who invents it.
However, this understanding nowadays is often false, as the ownership rights to the IP in the intangible world are case
specific and almost always defined differently in the agreement. One example is a professional services agreement
where, instead of the inventing party, the buyer usually gets the IP for the work. In all cases it is important to agree on
the intellectual property rights, as it is a common situation that a (potential) supplier and buyer are having discussions
and the work consists of innovating something. Even if the innovation does not lead to anything concrete, the
ownership rights are clear and protected by agreements for each party leading to the situation, where any possible
conflicts of the future using that IP are minimised.

A company can either own the IP or acquire a right to use the IP via an agreement. The agreement outlines how the
IP can be used. For example, a software licence agreement usually states that the software can be used for only a
customer’s internal purposes or can be used as an integral part of the customer service or product with third party
users. A professional service agreement can similarly state if the buyer is allowed to resell the result of the work. In
addition to the different agreements, IP and data rights are also regulated by laws.

It is important to fully understand and keep track of the solution and/or service terms and conditions over its entire
lifecycle. If the use of a solution that was originally intended for purely internal purpose, is changed so that it can be
accessed by a third party, depending on the terms and conditions, it might imply a complete change to what was
originally the agreed use of the solution and therefore the solution and/or service terms and conditions need to be
reassessed between the buyer and licence provider.

79
4. Sourcing and Optimisation

IP sharing policy
Since the rights to use an IP determines how the IP in a solution can be used, it also has a significant impact on the
price. Therefore, getting the correct usage rights is essential. When acquiring IP, getting more rights than needed
usually increases the price while having less rights will limit the opportunity to utilise the full benefit of that IP. In the
same way, the IP owned by the company may have an impact on the business value so giving out or keeping the IP
rights can either reduce or increase market value.

A company needs to have a policy regarding IPs: how they should be protected and to what extent they can be
shared. This should be included on a high level in the business strategy in conjunction with business planning. The IP
strategy for a specific product, if applicable, should be part of the service planning. Some IPs are a core asset of the
company and some are not, and could advantageously be shared to gain some other benefits such as:

• Lower licence fees: Granting service provider IP rights and asking for low licence or service price is a common
practice
• Better agreements: Sharing IP can enable more favourable other agreement terms
• Better services: If data or software is shared, the company is contributing to make the solution better, e.g. an
Artificial Intelligence (AI) solution learning from several companies’ data will learn faster than solutions
deployed uniquely for one company.

Commercial models
A commercial contract outlines how the business between two companies shall take place. The contract defines the
commercial model between the companies. The commercial model will have a significant impact on how the business
is done. On a high level, commercial models can be categorised as:

• Transactional where the charging model is based on transactions, which could be a computing capacity,
a software licence or an hour of consulting work. This business model is in general, easy to handle but does
not necessarily bring the buyer and seller close together as they have different objectives. With transactional
agreements, the buyer often has the interest in minimising the number of transactions while the seller wants to
maximise them in order to maximise the revenue
• Scope of work where the charging model is based on defining the deliverables or the business outcome. The
deliverables can be a development project where the code must be delivered according to the specifications
or support services delivered according to a service level agreement. These types of models are more complex
as the deliverables need to be clearly defined, but also enables the buyer to transfer more risk to the supplier.
The supplier on the other hand, can use its expertise to deliver the service in the best possible way
• Benefit sharing where the charging model is based on sharing costs and benefits. The most common is
various types of value sharing, such as a cost reduction initiative. In some cases, the benefit and cost sharing
are implemented by establishing a joint venture. This type of commercial model brings the supplier and buyer
close together as they tend to share the same objectives. The benefits need to be able to be measured and
controlled in an unambiguous and objective way.

80
 4. Sourcing and Optimisation

However, to remain competitive and enable fast development of new services, new types of commercial models can
be considered such as:

• Using data as instalments where the buyer pays only part of the fee but gives the supplier the rights to use
the produced data for other purposes. This is a common model used in AI or Big Data related
development cases where the seller agrees to sell the actual software at a lower price but gets to use the
buyer’s data for AI learning purposes or Big Data for further business use
• Using data as payment where the buyer is not paying anything but provides the data for free for any third
party to develop apps or solutions with it. This type of commercial model is a good way to provide public
services without extra costs for the public sector.

There might not always be a clear distinction between the used models and often the selected model can be
a combination of the different models. However, the sourcing function is responsible to ensure that the wanted
commercial model is agreed and that there are no unnecessary lock-ups with any of the vendors.

4.2 Sourcing, Purchasing and Contracts

The primary objective of sourcing is excellent business and user satisfaction, combined with a low total cost of
ownership. To succeed in attaining these goals, sourcing must achieve, maintain and utilise a strong negotiating
position towards the suppliers.

Sourcing and purchasing are traditionally quite challenging functions as the tasks they both take care of conflict:

• Be flexible enough to accommodate large sourcing projects that require comprehensive sourcing processes
and fast procurement sprints that are needed for agile development initiatives
• Be strong enough to enforce company policies and regulations (security, architecture, legal, etc.) throughout
the vendor network, while at the same time listening and learning what new vendors have to offer
• Manage the supplier ecosystem and contracts lifecycle to implement necessary controls and additionally,
sponsor creative cooperation and new innovations.

Sourcing and purchasing must evolve to manage all of the above considerations, as well as providing:

• A sourcing strategy to indicate the right sourcing approach and preferred partners for value streams and
service domains. In the case of developing a new product, solution or service, there might be a need to go
to the market and use sourcing team’s expertise. On the other hand, using existing vendors for smaller
improvements and changes, a direct purchase process can be used instead
• A sourcing process that will support development initiatives by requesting and contracting products, solutions
or services from the market with the best possible business, at the reasonable price and within the expected
timeline
• A purchase-to-pay process enabling to order, contract and deliver quick and efficient services from existing
vendors within the existing frame agreement, enabling speed and agility in incremental development initiatives

81
4. Sourcing and Optimisation

• A holistic vendor and contract management capability that implements the sourcing strategy and enables
direct purchasing. By monitoring existing contracts, preparing contract renewals and providing analytics on
costs and service quality, the company sourcing position is constantly updated.

Sourcing strategy
Sourcing strategy describes service and vendor categories and lists the preferred vendors. It also sets objectives for
creative ecosystems, consolidation of synergies and mitigation of vendor lock-in situations.

The key objectives of the sourcing strategy are to:

• Identify service categories and define the primary service strategy to provide services internally, source from
only one vendor (single source), or to source from multiple vendors
• Build innovative and competitive ecosystems to create business value
• Maintain a good negotiation position by avoiding vendor lock-in situations and having alternative sourcing
options
• Introduce cost targets and key commercial terms for agreements and related implementation plans.

When setting the sourcing strategy, it is essential to consider:

• Business drivers to define what the company wants to achieve: such as low cost, fast time to market,
exclusivity and innovations. By defining some high-level guiding principles, the priorities can be understood
and agreed
• Market dynamics to define how many suppliers are available, why the suppliers want to engage, if there are
any regulatory issues and what the rising and declining ecosystems are.

GOVERNANCE MODEL SUPPLIER ECOSYSTEM SUPPLIER CATEGORISATION

PRIMARY
STAKEHOLDER
INVOLVEMENT BUSINESS Consolidate, transform and
ALIGNMENT create business value
• Business
• Finance
• Legal
• HR
SERVICE COMPLEMENTARY
PLANNING
BUSINESS END USER INFRA- Selected solution provider
SOLUTIONS SOLUTIONS STRUCTURE
SERVICES

SERVICE UTILITY
OPERATIONS Commodity services

Business Technology Standard

Figure 4.2.1 The ecosystem [Link]

82
 4. Sourcing and Optimisation

Sequential RFP sourcing process

The starting point of the sourcing process is a business need originating from strategic planning, business capability
planning, service planning or concept design. When evaluating the feasibility of the sourcing request, one must
consider the alternatives between extending the relationship with the existing service provider(s) or to initiate a
Request for Proposal (RFP) process with a larger list of service provider candidates. In the public sector, the latter
alternative is often the only choice available to treat all potential service providers equally even if extending the
existing frame agreement provides shortest time to market, higher business value and cost synergies.

Traditionally, companies use a toll-gate sourcing process to deliver an RFP process. This is a comprehensive process
that involves multiple suppliers and the result usually gives the best commercial terms. These processes can take quite
some time and usually fit well when going in parallel with other planning and preparation activities.

REQUEST FOR SUPPLIER

VISION CONCEPT PROPOSAL (RFP) QUALIFICATION DECISION CONTRACT

Why do What is the Comments to Business Define down- Iterative Select the Negotiate
we initiate business solution the RFP docs acceptance selection sessions supplier with the
a tendering we look for? and supplier for the RFP criteria with max 3 selected
process? candidates candidates supplier

0 w1–2 w2–5 w5–7 w8 w9–12 w12–16 w17 w18–20

RFP out RFP out
Kick-off Supplier Supplier Supplier
info session info session selection

RFP DOCUMENT PREPARATION

DIALOGUE WITH SUPPLIER CANDIDATES

Business Technology Standard

Figure 4.2.2 Sequential RFP process [Link]

In some cases, a certain service provider could provide a shortcut to higher business benefits and therefore, a single
source initiative might be a good alternative. Single sourcing is similar to the RFP process but with a single candidate
only. Single sourcing requires clearly predefined business targets and if not met, the opportunity will be opened for
other candidates as well through a normal RFP process. Successfully implemented single sourcing can save costs
and maximise business benefits. It is applied typically in diligent cases requiring high confidentiality. Single sourcing
should still fulfil all documentation or process requirements to ensure complete transparency and traceability.

Incremental sourcing process

Digitalisation sets another requirement for sourcing: learn fast and scale fast, which means in practice that there
is no time nor reason for a time-consuming RFP process. Usually the process starts by having some ideation and
prototyping sessions with your ecosystem partners ending up with something that cannot be defined properly
beforehand and which requires specific ecosystem parties to be involved. In these cases, the sourcing parameters are
almost opposite compared to parameters in a traditional RFP process. The incremental sourcing process allows a way
to proceed with the sourcing process without compromising an innovative approach to development

83
4. Sourcing and Optimisation

Incremental sourcing process consists of following steps:

• Signing a trial agreement/LOI (Letter of Intent) to agree commercial frame, business model and
Intellectual Property Rights (IPR). A more comprehensive set of standard terms and conditions are typically
attached as an appendix to simplify the future negotiations
• Executing a trial where the idea, concept and solution is tested and verified to secure that both meet the
business and technical requirements. Preferably some real user testing with Minimum Viable Product (MVP) will
also be done under trial
• Negotiating and signing a full commercial agreement in parallel or subsequent to the trial.

However, it is worth noting that the commercial terms in the incremental sourcing process can be less
favourable than in a full sourcing process. In addition, incremental sourcing should not compromise proper
documentation. For example, requirement handling or awarding a supplier without proper evaluation that can
be audited.

Purchase-to-pay process
Purchase-to-pay or operational procurement is generally understood as part of sourcing that involves the actual
buying of products and services. In simplified terms, a purchase is as simple as a work order within an already agreed
commercial framework. Procurement and contract management usually ensures that the commercial framework relates
to the price and scope and the possible sanctions in case the agreed terms are not fulfilled.

All purchases made under the framework agreement are managed by individual contracts (e.g. work order or
purchase orders). Monitoring and control of the agreements are essential for two purposes:

• Securing the suppliers adherence to the contract as the monitoring covers the volume, price changes and
quality control
• Securing internal control that only authorised purchases go through, ensuring that this process and the
purchases are in line with the sourcing strategy and budgets. It also ensures that costs are allocated
properly internally.

In many cases, the procurement and contract management work with Managed Service Providers (MSP) who operate
as a broker with standardised contracts end terms.

A modern procurement and contract management capability is as automated as possible (e.g. systems integration) in
order to:

• Speed up the purchasing process

• Allow spotting deviations in data
• Use advanced data analytics
• Follow price development
• Observe how suppliers from two different framework agreements are performing compared to each other.

84
 4. Sourcing and Optimisation

Vendor and contract management

Service management together with sourcing are responsible for developing and managing successful vendor
relationships by adopting a clearly defined and structured governance model with regular meetings. On top of
the existing services, the governance model also addresses the emerging opportunities brought forth by service
development and potential new solutions.

Sourcing maintains a list of the company’s vendors and identifies the key vendors amongst them. Categorisation of
vendors is essential to manage them all in a holistic manner. Vendors can be categorised based on their criticality or
classified based on the individual vendor’s impact and value to the business, e.g. primary, complementary, or utility
vendors.

The classification can be used further to form a proper governance model for the vendors. The classification also gives
guidance on how to set up an adequate level of collaboration and performance management for each vendor. This
limits the time and effort used in vendor meetings and enables focusing on the vendor relationships producing the
most value. A good practice to engage vendors and vendor candidates in a meaningful dialogue is to host an annual
or biannual vendor interaction session, where business technology management and vendor ecosystem share future
outlook and development roadmaps and identify opportunities for alignment, additional business value and joint
development initiatives.

Sourcing also maintains a contract repository containing all contracts including electronic versions with attachments as
well as location references for the originals. A good practice is to write a contract summary document containing key
information of the contract. Such key information also includes deviations to standard terms and conditions, validity
period, contact persons and contract value.

Sourcing is responsible for the timely initiation and execution of contract revisions. It informs the service managers and
service portfolio steering about expir¬ing contracts. These, in turn, may authorise sourcing to renew contracts and/
or initiate tendering. Service management ensures that vendor cooperation runs according to the agreed governance
model on strategic, tactical and operational levels. Vendor management should focus on strategic and tactical levels
and reduce the need for operational management by using IT Service Management Systems with real-time service
information.

Apart from the sourcing lead, vendor management roles mostly belong to development and services disciplines
depending on the phase and scope of the vendor cooperation. For example, a service manager responsible for the
most critical service provider will also own the service contract and the vendor relationship as well as taking care of
the cooperation on the tactical level.

4.3 Supplier Relationship and

Performance Management
Service management, together with sourcing, is responsible for developing and managing successful supplier
relationships by adopting a clearly defined and structured approach to supplier collaboration.

85
4. Sourcing and Optimisation

Service managers maintain supplier rela¬tionships through regular meetings that address not only current services
development plans, performance and costs, but also opportunities to expand the relationship to different or new
services, driven by the company’s ambition to create innovative digital services.

Supplier relationship and performance management aims to build a healthy supplier ecosystem able to answer
the immediate needs from a company. A good supplier ecosystem will also be able to support the company’s
future business strategy by offering aligned innovative services or proposing proactive innovation or optimisation
opportunities to the company.

MARKET

ND NE W
NS A SO
TIO LU
VA TI
O
O
N

N
IN

S
DELIVERY ECOSYSTEM

Relationship Supplier
Management Categorization

Performance Contract Lifecycle

Management Management

SUPPLIER RELATIONSHIP AND PERFORMANCE MANAGEMENT

Figure 4.3.1 Supplier relationship and performance

Businessmanagement
Technology Standard overview
[Link]

Supplier relationship and performance management capability typically includes the following set of activities:

• Relationship management: Engaging leadership levels to get priority and commitment to required resources
to achieve the service objectives
• Supplier categorisation: Organising suppliers into categories to facilitate relationships, spend and risk
management as well as strengthening the collaboration with the suppliers
• Performance management: Defining business or service performance targets and including them in the
contracts. Implementing means to measure the supplier performance technically or based on feedback and
perform regular review of the supplier Service Level Agreements (SLA) based on service performance or Key
Performance Indicators (KPI) based on the market benchmarks
• Market watch and innovation: Understand through discussion with existing suppliers and by interacting

86
 4. Sourcing and Optimisation

with the market what are the latest technology evolutions and solutions, and what are the opportunities to
create business value and value to customer using technology
• Contract lifecycle management: Managing operationally the supplier contracts through their lifecycle
(creation, amendments, renewal, termination) and generate analytics to provide insights to the company
sourcing strategy.

Supplier relationship management

STRATEGIC

TACTICAL

OPERATIONAL

Possibility to reduce
operative meetings due to
service management system
Figure 4.3.2 From traditional pyramid structure to modern diamond model
Business Technology Standard
[Link]

Supplier relationship management aims to maintain a good relationship between the company and its suppliers. The
objective is to build an ecosystem of collaborative partners, and work closely with them to build future service plans
that benefit both the company and the suppliers.

A good approach to maintaining relationships with suppliers and ensuring that employees interact with relevant
stakeholders from the supplier’s side, is to organise the relationship management in three layers:

• Operational: to review service performance over a period (monthly or quarterly), address process issues,
financials and SLA deviations and related root causes
• Tactical: to discuss and review development plans for the coming three to six months including major service
and quality improvements as well as the potential amendments and changes to the service scope
• Strategic: to set and review (annually or semi-annually) future goals that benefit both the company and the
supplier (e.g. development of a new innovative service) and make decision on contract extensions.

87
4. Sourcing and Optimisation

The focus is typically on strategic and tactical levels whereas the time used for operative management can be reduced
by using IT Service Management (ITSM) systems with real-time service information.

Supplier categorisation
The goal in supplier relationship is to build collaborative relationships with the suppliers and maintain a list of the
company’s technology related suppliers and categorise them.
Categorisation helps the company to:

• Identify high-risk suppliers and prepare remediation plans

• Analyse spend per categories and spot savings opportunities
• Manage supplier relationships better by carefully allocating the sourcing team’s effort
• Source faster a new service a solution from an existing supplier.

Categorisation can have multiple dimensions, amongst which the most commons are:

• Service categorisation: What type of services does the vendor provide (e.g. software, network, consulting,
end-user services, etc). Service categorisation and related sourcing is managed by category managers
• Business criticality: How dependent the business is on the sourced services? How important is the is to ensure
the business continuity? These are key questions to service managers and OPS leads
• Risk classification: What kind of risks are inherent with the supplier (e.g. organisational, financial, regulatory,
reputational, etc) and what are remediation plans do we have? These are key questions to sourcing
• Spend categorisation: What is the annual spend committed with each supplier? This is a key question to
financial management and control as well as for service management.

Based on above classification, the company decides whether the nature of a supplier relationship is critical, strategic,
tactical or operative. Additionally, based on the individual supplier’s impact and value to the business, an adequate
level of collaboration and performance management should be determined for each supplier.

The Business Technology Standard advocates a slightly different approach to classification by providing a perspective
to use technology services to create business value. It distinguishes primary vendors that are key value drivers
in digital, technology or business transformation, complementary vendors that provide key business-related
solutions and services and utility vendors that empowers the company with commodity services (e.g. network or
workstations).

Performance management
Performance management has an essential role in setting targets and controlling the supplier performance. It creates a
quantitative scale for measuring and verifying contractually agreed and targeted performance of the suppliers.

Performance management starts before any supplier relationship, as business performance targets must be decided
before a service is implemented, or a solution purchased. Performance management then becomes an essential
component of the supplier relationship, from the contracting phase until the purchased service’s operational delivery.

88
 4. Sourcing and Optimisation

SET BUSINESS IMPLEMENT MEANS REVIEW SLAs AND

Sourcing ENGAGE ON PERFORMANCE
PERFORMANCE DEFINE KPIs activity TO MEASURE GOVERNANCE
CONTRACTUAL SLAs MONITORING
TARGETS AND ACT ON KPIs PROCESS

Determine accurate and Define Key Performance Formulate Service Level Ensure that SLAs and Collect, analyse and register Regularly (e.g. annually)
unambiguous performance Indicators (KPIs) to verify Agreements (SLAs) for metrics are measured with realised metrics. Review review SLAs with the supplier,
targets based on business performance measurement. contracts according to service management tools. performance metrics with the compare with the market
needs before making performance measurement Setup triggers to alert on suppliers and act accordingly benchmarks, and decide if
sourcing decisions. targets and relevant metrics. deviations. based on governance process. SLAs have to be modified.
Governance process can also
be amended.

THROUGH ACTIVE SUPPLIER RELATIONSHIP

Before any sourcing activity takes place

Business Technology Standard

[Link]
Figure 4.3.3 Performance management steps

The performance levels in operations are measured by determining accurate and unambiguous Service Level
Agreements (SLAs). Measurement needs are established with the business considering the business continuity
requirements and the corresponding cost impacts.

It is important to carefully consider target metrics because they will steer the suppliers’ performance in practice, in the
spirit of: “You will get what you measure”. Well-defined metrics can form the measurable ground for penalties in the
contract.

In many cases, vendors commit on key performance indicators (KPIs) which are more meaningful for the business and
often requires co-operation between service providers, such as end-to-end software availability which is dependent
on software, infrastructure and network.

Additionally, service managers, together with sourcing, should keep track on available services, quality standards and
service pricing on the marketplace to enable comparison and fair benchmarking of sourced services. Furthermore,
it is justified in outsourcing contracts to reserve rights to carry out audit of suppliers’ service processes to control their
quality and performance.

Market watch and innovation

Category management and performance reviews focus on viewing vendors from the inside-out. An outside-in
perspective is needed to follow the technology trends in the marketplace. This activity can take place as dedicated
initiatives on specific technologies or through continuous discussion with technology and services providers in order to
better understand their offering.

The key objective is to support service development activities by promoting new technology opportunities, and by
ensuring that there are no contractual issues prohibiting the development. This activity is also the demand discipline’s
responsibility area.

Another way to ensure the sourced service follow the market trends is to compare current suppliers’ operational
performance and cost in relation to their competitors (e.g. benchmark) to evaluate if there is need to review the
contracts, to help to decide on a contract renewal or termination.

89
4. Sourcing and Optimisation

Contract lifecycle management

The contract lifecycle management is a proactive process that can lead to significant cost savings and service quality
improvements.

Contract lifecycle management objectives are to:

• Create contract templates to support any sourcing activities (often requires a legal expert)
• Assist in creation and signing of new contracts including negotiation with the vendor on terms and conditions
(often requires a sourcing expert)
• Manage signatures of relevant stakeholders in the company, store and manage access to digital copies
of the contracts within the company and ensure that contracts are correctly implemented in financials systems
(purchasing, financial forecast, etc.)
• Manage contract evolutions (often done by contract and service managers)
• Prepare in advance contract renewals with relevant stakeholders
• Provide financial and performance analytics on contracts (e.g. actual spent vs contracted) identify and suggest
any savings opportunities (often done by service integration).

It is a good practice to have named contract owners for contracts that have large service coverage and the ownership
is not obvious. The contract owner works closely with financial management, service managers and sourcing.

4.4 Financial Planning and Control

Effective management of business technology requires proactive and analytical financial steering to justify operational
performance, investment feasibility and allocation of costs. Management, along with decision making, is dependent
on transparency with clear structures and processes surrounding financial management.

FINANCE VIEW BUSINESS VIEW

A list of services provided
Service to end users / business units.
Spend

FINANCE VIEW
BUSINESS VIEW
Detailed cost of developing
Service and running services.
Catalogue

Solutions,
Application, SERVICE VIEW
CMDB
Descriptions on how the services
are developed and supported.
SERVICE VIEW

Figure 4.4.1 Financial management

Businessviews
Technology Standard
[Link]
90
 4. Sourcing and Optimisation

Financial transparency and planning

Financial transparency shows how accumulated costs are transferred to service consuming fees and how actuals
correlate to plans. Financial planning ensures:

• Reserving future cash flow to business technology elements (budgeting)

• Measuring the actual spend by business technology elements and comparing actuals to planned costs to
identify deviations and suggest corrective actions (controlling)
• Allocation of business technology costs to business units and -capabilities as service fees (invoicing)

Cost transparency is not easy to achieve. Spends accumulate on general ledger level while budgeting is done on
business technology element level and business is invoiced on a higher business technology services level. The best
practices to tackle cost transparency are using a standardised taxonomy and grouping costs to pre-defined cost
groups and services. As well as utilising a rule-based cost modelling system to automate calculations.

Technology Business Management (TBM) taxonomy defines standard cost sources, technologies, resources, services
and capabilities to provide leaders with the facts they need to communicate the value of technology and make fact-
based decisions. Standardised taxonomy also enables effective collaboration and communication between business
management, business technology management and service development and delivery management. A simplified
view of the taxonomy is illustrated below.

BUSINESS UNITS (CONSUMING) BUSINESS CAPABILITIES (ENABLING)

Business View
Business Unit Business Unit Business Unit Business Capability Business Capability Business Capability

SERVICES

End User Services Business Application Services

Delivery Services Platform Services Infrastructure Services Emerging

Service View
SERVICE TOWERS

End User Application Delivery Security and Compliance Management

Data Centre Network Compute Storage Platform Output

Finance View
COST POOLS
Internal External Outside Facilities Internal
Hardware Software Telecom Other
Labour Labour Services and Power Services

Business Technology Standard

Figure 4.4.2 Technology Business [Link]
(TBM) taxonomy

Financial feasibility
Financial feasibility provides feasibility analysis about proposed, on-going and completed development initiatives
and feasibility of on-going services throughout their lifecycle by assessing:
91
4. Sourcing and Optimisation

• Financial feasibility of proposed development initiatives with the demand and development portfolio
steering. Analysis is based on a business case with payback and/or net present value calculation
(Pre-feasibility)
• Financial feasibility of an on-going development initiative with the project steering. Analysis will help to
make go/no-go decisions to identify initiatives that should not be continued even with high sunk costs
• Financial feasibility of completed initiative by measuring the realised costs and business benefits and
comparing them to the previously approved business case. The analysis is important for lessons learned
purposes (Post-feasibility)

Financial steering
Financial steering contributes to strategic planning and service portfolio steering by providing insights about optimal
allocation of financial resources. It provides insights on:

• Cost levels by making benchmarking total cost levels and more specific service cost levels with similar
organisations. Benchmarking justifies cost saving initiatives or additional investments (Benchmarking)
• Right balance between build and run as well as between investments (capex) and operational costs
(opex). These ratios are highly dependent on current business status, but usually organisations aim at saving
operational costs and investing more on development (Build/run ratio)
• Right allocation of money to different value streams. The value stream ranking high in created or expected
business value should get more money and vice versa. Value streams and their investment profile is a key topic
in strategic planning. Money allocation creates demand while cost allocation is result of supply (Demand-
supply balance)
• Business value of the on-going services to justify further investment or service retirement. Traditional
business case calculation is not adequate as it is targeted for investment calculation, while the on-going
business value calculation is based on current asset value of the business technology.

Financial management should not be seen only as a function operated by finance. To be effective, it requires
contributions and collaboration from multiple business functions, including business technology, and is enabled by
using standardised models, terminology and ways of working. Transparency, accurate planning and treating financial
management as a strategic capability allows businesses to create and demonstrate the value of technology.

4.5 Resource and Asset Management

Business technology operations require financial and human resources as well as software, hardware and data assets.
The use of financial resources has been defined in chapter 4.4 Financial planning and control and this chapter focuses
on human resources and assets, which consume approximately 20-40% of the total costs of business technology.
The rest is spent on services and tendency is to purchase resources (work) and assets (hardware and software) more
as a service rather than individually or separately.

92
 4. Sourcing and Optimisation

Resource and asset management has four major activity topics: forecast the demand, build the capacity, fulfil the
demand and optimise.

Forecast the demand

• Make on inventory of current utilisation of resources and assets
• Forecast the demand by estimating the changes (delta) to the current use of resources and assets.

Build the capacity

• Prepare commercial and capacity readiness to acquire the required resources and assets
• Organise an efficient onboarding process to ensure compliance with policies, instructions and practices
• Predefine the standard / normal resources and assets available for the order.

Fulfil the demand

• Implement an order process to manage and authorise resource and asset requests
• Purchase resources and assets on demand and allocate related costs to the requestor
• Ensure proper and efficient use of resources and assets
• Collect feedback and quality information and submit changes if necessary
• Free capacity of unused resources and assets and secure knowledge transfer.

Optimise
• Make a gap analysis against demand and strategy regularly to find resources and assets with low usage or
low business value
• Consolidate resource and asset acquisition under major frame agreements with volume benefits and
joint values
• Communicate resource and assets needs and coach suppliers to be prepared with the changing needs
• Minimise the need to report daily on-going matters.

Resource management
The Business Technology Standard recommends that standard and normal resources and assets are predefined and
made available in an order catalogue.

Standard resource or asset request does not require any purchasing, or the purchasing does not require any approval.
An example of a standard asset request is a subscription of a software where an organisation has agreed the
enterprise quota. Normal resource or asset requests require an approval but are based on the existing commercial
frame agreement and require no commercial negotiation.

An example of a normal resource request is an order for a project manager from the preferred supplier. The proposed
project manager must be qualified by the requester but as the prices and other terms are predefined, the automated
workflow process takes care of approvals and workorder.

93
4. Sourcing and Optimisation

The aim is to move from managing repetitive negotiations to faster on-boarding and thus increased speed and faster
benefits consumption.

People and
competence strategy

Operating model and competence development

Role catalogue Development portfolio Internal resources External resources

BUILD CAPABILITY FULFIL DEMAND MEASURE AND OPTIMISE

Forecast demand

Resource Request
Why?
Long term view What? Short term view Medium term view
Contract capacity for budgeting When? for resource allocation for resource usage optimisation
How?
Define processes

Find Acquire On-board Report Rate Release

Follow-up quality
resource resource resource utilisation results resource

Business Technology Standard

Figure 4.5.1 Resource management [Link]

Moving from individual resources to functional teams

Digitalisation is setting high expectation for speed and agility. The trend in resource management is therefore moving
from hiring individual resources towards hiring full functioning teams trained to work together and according to the
best practices defined by the organisation. Teams can be sourced either as a service with full delivery on the service
promise as outcome or, as a resource in which case the purchasing organisation remains responsible for guiding and
leading the work.

A practical example of sourcing a team can be digital office as illustrated below. A fully-functioning digital office
could have the following roles as a service:

• DEV lead to run and facilitate the development process

• Solution expert that understands the organisation’s enterprise architecture and knows well the functionality of
modern business platforms
• DEV expert of user experience to plan the user interface and user experience by using service design
• OPS expert with experience in planning service readiness for new solutions.

Organisation’s own key people such as CDO and business analyst can then complement this kind of functional team
to give a boost to development of new digital services.

94
 4. Sourcing and Optimisation

DIGITAL OFFICE

CHIEF DIGITAL DEV SOLUTION DEV EXPERT OPS

OFFICER LEAD ARCHITECT User Experience EXPERT

Business Technology Standard

Figure 4.5.2 Digital office [Link]

95
 Development
Discipline

96
 5. Development

5.0 Introduction to Development Discipline

Businesses activities, processes and services are supported by business solutions and platforms. They are enabled by
information technology that is planned, built, operated and continuously developed. The majority of an organisation’s
development initiatives are based on existing solutions and services. In order to transform and expand a business,
innovative solutions and services are a necessary addition.

Development initiatives are organised into value streams, which guide the understanding, organising, and value
delivery for a business. Value streams can be organised by technology or business domain or as a hybrid (see
Chapter 2.1 Strategic Planning for more information on value streams).

The development initiatives that feed in to the value streams are created from four sources of demand as illustrated in
the diagram below:

• Capability Planning – Plan a major business capability development

• Ideas & Concepts – Generate ideas and challenge the status quo
• Increments & Improvements – Uplift to existing business solutions or capability
• Service Changes – Continual service improvement.

These sources of demand transform into development requests and then evolve via different development paths.

DEMAND PORTFOLIO DEVELOPMENT PORTFOLIO SERVICE PORTFOLIO

to-INSIGHTS
OUTCOME-
STRATEGY-
to-PLANS

DEMAND INSIGHTS DEV INSIGHTS BUSINESS INSIGHTS OPS INSIGHTS

CAPABILITY PLANNING Development
Management Office
DATA ASSETS AND INTEGRATION

PLANS-to-BENEFITS
Portfolio SERVICE DELIVERY
Steering
SEQUENTIAL Group Feasibility &

BUSINESS VALUE REALISATION

FLOW GATE-BASED DEVELOPMENT
Prioritisation
Enterprise G0 G1 G2 G3 G4 Release G5 Rollout G6
Architecture Plan Design Develop Validate

Service
SPRINT-BASED DEVELOPMENT Release
IDEAS & CONCEPTS Service
Integration

Backlog Sprint Sprint Sprint Service

Operation
INCREMENTS / IMPROVEMENTS
Service
Support
INCREMENTAL SERVICE CHANGES Backlog
FLOW
Design Develop Change Advisory Board
CHANGE REQUEST BASED DEVELOPMENT and Validate

Business Technology Standard

Figure 5.0.1 End-to-end development [Link]

The development discipline is focused on one outcome, the business value. However, achieving the right balance
between short- and long-term value can be difficult: whether to react to the immediate needs of the business by
improving the existing solutions and services or invest in transforming the architecture and implementing innovative
solutions. The development function provides an efficient approach and best practice for managing development
requests from all sources without compromising the value.
97
5. Development

The following principles apply when maximising both short and long-term business value:

• Assign dedicated resources to focus on specific development requests to ensure efficiency and an improved
throughput
• Take control of development activities by planning and putting in place an appropriate governance structure.
This will enable identifying the dependencies with other projects and make corrective actions without delay
• Stay close to business to ensure greater business value. Executive decision-making alone is not enough to
drive informed business decisions. Shorter feedback loops between the business, development teams and end
users will provide faster and smarter decisions.

Selecting the right development methodology

The Business Technology Standard proposes two types of development methodologies, each with the following
characteristics:

• Sequential development consists of a specified number of phases, where the previous phase must be
reviewed and verified before moving on to the next one. Quality is assured by defining acceptance criteria
and test cases in order to evaluate whether the solution fully or partially satisfies the outlined requirements. The
test team will then execute these test cases and validate the developed product
• Incremental development uses an iterative process where the teams and the customer of the solution/
product provide feedback throughout the entire process of development. A large amount of work is divided
into smaller chunks called ‘sprints’. The solution is incrementally implemented and tested in a sprint. This means
that implementation and testing are closely integrated within a sprint which then ties two sprints together. The
testing then provides feedback for the next implementation step or sprint. When implemented fully,
this approach enables incremental releases into the live environment with each sprint which enables
early realisations of benefits.

Assigning resources for the delivery phase

There are two ways to deliver development requests: dedicated teams and shared resources teams. Both teams have
the objective to maximise the business value produced.

• Dedicated resources teams achieve faster time-to-market as they have full-time resources allocated to their
development requests and decision making is less complex. The continuous use of agile development practices
creates a rhythmic routine that allows teams to communicate and work together efficiently. The team headcount
remains the same and is therefore a fixed cost. However, the team must continuously justify the value of the
deliverables they are generating. This approach is typically associated with incremental development

98
 5. Development

D evelo p

D evelo p

D evelo p
Te s t

Te s t

Te s t
Req’s Design Deploy Req’s Design Deploy Req’s Design Deploy

Figure 5.0.2 Dedicated resources team Business Technology Standard

[Link]

• Shared resources teams allocate a portion of dedicated capacity across business units/functions and can
scale up a larger number of resources on demand for major development requests. As there are typically more
development requests than can be handled by shared teams, prioritisation of resources is handled centrally.
This can slow down time-to-market, yet it ensures that the necessary resources will be allocated towards the
prioritised development topics. This approach is typically associated with sequential development.

1 G0 G1 G2 G3 G4 G5 G6
Plan Design Develop Validate Release Rollout

2 G0 G1 G2 G3 G4 G5 G6
Plan Design Develop Validate Release Rollout

3 G0 G1 G2 G3 G4 G5 G6
Plan Design Develop Validate Release Rollout

Figure 5.0.3 Shared resources team Business Technology Standard

[Link]

For large and non-standard development requests, it is still good practice to initiate a project as it promotes good
governance and stakeholder practices.

Large enterprises often utilise a mix of dedicated and shared development capacity. Dedicated teams can be used
either for core business platforms due to continual high development volumes or, for new product and service
development to ensure fast development cycles. Shared development teams are useful when there is a need for
scalability or flexibility arising from variable demand.

99
5. Development

What are the core components of the development discipline?

1 Feasibility and
prioritisation 3 DEMAND PORTFOLIO DEVELOPMENT PORTFOLIO SERVICE PORTFOLIO

to-INSIGHTS
OUTCOME-
STRATEGY-
to-PLANS
2 Commitment DEMAND INSIGHTS DEV INSIGHTS BUSINESS INSIGHTS OPS INSIGHTS
Development
to fulfil request CAPABILITY PLANNING

1
Management Office
DATA ASSETS AND INTEGRATION

3 Steering and
risk mitigation
Portfolio
Steering
PLANS-to-BENEFITS
4 SERVICE DELIVERY
SEQUENTIAL Group Feasibility &

BUSINESS VALUE REALISATION

FLOW GATE-BASED DEVELOPMENT
Prioritisation
Enterprise

4 Development G0 Plan G1 Design G2 Develop G3 Validate G4 Release G5 Rollout G6

Architecture
methodology
1 2 SPRINT-BASED DEVELOPMENT
Service
Release 6
4
IDEAS & CONCEPTS Service

5 Service Integration
Release
Backlog Sprint Sprint Sprint Service

1 Operation

6 Business value INCREMENTS / IMPROVEMENTS

1 4
realisation Service
Support
INCREMENTAL
FLOW
SERVICE CHANGES Backlog

Design Develop
5
Change Advisory Board
CHANGE REQUEST BASED DEVELOPMENT and Validate

Business Technology Standard

Figure 5.0.4 Six governance elements of the development discipline [Link]

The development discipline structure can be adapted to the culture of the organisation. Nevertheless, it is important
that the following aspects are considered:

• Feasibility and prioritisation ensure that important development requests are completed first, the outcome
delivers the maximum business value and the right skills are allocated to focus on the task.
• Commitment to fulfil a request authorises allocating people and other resources for the development.
Commitment is based on the prioritisation phase and considers factors such as availability of resources,
dependencies, stakeholder readiness and risks
• Steering and risk mitigation support decision making during the development process and help to mitigate
any identified risks. Fast and iterative development cycles allow risk identification and mitigation early in the
development to avoid speed bumps further down the line. Gate reviews and steering groups help to mitigate
risks for larger development programmes that will have a greater business impact
• Development methodology consists of designing, validating and deploying the solutions into the business
environment based on a well-defined and understood procedure that is in use. In addition to the technical
development, the focus should be on change management in order to enhance the success of the deliverables,
such as communication with the stakeholders, running training sessions and collecting feedback
• Transition to service ensures that the business processes remain intact when a new or modified solution is
introduced into operation. This will provide the capability and capacity to respond rapidly with a greater
certainty of success
• Benefits realisation occurs when the deliverable has reached the business value initially promised in the
business case. The findings can then be fed back into the prioritisation process to support future decisions. The
business benefits often materialise soon after the service has been deployed. However, it is good practice to
monitor that the benefits are delivering the value in the long-term as well.

100
 5. Development

The table below illustrates how the development methodologies are used within the core components.

Sequential Incremental

The business case is prepared The product owner prioritises

Feasibility and by the project steering group requests in a backlog based
prioritisation and reviewed and prioritised on the demands of the value
by the portfolio steering group. stream stakeholders.

The project steering group

and the development portfolio The development team
Commitment to
approve the project plan, determines what requests in
fulfil
schedule the necessary the backlog they can complete
a request
resources and manage the during the upcoming sprint.
dependencies.

A plan is created beforehand,

Development is broken down
and anticipated risks are
into smaller deliverables and
Steering and risk managed. Milestones and
discussed more frequently
mitigation checkpoints throughout the
(daily stand-up, sprint
project lifecycle provide
planning, etc.).
steering and risk mitigation.

Each stage represents a Development is done in

Development distinct phase of development incremental sprints. A backlog
methodology that must be completed in tracks the desired features and
sequence. requirements.

Continuous testing and

Final deliverable is tested and
Transition to feedback of the incremental
released into production at the
service deliverables result in minimal
end of development.
impact to the service.

Most at once when the final Gradually with each

Benefits realisation
deliverable is deployed. incremental release.

101
5. Development

Applying Minimal Viable Governance

Minimum viable governance is an effective method for maintaining consistency and efficiency of a deliverable without
compromising the agility and speed.

Governance is important as it establishes responsibility, authority and communication to support the overall goals and
strategy of the businesses. It also defines metrics, policies, standards and control mechanisms to enable the employees
to carry out their roles and responsibilities effectively. However, it is important to find the right balance between
governance and agility.

Organisations can also define effective processes and practices, such as self-evaluation mechanisms, and follow-up
the completion criteria. The development teams can assess whether they fulfil the requirements by asking questions
such as:

Does this project meet the fast track criteria? Have approved partners been used? Have the right stakeholders
been involved? Does the solution align with the existing architectural standards? Is the solution compliant with
the security policy?

The governance of projects throughout the development lifecycle will vary based on the methodology employed.

Embedding industry development practices

The Business Technology Standard provides a pragmatic and business focused reference model that enables the
adoption of development practices. The standard is flexible to evolve with organisations of all maturity levels and can
integrate practices such as Scaled Agile Framework and DevOps. Some examples of development practices are:

• Scaled Agile Framework (SAFe) organises dedicated development workstreams with a specific business
focus. It provides an incremental development pipeline from idea-to-service with built-in prioritisation and
steering procedures
• DevOps (Develop and Operate) can be implemented on a smaller scale as it contains less built-in steering
and governance procedures. DevOps is good practice for dedicated incremental development
• Project and Portfolio Management (PPM) manages the alignment of projects with the business’s strategic
objectives. It is a structured approach to controlling complex projects and programmes that have a major
business impact. The function selects and prioritises projects, allocates suitable resources, monitors their
progress and provides consolidated information to stakeholders.

5.1 Requirements and Feasibility

Development of any product, solution or service should not begin without a clear set of requirements and approved
feasibility. The level of detail can be improved over time, but it is essential that the baseline requirements are agreed
before the actual development starts. Therefore, requirements are an essential part of any development request and
the foundation upon which a solution, product or service will be built.

102
 5. Development

The approach to capturing and managing requirements will differ depending on the selected development approach.

As illustrated in the diagram below, the incremental development methods anticipate resources to be fixed by
capacity, and time to be constrained by time-boxes. This allows requirements (also known as features) to be flexible in
contrast to sequential development where requirements and time are fixed, and therefore resources are variable.

SEQUENTIAL INCREMENTIAL

SCOPE SCOPE
Features, Functionality Features, Functionality

VARIABLE

QUALITY QUALITY
VA
R
IA
BL
E

RESOURCES SCHEDULE RESOURCES SCHEDULE

Cost, Budget Time Cost, Budget Time

Figure 5.1.1 Sequential and incremental development approach

Business Technology Standard
[Link]

Sequential development
Sequential development defines and finalises most of the requirements before development begins, thus determining
the project scope to produce a full project plan. This approach works well when the business requirements are clear
and the business objectives are fixed. However, if the business needs change after development has started, there is a
risk that the final deliverable is based on outdated requirements and does not meet the final business objectives. It also
may cause the project being delayed or exceeding the estimated costs due to extra work required for modifications
and fixes.

GATE-BASED DEVELOPMENT

G0 Plan G1 Design G2 Develop G3 Validate G4 Release G5 Rollout G6

Gather and Document “Big Bang”

Requirements Delivery

Business Technology Standard

[Link]

Figure 5.1.2 Sequential development

103
5. Development

The following categories of requirements should be documented before development starts:

• Business requirements to explain the targeted business capability and change – “why” and “what”
• Delivery requirements to outline stakeholder expectations on delivery – “how” and “when”
• Solution requirements to describe features, functions, characteristics, and the data needed for the solution
• Non-functional requirements to consider predicted volumetrics, performance, security, availability levels
and characteristics, scalability, maintainability and serviceability
• Project requirements to consider actions, processes, competences and other conditions
• Transition requirements to ensure service capabilities required to achieve the service release readiness.
• Quality requirements to verify acceptance criteria needed to validate successful completion
• Portfolio requirements to understand assumptions, dependencies, constraints with other projects.

Business Analysts (BA) analyse, define, document and manage requirements. They identify business needs and are
responsible for documenting and prioritising the requirements with stakeholders. Business Analysts also ensure that the
projects deliver business benefits.

Incremental development
The incremental development approach does not demand a full list of predefined requirements, and therefore the
value delivery starts quickly with every iteration round. With this approach, gathering or producing requirements is
very flexible. Typically, the stakeholders and development teams take an active role in generating new features and
requirements via user stories.

Requirements remain flexible as needs change or as new design considerations are discovered throughout the
development. Documentation should be kept unsubstantial and updated only based on the development team’s
actual needs. The team has a clear perception of the product vision, accompanied by a visual representation of the
roadmap to help them to achieve the desired outcomes.

Incremental development provides speed and agility but fails sometimes to recognise the big picture and the time,
effort and coordination required in business transformation. This is where sequential development may complement
the incremental development with a business transformation programme going parallel and synchronised with
incremental development.

104
 5. Development

D evelo p

D evelo p

D evelo p
Te s t

Te s t

Te s t
Req’s Design Deploy Req’s Design Deploy Req’s Design Deploy

Iterative Delivery

Figure 5.1.3 Incremental development

Business Technology Standard
[Link]

The requirements can be articulated by:

• User stories which are short requirements or requests written from the perspective of an end user
• Epics which are large bodies of work that can be broken down into several smaller tasks called stories
• Initiatives which are collections of epics that drive toward a common goal
• Themes which are large focus areas that span the organisation
• Acceptance criteria which are conditions that the product must satisfy to be accepted
• Non-functional requirements which describe how the system works

A DEV lead / product owneris responsible for reviewing, approving and managing the requirements in the product
backlog. Their aim is to maximise the value of the product resulting from the work of the development team.

Feasibility
Irrespective of whether the development is using a sequential or incremental approach, testing the feasibility will help
avoid costly mistakes, delivery risk, user dissatisfaction or failure to deliver envisioned benefits.

Feasibility testing consists of a variety of actions including at least the following:

• Business feasibility to ensure that the project will stay within a manageable and affordable cost level, relating
both the development and running phase, support and maintenance, costs. The expected business benefits
should cover the costs and also some surplus
• Technical feasibility to ensure that the proposed development fits with the overall business technology and
data strategy, roadmap and enterprise architecture. At the same time, it tests if the proposed technical solution
meets the overall requirements and especially the non-functional requirements
• Deliverability feasibility to ensure that adequate resources, skills and capabilities are available throughout
the development and for the ongoing service.

105
5. Development

Business feasibility
In sequential development, the business case must be produced throughout the planning stage by gathering
requirements, comparing solutions, assessing the architectural fit, and estimating the development costs. This can often
lead to identification of extra costs and risks due to additional complexity or features being identified. The business
case will determine the overall project feasibility, which may result in amendments to the project scope or even project
closure.

Incremental development does not have a complete set of requirements and features upfront. Therefore, the business
case is developed for the value stream instead of the specific project. Funding a value stream for incremental
development enables value to be delivered without delays.

The business case must clearly articulate business benefits that are targeted to be achieved. There are typically seven
types of business benefits that can be achieved:

• Increased sales revenue

• Increased gross margin
• Increased quality and business continuity
• Increased business capability
• Decreased operating cost
• Decreased financing cost
• Decreased enterprise expenses
• Decreased risk.

Technical feasibility
It is essential that the development includes a solution architecture definition. This will allow the development to
determine how it will meet the overall requirements. It typically includes a variety of different facets including:

• Application architecture to determine how the various elements operate

• Integration architecture to determine how individual components or services inter-operate, including the links
with other external systems and services
• Data architecture to determine how data will be gathered, structured, integrated and managed
• Security architecture to determine how the solution will be secured and regulatory or legal
requirements supported
• Infrastructure to determine how the solution will be hosted and support predicted volumetrics, availability, etc
• Service management to determine how the solution will be managed and supported once implemented.

106
 5. Development

Architectural feasibility is important to deliver confidence in the proposed solution. A sequential project typically
covers more details than incremental as the requirements are better known. However, in the incremental approach, it
is equally important to cover enough details to build confidence in the overall solution.

With incremental approach, the architectural design can also be tested early in the development lifecycle by
prototyping and planning major technical (or high risk) features into early increments so that the identified issues can
be fixed at an early stage. On the other hand, sequential development often relies on less risky standard solutions in
implementation.

Deliverability feasibility
The quality of the deliverables often depends on the development teams’ skill-level throughout the development.
Identifying the required skills and sourcing the right competence to required roles and teams is therefore important
already in the planning stages.

When using external resources, it is important to use assessment criteria that help to select reliable and competent
partners. Common assessment criteria are for example the following: employee size, area of expertise, past and
current client references, cultural fit, value vs cost, geographical location, and availability of resources.

5.2 Prioritisation, Commitment and Backlog

In the current highly competitive marketplace, business service and solution development is a major factor in the
competition. Most organisations continually receive development requests to update and improve the business
technology estate or to implement new capabilities and technologies that are key to supporting the company vision
and strategies for success.

Regarding this, a common challenge faced by business technology functions is to find the right way to orchestrate and
prioritise the continuous flow of requests with a minimal viable governance. The objective is to speed up the time-to-
market without losing sight of the requests that are lower down the priority order.

Development request evaluation

The prioritisation and commitment processenables development flow decision making for development initiatives.
At the same time the portfolio steering process and necessary stakeholders focus on initiatives that cannot be decided
in the development flow.

107
5. Development

Evaluation
CAPABILITY STRATEGIC

DEV Request
PLANNING Does the initiative have Portfolio DECISION

DEV Initiative
Strategy Governed
a business owner?
NO Steering
Group Feasibility &
Am I within the Prioritisation
budgeted costs? Go to Enterprise
Business Needs
IDEAS & portfolio Architecture
CONCEPTS Do I have the steering PORTFOLIO
people required? DECISION
Portfolio Governed
Am I aligned with archi-
tecture?

Change / DEV Request

INCREMENTS &
IMPROVEMENTS Am I compliant with
data security rules?

Am I working with
YES DEV FLOW
approved vendors? DECISION
Proceed to DEV flow Governed
SERVICE
CHANGES Am I using agreed development
processes?

Business Technology Standard

[Link]
Figure 5.2.1 Prioritisation and commitment process

As explained in chapter 2.6., Development Portfolio, the demand and development portfolio management provides
a set of rules and guidelines to help in identifying if the request is a fit for development flow decision or must go
through a deeper level of examination and approval.

The following evaluation criteria determine whether DEV flow approval can be used:

1. Sponsor: Is the request sponsored by a business or a value stream owner?

2. Financing: Does the owner have a financing/budget for the development?
3. Resources: Does the owner have a dedicated development team available to deliver the request?
4. Architecture: Is the request compliant with enterprise architecture guidelines?
5. Security: Is the request compliant with security policies and guidelines?
6. Vendors: Are you working with approved partners/vendors?
7. Processes: Is the project following the standard development processes in place?

If the answer to all of these seven criteria is affirmative, the requests can be approved with the development
flowdecision and the development team will add the request to its backlogand take care of further development of the
request.

Evaluation may also include further hierarchy steps. For example, if the first evaluation round does not provide positive
answer it can be escalated upwards in the hierarchy until it bypasses or reaches the portfolio level. Typically, the
lowest level self-evaluation is done by a service manager or a product owner and can be further escalated to a
service owner or a value stream owner before going to the portfolio level.

Portfolio-level management of development requests

When a request does not pass the evaluation criteria and cannot be approved by the development flow, portfolio
steering is required to:

• Evaluate the request feasibility and risks

108
 5. Development

• Define a priority for the request

• Arbitrate request’s priority against others
• Help in getting funding and required resources.

Once the portfolio steering group agrees and is confident with all aspects of the request, it is ready to proceed
to development phase where a development request will be produced using either sequential or incremental
development procedures:

• Sequential development expects a traditional project plan including a set of requirements, description of the
different phases, roles and responsibilities
• Incremental development expects a set of epics, features and stories to be added to a backlog.

Development request prioritisation

Before committing to the development, each development request must be prioritised according to different
considerations and development method.

Sequential development prioritisation

For sequential development, shared resources are allocated to the development for a planned period. Prioritisation of
sequential development is a complex exercise that requires carefully balancing the following three considerations:

• Business value and impact: Considering the business impact of the project on the strategic objectives,
opportunities of new revenue generation, market competitive advantage, etc. A common method for
calculating business value is Net Present Value (NPV) which is based on future cashflows (in and out) and the
associated risk
• Cost of delay: A way of sharing and understanding the impact of time against forecasted outcomes.
It provides the means to calculate and compare the cost of not completing a request by choosing to postpone
it. A common method for maximising the value delivered in a defined period with limited capacity is the Cost of
Delay Divided by Duration (CD3 score)
• Risks reduction and compliance to regulations: Considering risk for the organisation to not proceed with
the development. This consideration is impacted by the end-of-lifecycle status of the current solutions or other
deadlines in support, compliance or technical environment. A common method for risk analysis is a 5×5 risk
matrix having probability and impact as the two dimensions with scale from rare and very low to highly
probable and very high impact.

The above considerations are driven by the Development Management Office and provided by the project owner.
The portfolio steering provides its own judgement to ensure that all initiatives are prioritised equally.

109
5. Development

Incremental development prioritisation

In incremental development, a team dedicated to a specific business purpose manages a backlog of requests.
The team needs to manage the new requests coming in and prioritise its backlog while continuously delivering new
service releases.

During a specific workshop (e.g. PI planning session in SAFe) the team, including the stakeholders, works to break
down each request into large increments and spends time breaking down each increment into smaller pieces of
development (features, stories) that will be realised incrementally. Still working with the stakeholders, the team then
evaluates the different pieces of development and prioritises them based on:

• Feasibility including technical consideration to estimate duration of each feature based on a discussion
between the technical team members and the technical partners
• Desirability consisting of analysis of the end user needs and priority based on a discussion between products
owners, UX designers and strategists
• Viability formed by analysis of the different constraints that apply to the project itself such as finances, time,
regulations and dependencies

The result of this work is a prioritised backlog of tasks for each request. Requests are then compared between each
other to select the most viable one to develop first. The criteria for selection is often based on the Cost of Delay
Divided by Duration (CD3) of each request or Weighted Shortest Job First (WJSF in SAFe).

Changes
Some requests received by service teams refer to minor changes on some existent capabilities, products or services
and thus represent only a few hours’ or days’ worth of effort. These changes are usually decided by the development
flow and follow a specific steering governance and prioritisation decisions by the Change Advisory Board (CAB).

A service change management process is used to manage the implementation and release of the changes. It employs
standard methods and procedures to make an assessment between the need for change versus the impact of change.
The objective is to prevent all unintended consequences to service quality.

The changes are usually classified as normal, standard or urgent.

• Normal infrequent changes to a service or infrastructure requiring a risk assessment by the Change Advisory
Board (CAB)
• Standard changes are routine tasks pre-authorised by the service management function that uses approved
and established procedure to provide a specific change requirement
• Emergency changes must be introduced as soon as possible, usually in order to correct an error within a
defined environment. There is a substantial risk involved and therefore, it must be approved by the Emergency
Change Advisory Board (ECAB).

110
 5. Development

5.3 Design, Development and Validation

There are several methodologies to choose from when developing something new, or when making changes to
existing products, solutions or services. Each methodology has its own set of rules, principles, processes and practices,
and the selection of the best approach for the task will vary according to development purpose, organisational
aspects, nature of the business, skills and capabilities.

The various methodologies apply a trade-off between scope, resources and schedule to deliver the desired outcomes.

SCOPE
Features, Functionality

QUALITY

RESOURCES SCHEDULE
Cost, Budget Time

Figure 5.3.1 Different development perspectives

Business Technology Standard
[Link]

111
5. Development

The Business Technology Standard proposes two types of development approaches: sequential development and
incremental development. The following table shows the characteristics of the two approaches:

Sequential Development Incremental Development

Clear deadlines: Estimates development Adaptability: Enables shorter development

costs upfront, creates project timelines and cycles providing the business the flexibility to
clear deliverable milestones. pivot when it needs to.

Immediate user feedback: A strong

Disciplined by design: Each phase has
emphasis on releasing products into the
a defined start point and a review gate at
hands of users. Reduces the risk of building a
the end of it. All tasks must be completed
product that nobody wants while increasing the
before the project can proceed to the next
chances to find the feature that delivers value
phase.
earlier in the project life-cycle.

Documented: Each phase of development

requires a specified list of documentation Test approach: Develop and test within the
to be completed which makes it easier to same iteration so a working solution exists at
follow the logic of past projects and lay the every stage.
groundwork for future projects.

Clear communication: Timelines are Fast, high-quality delivery: Iteration leads

predictable and well-documented. Easy to to fewer bugs and higher-quality releases. A
provide status updates to management and great approach for quicker, higher-quality
stakeholders. releases with successive iterations.

Easy learning curve: Requires minimal

Teamwork: Places an emphasis on
knowledge or training to start the
frequent team communication, face-to-face
development work as each person has a
interactions and interfacing daily with business
clearly defined role in a clearly defined
representatives.
process.

112
 5. Development

Using DevOps methodology

C OD E DEPLOY

PL
A

OPE ATE
N
B U IL D

SE
A

R
LE
RE
MO
TE ST N IT O R

Figure 5.3.2 DevOps methodology

DevOps integrates development and operationsBusiness isTechnology Standard

[Link]
in line with the incremental development mindset and
methodology. It enables rapid service delivery through adoption of agile and lean practices in the context of system-
oriented approach. DevOps is a set of practices that automate the processes between software development and
operations teams.

This way, building, testing and releasing software becomes faster and is more reliable. It also promotes building a
culture of collaboration between teams that in a traditional organisation work in siloes. When deploying the DevOps
methodology, the organisation usually gets benefits such as: increased trust, quicker software releases, ability to solve
critical issues quickly and better management of unplanned work.

The Business Technology Standard has adopted the DevOps mindset by introducing development and operations role
names with DEV and OPS prefix.

113
5. Development

Selecting the best development methodology

The following evaluation criteria can be used as a guide to determine the development approach to be used for a
request.

Sequential Incremental
Evaluation criteria
development development

Is the final request fully defined? Yes No

Should the owner be able to make a

major scope change of the request No Yes
after it starts?

Is the scope of the request, not the

speed of development, the key to Yes No
success?

Does the initiative have a high level

of interdependencies with other Yes No
initiatives

Will the final product be subject to

Yes Yes
many future changes?

Design
In sequential development, the requirements are used to produce the high-level and detailed-level designs before the
development of the solution begins. The design phase has specific deliverables and a review process.
The development is then easy to manage due to the rigidity of the model. For example, pure infrastructure projects
often require the requirements and design to be decided at the start of a development.

In incremental development, an initial high-level design is often produced upfront in order to frame the solution
approach. Detailed design is done within the sprints in parallel with development. Some enabling design stories can
be included in a sprint to support or facilitate the development of a later sprint.

114
 5. Development

Validation
When a new or modified service has been developed and is ready to be deployed in a live environment, it must be
reviewed against the defined readiness criteria to ensure it meets the agreed requirements. This is to ensure that it can
be supported without adverse impact.

The approach to validation varies depending on the selected approach:

• Sequential approach has a defined validation phase prior to deployment. All associated rework and
retesting activities are contained within this phase. The validation is normally carried out by a dedicated test or
quality assurance function independent of the development team
• Incremental approach has a testing and validation phase normally done within each increment, as well as
fixes if necessary. Or, if they are not urgent, they can be put on the backlog. Sometimes, however, there may
not be a release to live within each increment. Instead there can be a so called ‘hardening’ sprint focusing all
efforts on more rigorous testing and defect fixing without any new development. The validation expertise is
ideally contained within the development team.

Final acceptance is often carried out by the stakeholders in User Acceptance Test (UAT). The service readiness is
tested by the operations organisation together with the service integration team.

Industry recognised Development Methodologies

The Business Technology standard enables the use of widely used development methodologies, such as PRINCE2 and
Scrum. The tables below provide examples of methodologies for the two types of development methodologies. The list
is not an exhaustive list and an assessment should be conducted to ensure that the right methods will be selected.

Sequential development

Guides you through the essentials for managing successful

projects, regardless of type or scale. Built upon seven principles,
PRINCE2
themes and processes, and can be tailored to meet your specific
requirements.

PMI is a project management certification that provides PMBOK,

a set of standard terminology and guidelines for project
management. It states five process groups that are prevalent in
almost every project – Initiating, Planning, Executing, Monitoring
PMI / PMBOK & Controlling, Closing.

Note that PMI is referred often as a reference guide rather than

an actual project management methodology. However, it can be
used to apply best practices to projects.

115
5. Development

Incremental development

The goal of Scrum is to develop, deliver, and sustain complex

products through collaboration, accountability, and iterative
Scrum progress. Scrum operates using key roles, events, and
artefacts which distinguished it from other incremental project
management methodologies.

Kanban, like Scrum, focuses on early releases with collaborative

and self-managing teams. A very visual method that aims to
Kanban deliver high quality results by painting a picture of the workflow
process so that bottlenecks can be identified early in the
development process.

Helps large enterprises realise the benefits of agile while

retaining some organisational structure and control over
Scaled Agile Framework (SAFe)
processes. It is the go-to option for large, software-intensive
projects where teams are highly interdependent.

A method that aligns development and operation teams’

activities through communication, integration, and collaboration.
DevOps It enables the deployment of code to production in a faster and
automated way. It increases an organisation’s speed to deliver
solutions and services.

A framework made up of eight principles, lifecycle and products,

roles and responsibilities and several best practice techniques.
Dynamic Systems Development
The method provides a four-phase framework consisting of
Method (DSDM)
feasibility and business study, functional model / prototype
iteration, design and build iteration and implementation.

5.4 Deployment and Training

Every development implements a transformation, whether a small change in functionality or a major business change.
Usually, it is about replacing something we currently have or use by something better or getting something, we have
not had before. A very human and understandable attitude is to resist change or to have too high expectations for
change.

116
 5. Development

Deployment and training is essential in all transformations as it plays a key role in the adoption of the new capability,
product or service being deployed. It is critical that people adapt and change in line with the deployment, and that
acceptance of change does not become a bottleneck for the deployment.

Business impact
The business impactof any transformation must be identified and understood as early as possible in the request stage.
In identifying the impacts, the following aspects must be considered:

• Scope of the transformation (geography, departments, users, etc.)

• Capability creation or updates, including ecosystem, people, processes, solutions, assets and data
• Processes, services and assets that need to be retired
• Integrations that need to be created and managed
• Skills and roles that are needed for the deployment period
• Assets that needs to be set up (data, licences, hardware, utilities, etc.)
• Regulations and legal aspects that needs to be respected
• Risks that must be mitigated and managed
• Costs and financial impact to the business.

As the business impact is often considerable and deployment usually takes a lot of time, money and effort, it is
preferable to run the deployment phase as a project of its own with project plan, business case and gate approval
practices.

Deployment and training components

The deployment and training phase activities vary depending on the selected development methodology:

• Incremental development is continuously delivering new releases and therefore the deployment and training
is a continual activity. The training efforts should be in line with the business impact of the change. However,
incremental development may also deploy major releases with a much larger business impact and deployment
effort requiring deployment to be organised as a sequential initiative
• Sequential development, the training and deployment starts when the solution is tested and approved for
deployment in User Acceptance Test (UAT) phase. The product, solution or service should not be released
without suitable UAT and signoff. The deployment itself can be done as big-bang, phased or modular roll-outs.

117
5. Development

The deployment and training phaseconsists of the following sequence of activities:

DEPLOYMENT & TRAINING

TRAINING

PILOT ROLL-OUT

Go / No Go

Feedback
and updates

Figure 5.4.1 Deployment and training phase components

Business Technology Standard
[Link]

• Training: Users need to be trained to use the new product, solution or service and all the available features
that help realise the anticipated business benefits. Training and support documentation must be made available
and easily accessible to everyone. Support teams may need additional technical training to handle the related
incidents in addition to learning the new processes introduced by the system or service
• Go-live: The moment when product, solution or service is released, and users are asked to use it instead of the
retiring solution. Go-live requires careful planning especially when the new solution is replacing extensively
used existing solutions. Therefore, the go-live planning is in many cases a major activity by itself with extensive
minute-by-minute action plan with rollback and recovery options
• Intensive care: Intensive care period starts just before the go-live and lasts few weeks after to tackle peeks in
support requests and enable fast handling of issues. Intensive care is provided by the development and
operations teams
• Pilot: The solution can be tried out with a set of defined users before the actual deployment in order to prove
the value, function and feasibility of the new solution. The deployment is done within a limited scope and tested
by real users, often in real use in their day-to-day work. A pilot will lower the risks for the final deployment as it
often highlights the test cases that have not been considered during UAT
• Feedback and updates: End-user feedback is consolidated and reported back to the deployment,
development and service teams for consideration, response and potential updates

118
 5. Development

• Roll-out: The new product, solution or service is made available to the targeted audience. Different roll-out
strategies can be applied depending on the situation. The selection of the right approach should be done based
on the target organisation’s ability to adopt change and the impact of change on the organisation:

o Phased roll-out: the solution is progressively made available to the users, starting with a specific user
category, and then moving on to subsequent categories according to an agreed schedule
o Module-based roll-out: a module of the solution containing a subset of features is deployed to all users.
Once achieved, another module is deployed, until all modules have been deployed
o Big-bang: the solution is fully deployed to all users.

PHASED ROLLOUT

MODULE-BASED ROLLOUT

BIG-BANG ROLLOUT

Figure 5.4.2 Roll-out strategies Business Technology Standard

[Link]

Project handover and completion

For sequential development, the project is closed after successful rollout and handover. Handover means transition
of operational and development responsibilities from the project organisation to the business technology line
organisations. The project owner and project manager hand over the responsibility to the service owner, including an
extensive knowledge transfer. Development responsibility is handed over to the development team led by a DEV lead
or solution lead. The operational responsibility is equally handed over to the OPS lead.

In some cases, instead of persons-to-persons handovers, it would be better if handovers occurred between roles.
For example, if a line organisation person also has a role in the project organisation, the handover would happen in
between the two roles of the same person and not in between different persons. However, the approach of “having
two hats” is seldom optimal in the implementation phase of the project as both roles require more than 50% allocation
of the person’s resources.
119
5. Development

The project completion includes an evaluation and project closedown report (sometimes called the transition-into-
service report) detailing how well the targets were met, approval of agreed deliverables, and documentation of any
further development ideas and unresolved issues. Deliverables and post-project service responsibilities and warranty
periods are recorded in the service handover documentation.

In incremental development, the process is continuous until there is a need for selecting a sequential approach for
implementing a large or major change.

In addition to preparing the programme closedown report, it is important to conduct a feedback survey across
stakeholder groups as well as document the lessons learned and experiences gained during the project.

Service Release Automation

A key factor of successful deployment is the organisation’s ability to automate the service release of new products,
solutions and services. Automated service release can make deployment more efficient and reduce the risks
associated with manual service releases, while enabling roll-back to a last-known good state in case there are
problems with the release.

Automated service release fit particularly well with incremental development, where there are new releases daily or
weekly. The automated service release has for example the following benefits:

• Release configurations are made once

• Release can be done when needed
• Chances of manual errors are reduced
• Feedback is collected immediately.

Governance
The governance in a deployment phase is linked to the business impact size: the larger the impact, the stronger
governance is needed. All service releases, excluding standard changes, go through a Change Advisory
Board(CAB). In addition, larger service releases require approval from a service or product owner or from the
steering group. Automated service release procedure, once reviewed and approved, does not require CAB review for
each release.

The governance structure is also reliant on the type of selected development approach:

• A sequential development with large business impact will require strong steering at the end of the project to
take decision on the deployment. From a risk perspective, a lot of risks are pushed to the end of the project and
therefore the project steering group and portfolio steering group decisions are required
• An incremental development approach will break down a large business impact into smaller risks, requiring
continuous deployment and training stream during the entire length of the project. However, a major release
with large business impact require value stream steering group’s approval.

120
 5. Development

SEQUENTIAL DEVELOPMENT INCREMENTAL DEVELOPMENT

G0 G1 G2 G3 G4 G5 G6
Sprint

User feedback DEPLOYMENT & TRAINING DEPLOYMENT & TRAINING

User feedback
Time Time

Figure 5.4.3 User involvement during development and deployment Business Technology Standard
[Link]

5.5 Business Value Realisation

Business value realisation is about achieving and demonstrating the actual business value resulting from a deployment
of a new or improved product, solution or service. Projects and programmes that implement new capabilities often
involve significant organisation changes, requiring a shift of mindset and significant investments by the organisation.

A key success factor of these transformations is the ability to measure the adoption of the new capabilities, products
or solutions by the organisation and its customers. A poor adoption will result in the benefits and value not being
realised. The business value realisation process therefore aims at measuring and maximising adoption and success of
business transformation over time.

BUSINESS VALUE REALISATION

Measuring and maximising adoption and

success of the transformation over time

Development, Business and customers feedbacks

Request deployment & training
Success
BUSINESS VALUE

Business New capability

REALISATION

objectives or product Post deployment communication

Improvements

Metrics measurement
Retirement
Translation into
measurable KPIs Incentive programmes

Defined period of observation

Business Technology Standard
[Link]

Figure 5.5.1 Business value realisation process

121
5. Development

The business value realisation process relies on early stage work relating to the creation of a business benefits plan
linked to the requested business case:

• Business objectives must be clearly identified and measurable (number of users, revenue contribution,
savings, etc.)
• Targets must be associated to a timeline (deployment +3 months, +6 months, etc.) to provide a timeframe for
the Business Value Realisation
• Conditions of success and failure must be described in order to facilitate an assessment at the end of the
business value realisation period
• Roles and responsibilities to measure the business value realisation must be attributed to identified resources.

There are four types of tasks associated with the business value realisation process:

• Business and customer feedback: Capturing the comments and improvement suggestions of the business
or customers, undertaking a lessons-learned exercise and feeding the demand process with improvements
suggestions where appropriate
• Post deployment communication: In coordination with the service delivery and service owners, prepare and
communicate to the target audience in a timely manner in order to promote the new capability or solution
• Metrics measurement: Periodically measure, in a consistent way, the success factor metrics defined in the
business case
• Incentive programs: Create incentive programmes and strategy to promote the new capability or solution to
the organisation or the customers (retirement of previous capability or service, etc.).

For sequential developments, some of the business benefits may be achieved before the rollout happens, for example
in the pilot, although in most cases they materialise after the rollout.

For incremental developments however, the business value realisation must be measured from the first increment.

BUSINESS VALUE REALISATION

SEQUENTIAL DEVELOPMENT BUSINESS VALUE REALISATION INCREMENTAL DEVELOPMENT

G0 G1 G2 G3 G4 G5 G6
Sprint
Business value

Business value

Time Time

Figure 5.5.2 Sequential and incremental business value realisation

Business Technology Standard
[Link]

122
 5. Development

The business value realisation process runs for a period set within the business case. At the end of the period, an
assessment has to be made as to whether the transformation is successful, has reached some success and must
improve, or is a failure.

In the case of a failure, where the business benefits are not realised as expected or realised too slowly, a root cause
analysis should be conducted to support decision making on initiating possible corrective actions. The most common
causes of failure include the following reasons:

• Lack of business readiness to use the new capabilities or solutions

• Organisations not incentivised to change
• Misalignment between business requirements and development delivery
• Divergences (priorities changed over time, original business case no longer valid, etc.).

If the initiative is only partially successful, improvement requests can be raised and fed back into the demand process.

If the business benefits are realised as expected, it is good practice to communicate this success to all relevant
stakeholders.

It is also good practice for the benefits to be continually managed and assessed throughout the whole investment
lifecycle, which includes incremental updates and amendments to any product or service.

123
 Services
Discipline

124
 6. Services

6.0 Introduction to Services Discipline

Services discipline makes the tested and validated development outcomes accessible to users via a service release.
Services discipline ensures the operational readiness with the service delivery ecosystem and validates that user
support and services are in place with required skills and capacity.

SERVICE PORTFOLIO STEERING

OUTCOME-to-INSIGHTS
PERFORMANCE AND FEEDBACK DATA ANALYSIS

INSIGHTS PERFORMANCE (KPIs) GUIDANCE OPS INSIGHTS

PLANS-to-BENEFITS BUSINESS BENEFITS REALISATION

Service SERVICE DELIVERY

Release

Service Integration and Quality – Discipline to Performance

SERVICE
Service Operation and Automation – Detect to Correct ECOSYSTEM
Change Service
Support and Service to Users – Request to Fulfill Catalogue Service Providers
Advisory
Board

Single Source of Truth and Platform for Actions – OPS Management System / ITSM

Business Technology Standard

[Link]

Figure 6.0.1 Services discipline

From the business perspective the services discipline has three major objectives:

• Business continuity to minimise the number of major incidents and downtime cost of business technology.
Major incident means that a business-critical product, solution or service is not working properly and disturbs
the business continuity often with costly effects
• Improved user experience by collecting and analysing user feedback, making continual small improvements
and having continual dialog with the development teams related to bigger improvements
• Cost efficiency by squeezing the run phase costs via consolidation and negotiating the commercial terms.
Most of the business technology costs relate to the run phase and as the cost of underlying technology evolve
constantly, cost efficiency requires a continual effort.

Global megatrends impact the services

Global megatrends such as cloudification, globalisation and individualisation have an impact on the services
requiring them to become centrally managed. In the early stage this was done by consolidating the services with
sourcing deals and later by using global cloud service providers. Digitalisation in its current scale-up phase also
increases the diversity. Many innovative products and solutions are created by smaller companies able to provide
agile and unique service. This sets a challenge to the services discipline as the service consumers expect simple,
intuitive and unified support processes.

125
6. Services

NEW
SERVICES

NEW COMMON
VENDORS PLATFORMS
BUSINESS
DIGITALISATION TECHNOLOGY GLOBALISATION

NEW UNIFIED
BUSINESS PROCESSES

NEW
MARKETS

Business Technology Standard

[Link]

Figure 6.0.2 Global megatrends impact the services

What is a business technology service?

Business technology service consumers are served with impression and touchpoints to have access to processes,
applications and data which encompasses the underlying platforms, integrations and infrastructure. If any of these
components fails, the whole service is failing. Therefore, the management of the service is essential even if the service
consumers usually perceive only the concrete results of the services.

To be productive within the organisation and successful in digital business, it is crucial to assure an integrated and
harmonised service experience regardless of what are the underpinning elements or who are the actual service
providers. At the same time, there is need for agile and responsive solution and service development.

Maintenance
Solutions
Delivery
Support ecosystem
Interface

Touchpoint Data Integration

Impression Process Platform Infra

Connectivity
Access
Service
Security levels
Monitoring

Business Technology Standard

Figure 6.0.3 Business Technology service

[Link]

126
 6. Services

Core elements of the services discipline

The core elements of service management consist of activities focusing on management, release and delivery
of the services.

Management of the services:

• Service portfolio steering is a set of activities and strategic decisions ensuring that the business is provided
with the right set of services now and in the future and that the service performance is on an appropriate level
• Service catalogue illustrates the available services in a visual and appealing way. Complete service
catalogue is formed of an overview of business technology services, service brochures and service and order
request catalogue implemented in service management and operations platform
• Service Integration focuses on optimising, harmonising and integrating service operations performed by
several (internal and external) service providers. It unifies service processes and quality assurance for a greater
service experience and decreases the operational costs.

Delivery of the services:

• Service release ensures that the business processes remain intact when a new or modified solution is
introduced into operation. This will provide the capability and capacity to respond rapidly with a greater
certainty of success
• Operational readiness verifies that the services meet the predefined operational readiness criteria
• Service operations ensures an efficient delivery of services without interruptions. Service providers (external
or internal) are responsible for professional service delivery
• Service and support to service consumers is responsible for day-to-day guidance, and the resolution
of service requests and issues. Service desk (physical or digital) acts as a single point of contact for the service
consumers. Questions that cannot be resolved by the service desk are assigned to respective service providers
(external or internal)
• Service management and operations platform has central role in enabling integrity, efficiency and
automation. It binds together all the elements of service management, development and delivery
• Service automation increases the productivity and lowers the operational costs.

Embedding industry development practices

Business Technology Standard provides a pragmatic and business focused reference model that enables the
adoption of development practices. The standard is flexible to evolve with the organisations of all maturity levels and
can integrate practices such as ITIL, SIAM and DevOps. Some examples of service management practices are the
following:

• ITIL providing a comprehensive reference set for managing services and processes
• SIAM (Service Integration and Management) providing organisations with a management methodology to
control the ecosystems and a structure to add and remove serviceproviders quickly and efficiently, with
practices and culture that drive collaborative behaviour

127
6. Services

• DevOps (Develop and Operate) can be implemented on a smaller scale as it contains less built-in steering
and governance procedures. DevOps is a good practice for dedicated incremental development.

6.1 Service Integration and Quality Assurance

The service operations ecosystem is in constant change. New and often quite small suppliers who have core
competence in product and service development (although not necessarily in operating the services) are reshaping
the ecosystem. The trend is to transfer traditional service operations from regional data centres into global data centres
operated by new global mega players instead of traditional service providers. In general, the organisations are less
dependent on dedicated operations management, and have to deal with a more fragmented and more complex
operational ecosystem.

Service integration or Service Integration and Management (SIAM) today has a significant role as it defines how to
manage services in a multi-vendor environment. It coordinates the whole service delivery ecosystem covering internal
and external operations as well as local on-premise and global cloudified service operations.

Service integration and quality is responsible for:

• Managing service catalogue

• Unifying and harmonising service processes across services
• Ensuring seamless integration of services for better user experience
• Verifying operational readiness of services
• Managing major incident situations by having control of command
• Measuring and reporting service status, KPIs and SLA compliance
• Managing operational environment configuration data
• Having process to onboard and retire services.

Service integration promotes a collaborative culture in the ecosystem and directs focus from reactive issue resolution
into proactive and preventive service management in good co-operation with all stakeholders.

Horizontal and vertical service integration

Service integration and quality assurance is a multi-dimensional effort. Horizontal service integration represents
the main service integration function as it goes across all services and major service providers. Horizontal service
integration is often provided by internal resources togetherwith, or even solely by, a service provider that does not
have other major service responsibilities or interest in the ecosystem.

128
 6. Services

Vertical service integration is provided by the main service providers who have accountability of the service
integration and quality within their service delivery scope. Vertical service integration must be compliant with
processes, policies and guidelines provided by the horizontal service integration.

SERVICE PORTFOLIO STEERING

SERVICE INTEGRATION CENTRE

Compliance Management Core Process Management Continuity Management

Catalogue and SLA Management Security Assurance Change Management HORIZONTAL
SERVICE INTEGRATION

SERVICE SERVICE DESK

DEVELOPMENT

PRIME SERVICE SERVICE SERVICE

SERVICE PROVIDER PROVIDER PROVIDER PROVIDER

PROVIDER PROVIDER PROVIDER

VERTICAL SERVICE
INTEGRATION

Business Technology Standard

[Link]

Figure 6.1.1 The dimensions of service integration

Standard operational procedures and tools

Service integration and quality requires all delivery ecosystem parties to strictly follow the set guidelines and
practices. Service integration requires standard operational procedures, defined roles and responsibilities, as well
as processes and document templates to cover the typical use cases. Most procedures, such as incident and change
management, can apply global best practices from ITIL, while others, like service compliance, require organisation-
specific definitions.

The Business Technology Standard groups the standard operational procedures as follows:

• Qualify compliance and quality: qualification of vendors and services to meet compliance and quality
criteria
• Govern catalogue and service levels: defining the service catalogue and verifying it is up-to-date and that
services fulfil end-to-end KPIs and SLAs
• Assure core process performance: designing and assuring the performance of core service management
processes
• Detect security and quality issues: detecting security flaws and threats by monitoring and inspecting unusual
behaviour of network traffic, systems and users
• Manage change and continuity: controlling service changes and ensuring the business continuity.

129
6. Services

QUALIFY GOVERN ASSURE DETECT MANAGE

Compliance Catalogue and Core Process Security and Change and
and Quality Service Levels Performance Quality Issues Continuity

ITSM TOOL
Provide service catalogue & Self-service portal. Automate workflow and measure E2E performance.

DASHBOARD ANALYTICS ROBOTICS E2E MONITORING

Visualise Identify improvement Automate Monitor overall
Key Performance targets by analysing routine tasks and E2E service status
Indicators with best process, metrics process elements. and performance
practice dashboard. and trends. challenges.

Figure 6.1.2 Service integration topics and related processes and activities
Business Technology Standard
[Link]
Efficient execution of service integration requires tools to manage and automate the processes. Whether implemented
simultaneously or gradually, it is recommended to set up tools for service management as the following:

• Dashboard: gathers information from different sources and provides automated on-time performance and
trend information on all KPIs
• Analytics: gathers data from different sources and analyses it through various dimensions so that improvement
needs related to the services can be discovered efficiently
• Robotics: lowers operational effort by automating routine tasks in processes and operational procedures
• E2E monitoring: help to simulate the end user experience of a given service.

Service integration team/centre

The increasing business criticality and diversity of the services call for dedicated service integration capability. Service
integration team, or in large companies, service integration centre, is usually a good and effective way to ensure the
execution of service integration across all services.

The service integration team/centre is responsible for:

130
 6. Services

• Managing service integration centrally with maximum payback of investments

• Scaling service integration operations according to company size and service volumes
• Maximising the power and value of service integration by dedicating resources to continuously
improve the outcomes
• Cooperating and collaborating with stakeholders as one accountable entity.

The business technology service integration centre is responsible for horizontal service integration while service
providers’ service integration centres are responsible for vertical service integration within the vendor’s responsibility
area.
SERVICE INTEGRATION CENTRE
MANAGEMENT PERSPECTIVE

VENDOR PERSPECTIVE
Service governance Core process management

Dashboard & reporting ITSM tool & analytics

Service desk and self-service

SERVICE CONSUMER PERSPECTIVE

Business Technology Standard
[Link]

Figure 6.1.3 Service integration centre

Responsibilities, objectives and governance

The service integration team/centre is responsible for defining standard procedures and governing proper
implementation of services. It works mainly with service providers and runs service integration steering group chaired
by the Business Technology Operations Officer (BTOO).

Service desk is a single point of contact for service users and has the best visibility on the most up-to-date service
status. Good collaboration and cooperation between the service integration team/centre and service desk will
improve the capability to respond to and prevent service failures.

Change Advisory Board (CAB) is responsible for approving the service releases while the service integration team/
centre is responsible for defining the operational readiness procedure and consulting services for building the
readiness. A close cooperation will improve the service release quality and reduce the number of release-related
service issues.

Service integration team/centre also reports and analyses the service performance and consults development and
operations teams related to continual service improvement.
131
6. Services

When working in close co-operation with other functions, the service integration team/centre can contribute to the
following objectives:

• Improve user satisfaction

• Improve cost performance
• Reduce the number of issues.

Usually, in bigger organisations, a good-quality service integration can be achieved by forming a service integration
centre with service integration leads for each standard procedure category and additional service integration centre
experts for analysis, automation and maintenance activities. In smaller organisations, one person can have two roles
and the service integration team can be staffed with less resources.

6.2 Service Release and Operational Readiness

The aim of service release and operational readiness is to ensure that the transition of a new or modified service into
a live environment goes as smoothly as possible and that the service meets the predefined operational readiness
criteria. The business expectations to service releases are twofold: speed and agility, and error free service delivery.
These expectations are difficult, yet possible to achieve at the same.

Service release
A service first becomes available for service users during the service release phase and requires, therefore, careful
planning already during the development phase.

There are two ways to release a service:

• Service transition consisting of a sequence of manual service release activities taking place in well-planned
order. A “big-bang” service release in sequential development is usually done this way
• Automated service testing and release, which enable release activities whenever needed. This approach is
especially suited for incremental development with fast sprint cycles.

In both cases, the operational readiness criteria must be fulfilled before go-live and the service must be approved
by the change advisory board (CAB). However, standard service changes and pre-approved automated service
releases can take place without CAB’s approval. The service integration team or centre provides the service readiness
criteria and procedure for the service release.

132
 6. Services

Service Service
Readiness Transition

DEV Request
GATE-BASED DEVELOPMENT

G0 G1 Design G2 Develop G3 Validate G4 Release G5 Rollout G6

Portfolio Steering
Approve development request
SPRINT-BASED DEVELOPMENT
DEV Request

Backlog Sprint Sprint Sprint Test

CAB approved
test automation

Priorisation,
Categorisation
and Evaluation

Normal change
Change Advisory Board
CHANGE Req

Standard change Approve service release

Backlog

Design Develop
and Validate

Business Technology Standard

Figure 6.2.1 Request-to-release governance [Link]

Operational readiness
The primary focus of operational readiness is to ensure business continuity during and after the service transition of a
new solution or service into a live environment. The operational environment has many dependencies and one poorly-
planned service transition or service release may jeopardise the integrity and availability of services.

Operational readiness ensures that the service transition, service processes and the support model are well planned,
tested, implemented and enabled before the release. In addition, it ensures that the security, data protection and
integrity as well as the business continuity aspects are considered for the new service and that the transition does not
cause any vulnerabilities to existing services or platforms.

An operational readiness checklist helps to ensure a smooth transition as it provides transparency of operational
readiness of services and gives all parties a common understanding of the steps and key criteria for acceptance.

133
6. Services

Operational Readiness Checklist

(Designed and Maintained by Service Integration)

DEVELOPMENT SERVICE INTEGRATION SERVICE OPERATIONS

Develop operational Validate operational Ensure efficient delivery

readiness according readiness of changes, Yes of services according
to predefined operational releases and project Passed? to defined service levels,
readiness criteria rollouts before their support model and
(operational readiness transition into Service service delivery
checklist). operations. processes.
No

Business Technology Standard

[Link]
Figure 6.2.2 Procedure for operational readiness

Business needs may sometimes put pressure to deploy premature service releases as the business benefits cannot start
accumulating until the service is in use. In cases where all the operational readiness checkpoints cannot be passed
and there is a need to put the service in operation, the service release can be done incrementally. In such cases, it is
essential to assess the risks, define and agree the mitigation actions and procedures in advance.

When using the incremental approach, the team responsible for the development can support the service operations
and work on closing the gaps found in the service acceptance. Once all acceptance criteria are met, the service is
ready for launch.

6.3 Service Operation and Automation

Service operation ensures an efficient delivery of services without unplanned interruptions. Services are operated
according to Service Level Agreements (SLAs) and Key Performance Indicators (KPIs) setting criteria for service
availability and quality. Successful service operation requires seamless collaboration across teams and service
provider ecosystem.

Service providers, external and internal, are responsible for professional delivery of their services. They are also
responsible for managing the service delivery in such a way that all their services form an integrated entity. Service
operation activities are managed by dedicated line organisation or by the multi-expertise development and
operations team.

Service integration oversees the service quality and is responsible for unifying and harmonising service processes
across services and service providers. It is also responsible for ensuring a seamless integration of services for a better
user experience.

134
 6. Services

Measurement and analytics in service operations

Key Performance Indicators (KPIs) help organisations to understand how well services are performing in relation to
predefined goals and objectives. In a broad sense, KPIs can provide the most important performance information
enabling organisations or their stakeholders to understand whether the organisation is on track or not. Quite often
several individual Service Level Agreements (SLAs) affect common KPIs.

Service measurement examples:

SERVICE SERVICE OPERATIONS AND ECOSYSTEM

DELIVERY PROCESS PERFORMANCE PERFOMANCE

• Benefits •Lost business hours due to • SLA compliance /

realisation technology issues service provider
(should be close to 0)
• Development • SLA compliance total
costs / run costs • Number of issues, especially
trend: is the number increasing or • Net Promoter Score of
• End user decreasing selected service providers
satisfaction performance
• Average E2E resolution times of
supportive and repairing activities • Net Promoter Score Total

• Number of automated service

requests of all initiated requests

• % of services and solutions

supported by self-help

Analytics, performed by the service integration team or centre, is an essential activity to measure the performance
of service operations. As the requirements for the quality of services increase and business technology environments
become more complex, there is a need for qualified decisions based on intelligent and accurate information. Turning
large volumes of data into knowledge will enable forecasting and staying one step ahead of events.

Measurement and analytics should be a continuous process that proactively detects service status and potential issues
and provides comprehensible information that can be used to make preventive actions and improvements.

Service automation
Most organisations are constantly seeking new ways to increase the productivity and lower the operational costs.
This can be achieved by increasing the level of automation. There are many types of automation solutions for service
operations like for example:

135
6. Services

• Chatbots and virtual agents for customer interaction

• Workflows and machine learning for assisted or autonomous decision-making
• Robotic process automation and orchestration for process execution.

Robotics and Artificial Intelligence (AI) are emerging trends that are reshaping the world. They can improve
productivity, efficiency and flexibility of service operations. When using algorithms together with human workforce,
the algorithms learn and can take care of more and more of the routine tasks and thus leave the more complicated
and meaningful tasks to humans.
COGNITIVE AGENT Instant SOFTWARE ROBOTICS
scalability
Learn human behaviour Error-free handling
Natural language Consistent Speed of computing
quality
Monitors & adapts Simulates human actions
to human sentiments 24/7 Full traceability
Learns constantly availability

Human interface Robotic process automation

HUMAN Interacts with the
Process interface
Software tool that pergorm
TO DIGITAL Interacts with API to
human to specify and request processes multiple digital tasks in
perform required tasks an automated way

Can identify 90% Can automate Accurate logs

of human needs 60% of tasks and reports

Multiple times faster resolutions

Support
HUMAN 40% of interactions need human execution Centre
TO HUMAN
Unidentified needs of 10% require human interface

Service diagnostics
Figure 6.3.1 Cognitive agent and software robotics
Business Technology Standard
[Link]

Robotics and AI also need governance and that’s why integrating and managing them with a service management
platform is essential to maintaining the overall transparency and control of processes.

Automation solutions can be utilised for the following activities:

Interaction Decision-making Process execution

.
• Customer service • Automated approval • Process automation
chatbot for support management between multiple
systems
• Conversational self- • Machine learning based
service portal for easy ticket routing, prioritisation • Predictive
ordering and categorisation maintenance
tasks
• Voice-based virtual • Assisted or automated
assistant. incident resolution. • Data entry and
reporting.

136
 6. Services

6.4 Support and Service to Users

Service support responds to day-to-day questions from users, handles service requests and resolves incidents.
The range of users served by the service support can include customers and external partners as well as internal
employees.

Support and service request volumes are usually very high and variable. For example, service support has to be able
to solve and respond to both specific service requests, such as give instruction for using a specific service and routine
tasks like resetting a password.

To be able to handle the variety of service requests and solve incidents, service support is organised into tiers where
each tier has a different purpose and way of working. The two topmost tiers, self-service (tier 0) and service desk
(tier 1), interact directly with users and operate usually 24/7. Service desk agents are trained and instructed to
support users in all service-related questions. Requests that cannot be resolved by the service desk are assigned to
service delivery organisations or key users (tier 2). Cases requiring in-depth technical knowledge are assigned to
development teams or technology providers (tier 3).

“HOW DO I USE “Something “I have a QUESTION / “I want to

the process or system?” DOESN’T WORK” I need something NEW” IMPROVE”

CHANNELS Face Social

to face media Call Email Chat Portal

TIER 0
Virtual Agent Self-Service and Self-Help
and ITSM Tool

Workflow Automation Service

Integration
TIER 1 Manage
SPOC Service Desk service quality
and integration
over services and
On-Site Support service providers

TIER 2
Solution and Service Delivery Organisation
Service Teams Key Users in Business
TIER 3 Business Knowledge
Service Development Organisation

Business Technology Standard

[Link]
Figure 6.4.1 Service support tiers

Four types of user request

As illustrated in the picture above, support and service requests can be divided into four categories:

• “How do I use?” – This category refers to cases where the user is looking for help regarding how to do
something and is guided to visit the self-service portal. If further help is needed, the user is advised to contact
the service desk. If the request concerns a business process, the user is guided to contact a key user who works
in a business organisation and has more advanced business process and solution knowledge. Service desk
maintains a list of Frequently Asked Questions (FAQ) and user instructions in the self-help portal.
137
6. Services

• “It doesn’t work!” – This category means cases where the user has a problem because something does not
work properly. The problem may be caused by a broken device, malfunctioning software or a user who does
not know how to use the product. The support steps in these cases are similar to those mentioned above, but in
obvious cases, like those involving a broken product, users are provided an option to order a replacement. The
replacement process may automatically trigger an approval request which is managed via a service
management system. The request process may also initiate repair actions which can be carried out by a
technical agent visiting the user or accessing the device remotely

• “I need something new” – This category refers to cases where the user wants to order new services or
products. Users are provided with a user catalogue containing items that are predefined and followed by a
specific workflow consisting of approval requests, triggering the right people and services and keeping the user
updated on how the order is proceeding

• “I want to improve” – This category consists of service improvement proposals. The ideas are evaluated, and
the ones that are considered as feasible will be turned into development actions.

Self-service and self-help portals assist with predefined service requests and knowledge base articles to provide
instant service to users 24/7 and to resolve the FAQs. The use of self-service and self-help together with workflow
automation makes the support independent of time and place, thus increasing the user satisfaction and, at the same
time, lowering the operational costs. Self-service portal has become today the most important support channel and, in
fact, the only reason to name it as tier 0 is to keep the traditional convention to refer to the service desk as tier 1.

The term ‘portal’ is somewhat misleading as, nowadays, the self-service is like any organisation’s web page with fill-in
forms and search functionalities. The only difference is the use of the service management system providing service
catalogue, workflows for service requests and detailed service information as the logic behind the portal.

In order to gain high self-service portal usage levels, the focus during development must be put on enhancing the
user experience. Excellent end-to-end user experience can be achieved by utilising personalised content, user-
intuitive language, icons and terminology and promoting the relevant information. For example, customers and users
should only see the services available to them and be able to create requests without understanding the service
delivery organisation’s structure or processes. In addition, important information like need for an approval should be
highlighted when the order is in the approval stage.

138
 6. Services

Figure 6.4.2 Example of self-service portal

Digital service desk

Organisations are constantly seeking new ways to increase user satisfaction and lower operational costs. One way
to do this is to automate the support routines by establishing an artificial intelligence (AI) powered digital worker to
extend the human service desk (tier 1).
“HOW DO I USE “Something “I have a QUESTION / “I want to
the process or system?” DOESN’T WORK” I need something NEW” IMPROVE”

CHANNELS Face Social

to face media Call Email Chat Portal

TIER 0
Virtual Agent Self-Service and Self-Help
and ITSM Tool

Workflow Automation Service

Digital Worker Integration
TIER 1 Manage
SPOC Service Desk service quality
Business
and integration
Support Center
over services and
On-Site Support service providers

TIER 2
Solution and Service Delivery Organisation
Service Teams Key Users in Business
TIER 3 Business Knowledge
Service Development Organisation

Business Technology Standard

Figure 6.4.3 Digital service desk [Link]

139
6. Services

Figure 6.4.3 shows the use of a digital worker in a service desk. The digital worker interacts with the user in
natural language and initiates the service routines based on the dialogue. The advantage of a digital worker is its
capability to learn from use cases and provide the highest-level service to everyone independently of time and place
differences.

In the scenario illustrated above, the need for a traditional service desk is cut in half assuming that the digital worker
can understand 90% of the user requests and is able to automate 60% of the required actions. This lowers the cost
and changes the role of a human-operated service desk which, by consequence, has to deal less with routine work
and can take care of more advanced questions as well as give support to business changes. This way, the traditional
service desk is transformed into a business support centre which is an ideal way to support business excellence and
transformation in any company.

6.5 Continual Improvement and Retirement

Designing innovative services takes effort. However, even the best and most useful services need to be continuously
improved as the operational environment changes and users’ needs evolve. The main purpose of continual service
improvement is to align services with changing business needs.

In order to improve a service, it is essential to measure the current performance needs and define key metrics and
objectives. Evaluating the service performance on a regular basis and utilising reports and analytics tools allow the
service management to identify the improvement needs, assess them and turn them into improvement actions.

On top of measuring and monitoring the service, other sources of information should also be used as basis for
continual improvement. For example, a constant dialogue with business stakeholders supports understanding the
business environment and roadmaps. In addition, the users should be encouraged to give input concerning the update
needs of the service or the service experience through, for example, a self-service portal. Periodical user surveys are
also a good source for user feedback and help to follow the trends related to user needs.

Continual service improvement requires a certain service management maturity such as clear roles and matching
competence, well-defined tools and processes as well as a governance model.

Continual improvement also requires an active approach as well as a willingness and mindset to aim always for
better. Each area of continual improvement should have an owner with enough empowerment to make things happen.
Continual improvement activities should be built into the service management setup and the deliverables should be
reviewed on a regular basis.

Retirement of services
Retirement is the final stage in the service lifecycle. Service portfolio steering, after considering the relevant business or
service operations reasons, can authorise the retirement. In many cases, the retirement takes place after the release of
a new service replacing the existing one.

Service owners and managers are responsible for maintaining service plans and roadmaps relating to the underlying
technologies and solutions. In addition to the development initiatives, service roadmaps also indicate the ramp-downs

140
 6. Services

of services or their components. Ramp-down planningmust start well before the planned service retirement time and is
linked and synchronised with the development project of the possible replacing service.

Quality of operational data and configuration management database (CMDB) are key to identifying service item
relations and to avoiding unwanted impacts to other services. Up-to-date configuration data and service relations
enable proper ramp-down planning with minimised risk of surprises and unplanned downtime. Service integration will
coordinate actions to retire the service in a planned and controlled way.

141
 Appendix

142
 Appendix

7.0 Appendix - International Models and Standards

This chapter briefly describes the international technology management models and standards applied in the
development of the Business Technology Standard.

ITIL
ITIL, formerly known as Information Technology Infrastructure Library, is a set of guidelines and best practices for IT
service management (ITSM). It is a registered trademark of AXELOS Limited. ITIL focuses on aligning IT services to
the needs of businesses and supports its core processes. It is structured and published in five core volumes: service
strategy, service design, service transition, service operation and continual service improvement.

The framework that ITIL provides can be adapted and applied to all business and organisational environments. It
includes guidance for identifying, planning, delivering, and supporting IT services.

CMMI
CMMI®, Capability Maturity Model Integration®, is an internationally reputed reference model providing
guidance for improving processes to meet the business goals of an organisation. It is developed by industry experts,
governments, and the Software Engineering Institute (SEI). The framework supports coordination of multi-disciplinary
activities and systematic thinking.

COBIT
COBIT 5, the Control Objectives for Information and Related Technology, is owned and supported by ISACA. The
current version 5.0 consist of COBIT 4.1, VAL IT 2.0, and Risk IT frameworks.

COBIT 5 provides metrics and maturity models to measure whether or not the IT organisation has achieved its
objectives. It also balances the needs of internal and external stakeholders.

PMBOK
PMBOK, the Project Management Body of Knowledge, is a set of standard terminology and guidelines based
on internationally recognised project management methods provided by the Project Management Institute (PMI).
PMBOK is a widely accepted and acknowledged standard and used as basis of many other project management
methods.

PMBOK provides an in-depth description of the required content and fundamentals of a project but does not focus on
giving hands-on implementation advice.

143
Appendix

PRINCE2
PRINCE2, Projects IN a Controlled Environment, is a de facto standard project management method owned by the
UK Cabinet Office. PRINCE2 complements the PMBOK model by providinga process-based and practical guidance
with ready-to-use templates for Project Managers and project steering groups in the different phases of a project.
PRINCE2 ensures greater control of resources and effective management of business and project risks.

ISO/IEC 20000
ISO/IEC 20000 is a service management system (SMS) and the first international standard for IT service
management. It is owned by The International Organisation for Standardisation (ISO) and the International
Electrotechnical Commission (IEC). It is broadly aligned with ITIL.

The ISO/IEC 20000 has two parts. The first part defines the formal requirements for high-quality production of IT
services to the business. It includes criteria for planning, service management, and service production as well as for
customer / supplier management. The second part describes the processes of service production largely in the same
way as the ITIL processes while focusing, however, more closely on customer/supplier management processes.

ISO 21500
ISO 21500 is a standard that provides generic guidance on the concepts and projects of project management. It can
be used by any type of organisation and applied to any type of project – irrespective of size, complexity or duration.

ISO 21500 is an informative standard rather than a certified methodology. It provides a high-level description of
concepts and processes that are considered to form good practice in project management and places projects in the
context of programmes and project portfolios. PMBOK is very much in line with ISO 21500 and vice versa.

ISO/IEC 38500
ISO/IEC 38500 is a standard providing general principles for IT governance especially to managers with the
highest level of business responsibility (such as board of directors and management team). It can be widely applied to
all kinds of organisations of varying sizes, including public and private companies and non-profit organisations.

TOGAF
TOGAF the Open Group Architecture Framework, is an enterprise architecture framework that allows organisations to
have a structured approach for governing the implementation of technology related especially to software technology
design, development and maintenance. It was first published in 1995 and was based on the US Department of
Defence Technical Architecture Framework for Information Management (TAFIM). It has been since developed by The
Open Group Architecture Forum and released in regular intervals on the Open Group public website.

TOGAF aims at improving business efficiency by ensuring consistent methods, communication and efficient usage of
resources. It ensures industry credibility with a common language among enterprise architecture professionals.

144
 Appendix

SAFe
SAFe, Scaled Agile Framework is a framework and a set of best practices for enterprises for scaling agile
development. The base of SAFe was developed in 2008 by Dean Leffingwell and is nowadays freely available by
Scaled Agile, Inc.

SAFe has its emphasis on continuous improvement and managing workflows instead of single projects. It has gained
influence from three main disciplines: agile software development, lean product development and systems thinking.
The aim is to support alignment, collaboration and delivery across many agile teams.

DevOps
DevOps, “Development” and “Operations”, is a methodology for software development. It has its basis in lean
and agile approaches and consists of different methods, practices and tools or toolchains. By combining software
development (Dev) and information technology operations (Ops), the aim is to shorten the systems development life-
cycle, ensure high quality of productivity as well as provide fixes and updates that contribute to business objectives.

IT4IT
IT4IT is an open standard providing an IT framework for delivering value for business created by Open Group. It is
vendor and technology-neutral reference architecture and operative model for leading business IT. IT4IT is based
on value chain concept known as the IT Value Chain that has four value streams: strategy to portfolio, requirement to
deploy, request to fulfil and detect to correct. The aim is to provide structure and tools for organising IT.

SIAM
SIAM, Service Integration and Management, is an approach for managing multi-sourced service suppliers and
integrating them to support a single business-facing IT organisation. SIAM is not a process, but rather a model for
building service capability with a collection of best practices and tools. The aim is to provide better service to end-
users via enhanced cost-efficiency, increased accountability and flexibility.

145
 Who we are

146
Who We Are
The Business Technology Forum (or BT Forum) is a non-profit professional organisation consisting of a community of
forerunner companies, and public organisations collaborating according to platform economy model.

The BT Forum provides business and technology leaders with an open-source technology management framework
called the Business Technology Standard. The BT Standard consists of best practices, models and tools developed
together with the BT Forum community in order to plan, build and run information technology in today’s technology-
driven business world.

The BT Forum coordinates the development work within the community members and publishes an upgraded
version of the BT Standard twice a year. In addition the BT Forum also organises events and conferences, publishes
educational materials and offers training courses to advance the business technology management profession.

Follow Business Technology Forum on Linkedin and Twitter to stay updated with the latest news!

Contact us: info@[Link]

147
 Mindset Model

148
 Roles and Responsibilities Model

SMART
CIO GOVERNANCE

SOURCING BTGO CISO

LEAD

BTMO BTPO GOV LEAD

BIO / PROJECT
SERVICE BTSO BTOO
MANAGER
OWNER
BUSINESS
BUSINESS ENTERPRISE AND PROCESS SERVICE OPS LEAD
CAPABILITY ARCHITECT DEVELOPMENT MANAGER / EXPERT
OWNER
BUSINESS BUSINESS SOLUTION SERVICE
CDO
EXCELLENCE OWNER LEAD / EXCELLENCE
EXPERT
PRODUCT PRODUCT SERVICE
INNOVATION TECH /
OWNER / AND SERVICE INTEGRATION
LEAD SERVICE
BUSINESS DEVELOPMENT LEAD / AGENT
ANALYST EXPERT
BTDO / SCRUM SOLUTION
MASTER / KEY USER
DATA LEAD ARCHITECT
/ EXPERT DEV LEAD

Business Technology Standard

[Link]
 Capability Model

150
Operating Model with
End-to-End Flow
 [Link]

152