Service Systems Engineering Stages

In a service provided by a Service System the business process, organizational processes, Information Technology and technology innovation are dynamically tied among the customer, Service providers, Service System entities, product providers and intermediaries to create new innovative services. Business Process Management tools have emerged to analyze end-to-end business processes. [Hantry, et.al. 2010] [Carroll et al. 2010] [Andrikoupolous et al. 2010] [Lin and Hsieh 2011].

In the next paragraphs we describe the stages of the SDP and their expected outputs; for a closer alignment with the TSE process we lumped together the Concept and Feasibility Phase into a single Service Strategy/Concept/; as shown in Part 3 of the SeBOK Figure 1. All of the phases of the SDP take a similar iterative approach to fully understand the enterprise capabilities, enterprise process impact, Information technology and technology impacts and customer expectations. We have purposely added the ITIL stages’ names to the SSE stages to show the needed alignment between IT and Technology but the reader should keep in mind that even though IT is crucial to the overall end-to-end service technology development needs must be taken into consideration in all the stages of the SSE design process.

Figure 1. Converting business requirements into new services

Service Strategy/Concept

A Service Concept is the entry into the SDP. The concept may be generated by an end-user (enterprise customer or consumer), a business manager, an engineering organization, new web services, new technology developments and/or IT, technology trends. The Service Concept is the highest level of the service idea and it usually addresses what service is being proposed, to what markets and to whom within these markets.

A high level feasibility assessment of the concept is then carried out by the Integrated Service Development Team (ISDT) to assess needs/impacts on enterprise process capabilities, operational capabilities and/or new technology developments (access, infrastructure, Operations Support Systems, Service Support Systems and Business Support Systems); it should also include any impacts on service governance, understanding on possible social, cultural, human behaviors. The feasibility assessment also gives a +/- 30% estimates on Time to develop and Cost of development which are entry points into the Business Case to evaluate whether the service is viable with the constraints and estimates to develop and to market. At this time a decision (Decision Gate) determines if the Service is to be developed.

SSE takes an important role in understanding and eliciting the enterprise service concepts; service is a process and as such fundamental to its successful development, deployment and customer satisfaction is clearly understood end-to-end business processes required for the intended service. SSE works with Business Process Management (BPM), social science, cognitive science to elicit intended service operations including target audiences, pre-sale, sale and post-sale customer care processes.

If the business case is viable then a detailed business description of the service including functions and features to be included and/or phases of development, markets to be addressed and customer within the markets to be targeted is developed and includes the customer experience expected from the service (i.e., defining the non-functional requirements of the service such Quality Of Service, availability, reliability, security considerations and offerings within the service). This description allows detailed studies of expected Human-Computer-Interactions, social networking, technology requirements, operations requirements; governance and organizational process requirements should also be included to develop the “Service Description” as the main output from this stage.

Requirements Analysis and Engineering

In the SSE process a Service Requirement Document then describes the service functions, the service entities, the intended interaction among entities and the customer facing and internal facing functions/processes required to support the service. This description should conceptually include intended Service Level Agreements (SLA) and the obligations of the service provider process should there be no compliance during service operation.

The SSE Requirements Analysis and Engineering Process in addition to the TSE activities described in Part 3 must also start with a customer-centric view to analyze SLA, Quality Of Service (QOS) requirements, value co-creation requirements, monitoring and assessment requirements to comply with expected/planned SLA. This analysis will determine whether dynamic changes of the service are required during service operation to correct faults, reconfigure, administer or to adapt/self-adapt for possible performance degradations. In addition, to the traditional service LCM processes (Operations, Administration, Maintenance, Billing, Customer care) particular attention must be drawn to Service Level Management (SLM) processes and systems needed to monitor, measure, assess KPIs, TPMs and SPMs according to intended SLA.

