Available online at ScienceDirect. Procedia CIRP 60 (2017 ) th CIRP Design 2017

Transcription

1 Available online at ScienceDirect Procedia CIRP 60 (2017 ) th CIRP Design 2017 Bridging On-site Practices and Design Principles for Service Development Shigeru Hosono a *, Yoshiki Shimomura a a Tokyo Metropolitan University, 6-6 Asahigaoka, Hino, Tokyo , Japan * Corresponding author. Tel.: address: s-hosono@tmu.ac.jp Abstract The significance of collaboration between developers and operators has increased through service lifecycles, as they are expected to explore their clients pains and co-create new ICT systems for their business opportunities through a number of trials. However, such agile development has caused conflicts with the conventional development management, which assumes waterfall development. This development process is administrated by the progress of documents statuses, such as created, reviewed, updated, and finalized, at development sites. This paper introduces a document-concern-design model to indicate developers their associated tasks to update specific sections of documents during their repetitive work between development and operation. The model incorporates three domains - document review process, concern, and design principle - with linking them one-by-one and form a single structure. This procedure enables to adapt any on-site local rule of design and development. Hence, the system can be introduced to any developers site with little adaptation cost. Then, this mechanism can accelerate various collaborative activities between developers and operators and guide their deliverables The Authors. Published by Elsevier by Elsevier B.V. This B.V. is an open access article under the CC BY-NC-ND license ( Peer-review under responsibility of the scientific committee of the 27th CIRP Design Conference. Peer-review under responsibility of the scientific committee of the 27th CIRP Design Conference Keywords: DevOps (development and operation); design principles; collaboration; concerns; tasks 1. Introduction ICT (information and communication technologies) service providers have provided systems integration services to their clients. Systems engineers implement software components, build on-premise ICT system infrastructures with hardware products, and support ICT system troubles in operation. The clients expect a high degree of perfection of the functions of ICT system infrastructure as the result of integration services. However, their expectation has changed from implementation and integration to valuable experiences through ICT service lifecycle, as such infrastructures can be easily integrated with software and hardware functions from cloud services [1]: infrastructure as a service (IaaS), platform as a service (PaaS) and software as a service (SaaS) (Fig.1). While a number of such cloud services have been marketed, systems engineers are urged to extend their roles from the middle to early and later phases of service lifecycle; designing conceptual service systems and improving the services for the next generation (Fig.2). These phases require continuous practices of hypothesis and verification to lift recently emerged business and technical constraints. However, this process is irreconcilable with the waterfall development process management, which is in widespread use in business. Fig. 1 Cloud services Fig.2 Service practitioners role through lifecycle The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license ( Peer-review under responsibility of the scientific committee of the 27th CIRP Design Conference doi: /j.procir

2 Shigeru Hosono and Yoshiki Shimomura / Procedia CIRP 60 ( 2017 ) The continuous practices will go back and forth. For example, the position of development progress will go back to earlier phases when revising specification become imperative after a prototype evaluation. Such iterative work can be done with a group of developers and operators. Their co-creative activities and culture has become significant, and symbolized as DevOps [2-3]. However, this iterative and gradual progress in collaboration is hard to administrate under the conventional ways of project management, which assumes that development progress should follow waterfall models. Advancement of projects are typically monitored by the completion of tasks in a structured task set i.e. workbreakdown-structure (WBS), and by decisive milestones of document reviews and approvals. However, such inflexible procedures cannot be applicable to development sites as it is. The adaptation work by modifying and realigning the standard WBS is costly for them. Therefore, it is urgent to provide mechanisms to developers, operators and administrators for task and document control. 2. Related Work 2.1. Lifecycle Management for ICT Infrastructure Services Lifecycle management approaches for ICT infrastructure services have presented best practices of service delivery and discuss how service development and operation phases can be streamlined and what targets the service practitioners should pursue in each phase. ITIL (IT Infrastructure Library) [4], COBIT (Control objectives for information and related technology) [5], and IT4IT (IT for IT) [6] are lifecycle management frameworks for ICT services, though their deliverables arise from a difference in management angles ITIL ITIL is a series of documents, which are used to aid the implementation of a lifecycle framework for IT (information technology) service management. This customizable framework defines how service management is applied within an organization. It is also aligned with the international standard, ISO [7]. ITIL is organized into a series of five elements: service strategy, service design, service transition, service operation and continual service improvement. These elements in turn describe a closed loop feedback system, which provides feedback throughout all stages of the lifecycle. The ITIL books for each element provide best practices and disciplines behind them to provide ICT services effectively; thereby ITIL does not provide concrete tasks or procedures. They are vested in the discretion of individual practitioner s interpretation COBIT COBIT is an ICT governance framework and supporting toolset, which allows managers to bridge the gap between control requirements, technical issues and business risks. COBIT enables clear policy development and good practice for ICT control throughout organizations. COBIT emphasizes regulatory compliance, helps organizations to increase the value attained from ICT, enables alignment and simplifies implementation of the enterprises ICT governance and control framework. COBIT refers to organization, though it does not give much thought to individual actions in organizations IT4IT IT4IT defines reference architectural standards, which comprises a reference architecture and a value chain-based operating model for managing the business of information technology. A value chain is a series of activities that an organization performs to deliver valuable products and services. While products pass through activities of a chain in order, the products gain value at each activity. Introducing a framework of this value chain to ICT providers will help identify the activities that are especially important for the advancement of strategy and attainment of goals. The value chain is grouped into two main categories of activities: (1) primary activities, which are concerned with the production or delivery of goods/services, and (2) supporting activities, which facilitate the efficiency and effectiveness of the primary activities. The IT4IT standard breaks down the value chain into four value streams to help adoptability of the IT4IT reference architecture. Each value stream represents a key area of value that ICT provides the comprehensive service lifecycle. The four primary value streams are (1) strategy to portfolio, (2) requirement to deploy, (3) request to fulfill, and (4) detect to correct. The primary value streams for the ICT value chain generally align to what ICT traditionally calls plan, build, deliver, and run. When it is used with an ICT value chain-based model, this is transformed into plan, source, offer, and manage. These value streams have vital roles in helping to holistically run the whole service lifecycle. In this way, IT4IT examines the activities through lifecycle. However, the discussion about activities of each value stream is abstract and there still exists gaps to the practices at development sites, where document-based project management is expected. As observed above, the previous work does not describe tangible practices but shows ideal practices to be followed through lifecycle. Hence, service practitioners have to bridge the gap between conventional project management and the frameworks by their interpretation and experiences. 3. Guiding Platform for DevOps Practices 3.1. Document, Concern and Design Principles To provide mechanism about controlling tasks and documents to developers, operators and administrators, the authors focus on the relationships between documents, tasks of concerns and design principles. Document-based project management leads directly to quality control of services. Development documents are developed and reviewed by practitioners and managers,

3 424 Shigeru Hosono and Yoshiki Shimomura / Procedia CIRP 60 ( 2017 ) Fig. 3. Structure between on-site development practices and design principles. following conventional on-site development practices, which are locally defined and conducted. The procedures are structured with practitioners tasks. Tasks in development such as defining requirements, specification, and test cases, are stipulated practitioners roles, e.g. design, build, delivery, support. The tasks are not always conducted by the practitioners but through collaborative work with other practitioners, who have other roles. This collaborative work can go back and forth, while it makes progress gradually towards next phases. The position of iterative task in lifecycle process can be visualized when the current status of development is described and mapped to the flow of design principles (Fig.3). The following sections describe the layers of Fig.3: design principles, tasks and document review, and how the layers can be integrated into a single structure Design Principles The bottom layer is based on design principles -Axiomatic Design approach, which abstracts design process with transition of design parameters between four domains [8]. The customer attributes (CA) are transcribed into functional requirements (FR). The functional requirements (FR) are transcribed into design parameters (DP). The design parameters are transcribed into process variables (PV). This principle of design gives fundamental analysis and synthesis process in design, and they can be mapped to development processes in practice and represented with their names of phases: observation, requirement definition, functional design, implementation, test, operation and improvement Concerns and Tasks of Service Practitioners The middle layer is about concerns and tasks. Tasks are defined by roles in the service development and operation phases, and the tasks can be categorized by major concerns in roles. For example, analysts investigate clients objectives in business and obstacles to pursue them. Consultants identify the clients demands and define requirements for solutions. Designers define functional specifications following the requirements. Implementers develop software components and integrate them with hardware and software to work. They also define specifications of test and conduct them. These practitioners prioritized tasks are changed while development proceeds and also their focus on concern will shift Document Review Process The top layer is about practices, which are conducted under individual business rules and customs at development sites. Each development site has stipulated standardized tasks of development. The tasks are requirement definition, functional design, operational procedure, source codes. In most cases the deliverables are reported by documents, which are reviewed by administrators or project managers. This development and review process has been adopted under their project management schemes Document-Concern-Design Model The documents, concerns and design principles in the previous section are independent concepts, though contemplating their objectives enables us to make corresponding relations. The tasks for updating documents can be identified by the position of the design process. This relationship can be obtained by associating a document with a design domain through practitioners tasks. The design part represents design principle, which consists of request, function, structure and variables. The relationships between them represent transcription of attributes, parameters or variables between design phases such as requirements to functions and functions to variables. The concern part represents practitioners concerns, which comprise a group of states. They consist of tasks, which can be categorized at development sites where local development rules and procedures have been conducted. Consequently, the three domains - design principle, concern and document review process - are incorporated with links between them and formed into a single structure.

4 Shigeru Hosono and Yoshiki Shimomura / Procedia CIRP 60 ( 2017 ) In this manner, the design principle, concern and document review process are structured (Fig.4). 4. Implementation Fig. 4. Document-concern-design model Standardizing Concerns and Tasks To implement the document-concern-design model, an approach in the software engineering helps to provide concrete forms of concerns and tasks. The approach SEMAT (Software Engineering Method and Theory) visualizes such iterative progress and prompt next actions for practitioners [9-12]. SEMAT defines the kernel to make the essence of agile software development concrete and to identify the areas of a software endeavour that a development team must be mindful of and assess for progress and health. The kernel consists of three discrete areas of concerns; customer, solution and endeavour. The concern about customer includes everything to do with the actual use and exploitation of the software system to be produced. The concern about solution comprises everything related to the specification and development of the software system. The concern about endeavour covers everything related to the development team and the way they do their work. Each area of concern consists of Alphas (abstract-level progress health attribute) to understand, monitor, direct and control for progress and health of endeavours. SEMAT Kernel provides basic alphas: opportunity, stakeholders, requirements, software system, team, work, and way of working. Each alpha stipulates states and a checklist to help professionals understand the progress and health of software development. The way of defining concerns and their tasks of SEMAT kernel can be applied for stipulating that of document-concerndesign model. The item of concerns can be obtained from IT4IT as it stipulates major activities in terms of value proposition through lifecycle. Activities defined in the Value Streams are concerns of partitions: (1) strategy to portfolio, (2) request to deploy, (3) request to fulfil, and (4) detect to correct. Each concern consists of four states, and each state can be accomplished by a set of tasks. The following shows concerns, states, and tasks (Appendix Table1). Task: define objectives; align business and IT roadmaps; and set up standards and policies (b) State: Service Portfolio is established. Task: define enterprise architecture; rationalize service portfolio; and create service blueprint and roadmap (c) State: Demand is extracted. Task: consolidate demand; and analyse priority (d) State: Selection is completed. Task: business value; risk; costs; benefits and resources; what-if analysis; and ensure governance (2) Concern: Request to Deploy (R2D) Value Stream (a) State: Plan and Delivery Task: IT project plan; logical service model; requirements; and functional and technical; and standards and policies (b) State: Development Task: development agile; iterative; and waterfall (c) State: Test Task: functional (desktop, web, mobile); performance (desktop, web, mobile); and security (static, dynamic) (d) State: Deployment Task: release plan; change and configuration process; knowledge management; and application and security monitors (3) Concern: Request to Fulfil (R2F) Value Stream (a) State: Design and Publish Task: mash catalogue items from all fulfilment engines; set pricing options and SLA; and publish services (b) State: Subscribe Task: portal engagement; personalized experience; selfservice; and manage subscriptions (c) State: Fulfil Task: route fulfilments; automate deployment; use internal and external providers; and integrate with change asset and configuration systems (d) State: Measure Task: service usage management; chargeback/show back; cost transparency; and surveys and ratings (4) Concern: Detect to Correct (D2C) Value Stream (a) State: Detect Task: see events; alarms; and metrics across the entire infrastructure (b) State: Diagnose Task: enrichment; root cause; severity and business impact; pre-defined escalation path; and auto-fix common issues (c) State: Change Task: define change request; and perform problem and risk analysis (d) State: Resolve Task: implement change; leverage run books; verify recovery; and close records (1) Concern: Strategy to Portfolio (S2P) value stream (a) State: Strategy is determined.

5 426 Shigeru Hosono and Yoshiki Shimomura / Procedia CIRP 60 ( 2017 ) Task Management Tool The standardized concerns and tasks can be managed by a task management tool, which also monitors statuses of development documents. Fig. 5 shows the architecture of its prototype. It consists of an input module of development process, an extract module of document milestones, an extract module of tasks, an input module of design instance, a design principles database, a design instance database, a task database, an extract module of influenced tasks, a progress management module, and a viewer module. Fig. 5 Architecture of task management tool. While doing this design reconsideration, the functional specifications is updated and the related objects are identified. The document of functional specifications and the document of detailed functional specifications are indicated for update. The sections of these documents were specified by the relationships between the layers (Fig. 6). 5. Discussion The links from task to documents are defined for the development process at the site of case study. The task list (Appendix Table.1) is used as a standard, therefore the designers should ensure that it is exhaustive to include all the required tasks. Meanwhile, documents, whose formats and reviewing steps differ at each development site, are linked with the tasks according to their development procedures. This oneby-one linkage for development enables to adapt various document-base processes (Fig. 7). Hence, the system can be introduced to any local developers sites with little adaptation cost. Then, service development sites can introduce this mechanism into their task/project management systems easily, and accelerate various collaborative activities between developers and operators and guide their deliverables Case Study To validate the document-concern-design model, the tool has been applied to the design phase of a health care service development. The target users of this service are middle-aged business men, who are always busy in his work. The users want to become healthy, and reduce the risks of having diseases associated with their lifestyle habits, such as everyday drinking. They also want to know the outcome of their efforts immediately. The first version of the service was designed in collaboration with healthcare services. After proceeding to the detailed design, the designers reviewed the structure of the service system design. They decided to change delivery of health records not from the healthcare firm but from the ICT service provider. This revision of system design choice did not affect the function of providing health data; nothing changed from the users side. Thus, rework of design should be limited, thereby avoiding rework of all documentation work. 6. Conclusion Fig. 7 Adapting to on-site document review practices The emergence of cloud environments has prompted developers and operators to have close relationships and deliver cloud-enabled web services over and over again to comply with their clients needs. However, the conventional waterfall development management does not fit such iterative work. To fill in the gap, this article presents the documentconcern-design model, which enables to identify tasks for documentation. This approach can cover all the phases through the lifecycle and assist collaborative work between practitioners who have different roles. In addition, this one-byone linking steps enable to adapt any on-site rule locally defined for managing their development process. Hence, the system can be introduced to any developers site with little adaptation cost. Then, this mechanism can accelerate various collaborative activities between developers and operators and guide their deliverables. Fig. 6 Identifying influenced sections of documents.

6 Shigeru Hosono and Yoshiki Shimomura / Procedia CIRP 60 ( 2017 ) References [1] Ambrust, M., Fox, A., Griffith, R., Joseph, A., Katz, R., Konwinski, A., Lee, G., Patterson, D. Rabkin, A., Stoica I. and Zahaira, M. Above the cloud: a Berkeley view of cloud computing available at (accessed on 1 September 2016) [2] Haight, C., DevOps: born in the cloud and coming to the enterprise, Gartner Research, ID Number: G , [3] Haight, C., DevOps: the changing nature of system administration, Gartner Research, ID Number: G , [4] ITIL, available at (accessed on 1 September 2016) [5] COBIT, available at (accessed on 1 September 2016) [6] IT4IT, available at (accessed on 1 September 2016) [7] ISO20000, available at catalogue_tc_browse.htm0?commid= (accessed on 1 September 2016) [8] Suh, NP.: Axiomatic Design, Oxford University Press, Oxford, [9] Jacobson, I., Ng, P.W., McMahon, P., Spence, I., Lidman, S., The Essence of Software Engineering: Applying the SEMAT Kernel, Addison-Wesley; [10] Jacobson, I., Huang, S., Kajko-Mattsson, M., McMahon, P., Seymour, E., SEMAT: Three-Year Vision, Programming and Computer Software 38:1; 2012, p [11] The Object Management Group (OMG), Documents Associated With Essence - Kernel And Language For Software Engineering Methods Beta 1; 2013, [12] K. Muto, K. Kimita, H. Tanaka, E. Numata, S. Hosono, S. Izukura, T. Sakaki and Y. Shimomura: A Task Management Method for Product- Service-Systems Design. In Proceedings of CIRP, IPS2 Conference 2016, pp , CIRP, Appendix: Kernel Alphas Strategy to Portfolio (S2P) Requireme nts to Deploy (R2D) Request to Fulfil (R2F) Detect to Correct (D2C) Table 1: Kernel Alphas for Value Stream in Service Lifecycle State / Checklist 1 State / Checklist 2 State / Checklist 3 State / Checklist 4 Strategy: - Define objectives - Align business and IT roadmaps - Set up standards and policies Plan and design: - IT project plan - Logical service model - Requirements - Functional and technical - Standards and policies Design and Publish: - Mash catalogue items from all fulfilment engines - Set pricing, options, and SLA - Publish services Detect: - See events, alarm, and metrics across the entire infrastructure - Understand user issues - Trace the relationship between events Service Portfolio: - Enterprise architecture - Service portfolio rationalization - Create service blueprint and roadmap Develop: - Development agile, iterative, waterfall - Source and set up development environment - Version control - Developer testing Subscribe: - Portal engagement - Personalized experience - Self-service - Manage subscriptions Diagnose: - Enrichment - Root cause - Severity and business impact - Define escalation path - Auto-fixed common issues Demand: - Consolidate demand - Analyse priority, urgency and impact - Create new or tag existing demand Test: - Functional: desktop, web, mobile - Performance: desktop, web, mobile - Security: static, dynamic Fulfil: - Route fulfilments - Automate deployment - Use internal and external providers - Integrate with change, asset and configuration systems Change: - Define change request - Perform problem and risk analysis - Approve Selection: - Business value, risk, costs, benefits and resources - What-if analysis - Ensure governance Deploy: - Release plan - Change and configuration process - Knowledge management - Application and security monitors Measure: - Service usage measurement - Chargeback / show back - Cost transparency - Surveys and rating Resolve: - Implement change - Leverage run books - Verify recovery - Close records