Service-Driven Approach (SDA)

Introduction

Holistic enterprise development can be supported by the Service-Driven Approach (SDA), which focuses on services (instead of projects) as primary units of  value creation, design, development and operations. The SDA combines both customer oriented (“outside-in”) and organization internal behavior and structure oriented (“inside-out”) approaches. By focusing on services, enterprise development (or an IT function) can be organized as a “production line” that produces services. The SDA can be supported by practical and simple model-based method, which concentrates on service life-cycle.

Service-Driven Thinking

The service concept is crucial, according to idea where “everything is a service“: everything can be provided and consumed as a service. Again, everybody are (service) architects, given that everyone works in the production line of service delivery value chain. The SDA is a practical and simple method for execution of lean and agile Enterprise Architecture (EA) in practice, together with Service Design (Design Thinking) approach.

Characteristics of a service: All the development targets are services by nature, all the organizational capabilities provide services, customer-orientation is related to service-centric thinking, value can be linked to a service etc. Services are designed based on customer needs and other business demands, as well as existing and required capabilities of the organization. Services can be associated with values they deliver in the overall value chain of the organization.

Services can be designed, developed and deployed independently as autonomous Building Blocks (those of which can be associated to Microservices, Cloud services and API-economy approaches). All the services can be linked backwards to business demands and finally to strategic goals via capabilities of the organization. SDA can be supported by practical and pragmatic model-based method, utilizing ArchiMate notation and appropriate modelling tool. As such, SDA enables traceability between all the elements that are related to services with an organization and its environment.

From the IT organization point of view, the holistic enterprise development that is based on the SDA, can be organized according to a value-chain based operational model. This “production line” produces services from “ideas to production”. All the organization structures (such as groups, units or functions) and capabilities are integrated into this production line, which is operated according to Lean and agile principles. Work within this production line is managed with a single backlog of development items, and related tasks are followed with a Kanban board. This simplified, pragmatic and light-weight process provides overall visibility and transparency, and it is based on co-operation and collaboration between the actors and roles.

Service Concept

The Service-Driven Approach (SDA) is focused on services as primary units of value creation, design, development and operation. A service encapsulates all the behavior and structure into one concept, which can be logically and physically regarded as an autonomous entity. The Service-Driven Approach concentrates on individual services as vertical slices of the organization’s architecture landscape. Initially, the services are planned based on customer needs by utilizing modern Service Design concepts and methods. Secondly, those services are developed and deployed according to DevOps practices, independently as autonomous Operation Building Blocks (OBB), that are operated as IT-services. All the services are linked with strategic goals of the organization, which connections supports the strategy execution.

Abstract “Service” concept can be divided into more specialized service categories as illustrated in the figure below.

There can be identified several types of services as follows (according to ArchiMate and TOGAF):

1. Business Service 
– A business service represents an explicitly defined exposed business behavior
– A business service is associated with a value (e.g. add value to customer or to the organization, “outside-in” or “inside-out” viewpoints)
– A business service can be realized by a business process or -function, to which an organization structure (such as unit or group or role) can be assigned
– A business service can be realized by manual and automated phases, some of which can be supported or performed by application services
2. Application Service
– An application service represents an explicitly defined exposed application behavior (application function or application process)
– An application service exposes the functionality of an application to its environment
– This functionality is accessed through one or more application interfaces
– An application service can be associated with a Use Case (or System Case)
3. Technology Service
– A technology service represents an explicitly defined exposed technology behavior
– A technology service exposes the functionality of a node to its environment
– This functionality is accessed through one or more technology interfaces
– technology services may include e.g. messaging, storage, naming, and directory services

4. IT-service
– An IT-service can be a combination of service types 1-3, but it is closely related to application services
– according to ITIL definition:
– A service provided by an IT service provider
– An IT service is made up of a combination of information technology, people and processes
– A customer-facing IT service directly supports the business processes of one or more customers and its service level targets should be defined in a service level agreement

Service types according to ArchiMate -notation illustrated in the figure below.

Service vs. Product

Product -concept can be used as a composite element for grouping services. According to ArchiMate -specification:

“A product may aggregate or compose business services, application services, and technology services, business objects, data objects, and technology objects, as well as a contract. Hence a product may aggregate or compose elements from other layers than the Business Layer. “

“A value may be associated with a product. The name of a product is usually the name which is used in the communication with customers, or possibly a more generic noun (e.g., “travel insurance”).”

Product -term use cases:

• as a marketing term for a service
• as a production term in an agile method, when a development team is organized around a product (instead of project) to produce service(s)

According to John Spacey (link), “there is a significant shift in many industries towards wrapping all products in value added services. Services also allow businesses to establish closer relationships with customers”.

From the architecture point of view, usually a product can be associated with one or more services, which in turn represent the functionalities of the product.

Method

