- The document discusses service design thinking and the service development cycle. It outlines a process with six phases: preliminary phase, requirements, vision, organizational structures, process framework, and service features.
- The goal is to develop digital services using building blocks and blueprints by defining requirements, creating a vision, and developing organizational structures, processes, and specific service features.
- Each phase takes inputs from previous phases and produces outputs to feed into subsequent phases to iteratively design the service model.
This Slideshare presentation is a partial preview of the full business document. To view and download the full document, please go here
https://flevy.com/browse/business-document/itil-process-assessment--service-design-xls-3668
DOCUMENT DESCRIPTION
This Excel spreadsheet system with approx. 400 Questions allows you to conduct a Assessment of ITIL v3 Service Design processes:
1 Design Coordination
2 Service Catalogue Management
3 Service Level Management
4 Supplier Management
5 Availability Management
6 Capacity Management
7 IT Service Continuity Management
8 Information Security Management
Assessment highlights areas that require particular attention and gives you idea on process maturity. It can also be used as a benchmarking mechanism and a boost in creating continual improvement culture for your ITSM / ITIL processes.
The assessment is based on Process maturity framework (PMF), (as recommended in ITIL Service Design book). Maturity rating levels are:
Level 1: Initial
Level 2: Repeatable
Level 3: Defined
(Level 3 +: Deployed )
Level 4: Managed
Level 5: Optimizing
The use of the PMF in the assessment of service management processes relies on an appreciation of the IT organization growth model. At the process level, assessment covered following groups of questions regarding process attributes to establish process maturity:
1. Process performance (outcomes achieved)
2. Performance Management ( activities performed)
3. Work product management ( inputs/outputs)
4. Process Definition ( roles documentation)
5. Process deployment( accepted, performed)
6. Process Measurement
7. Process control
8. Process innovation
9. Process optimisation
This Slideshare presentation is a partial preview of the full business document. To view and download the full document, please go here
https://flevy.com/browse/business-document/itil-process-assessment--service-strategy-xls-3666
DOCUMENT DESCRIPTION
This Excel spreadsheet system with approx. 300 Questions allows you to conduct a Assessment of ITIL v3 Service Strategy processes:
1 Strategy Management for IT Services
2 Service Portfolio Management
3 Financial Management for IT Services
4 Demand Management
5 Business Relationship Management
Assessment highlights areas that require particular attention and gives you idea on process maturity. It can also be used as a benchmarking mechanism and a boost in creating continual improvement culture for your ITSM / ITIL processes.
The assessment is based on Process maturity framework (PMF), (as recommended in ITIL Service Design book). Maturity rating levels are:
Level 1: Initial
Level 2: Repeatable
Level 3: Defined
(Level 3 +: Deployed )
Level 4: Managed
Level 5: Optimizing
The use of the PMF in the assessment of service management processes relies on an appreciation of the IT organization growth model. At the process level, assessment covered following groups of questions regarding process attributes to establish process maturity:
1. Process performance (outcomes achieved)
2. Performance Management ( activities performed)
3. Work product management ( inputs/outputs)
4. Process Definition ( roles documentation)
5. Process deployment( accepted, performed)
6. Process Measurement
7. Process control
8. Process innovation
9. Process optimisation
This Slideshare presentation is a partial preview of the full business document. To view and download the full document, please go here
https://flevy.com/browse/business-document/itil-process-assessment--service-design-xls-3668
DOCUMENT DESCRIPTION
This Excel spreadsheet system with approx. 400 Questions allows you to conduct a Assessment of ITIL v3 Service Design processes:
1 Design Coordination
2 Service Catalogue Management
3 Service Level Management
4 Supplier Management
5 Availability Management
6 Capacity Management
7 IT Service Continuity Management
8 Information Security Management
Assessment highlights areas that require particular attention and gives you idea on process maturity. It can also be used as a benchmarking mechanism and a boost in creating continual improvement culture for your ITSM / ITIL processes.
The assessment is based on Process maturity framework (PMF), (as recommended in ITIL Service Design book). Maturity rating levels are:
Level 1: Initial
Level 2: Repeatable
Level 3: Defined
(Level 3 +: Deployed )
Level 4: Managed
Level 5: Optimizing
The use of the PMF in the assessment of service management processes relies on an appreciation of the IT organization growth model. At the process level, assessment covered following groups of questions regarding process attributes to establish process maturity:
1. Process performance (outcomes achieved)
2. Performance Management ( activities performed)
3. Work product management ( inputs/outputs)
4. Process Definition ( roles documentation)
5. Process deployment( accepted, performed)
6. Process Measurement
7. Process control
8. Process innovation
9. Process optimisation
This Slideshare presentation is a partial preview of the full business document. To view and download the full document, please go here
https://flevy.com/browse/business-document/itil-process-assessment--service-strategy-xls-3666
DOCUMENT DESCRIPTION
This Excel spreadsheet system with approx. 300 Questions allows you to conduct a Assessment of ITIL v3 Service Strategy processes:
1 Strategy Management for IT Services
2 Service Portfolio Management
3 Financial Management for IT Services
4 Demand Management
5 Business Relationship Management
Assessment highlights areas that require particular attention and gives you idea on process maturity. It can also be used as a benchmarking mechanism and a boost in creating continual improvement culture for your ITSM / ITIL processes.
The assessment is based on Process maturity framework (PMF), (as recommended in ITIL Service Design book). Maturity rating levels are:
Level 1: Initial
Level 2: Repeatable
Level 3: Defined
(Level 3 +: Deployed )
Level 4: Managed
Level 5: Optimizing
The use of the PMF in the assessment of service management processes relies on an appreciation of the IT organization growth model. At the process level, assessment covered following groups of questions regarding process attributes to establish process maturity:
1. Process performance (outcomes achieved)
2. Performance Management ( activities performed)
3. Work product management ( inputs/outputs)
4. Process Definition ( roles documentation)
5. Process deployment( accepted, performed)
6. Process Measurement
7. Process control
8. Process innovation
9. Process optimisation
Architecture Series 5-4 Solution Architecture DraftFrankie Hsiang
Use Solution Architecture as a tool to produce solid solutions that fully meet business needs, within budget, deploy on schedule, easy to maintain, and use fewer resources.
This presentation will cover first exam of SOA , by introducing terms related to Service oriented Computing umbrella to start your knowledge base about Service Orientation world.
This describes the concept of a Process Oriented Architecture. A Process Oriented Architecture is a way of linking process areas to actual (desired) interactions – customer (external interacting party) service journeys through the organisation. It allows two views of any process to be maintained and operated:
1. External view – that experienced by user
2. Internal view – that worked on by the organisational competency
An organisation will interact will multiple external parties. Each external party will have a number of interaction paths or journeys. These journeys are the routes of experience of external parties. These routes of experience need to be mapped (as) seamlessly (as possible) to internal organisational operational process competency groupings.
The interaction paths or journeys represent the Straight Through Processing that the customer (external party) wants to experience. The complexity of internal organisational operational process competency groupings needs to be masked from the customer (external party). Process Oriented Architecture is a key enabler of successful digital transformation.
Service Management Solution Framework (SMSF)Malcolm Ryder
Despite even the most popular "standards", such as ITIL, ITSM practitioners and commentators constantly regenerate confusion about providing and acquiring "solutions" to the problem of managing IT services for the business. The confusion means that the investment in prescribed activities and offered support can be difficult to assess for its probable effectiveness. A Solution Framework provides a standing reference for recognizing when and how something qualifies unambiguously as a solution. This Archestra Research notebook narrows the scope of the problem to exposing what a "solution" is, regardless of its source.The framework consists of three perspectives: Business-centric, Capability-centric, and IT-centric.
I hope this introductory presentation to ITIL v3 Foundation exam will be very useful to the readers. The time one needs to spend on study depends upon one's experience with ITIL related practices in real world. Nonetheless, it is very simple study, but the exam questions may be trickier than expectation. So, focus on learning ITIL concepts rather than adding ITIL certificate to your resume.
References for the slides used from:
http://taruu.com/Documents/ITIL%20v3%20Foundation%20Study%20Guide%20v4.2.2.5.pdf
The Art of Service – ITIL v3 Foundation Complete Certification Kit (book and online course)
Skillport - IT Infrastructure Library (ITIL) v3 Foundation Syllabus v4.2 exam
PECB Webinar: Aligning ITIL/ISO 20000 Service Design and TOGAF Enterprise Arc...PECB
Summary:
The ITIL Service Design stage specifies 8 key IT processes that organizations need to excel at, if they are to develop effective designs for their IT ecosystem.
TOGAF is an Enterprise Architecture Model that takes a holistic and integrated look at how architectures are conceptualized and implemented.
To get Service Design right means the individual/organizations has to have some sort of knowledge and experience in the use and adoption of TOGAF.
IT Projects go wrong in the Service Design stage and they further go wrong because they lack the rigor that an enterprise architecture brings into play.
In this webinar we will explore the following:
• The very heart of ITIL Service Design
• The 8 Design Process
• TOGAF Introduction
• Architecture Development Lifecycle
• IT Infrastructure and Application Design Issues
• The Link between Service Design, Enterprise Architecture and IT Implementation
Presenter:
Orlando is an Enterprise Architect and Programme Director with over 15 years’ experience in the field of Computing and Information Technology Consulting. He has an excellent technical background and has carried out Project Management, Service Management, Assurance, Advisory and System Integration Projects within SAP, Microsoft, Oracle, HP, Cisco and other solution areas of Information Technology. He has led more than 100 successful engagements for clients over the past 15 years. Orlando has developed various documentation for Enterprise Architecture, IT Service Management, CRM Implementation and Information Security. He has also trained over 2, 000 Professionals on (ITIL, TOGAF, Business Analysis, COBIT, CMMI, XBRL, ISO 20000, ISO 27001 and ISO 22301).
Very useful set of TOGAF-related diagrams from the Orbus Software.
TOGAF®9.1 is an Architecture Framework which has been developed by the Open Group to provide the methods and tools
for assisting in the acceptance, production, use and maintenance of an Enterprise Architecture.
Architecture Series 5-4 Solution Architecture DraftFrankie Hsiang
Use Solution Architecture as a tool to produce solid solutions that fully meet business needs, within budget, deploy on schedule, easy to maintain, and use fewer resources.
This presentation will cover first exam of SOA , by introducing terms related to Service oriented Computing umbrella to start your knowledge base about Service Orientation world.
This describes the concept of a Process Oriented Architecture. A Process Oriented Architecture is a way of linking process areas to actual (desired) interactions – customer (external interacting party) service journeys through the organisation. It allows two views of any process to be maintained and operated:
1. External view – that experienced by user
2. Internal view – that worked on by the organisational competency
An organisation will interact will multiple external parties. Each external party will have a number of interaction paths or journeys. These journeys are the routes of experience of external parties. These routes of experience need to be mapped (as) seamlessly (as possible) to internal organisational operational process competency groupings.
The interaction paths or journeys represent the Straight Through Processing that the customer (external party) wants to experience. The complexity of internal organisational operational process competency groupings needs to be masked from the customer (external party). Process Oriented Architecture is a key enabler of successful digital transformation.
Service Management Solution Framework (SMSF)Malcolm Ryder
Despite even the most popular "standards", such as ITIL, ITSM practitioners and commentators constantly regenerate confusion about providing and acquiring "solutions" to the problem of managing IT services for the business. The confusion means that the investment in prescribed activities and offered support can be difficult to assess for its probable effectiveness. A Solution Framework provides a standing reference for recognizing when and how something qualifies unambiguously as a solution. This Archestra Research notebook narrows the scope of the problem to exposing what a "solution" is, regardless of its source.The framework consists of three perspectives: Business-centric, Capability-centric, and IT-centric.
I hope this introductory presentation to ITIL v3 Foundation exam will be very useful to the readers. The time one needs to spend on study depends upon one's experience with ITIL related practices in real world. Nonetheless, it is very simple study, but the exam questions may be trickier than expectation. So, focus on learning ITIL concepts rather than adding ITIL certificate to your resume.
References for the slides used from:
http://taruu.com/Documents/ITIL%20v3%20Foundation%20Study%20Guide%20v4.2.2.5.pdf
The Art of Service – ITIL v3 Foundation Complete Certification Kit (book and online course)
Skillport - IT Infrastructure Library (ITIL) v3 Foundation Syllabus v4.2 exam
PECB Webinar: Aligning ITIL/ISO 20000 Service Design and TOGAF Enterprise Arc...PECB
Summary:
The ITIL Service Design stage specifies 8 key IT processes that organizations need to excel at, if they are to develop effective designs for their IT ecosystem.
TOGAF is an Enterprise Architecture Model that takes a holistic and integrated look at how architectures are conceptualized and implemented.
To get Service Design right means the individual/organizations has to have some sort of knowledge and experience in the use and adoption of TOGAF.
IT Projects go wrong in the Service Design stage and they further go wrong because they lack the rigor that an enterprise architecture brings into play.
In this webinar we will explore the following:
• The very heart of ITIL Service Design
• The 8 Design Process
• TOGAF Introduction
• Architecture Development Lifecycle
• IT Infrastructure and Application Design Issues
• The Link between Service Design, Enterprise Architecture and IT Implementation
Presenter:
Orlando is an Enterprise Architect and Programme Director with over 15 years’ experience in the field of Computing and Information Technology Consulting. He has an excellent technical background and has carried out Project Management, Service Management, Assurance, Advisory and System Integration Projects within SAP, Microsoft, Oracle, HP, Cisco and other solution areas of Information Technology. He has led more than 100 successful engagements for clients over the past 15 years. Orlando has developed various documentation for Enterprise Architecture, IT Service Management, CRM Implementation and Information Security. He has also trained over 2, 000 Professionals on (ITIL, TOGAF, Business Analysis, COBIT, CMMI, XBRL, ISO 20000, ISO 27001 and ISO 22301).
Very useful set of TOGAF-related diagrams from the Orbus Software.
TOGAF®9.1 is an Architecture Framework which has been developed by the Open Group to provide the methods and tools
for assisting in the acceptance, production, use and maintenance of an Enterprise Architecture.
Manejo y uso de las nuevas tecnologías en la tercera edad2867jbc
La presente investigación tiene como finalidad conocer los aspectos facilitadores del aprendizaje de las nuevas tecnologías en personas de tercera edad. Para ello Se ha utilizado una metodología cualitativa, mediante observación participante en un taller de alfabetización digital. A partir del análisis de los datos recogidos se ha plasmado los aspectos más significativos acompañados de una serie de sugerencias para la impartición de este tipo de talleres.
Horn Law takes great pride in representing people who have been injured by the negligence of others. Lead Attorney Douglas Horn wants to make sure clients get the best medical care, the accident investigation is complete, the insurance claims are filed properly.
BIMCV, Banco de Imagen Medica de la Comunidad Valenciana. María de la IglesiaMaria de la Iglesia
Según Hal Varian (experto en microeconomía y economía de la información y, desde el año 2002, Chief Economist de Google) “En los próximos años, el trabajo más atractivo será el de los estadísticos: La capacidad de recoger datos, comprenderlos, procesarlos, extraer su valor, visualizarlos, comunicarlos serán todas habilidades importantes en las próximas décadas. Ahora disponemos de datos gratuitos y omnipresentes. Lo que aún falta es la capacidad de comprender estos datos“.
How to speak english fluently-inlingua methodDhaneshRathore
Here you will find all the necessary details about inlingua, New Delhi. Our background, our teaching methods and our clients to whom we have provided our services.
Libro de "Bits Viajeros" de la clase de 4 años A del CEIP Ciudad de Mérida, perteneciente al "Proyecto Método Doman", y realizado en colaboración con las familias.
Curso 2014-15
Los sentidos - Realizado por la familia de Jaime Galán García.
Stwórz aplikacje internetowe za pomocą nowoczesnego narzędzia
* Poznaj język Ruby
* Skorzystaj ze środowiska Rails
* Napisz własne aplikacje
W dobie rosnącej popularności Linuksa, niesłabnącej popularności systemu Windows i obecności na rynku innych systemów operacyjnych aplikacje "biurkowe", wymagające konkretnego środowiska uruchomieniowego, tracą swoją pozycję. Ich miejsce zajmują aplikacje intranetowe bądź internetowe -- instalowane na serwerach sieciowych, wymagające po stronie użytkownika jedynie przeglądarki WWW. Rozwiązanie takie jest niezwykle wygodne również dla twórców aplikacji, ponieważ zdecydowanie upraszcza proces wprowadzania nowych wersji systemu oraz jego konserwacji. Istnieje wiele technologii ułatwiających tworzenie takich aplikacji. Jedną z nowości na rynku jest zyskująca coraz większe uznanie Ruby on Rails.
Dzięki książce "Ruby on Rails. Ćwiczenia" opanujesz podstawy tworzenia aplikacji internetowych za pomocą tej technologii. Nauczysz się programować w języku Ruby: poznasz jego elementy i zasady projektowania obiektowego, metody przetwarzania danych tekstowych, pracy z plikami i katalogami oraz obsługi błędów i wyjątków. Przeczytasz także o środowisku Rails, instalowanym na serwerze aplikacji. Wykonując ćwiczenia z ostatnich rozdziałów, zrealizujesz projekt aplikacji służącej do zarządzania czasem w technice Ruby on Rails.
* Instalacja interpretera Ruby
* Podstawowe elementy języka Ruby
* Konstrukcje warunkowe i sterujące
* Programowanie obiektowe
* Obsługa wyjątków
* Korzystanie z wyrażeń regularnych
* Instalacja środowiska Rails
* Generowanie adresów URL
* Szablony RHTML
* Wysyłanie poczty elektronicznej
Poznaj już dziś technologię, dzięki której tworzenie aplikacji będzie bardzo wydajne i przyjemne.
Information Technology Infrastructure Library Service Management based on ITIL v3 Official Introduction. Contains Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement.
The how, why and what of ITIL® certificationsLora Beros
The ITIL® path is long and challenging, but you have to start somewhere. In this on-demand presentation, TrainSignal instructor Lowell Amos discusses the benefits of obtaining an ITIL® certification. Where do you start? Why should you bother? How can this certification transform your career? Let Lowell guide you through the first ladder of the ITIL® climb to success.
Documentation Framework for IT Service DeliverySimon Denton
I developed this for a project that I am currently involved in. The project aim is to develop a documentation framework for the provision of IT as a Service. I devised the framework using the Microsoft Operations Framework as ‘glue’ between other frameworks like ITIL. I thought I’d share it as it might be useful to others who are in a similar situation. The end result is a relatively compact set of documents for each service offered by IT.
Service Catalogue Management - Getting StartedSteve Lawless
The Service Catalogue has many uses including being a front end portal for your IT Services. Check out our training offerings https://purplegriffon.com/
Service Catalogue SITS 2013 presentationSteve Lawless
Billed as 'Behold the incredible multi-talented service catalogue' and delivered at SITS13 at Earls Court by Steve Lawless.
Begin your 'ITIL' IT Service Management journey here https://purplegriffon.com/courses/itil-it-service-management-itsm/itil-foundation
ITIL Practical Guide - Continual Service Improvement (CSI)Axios Systems
To view this complimentary webcast in full, visit: http://forms.axiossystems.com/LP=272
This video provides a run through of the lifecycle stage, which manages the day-to-day operation of IT services for the identification and reporting of interruptions in the delivery of services and handling of service requests at agreed levels.
How to Get Started with GxP Processes in Office 365 - The Discovery PhaseMontrium
The webinar covers the following topics:
-How the GxP Design and Delivery Landscape is Changing (digitization of processes, cloud adoption, agile adaptation, better relationships with service providers)
-Business Analysis for Office 365 and the Cloud (methods applied in a Discovery that meet life science trends)
-Discovery Goals (relationships, vision, delivery and enablement of GxP solutions in Office 365)
-Discovery Walkthrough (methodology, sessions, best practices)
Similar to BuildingdigitalServiceswithServiceBuildingBlocks (2) (20)
1. Knowledge for Servicemanagement and Sourcing
Dr. Helmut Steigele
Building digital Services with
Service Building Blocks and Blueprints
Dr. Helmut Steigele
2. Who should attend this training
• Persons who want to create services and service process flows
• Which want to solve «wicked problems»
• And are offered as a service on a digital channel
• Want to learn about Design Thinking and Architectural Work within
Service Design
3. What is a wicked problem
• The Problem is difficult to define
• Each wicked problem is essentially unique
• Multi-causal
• May itself contain problems
• No rules or markers for where to stop
• Attempts to address may open cause unforeseen consequences
• No or limited opportunity for trial and error learning with immunity
• The planner is held accountable for result, efficiency and effectivity
of the problem solution
3
4. Fields where wicked problems can be found
• Simplifying Business Transactions
• Inventing new Business- and Service Models
• Optimizing, Improving and Redesigning Processes
4
5. • Servicedesign Thinking and Blueprint Approach
• The Service Development Cycle and it’s Building blocks
• Blueprints stored in Repositories as Success Factor in Service Realization
Agenda
6. • A skill that allows a designer to align what people want with what can be
done, and produce a viable business strategy that creates customer
service value and market opportunity
• A Method of focusing innovation on people and designing based on:
– What people need and want
– What people like or dislike
• In regards to provisioning, marketing, support, or all of them
What is Service Design Thinking
6
7. Is a Service-Model that defines and describes how an organisation needs
to operate in the future to meet specific needs of all service consumers
across and within a business domain
• So it is about creating
– Value Proposition
– Value Chains
– Capabilities
– Resources
The central Blueprint of Service-Design-Thinking
7
8. • that Servicedesign and Service-Improvement are based on
– incremental building blocks
– Which can be
• Captured from a repository
• For Re-use
• And Production of new increments and service-artefacts
• Examples of such «building blocks»
– Patterns of user activity
– Gain-Pain-Demand-Diagrammes for Demand Profiling
– Business and Service-Model Canvas
– Policies, Processes and Procedure-Templates
– Service-Feature-Catalogues
– Configuration Models etc.
What if you realize
8.
9. • Desirable, feasible and viable services
• Shorter service development cycles
• Better integration of different services and underlying processes in an overall
organisation
• Transparency within the Servicegovernance and Servicemanagement
• It considers Customers perception as well as effectivity and efficiency of
provisioning process
Benefits of this approach
desirable
feasible viable
Services
10. Definition Service Model:
An abstract representation of a service be it conceptual, textual, and/or graphical,
of all core interrelated architectural, co-operational, and financial arrangements
designed and developed by an organization presently and in the future, as well as
all service features the organization offers, or will offer, based on these
arrangements that are needed to achieve its strategic goals and objectives.
Relationship Service Model / Operation-Model
10.
An operation model is therefore an aspect of the service model
12. • Servicedesign Thinking and Blueprint Approach
• The Service Development Cycle and it’s building blocks
• Blueprints stored in Repositories as success factor in Service realization
Agenda
13. • As a lot of services are nowadays related with specific information
technology building blocks and as there is the need for designing
sustainable services
• The best practice approach of enterprise architecture (TOGAF) was taken
as baseline for
– Defining a consistent sequence (from idea to operations of a service) of design
tasks
– Assuring seamless information flow and interoperability of developped service
building blocks
– Integrating those building blocks later on in best practice servicemanagement
frameworks like ITIL®
Comments on the Cycle
13
15. • Undertake the preparation and initiation activities required to meet the
business directive for a new target service, including the definition of an
Service-Specific Architecture framework and tools, and the definition of
principles.
• The Preliminary Phase is about defining “where, what, why, who, and how
we do service-architecture” in the enterprise concerned.
• This means
– Defining the extent of the “Service” behind the operation model
– Identifying key drivers and elements in the organizational context.
– Defining the requirements for architecture work.
– Defining the architecture principles that will inform any architecture work.
– Defining the framework to be used
– Defining the relationships between management frameworks
– Evaluating the maturity of the referred organisation in architectural work
Preliminary Phase - Objective
15
16. Phase 1 - Input Objects
16
Preliminary
Phase
Business Principles, Governance- and Legal Frameworks
Initial Stakeholder-Lists
Organisational Model for Servicedesign-Project
Existing Architecture Framework
Business Model and Business Strategy
Service Architecture Governance Strategy
Initial Content (Blueprints) of Service-Architecture
Repository
Existing Catalogue on Services and related Business
Processes
17. Phase 2 - Process Steps
17
Preliminary
Phase
1. Scope the Enterprise Organizations Impacted
2. Confirm Governance and Support Frameworks
3. Define and Establish Project Team and Organization
4. Identify and Establish Architecture Principles
5. Tailor Servicedesign-Framework and, if any, other
selected Architecture Framework(s)
6. Implement Architecture Tools
18. Phase 3 – Output - Objects
18
Service Architecture Repository
Scoping Statement
Architectural Principles
Project Organisation Model for Service
Preliminary
Phase
20. Objectives of Requirements Management
20.
• Ensure that the Requirements Management process is
sustained and operates for all relevant Development phases
• Manage requirements identified during any execution of the
Development cycle or a phase
• Ensure that relevant requirements are available for use by
each phase as the phase is executed
• Classifying captured Requirement for following structurization
and prioritization
21. Steps of Requirements Engineering
21.
In each relevant phase of the Project the Team should identify types
of requirement that must be met by the architecture, including
applicable:
• Functional requirements
• Non-functional requirements
When defining requirements following points should be taken into
account:
• Assumptions for requirements
• Constraints for requirements
• Domain-specific principles that drive requirements
• Policies affecting requirements
• Standards that requirements must meet
• Organization guidelines for requirements
• Specifications for requirements
22. Requirements Impact Assessment
22.
• Reference to specific requirements
• Stakeholder priority of the requirements to date
• Phases to be revisited
• Phase to lead on requirements prioritization
• Results of phase investigations and revised priorities
• Recommendations on management of requirements
• Repository reference number
23. Requirements - Examples
23.
• Requirements which are service outcome related
• Requirements which are related with Customer «pain-experience»
• Requirements which are related with Customer «gain-
expectation»
• Requirements which are related with «availability, security,
continuity and performance»
• Architecture requirements
• Business service contracts
• Application service contracts
• Implementation guidelines
• Implementation specifications
• Implementation standards
• Interoperability requirements
• IT Service Management requirements
• Constraints
• Assumptions
28. • The Service-Vision describes how the new capabilities of the referenced
service will support Customer goals and strategic objectives and address
the stakeholder concerns when implemented
• It provides a first-cut, high-level description of the Baseline and Service
Architectures, covering the Governance, Service, Process, Organisation,
Data, Application, Technology and Provider domains (Service Model)
• Business scenarios (Patterns of Business Activity) are an appropriate and
useful technique to discover and document business requirements, and to
articulate an Architecture Vision that responds to those requirements.
Vision
28
30. Phase 1 - Input Objects
30
Vision
Drivers, Principles, Strategic Goals and Constraints
Stakeholders and their Requirements
Service Operating Capabilities Assessment
Demand Scenarios and Customers Patterns of Business
Activity
Problem Description
31. Phase 2 - Process Steps
31
Vision
1. Establish the Design Project
2. Identify Stakeholders, Concerns, and Business
Requirements
3. Confirm and Elaborate Business Goals, Business
Drivers, and Constraints
4. Evaluate Customer Tasks which should to be
supported
5. Assess Readiness for Service Provisioning
6. Define Scope
7. Confirm and Elaborate Operational and architectural
Principles for the Service
8. Develop Service Vision
9. Define the Target Value Propositions and Service KPIs
10. Identify the Risks and Mitigation Activities
11. Develop Statement of Service Architecture Work;
Secure Approval
32. Phase 3 – Output - Objects
32
Vision
Service Interaction Channels and Delivery Structures
(Where will service happen)
Pattern of Business Activity – Critical to Quality –
Feature-List (Why)
Service Proposition e. g. Servicelevelpackages
(What will be offered)
Stakeholder Map (Who)
Operation Principles (How)
All Outputs will be parts of the «Highlevel Service Model»
35. Matching PCA with Value Map – Describe Demand
Scenario
35
So for each pattern of Customer activity (or task) describe on high level feature candidates
which generate gain and releave pain and set service objectives for them!
Requirement
Customer
Job
Service
Feature
37. Generating Value – The basic principle
37
UTILITY
WARRANTY
Gain created?
Pain relieved?
Available enough?
Performant enough?
Continuous enough?
Secure enough?
Fit for Purpose?
Fit for use?
Value
39. • Objective 1:
– Develop those service model parts that describes how the service needs to
operate to achieve the business goals, and respond to the strategic drivers set
out in the Architecture Vision, in a way that addresses the Service-Project-
Objectives and the Stakeholder concerns
• Objective 2:
– Identify candidate service architecture roadmap components based upon gaps
between the Baseline and Target Business Architectures
Organisational Structures within Service
39
Which organisational units and roles will cover which capability within
servicedelivery?
All Outputs will be parts of the «Highlevel Service Model»
40. Phase 1 - Input Objects
40
Org-
Structures
Baseline Governance Documents for Roles, Policies and
Responsibilities within the service
Baseline Skill-Documentation for service delivery
Baseline Org-Structures
Baseline Functional Capabilities Allocation for Service-Org
Results from the Vision-Phase
41. Phase 2 - Process Steps
41
Org-
Structures
1. Select reference models, viewpoints, and tools
2. Develop Baseline Functional Architecture Description
3. Develop Target Functional Architecture Description
4. Perform gap analysis
5. Define roadmap components
6. Resolve impacts across the Architecture Landscape
7. Conduct formal stakeholder review
8. Finalize the Functional Architecture
9. Create Architecture Definition Document
45. • Objective 1:
– Develop the Target Process Framework that describes how the enterprise
needs to operate to achieve the functional goals
– Target Process Modell consists of:
• Governance Structures for Services, Roles and Responsibilities for Service-
Processes
– Process Definitions for service features
– Process Definitions for service management processes
• Objective 2:
– Identify candidate process components to be adapted based upon gaps
between the Baseline and Target Process Architectures
Process Architecture within Service Value Chain
45
Which processes should be considered for Service Value Generation?
46. Phase 1 - Input Objects
46
Process-
Framework
Baseline Process Definitions
Baseline Process-Framework
Baseline Process Outcome Definitions
Baseline Service Objectives
Results from the Pre-Phases
47. Phase 2 - Process Steps
47
Process-
Framework
1. Select reference models, viewpoints, and tools
2. Develop Baseline Process Definitions
3. Develop Target Definitions
4. Perform gap analysis
5. Define roadmap components
6. Resolve impacts across the Process-Framework
7. Conduct first Customer Journey
8. Finalize the Process-Framework
9. Create Target Process Definitions and overall Process-
Framework
48. Phase 3 – Output
48
Process-
Framework Service Goal – Service-Process-Map
Baseline Process-Framework – Target Process-Framework
Isolated Gaps between Baseline and Target Process
Landscape
Solution Architecture
Target Process Definitions
Target Process-Framework
Target Process Outcome Definitions
50. What is a Customer Journey
• A process designed to allow you to think as your customer.
• It allows to track all your customer or service user experiences and
their responses
• It prevents design work, which is not valued at the end
51. Journey steps
• Decide on your journey
• Identify who your customer is e.g
• Use captured patterns of customer activity Note each part of the
journey.
• What are the major journey steps, reconstruct the journey
• Identify key touchpoints in interaction between service customer
and you
• Isolate “hot spots” or “moments of truth”
• Learn and handover journey experience to all other design
activities
54. • Objective 1:
– Develop the Target Procedures and Service Features that describe how the
service needs to operate to achieve the Customer goals
• Objective 2:
– Identify candidate processes to be adapted, based upon gaps between the
Baseline and Target Service Architecture
• Objective 3:
– Identify candidate supportive services to be adapted, based upon gaps
between the Baseline and the Target Service Architecture
Feature Landscape and Service Value Proposition
54
Which service feature supports in which form specific service objectives?
55. Phase 1 - Input Objects
55
Service-
Features
Baseline Service Portfolio (incl. Servicecatalogue)
Baseline Service Definition
Baseline Service Requirements
Baseline Service Models
Results from the Pre-Phases
56. Phase 2 - Process Steps
56
Service-
Features
1. Select reference models, viewpoints, and tools
2. Develop Baseline Service Definitions
3. Develop Target Service Definitions
4. Perform gap analysis
5. Define roadmap components
6. Resolve impacts
7. Conduct Customer Journey
8. Finalize the Service Features and Relations (eg.
Serviceportfolio)
9. Create Target Feature Definitions and overall
Servicelevel-Package
57. Phase 3 – Output
57
Service-
Features
Target Process-Framework – Target Service Features and
Relations - Map
Isolated Gaps between Baseline and Target Landscape
Solution Architecture
Target Service Definitions in Serviceportfolio
Target Service Features and Relations
Target Servicelevel Packages
Target Servicedefinitions
58. Matching PCA with Value Map – Describe Service
Features in Detail – Define Value Proposition
58
So for each pattern of Customer activity (or task) describe on detailed level feature candidates
which generate gain and releave pain, set priorities and create servicelevel packages!
59. • Solve specific Customer pains
• Create specific Customer gains
• Will be performed at specific «points of service»
• Will adress provider specific capabilities
– Serviceprocedures
– Servicemanagement-Processes
– Organisational Structures
– Service Skills
• Will use provider specific resources
– Applications
– Technology
– Headcount
– Providers
Character of Service-Features
59
62. • Objective 1:
– Describing how the the referred application will enable the service vision, in a
way that it addresses the service objectives and stakeholder concerns.
• Objective 2:
– Identify candidate Application Architecture Roadmap components based upon
gaps between the Baseline and Target Information Systems (Data and
Application) Architectures.
Application Architecture within a Service
62
Which application and application feature supports which service-to-
Customer-activity-context?
63. Phase 1 - Input Objects
63
Application
Landscape
Baseline Application Portfolio
Baseline Mapping between Applications, Services and
Processes
Baseline Data Structures and Requirements
Configuration Model – Layer Application
Results from the Pre-Phases
65. Phase 3 – Output
65
Application
Landscape Target Service Features and Relations – Target Applications
- Map
Isolated Gaps between Baseline and Target Landscape
Applicaton related Performance Design
Process - Service – Application Map
Target Applications
Target Information Building Blocks and Usecases by
Application
Business Rules and Information Building Blocks by
Applicaton
Solution Architecture
68. • Objective 1:
– Develop the Target Technology Landscape that enables the physical
components addressing the Service objectives and stakeholder concerns.
• Objective 2:
– Identify candidate Architecture Roadmap components based upon gaps
between the Baseline and Target Technology Landscape
Technology Landscape within Service
68
Which Technology Elements are supporting which service-to-Customer-
activity-context
69. Phase 1 - Input Objects
69
Technology
Landscape
Technology Baseline
Baseline Mapping between Technology and Services
Baseline Technology Requirements
Baseline Configuration Models
Results from the Pre-Phases
74. Provider Landscape - Objectives
74.
Objective 1:
Develop the Target Provider Landscape that enables the operational
support of the service
• Defining Target Provider Landscape
• Defining Provider Interfaces for Service
• Define Provider Governance Structures for Service
• Define Underpinning Contacts
• Align Underpinning Contracts with your Service Value Proposition
Objective 2:
Identify Roadmap candidates based upon gaps between the
Baseline and Target Provider Landscape
75. Phase 1 - Input Objects
75
Provider
Landscape
All other Gaps and Roadmaps from former phases
Baseline Mapping between Providers and Services
Baseline Provider Requirements
Baseline Provider- and Contract Policies
Sourcing Strategy Part from Business Strategy
77. Phase 3 – Output
77
Provider
Landscape
Target Provider Landscape – Target Service Features and
Relations - Map
Isolated Gaps between Baseline and Target Landscape
Solution Architecture
Provider - Service – Map
Target Provider Landscape
Target Sourcing Building Blocks
Sourcing Building Blocks by Service
80. Plan Service-Development
80.
• Generate the initial complete version of the Servicedesign
Package and the realization roadmap based upon the gap
analysis and the service components
• Determine whether an incremental approach is required, and if
so identify Transition candidates that will deliver continuous
business value.
• Confirm the enterprise’s capability for undergoing change.
• Generate and gain consensus on an outline Implementation
and Migration Strategy.
81. Phase 1 - Input Objects
81
Plan Service
All other Solution Architectures from former phases
Inputs from Outside-Project Context
Service-Readyness-Assessment
Programme- and Project-Management-Guidelines
Results from Gap - Analysis
82. Phase 2 - Process Steps
82
Plan Service
1. Determine/Confirm Key Change Attributes in Service
2. Determine Business Constraints for Implementation
3. Review and Consolidate Gap Analysis Results from
former Phases
4. Review Consolidated Requirements Across Related
Service Features and Objectives
5. Consolidate and Reconcile Supporting Services
6. Refine and Validate Dependencies
9. Confirm Readiness and Risk for Service Design
8. Formulate Implementation and Transition Strategy
9. Identify and Group Major Work Packages
10. Identify Transition Landscapes
11. Create the Service Architecture Roadmap &
Implementation and Migration Plan
7. Calculate Businescase based on Cost- and Revenue-
Streams
8. Decide on Service Realization
83. Phase 3 – Output
83
Plan Service
Communication Plan
Service Acceptance Criteria
Revenue- and Cost-Streams per Service
Service Business Case
Project Charter – Work Packages
Servicedesign Package
86. Build Service
86.
• Develop Service-Components
• Governance Structures
• Organisational Structures (Roles, Responsibilities, Functions)
• Policies and Processes
• Servicedescriptions, Servicelevel-Agreements
• Service-Procedures
• Skillbase for operating the Service
• Headcount for operating the Service
• Application-Landscape
• Technology-Landscape
• Provider-Landscape
• Ensure that the implementation roadmap conforms the Servicedesign
package
87. Approach
• Establish a project that will enable the delivery of service components
agreed for implementation during the Planning Phase
• Adopt a phased deployment schedule that reflects the business priorities
embodied in the Project Roadmap.
• Follow the organization's standard for corporate, IT, and architecture
governance.
• Use the organization's established portfolio/program management
approach, where this exists.
• Define an operations framework to ensure the effective long life of the
deployed solution.
87
The overall approach is to:
88. Phase 1 - Input Objects
88
Build Service
Servicedesign Package
Requirements List
Building Blocks from Baseline Repository
Service Acceptance Criteria
Service Project Charter
89. Phase 2 - Process Steps
89
Build Service
1. Confirm Scope and Priorities for Build
2. Identify required Capabilities and Resources
3. Guide Development of Solutions Deployment
4. Perform Acceptance Criteria Reviews
5. Start and Coordinate Sub-Cycles on Process-, Service-,
Application-, Technology- and Provider-Layers
6. Perform Post-Implementation Review and Close the
Implementation
90. Phase 3 – Output
90
Build Service
Servicelevel Agreements
Drafted Transition Plan and Test-Scenarios
Components of Servicedesignpackage
Service Transition Packages
Policies, Processes, Organisational Structures and
Procedures
Skillbase and Staffing
Service Report Structures and Service Monitoring
92. Deploy Service
92.
Objective 1:
Develop the Target Provider Landscape that enables the operational
support of Service.
• Defining Resource-Categories for Service
• Defining Provider Classifications for Service
• Defining Provider- and Contractmanagement Policies and
Processes
• Defining Target Provider Landscape
Objective 2:
Identify Roadmap candidates based upon gaps between the
Baseline and Target Provider Landscape
93. Phase 1 - Input Objects
93
Deploy
Service
Requirements – now used for Test and Signoff
Communication Plan
Transition- and Test-Plan
Operational Readyness Assessments
Transition Packages from Build
94. Phase 2 - Process Steps
94
Provider
Landscape
1. Confirm Scope and Priorities for Deployment
3. Identify Deployment Resources and Skills
4. Coordinate final Customer Journeys and Acceptance Tests
7. Establish Early Life Support for Service
8. Manage Transition between Baseline Mode and Target Mode of
Operation
10 . Perform Post-Implementation Review and Close the Implementation
2. Define Deployment Scenarios and Sequences
5. Coordinate Validations and Expectation Management
6. Coordinate and Authorize Deployments
9. Establish operational Change Management for Service – Invoke new
Development Cycles
95. Phase 3 – Output
95
Deploy
Service
Implementation Review Results
New Requests for Service-Architecture-Work
Candidates for new Release of Baseline-Repository
Active Policies, Processes and Management Controls
Established Organisational Structures
Actualized Serviceportfolio, Servicecatalogue and Services
Active Service-Resources
(Application, Technology, Provider)
Output for Results-Repository
97. Learn and Improve - Objectives
• Providing continual monitoring and a change management process to ensure that the
architecture responds to the needs of the enterprise and maximizes the value of the
architecture to the business.
• Preventing “creeping elegance” whilst changing the architecture building blocks within
established Service
• Validation of opportunities in adapting
– Existing Architecture Building Blocks in the Repositories
• Policies, Processes
• Serviceportfolio and Servicecatalogue
• Technologies (Application, Technology)
• Providers
• Invoking Improvements within Service-Context or Service-Development-Cycle itself
• Keeping Repository-Content actual, complete, accurate and accessable
97
98. Phase 1 - Input Objects
98
Learn –
Improve
Change-Requests
New Business Scenarios
New Technology Input
New Deployed Building Blocks
Existing Baseline and Solution Building Blocks
99. Phase 2 - Process Steps
99
Learn -
Improve
1. Establish Value Realization Process
2. Deploy Monitoring Tools
3. Review new deployed building blocks
4. Provide Analysis for Architecture Change Management
5. Develop Change Requirements to meet Performance
Targets
6. Manage Governance Process for Repositories and
Architecture Building Blocks in Service
6. Activate the Process to Implement Change (for Starting
new Cycle)
100. Phase 3 – Output
100
Learn -
Improve
Changes on Architecture Framework and Principles
New Project Charter for Architectural Work
Repository Content Updates
Repository Structure Updates
101. • Servicedesign Thinking and Blueprint Approach
• The Service Development Cycle and it’s building blocks
• Blueprints stored in Repositories as success factor in Service
realization
Agenda
103. • Work with the principle of Building Blocks
• Use a Repository for your those
• Follow the principle of Re-Useability
• Classify along Evolution History of Building Block
– Requirements capturing from (pre-phase)
– Baseline Architecture
– Target Architecture
– Solution Architecture
• Solution Building Blocks always have
– Input- and Output Parameters (often described in Lists)
– Relationships or Interfaces (often described in a Matrix)
– Activity or Status Flow (often described in Diagrammes)
– Are saved and baselined in Repositories
• Consolidate recurring Relationships of Building Blocks in a Blueprint
• Store Building Blocks and Blueprints in a Baseline Repository
What means Repository Approach
103.
105. • Higher frequence in solution deploys
• Consistency within developped solutions
• Higher degree of interoperability within Target Organisations
• Lower Cost of Operation
• Higher responsibility to changes at business level
Consequences
105.