The SSE requirements analysis will also include the analysis and engineering of support Systems for the Governance, Business, Service, Operations, and support processes to derive requirements on technologies, on Information Systems, on processes and on enterprise organizations. Interface requirements, information flows, and data requirements are also within the scope of requirements analysis. The main output is the Service Requirements Document (SRD).

SSE plays a critical role in describing the needs of the intended service in terms of the Service day to day operations including customer care centers requirements, interface between network infrastructure provider(s), content provider(s) and service provider(s), service based application provider(s) and the Customer Management Process for the service all of these have to be described in detail in the Service Operations Plans and the Operations Technical Plans (SOP/OTP)

Systems Design/Development

The SRD, SOP and OTP have enough details about the service functions, service operations and the interfaces and information flows required among the different Service Systems entities to analyze, identify and recommend end-to-end applicable Architectural Frameworks, to carry out Tradeoff analysis for the alternatives among Service Systems entities, to describe and allocate relationships (interactions) among entities, and at the subsystem, component, etc. Detailed requirements are worked at lower levels to generate Specifications for entities developers including data structures and data flow diagrams and allocated performance requirements.

Service Integration, Verification & Validation

SSE takes a very special role in defining Integration and Interface requirement for the seamless operation of the service. In this regard the System Engineer takes an integrator role to ensure proper data generation and flow through among all the different Systems composing the offer to ensure customer (consumer or internal) are getting the information required to carry out the task required in the business, operations, service and customer processes. The Service IV&V plans need to include end-to-end verification and validation procedures for any new development/adaptations required for planned dynamic configuration/re-configuration of previously tested Service System.

The Systems Engineer usually takes on the task to create the plans for Integration, Verification and Validation of the end-to-end service from different perspectives:

• End-to-end Service (Service Validation Test Plans)

• Customer Care (Operational Readiness Test Plans)

• Service Provider (Network Validation Test Plans)

• Service System entities Interoperability/ Interface Test Plans

• Content Provider (Content Validation Test Plans)

• Application (User Acceptance Test Plans)

Service Transition/Deployment

Service Life Cycle Management

Service Systems may change very rapidly and new enhancements, new features, or new applications are required to be added as incremental developments, new developments or adaptation to service offerings. Service Systems Engineers take those requirements to assess the feasibility of the changes and impacts to the service value chain, Service System entities, technologies, processes and organizations on the Service offerings. The current major challenge for SSE is the quick response times especially when Adaptation requirements are requested because of customer generated content, or because competitive offers from other Service providers.

Service SE Process Activities

This section summarizes the main activities carried out by Service Systems Engineers. The list is not meant to be exhaustive but rather to provide guidelines on Service Systems Engineering activities.

Strategy/Concept • Assist business marketing organization to elicit the intended service

• Assemble team with required specialties for initial techno-economical feasibility analysis

• Identify High Level (HL) impacts on existing processes: governance, business, services, operations, customer care, and billing.

• Identify Processes development needs

• Identify HL impacts on existing Service System entities

• Identify HL interaction/interfaces required among participating Service System entities

• Identify HL impacts on Access rights, access technologies with particular attention to the participating equipment and technologies in the service.

• Identify impacts/new Access devices (including terminal equipment), Information Systems (BSS, SSS, CC, Billing), Networks (Backbone, Access, etc.), Network Operations (OSS), Application Servers, etc.

• Identify HL impacts on Service Level Management, Quality Assurance Systems; SLA

• Identify HL Security requirements

• Describe at a HL Architectural Block Diagrams (ABD) to describe links among participating Service Systems entities

• Rough Order of Magnitude estimate (Time and Cost) for adaptation/development of processes/technologies (+/- 40%) and needed resources.

• Describe HL Concept of Operations

Service Requirements

• Manage Service System Requirements for the end-to-end service

• Assemble Architectural Review Board (ARD)

• Describe service requirements on Service System entities

• Describe end-to-end Service Requirements identifying service logic in terms of information flows among Systems Entities, BSS, SSS, OSS, subsystems, components.