The Service-Driven Approach is simplified in the figure below. It is important always to analyse WHY before WHAT (inspired by Simon Sinek’s “Start With Why”). The purpose for the change before defining the behavioral and structural parts of the change / service. A service can be e.g. a) business change in the form of business service (that encapsulates concerning business processes and business functions), or b) application change in the form of application service (that encapsulates application components, application functions and -processes).

Framework

Implementing SDA by integrating it within holistic enterprise development, can be done by utilizing the Lean EA Framework (LEAF ), which supports the overall Lean Enterprise Architecture Development (LEAD) method. This method is focusing on service delivery value chain.

Digram Types

When designing services, it can be performed by using appropriate architecture modelling tool. Lots of things can be modelled by various ways and styles. However, to be professional, a systematic approach is the most preferable. Here is introduced few most useful diagram types, with which most of the cases can be modelled:

1. Goals View – for analysing WHY certain service is important (drivers, goals, added value, principles, requirements etc.)
2. Layered View – for analysing WHAT are the building blocks related to a service or to group of services (processes, applications etc.)
3. Interaction View – for analysing co-operation between a) actors, b) processes or c) applications.

There are also other diagram types that can be used when necessary, such as:

• Business Model Canvas (BMC) – for analysing business case
• SWOT – for analysing internal strengths and weaknesses, as well as external opportunities and threats
• Service Blueprint and Customer Journey – for analysing HOW a service interconnects customer view with organization view
• Conceptual Data Model – for analysing the concepts and their relations concerning specific problem domain, such as service area

Examples of these diagrams can be found from this blog (e.g. from here).

Examples

Goals View

Layered View

Simplification of Layered View, which is focused on services and service layers (figure below). Services bind the elements in layers together into one overall view of the behavior and structure of the development target.

Interaction View

Whenever a service or service area needs some more high-level, overall clarification, some information flows can be identified. Most useful integration views are as follows: 1) Actor Interaction View, 2) ProcessInteraction View and 3) Application Interaction View.

Actor Interaction View

Business Process Interaction View

Application Interaction View

Other diagram types

Business Model Canvas (BMC)

Service Blueprint

The Service Blueprint is built around services on different layers. The Service Blueprint is based on the Layered View.

Customer Journey

This is an applied version of a customer journey, in which services play an important role. A business service is serving the customer, which is using the service by flowing on service journey path. Each phase of the service path is served by certain application services. As such, a service is meaningful concept to analyze what’s happening in a customer / service journey.

Conceptual Data Model

Actors And Roles

Example business actors and -roles related to Service-Driven Approach are introduced in the figure below (actor symbol is stick figure, role is cylinder).

Note! Service Owner -role is analogous to Product Owner (PO) -role, as it the same responsibilities can be assigned to it. Service Architect role is analogous to conventional Solution Architect role.

The role and meaning of all the business actors or -functions are to be considered: why are they needed, what is the added value they provide. Those can be analyzed with the help of value stream modelling. The purpose of some actors can change dramatically (e.g. project management,  service management or product management).

In SDA there is three levels of architectures and related architect roles:

1. Enterprise Architecture (Enterprise Architect role)
2. Domain Architecture / Capability Architecture (Domain Architect role)
3. Solution Architecture (Solution Architect role, or Service Architect role)

SDA is supported by architecture. No matter what is the level of architecture (enterprise, domain or solution), as same methods and tools are used. The overall enterprise architecture content is depending on domain architectures, that consists of solution architectures. According to Lean and agile principles, architecture artifacts are created on demand just-in-time basis. Architecture work is mostly done in the solution level (80%).

Service-Driven Operating Model

The development operating model of the organization can be defined as a value stream, in which services flow through the “production line”. First the services are designed as service concepts, then developed as logical services, and finally deployed to production as realized services. A service can be designed e.g. based on certain viewpoints, such as customer perspective (outside-in) or intra-organizational perspective (inside-out). The basic idea of this simple process is illustrated in the figure below.

The “Service Design” phase shown in the process diagram above, is abstraction of actions to be taken when planning a service. The service can be e.g. a) business service, that is related to processes, or b) application service, or c) technology service, or d) combination of these. The Service Design phase can utilize the most appropriate methods and tools – depending on the case. As the incoming demands can vary from their characteristic, they are all handled as ideas in the very first ideation step of the Service Design phase. Some ideas may trigger an experimental innovation step, from which it is possible to get quick customer feedback.

The “Service Development” phase represents the development actions that are taken after service concept is created. The Service Development produces a concrete, realized service, that can be deployed on production.

The “Service Operation” represents the continuous services that are managing realized services on production.

The idea in this process is to manage end to end activities within the same production line, to make all the service life-cycle visible in the organization. In addition, all the required actors and roles can be identified and assigned to phases of the process. Again, all the information accessed and concrete deliverables can be identified and linked to the phases of the process.

Conclusions

