Service-Driven Thinking<\/h2>\n
The service concept is crucial, according to idea where “everything is a service<\/em>“: 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.<\/p>\n Characteristics of a service<\/strong>: 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.\u00a0Services can be\u00a0associated with\u00a0values they deliver in the overall value chain of the organization.<\/p>\n Services can be\u00a0designed, developed and deployed independently\u00a0as autonomous Building Blocks <\/em>(those of which can be associated to Microservices, Cloud services<\/em> and API-economy<\/em> approaches). All the services can be linked backwards to business demands and finally to strategic\u00a0goals 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\u00a0traceability<\/strong> between all the elements that are related to services with an organization and its environment.<\/p>\n 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<\/strong> and transparency<\/strong>, and it is based on co-operation and collaboration<\/strong> between the actors and roles.<\/p>\n The Service-Driven Approach (SDA)<\/em> is focused on services as primary units of value creation, design,\u00a0development 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<\/strong><\/em> concepts and methods. Secondly, those services are developed and deployed according to DevOps<\/strong><\/em> practices, independently\u00a0as autonomous Operation Building Blocks (OBB)<\/em>, that are operated as IT-services<\/em>. All the services are linked\u00a0with strategic\u00a0goals of the organization, which connections supports the strategy execution.<\/p>\n Abstract “Service” concept can be divided into more specialized service categories as illustrated in the figure below.<\/p>\n There can be identified several types of services as follows (according to ArchiMate and TOGAF):<\/p>\n 1. Business Service\u00a0<\/strong> 4. IT-service<\/strong> Service types according to ArchiMate<\/a> -notation illustrated in the figure below.<\/p>\n Product -concept can be used as a composite element for grouping services. According to ArchiMate -specification:<\/p>\n “A product represents a coherent collection of services and\/or passive structure elements, accompanied by a contract\/set of agreements, which is offered as a whole to (internal or external) customers.”<\/p>\n<\/div>\n<\/div>\n<\/div>\n “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. “<\/p>\n “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., \u201ctravel insurance\u201d).”<\/p>\n Product -term use cases:<\/p>\n According to John Spacey (link<\/a>), “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”.<\/p>\n 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.<\/p>\n 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).<\/p>\n Implementing SDA by integrating it within holistic enterprise development, can be done by utilizing the Lean EA Framework (LEAF<\/strong>\u00a0)<\/em><\/a>, which supports the overall\u00a0Lean Enterprise Architecture Development (LEAD)<\/em><\/strong><\/a>\u00a0method. This method is focusing on service delivery value chain.<\/p>\n 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:<\/p>\n There are also other diagram types that can be used when necessary, such as:<\/p>\n Examples of these diagrams can be found from this blog (e.g. from\u00a0here<\/a>).<\/p>\n Simplification of Layered View<\/em>, 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.<\/p>\n 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.<\/p>\n The Service Blueprint is built around services on different layers. The Service Blueprint is based on the Layered View.<\/p>\n 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.<\/p>\n Example business actors and -roles related to Service-Driven Approach are introduced in the figure below (actor symbol is stick figure, role is cylinder).<\/p>\n Note! Service Owner<\/em> -role is analogous to Product Owner (PO)<\/em> -role, as it the same responsibilities can be assigned to it. Service Architect<\/em> role is analogous to conventional Solution Architect role.<\/p>\n 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,\u00a0\u00a0service management or\u00a0product management).<\/p>\n In SDA there is three levels of architectures and related architect roles:<\/p>\n 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%).<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n The “Service Operation” represents the continuous services that are managing realized services on production.<\/p>\n 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.<\/p>\n 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\u00a0 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.<\/p>\n <\/p>\n Goals<\/strong> <\/em>are\u00a0the primary initiators for all the development activities of\u00a0an 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<\/em>” (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.<\/p>\n Business model<\/strong><\/em>\u00a0can used as starting points to design\u00a0services or required capabilities. This approach utilize tools such as\u00a0Business Model Canvas (BMC) \u00a0<\/em>and Value Proposition Canvas<\/em>\u00a0for 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.<\/p>\n Capability<\/strong><\/em> = A capability represents an ability that an active structure element, such as an organization,\u00a0person, or system, possesses [ArchiMate]. Capabilities are typically expressed\u00a0in general and high-level terms and typically require a combination of organization, people, Capabilities\u00a0<\/em>represent the current and desired abilities of an organization, in relation to its\u00a0strategy and its environment. Capabilities\u00a0are realized by various elements such as people,\u00a0processes\u00a0and systems. The importance of capabilities as central concepts, is related to their role and meaning to\u00a0link the goals to enterprise architecture\u00a0–\u00a0the 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\u00a0exchange to achieve a specific purpose or outcome”. The Capability-Based Planning (CBP)\u00a0technique can be utilized when developing capabilities.\u00a0CBP can be used to set\u00a0investment priorities that would deliver the most value to an organization, according to the organizational\u00a0strategy. When developing an organization,\u00a0concept of \u201ccapability\u201d is to be used as a fundamental building block.<\/p>\n Customer-centricit<\/em>y<\/strong> = develop\u00a0business to\u00a0provide a positive Customer Experience (CX),\u00a0to ensure delivering\u00a0customer value. The development method shall comply with the customer centricity<\/p>\n Continuous Improvement<\/strong> <\/em>=\u00a0streamlining work and reducing\u00a0unnecessary efforts, costs, delays etc. – continuously – are guiding principles for the development work and for the development method and practices<\/p>\n Feature<\/strong><\/em> = 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].<\/p>\n Holistic Enterprise Development<\/strong><\/em>\u00a0is 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\u00a0supports organization\u2019s mission, vision and strategy execution by developing business-driven capabilities to produce services and products to customers.\u00a0Holistic approach which observes the enterprise as a whole: not any distinct part or aspect, but the completeness.\u00a0It 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”.<\/p>\n Kanban board<\/strong><\/em> is used to manage and to visualize all the development tasks and activities.<\/p>\n Operations<\/strong> <\/em>aspect links developed\u00a0services\u00a0to 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.<\/p>\n Portfolios<\/strong>\u00a0<\/em>are used to manage\u00a0all the ideas, services under development and services in production, as well as other assets such as applications, projects.<\/p>\n Service<\/strong> <\/em>= An overloaded term, which can be referred to as follows:<\/p>\n 1)\u00a0A “business service” that is provided by the organization to its customers, which can be associated with value<\/p>\n 2)\u00a0An “application service” that is provided by an application, to support processes and business services\u00a0of the organization, which can be associated with value<\/p>\n 3)\u00a0A “technology service” that supports applications by providing\u00a0needed platform and infrastructure (can be also referred to “platform service” or “infrastructure service”),\u00a0can be associated with value<\/p>\n 4)\u00a0An “IT-service” that is defined as follows: “A means of delivering value to customers by\u00a0facilitating outcomes customers want to achieve” (ITIL Glossary<\/a>).<\/p>\n Note!<\/em> An “application service” (2) is also closely related a\u00a0“microservice<\/a>“, which\u00a0is a fundamental unit of development in Microservices Architecture (MSA)<\/em><\/a>.<\/em>\u00a0 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\u00a0also analogous to APIs (Application Programming Interfaces), as microservices expose their\u00a0operations via “application interfaces” that are made available via so called “APIs”. In addition, a\u00a0MSA 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\u00a0reality 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\u00a0here <\/a>)…<\/p>\n Services <\/em>represent substantial and valuable behaviors that the organization provides to its customers. In addition to those business services <\/em>that can be associated with value, there are enabler services that support the business processes and -functions that realize the topmost business services. These\u00a0supporting services can be e.g. application services<\/em>\u00a0and technology- <\/em>or infrastructure services<\/em>.\u00a0All the services participate to support the goal-based capabilities. For service design, several useful methods can be used, such as Customer Journey Map\u00a0and\u00a0Service Blueprint.<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" Introduction Holistic enterprise development can be supported by the\u00a0Service-Driven Approach (SDA), which focuses on services (instead of projects) as primary units of\u00a0 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 […]<\/p>\n","protected":false},"author":1,"featured_media":2817,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,10,27],"tags":[],"class_list":["post-1434","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-archimate","category-enterprise-architecture","category-service-driven-approach"],"yoast_head":"\nService Concept<\/h3>\n
![\"\"](\"http:\/\/www.hosiaisluoma.fi\/blog\/wp-content\/uploads\/2018\/10\/Service-Concept.jpg\")
<\/a>
\n– A business service represents an explicitly defined exposed business behavior
\n– A business service is associated with a value (e.g. add value to customer or to the organization, “outside-in” or “inside-out” viewpoints)
\n– 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
\n– A business service can be realized by manual and automated phases, some of which can be supported or performed by application services
\n2. Application Service<\/strong>
\n– An application service represents an explicitly defined exposed application behavior (application function or application process)
\n– An application service exposes the functionality of an application to its environment
\n– This functionality is accessed through one or more application interfaces
\n– An application service can be associated with a Use Case (or System Case)
\n3. Technology Service<\/strong>
\n– A technology service represents an explicitly defined exposed technology behavior
\n– A technology service exposes the functionality of a node to its environment
\n– This functionality is accessed through one or more technology interfaces
\n– technology services may include e.g. messaging, storage, naming, and directory services<\/p>\n
\n– An IT-service can be a combination of service types 1-3, but it is closely related to application services
\n–\u00a0according to ITIL definition:
\n– A service provided by an IT service provider
\n– An IT service is made up of a combination of information technology, people and processes
\n– 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<\/p>\n<\/a>Service vs. Product<\/h3>\n
<\/a>\n
Method<\/h2>\n
<\/a>Framework<\/h3>\n
Digram Types<\/h3>\n
\n
\n
Examples<\/h3>\n
Goals View<\/h4>\n
<\/a>Layered View<\/h4>\n
<\/a>Interaction View<\/h4>\n
Actor\u00a0Interaction View<\/h5>\n
<\/a>Business Process Interaction View<\/h5>\n
<\/a>Application\u00a0Interaction View<\/h5>\n
<\/a>Other diagram types<\/h3>\n
Business Model Canvas (BMC)<\/h4>\n
<\/a>Service Blueprint<\/h4>\n
<\/a>Customer Journey<\/h4>\n
<\/a>Conceptual Data Model<\/h4>\n
<\/a>Actors And Roles<\/h3>\n
<\/a>\n
Service-Driven Operating Model<\/h3>\n
Conclusions<\/h2>\n
<\/a>
\n<\/h2>\n
Concepts<\/h2>\n
\nprocesses, and technology to achieve [Togaf]. Capability concept is used e.g. in Togaf, ArchiMate, and SAFe.<\/p>\n