• Describe processes impacts or new processes required for governance, service management, security, SLA

• Document end-to-end service logic (value chain) through a Service Description identifying stakeholders, impacted organizations, etc.

• Identify assumptions made: Regulatory, legal, social, etc.

• Identify Operations Centers (Customer Care, Network Operations, Service Operations Centers) impacts and/or new center requirements

• Review Service Description and document issues and their resolutions

• Get Stakeholder’s and Service Team approval of Service Description baseline

• Etc.

Service Design/Development Activities

• Assemble Architectural Team with participation from Service System entities experts, Processes, Technology, Software, Operations, Information Systems, etc.

• Manage Service Architecture Team activities

• Schedule periodic reviews with Architecture Review Board

• Define WBS and identify Leaders

• Identify and recommend end-to-end applicable Architectural Framework(s) for end-to-end service including security frameworks

• Identify adaptations/developments required for dynamic creation both for technologies and end-to-end processes.

• Tradeoff Analysis among different alternatives

• Use simulation and Model Based tools to identify Functions (logical), Behavior (Operational) and Physical components of the intended service

• Identify relationships (interactions) among Service Systems entities and the information flows among them through Functional Flow Block diagrams, behavioral diagramming, State diagrams, etc.

• Define In-Service Support Processes required for Incident Management, Problem Management, Change Management, Release Management, Configuration Management

• Allocate requirements to Service System entities and their corresponding subsystems. This activity usually includes:

o Access including equipment

o Infrastructure Architecture allocations

o OSS Architecture

o SSS Architecture

o CC Systems Architecture

o BSS Architecture

o Security Architecture

• Analyze expected end-to-end service demand loads impact on different Service System entities (usually done through simulation techniques or mathematical models).

Service Integration, Verification & Validation Activities

• Create Traceability matrix to validate end-to-end requirements

• Manage Integration, Verification, Validation and Test & Evaluation

• Identify IV&V needs for processes technologies and possible processes and test plans for dynamic configuration.

• Integration and Verification plans for the end-to-end service. These plans should include:

o End-user Validation test plans

o Business Operations Test Plans: pre-sales, service ordering, service provisioning, customer care functions (operational readiness)

o Service Validation test plans to ensure end-to-end service functionality

o Regression test plans

o Connectivity Test plans

o Systems Test Plans

o Unitary test plans

Service Transition/Deployment

Services Life Cycle Management Process

• Elicit new market request for service enhancements, new services etc.

• Impacts on Service value chain Service System entity for dynamic service configuration

• Monitor Technology trends

• Create Technology Roadmaps

• Historical operations data collection and analysis in support CSI

• Etc.

In summary, During this stage the main tools used by Systems Engineers include the creation of Service Systems Context Diagram, Use Cases, Architectural Block Diagrams (ABD) using modeling languages such as SysML, BIPEL, etc.

References

Citations

Andrikopoulos, V., Bucchiarone, A., Di Nitto, E., Kazhamiakin, R., Lane, S., Mazza, V., and Richardson, I. 2010. Service Engineering. S-CUBE Book 2010: 271-337.

Carroll, N, Whelan, E., and Richardson, I. 2010. Applying Social Network Analysis to Discover Service Innovation within Agile Service Networks. Service Science 2 (4): 225-244.

Hantry, F., Papazoglou, M.P., van den Heuvel, W., Haque, R., Whelan, E., Carroll, N., Karastoyanova, D., Leymann, F., Nikolaou, C., Lamersdorf, W., and Hacid, M. 2010. Business Process Management. S-CUBE Book: 27-54.

Lin, F. and Hsieh, P. 2011. A SAT View on New Service Development. Service Science 3 (2): 141-157.

Primary References

All primary references should be listed in alphabetical order. Remember to identify primary references by creating an internal link using the ‘’’reference title only’’’ (title). Please do not include version numbers in the links.