Service-Driven Approach (SDA) is an enterprise development method, in which the service-concept is crucial. It is all about services: ideation, creation and operation of development targets is related to the concept of service. A service can be associated with value. As such, when developing new ideas to production, it is question of  delivering services within a value stream. The value stream consists of phases to design, develop and operate services. All the phases are performed by specific actors, each of which provide added value to this production line. The SDA approach can be supported by modelling, which provides systematic method for identifying relevant behavioral and structural building blocks. There is a generic process for the value stream (introduced above), which can applied and adjusted for organization specific purposes.

 

---

Concepts

Goals are the primary initiators for all the development activities of an organization. All the goals shall be derived from strategic goals of the organization. As such, this approach is aligned with so called “Goal-Based Strategy Model” (Azevedo et al. 2015). ArchiMate motivation concepts can be used for defining the purpose of each service, the question WHY this specific services or group of services are important.

Business model can used as starting points to design services or required capabilities. This approach utilize tools such as Business Model Canvas (BMC)  and Value Proposition Canvas for quick analysis of the planned services. This enables fast learning with small amount of work, to give the first feedback about the planned services before the development starts.

Capability = A capability represents an ability that an active structure element, such as an organization, person, or system, possesses [ArchiMate]. Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people,
processes, and technology to achieve [Togaf]. Capability concept is used e.g. in Togaf, ArchiMate, and SAFe.

Capabilities represent the current and desired abilities of an organization, in relation to its strategy and its environment. Capabilities are realized by various elements such as people, processes and systems. The importance of capabilities as central concepts, is related to their role and meaning to link the goals to enterprise architecture – the behavior and structure of the organization. Another definition for capability is as follows: “a capability is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome”. The Capability-Based Planning (CBP) technique can be utilized when developing capabilities. CBP can be used to set investment priorities that would deliver the most value to an organization, according to the organizational strategy. When developing an organization, concept of “capability” is to be used as a fundamental building block.

Customer-centricity = develop business to provide a positive Customer Experience (CX), to ensure delivering customer value. The development method shall comply with the customer centricity

Continuous Improvement = streamlining work and reducing unnecessary efforts, costs, delays etc. – continuously – are guiding principles for the development work and for the development method and practices

Feature = A feature is a service provided by the system that fulfills stakeholder needs. Each feature includes a statement of benefits and defined acceptance criteria [SAFe].

Holistic Enterprise Development is an overall view, in which an enterprise refers to an organization (or ecosystem), which is by nature, a dynamic socio-technical “system” – a “system of systems” – as it consists of number of distinct systems (combinations of processes, people, applications etc.). Those systems are interrelated and interdependent on each other. Holistic enterprise development approach covers all the development aspects from strategy planning to operations. This approach supports organization’s mission, vision and strategy execution by developing business-driven capabilities to produce services and products to customers. Holistic approach which observes the enterprise as a whole: not any distinct part or aspect, but the completeness. It applies systems thinking: an enterprise is a complex “system of systems”, it is more than the sum of its parts. It is a “network of elements and relations between them”.

Kanban board is used to manage and to visualize all the development tasks and activities.

Operations aspect links developed services to concrete, deployed IT-services. If necessary, additional data can be imported from other systems such as CMDB or ITSM, to provide more information concerning running IT-services.

Portfolios are used to manage all the ideas, services under development and services in production, as well as other assets such as applications, projects.

Service = An overloaded term, which can be referred to as follows:

1) A “business service” that is provided by the organization to its customers, which can be associated with value

2) An “application service” that is provided by an application, to support processes and business services of the organization, which can be associated with value

3) A “technology service” that supports applications by providing needed platform and infrastructure (can be also referred to “platform service” or “infrastructure service”), can be associated with value

4) An “IT-service” that is defined as follows: “A means of delivering value to customers by facilitating outcomes customers want to achieve” (ITIL Glossary).

Note! An “application service” (2) is also closely related a “microservice“, which is a fundamental unit of development in Microservices Architecture (MSA).  A microservice is suitable for agile and DevOps -styled development, as microservices are autonomous by their nature. Whole system landscape can be built up based on small microservices, which makes the whole enterprise/ecosystem more agile and flexible for continuously changing conditions in a modern volatile business environment. Microservices are also analogous to APIs (Application Programming Interfaces), as microservices expose their operations via “application interfaces” that are made available via so called “APIs”. In addition, a MSA is an opposite architecture style compared to traditional monoliths. The benefit of using microservices comes with the agility and speed of their design, development and deployment. Every changes into monolith systems cause time consuming and expensive development cycles. However, in reality the system landscapes in large organizations are often combinations of different architecture styles and development practices – which leads to so called “Bimodal IT” (see Gartner’s definition here )…

Services represent substantial and valuable behaviors that the organization provides to its customers. In addition to those business services that can be associated with value, there are enabler services that support the business processes and -functions that realize the topmost business services. These supporting services can be e.g. application services and technology- or infrastructure services. All the services participate to support the goal-based capabilities. For service design, several useful methods can be used, such as Customer Journey Map and Service Blueprint.