Download Report

MSDP 2.0
How to get there
TEAM Project
Methodology Pack
Abbreviations
ABBREVIATION
TERM
BO
Business Object
BS
Business Service
I/O
Input/Output
OG
Object Group
SCM
Service Collaboration Model
SLCM
Solution Lifecycle Manager
SME
Subject Matter Expertise
VA
Vision Architecture
Ericsson Internal | 2012-03-06 | Page 2
Moving msdp from being a business
constraint to a business enabler
• Complex structure with many dependencies
• Becomes a true Competitive Edge being proud of
• New functionality takes long time to implement
• Brings down TTM and secure quality
• Difficult to support new business requirements
• A Business enabler supporting new business models
and requirements
Provides support for strategic decisions
• Only supports parts of the global services portfolio
• MSTOP 2G is not supported
• Contains customer specific solutions
• Provides solid ROI and TCO reduction
• Secures alignment between business and tools
• Enables full support of business processes (e.g.MSTOP)
Ericsson Internal | 2012-03-06 | Page 3
TEAM project Scope step 1
› In scope for TEAM project
– MSTOP 2G Processes including interaction between
these processes and their information needs
› Event Management
› Incident Management
› Problem Management
› Field Operations Process
› Change Management
– Service areas
› Network operations
› Field maintenance
– Technology domains
› Wireline
› Wireless
› Out of scope for
–
–
–
–
–
–
All other MSTOP processes
All other MSDP AS-IS Processes
All other Non MSDP processes
Technology domains
All other service areas
These areas may be applicable for
follow up projects
Ericsson Internal | 2012-03-06 | Page 4
Project TEAM 1
2011-08-31
TG1
2012-09-03
2013-03-01
TG2
2013-04-30
TG3
Project
Mgmt.
TG0
2011-10-16
TG4
TG5
Steering
Control
EA Governance Development
Develop EA
Governance
Governance Feasibility
Feasibility study
Mobilize
EA Coaching
Design long term solution
Analyze process architecture
Develop Service Architecture
Develop Vision Architecture
Develop Information Architecture
Analyze System Architecture
Develop Solution Architecture
Secure MSTOP alignment
MSDP Delivery process (Design, Development and Deployment)
Ericsson Internal | 2012-03-06 | Page 5
Establish EA
Governance
Operate EA
Governance
Designing the long term
solution in six work packages
Analyze Process Architecture
Produce I/O
Hypothesis
Validate I/O
Define I/O
Build Common
Process Information
Flow Model
Develop Vision
Architecture
Draft Vision
Architecture
Develop Service Architecture
Draft Service
Architecture
Detail Service
Collaboration
Model Business
Objects
Review & Approve
Service
Architecture
Define Vision
Architecture
Scenarios
Develop Information Architecture
Describe AS-IS
and gather
requirements
Create Object
Group Hypothesis
Verify and Finalize
Object Groups
Review & Approve
Information
Architecture
Analyze Vision
Architecture
Scenarios
Analyze System Architecture
Decompose AS-IS
Systems
Model Integration
Landscape
Collect & create
system data
models
Finalize Vision
Architecture
Develop Solution Architecture
Identify Current
and Future
Demands
Internal Market
Scan (System
Diagnose)
Prepare, Submit
and Analyze high
level RFI for main
systems
Select Main
System Hot
Candidates
Define Overall
Architecture
Complement RFI
Describe
Transformation
Scenarios
Create
Transformation
Roadmap
› Scope
– The scope was reduced and adapted to
accommodate think big – start small – act now
– Identify all the information object groups – start
working on 5 of the MSTOP2G processes –
work hypothesis driven
› Plan
– One driver per track
– Collect all information in a common tool
– Mix people experienced with architecture work
with domain experts
› Work
– Change of setup from stream drivers to drivers
per processes after initial evaluation of progress
– Ways of working was accommodated
accordingly
– This led to a more iterative approach to the
development
– Possible to complete all streams per process in
6-8 weeks with a 5 person dedicated TEAM
› Enterprise Architect (driver)
› Modeler (tool responsible)
› Information Architect
› Process SME
› SLCM
The TEAM Project is currently working with the Solution Architecture
Ericsson Internal | 2012-03-06 | Page 6
USING EXISTING KNOWLEDGE TO DRAFT
INFORMATION MODELS
Reference model from SID
1
Reference model from ECIM
2
› Purpose & Scope
– Reusing and building upon existing knowledge
– Aligning with previously established information
structure
– Ensuring that information requirements support
desired AS-IS possibilities
› Prerequisites
– Access to reference models and AS-IS models
› Deliverables
– Understanding of AS-IS, existing needs, pain points,
future plans etcetera.
– Alignment with desired AS-IS possibilities
AS-IS system data model
3
4
AS-IS system data model
Parameters
Profile
Customer
Groups
Location
Groups
Location Types
Customer
Location
Repair Center
› Brief Description
Work Log
1. Using SID to draft information models
2. Using ECIM to draft information models
3. Using system data models to ensure alignment with
AS-IS information requirements
Sent Incident
Items
Change Request
MSDP State
Maintenance
Request
MSDP Priority
Site
User
Order
Sparepart
Product
Entity type
› Methodology Conclusion
Service
Node
NOC User
Trouble Ticket
Work order
Attachment
User Groups
Service Order
Process?
Order line
Customer
CSUL - Customer
Service Unit List
Ext User
Bullentin Board
TT Type
TT Sub
Category
NOC
Organisation
User Group
NOC
– Reference models help in effectively and efficiently
developing a basis for further development. During
this project reference models were used primarily for
creating drafts which later were used as basis for
discussion and further development.
Organizational
unit
Reference models enabled efficient drafting of information models and ensured
alignment with AS-IS functionality
Ericsson Internal | 2012-03-06 | Page 7
Identifying INFORMATION produced and
consumed By processes
Excel spreadsheet with I/O
2
Event Management
INPUT
Monitoring log book
record (Event Record)
Resource
interdependency
(topology) and service
mapping
List of Commands per
resource
1
Active Monitoring
Continuation Decision
Result (Positive, from
1.16)
Activity flow
Resource Monitoring
Data
Resource Type
Thresholds
Monitoring log book
record (Event Record)
3
ACTIVITY
OUTPUT
CLARIFICATION
Once the need to
perform Active
Monitoring is confirmed,
1st Level Operations
should perform the
Perform active
Active Monitoring on the
1.04 monitoring as per Network covering the
Monitoring data
need
area specified in Log
Book. This would
generally mean to
constantly check the
health of one or a set of
resources.
Verify if there is any
deviation on the
performance or
utilization of the
Analyze
Active Monitoring
1.05
resource, compared to
monitoring data
Analysis Result
the expected behavior
taking into consideration
the monitoring
objectives.
ID
PROCESS
ACTIVITY
Activity flow with I/O
› Purpose & Scope
– Capturing Process I/O as a foundation for further
architecture development
› Prerequisites
– Activity flow
› Deliverables
– I/O mapped to Business Processes
› Brief Description
1. Capturing the current Activity flow
2. Creating a Excel spreadsheet based on the activities
for the organization to fill out with process I/O.
Sending out and receiving Excel spreadsheet.
3. Modeling process I/O and write in the descriptions
Conducting workshops to verifying I/O and
descriptions.
› Methodology Conclusion
– Capturing I/O using excel was efficient, but it should
be thoroughly explained how to work with the
spreadsheet. Examples are vital.
– Identifying inputs and outputs are absolutely
necessary in order to further develop the service
architecture. Sometimes it was a bit awkward to
define them activity level - a pragmatic approach is
necessary.
Identifying process inputs and outputs as a foundation for further architecture work
Ericsson Internal | 2012-03-06 | Page 8
STRUCTURING Business information
REQUIREMENTS
I/O sorted per OG
2
Environmental
data
Preventive
Maintenance
1
Activity flow with I/O
› Purpose & Scope
Change/Maintenance
information
Matched Change /
Maintenance Identification
Weather feed
Maintenance information
Matched Change /
Maintenance Information
Weather/news highlight
(verification)
Change/Maintenance list
Matched Change /
Maintenance Identification
(If positive)
News feed
– Capturing business information requirements
– Transforming process I/O to information objects
– Identifying information architectural building blocks
› Prerequisites
– I/O mapped to Business Processes
– I/O described and exemplified
› Deliverables
– Object Group hypothesis
– Business Object hypothesis
Change/Maintenance list /
information
› Brief Description
I/O sorted per BO
3
MONITORING
DATA
Resource monitoring
evaluation result
Resource Monitoring
Results
ACTIVE
MONITORING
REQUEST
Active Monitoring
Continuation Decision
Result
Active Monitoring Request
1. Using activity flow as input for IA
2. Creating and validating OG hypothesis by sorting I/O
Resource Query Resultper OG
3. Creating BO hypothesis by sorting I/O per BO
› Methodology Conclusion
Deviation Persistency
Check Result
– I/O’s were well described and exemplified. This was
very valuable in order to understand the process flow
and to understand the information requirements.
– Some amount of redundancy existed amongst I/O.
This made the analysis slower than anticipated.
Perform Active Monitoring
Decision
ACTIVE
MONITORING
STATUS
REPORT
Status Report
ACTIVE
MONITORING
QUALIFICATOR
S
Active Monitoring Decision
Rule Set
RESOURCE
TYPE
THRESHOLD
Resource Type Tresholds
Structuring business information in order to identify information building blocks
for the overall architecture
Ericsson Internal | 2012-03-06 | Page 9
Bridging process and Business Service
Architecture
Activity Flow with I/O
1
2
Process Capability Mapping Model
› Purpose & Scope
– Identifying Process Capabilities based on business
processes
– Collaborating Capabilities with Business Objects
› Prerequisites
– Activity flows
– I/O described and exemplified
› Deliverables
– Process Capabilities
– Business Collaboration Model
› Brief Description
I/O sorted per BO
3
MONITORING
DATA
Resource monitoring
evaluation result
Resource Monitoring
Results
ACTIVE
MONITORING
REQUEST
Active Monitoring
Continuation Decision
Result
Active Monitoring Request
4
Resource Query Result
Deviation Persistency
Check Result
Perform Active Monitoring
Decision
ACTIVE
MONITORING
STATUS
REPORT
Status Report
ACTIVE
MONITORING
QUALIFICATOR
S
Active Monitoring Decision
Rule Set
RESOURCE
TYPE
THRESHOLD
Resource Type Tresholds
Capability Collaboration Model
1. Capturing the Activities in the Activity flow
2. Drafting and mapping Process Capabilities to
Activities
3. Validating and choosing Business Objects to be used
4. Iteratively puzzling out how Process Capabilities
collaborate with Business Objects using previously
drafted capabilities and business objects.
› Methodology Conclusion
– Shortcomings in the Activity flow resulted in many
iterations to find appropriate Process Capabilities
and identifying the information flow.
Identifying how information flows between Capabilities by puzzling together
drafted Capabilities and Business Objects
Ericsson Internal | 2012-03-06 | Page 10
DETAILING AND STRUCTURING BUSINESS
INFORMATION REQUIREMENTS
Capability Collaboration Model
1
Business Object Model
2
ALARM
L3 ALARM
ENRICHMENT
&
CORRELATIO...
› Purpose & Scope
Contains information about alarm, thresholds
crossed together with a reference to the resource
causing the alarm.
CONFIGURATION
ITEM
– Describing detailed information requirements with
entities and relationships between entities
– Describing the contents of key business objects
– Arranging business information requirements into
information architectural building blocks
ALARM SLOGAN
L3
RESOURCE
CONFIGURATI
ON
ALARM
ALARM STATUS
L3
TOPOLOGY
ALARM
COMMENT
Qualify
m
CONFIGURATION
ITEM
L3
PERCEIVED
SEVERITY
L3
ALARM SLOGAN
ALARM
RESOURCE
ALARM
› Prerequisites
ALARM SPECIFIC
PROBLEM
– Business Objects identified
– Service Collaboration described
ALARM CLASS
ENRICHED
ALARM
Enrich and
Correlate Alarm
PROBABLE
CAUSE
ALARM TYPE
› Deliverables
EVENT TYPE
(X733)
Alarm
Object Group Model
3
ALARM TREND
RESOURCE TYPE
DIMENSION
Business
Object Model (updated)
4
ALARM TREND
ALARM IMPACT
ANALYSIS
ALARM
CORRELATION
LOCATION
ALARM
CORRELATION
TYPE
CONFIGURATION
ITEM
ALARM SLOGAN
RESOURCE
THRESHOLD
APPLICABILITY
THRESHOLD
CROSSED
THRESHOLD
ALARM
ALARM SPECIFIC
PROBLEM
ALARM
OMMENT
CROSSED
THRESHOLD
ALARM STATUS
ALARM
COMMENT
PROBABLE
CAUSE
ERCEIVED
SEVERITY
RESOURCE
ALARM
PERCEIVED
SEVERITY
RESOURCE
THRESHOLD
APPLICABILITY
ALARM SPECIFIC
PROBLEM
ALARM SLOGAN
Alarm
ALARM TREND
ALARM
IMPACTED
OBJECT
ALARM IMPACT
ANALYSIS
ALARM TREND
DIMENSION
RESOURCE TYPE
We can have lot of different dimensions,
e.g. all properties of an alarm can be a
propertiy.
ALARM CLASS
LOCATION
ALARM
CORRELATION
ALARM
CORRELATION
TYPE
ALARM
ALARM STATUS
RESOURCE
THRESHOLD
APPLICABILITY
CROSSED
THRESHOLD
ERICSSON
HUMAN
RESOURCE
ALARM SPECIFIC
PROBLEM
ALARM
COMMENT
PROBABLE
CAUSE
PERCEIVED
SEVERITY
ALARM TYPE
ALARM CLASS
WARNING
TREATMENT
PROCEDURE
WARNING
TREATMENT
PROCEDURE
WARNING
TREATEMENT
PROCEDURE
STEP
WARNING
TREATEMENT
PROCEDURE
STEP
EVENT TYPE
(X733)
AUTOMATIC
WARNING
TREATEMENT
PROCEDURE
Complex object that could represent some
property of an alarm, e.g. alarm type, alarm
class or other property.
TIME BASED
CORRELATION
RULE
RESOURCE
INTERACTION
RULE
COMBINED
CORRELATION
RULE
ALARM FILTER
RULE
WARNING
TREATEMENT
PROCEDURE
APPLICABILITY...
RESOURCE TYPE
CONFIGURATION
ITEM
ALARM CORRELATION RULE
TOPOLOGY
BASED
CORRELATION
RULE
MANUAL
WARNING
TREATMENT
PROVEDURE
ALARM TYPE
EVENT TYPE
(X733)
WARNING TREATEMENT PROCEDURE
APPLICABILITY
ALARM
PROPERTY
› Brief Description
1. Identifying which Business Objects to detail using the
Capability Collaboration Models
2. Detailing Key Business Objects
3. Distributing BO information structures into OG:s
4. Updating BO:s based on adjustments during previous
step
› Methodology Conclusion
ALARM CLASS
PROBABLE
CAUSE
CONFIGURATION
ITEM
ARM TYPE
ALARM
CORRELATION
RULE TYPE
– By iterating between BO:s and OG:S the quality of
the architecture improves. Iterating also supports
finding the right balance between generalization
(flexible) and specialization (restrictive)
WARNING TREATEMENT PROCEDURE
APPLICABILITY
Complex object that could represent some
property of an alarm, e.g. alarm type, alarm
class or other property.
WARNING
TREATEMENT
PROCEDURE
APPLICABILITY...
Structuring the same business information with different contexts in
mind enhances architecture quality
AUTOMATIC
WARNING
TREATEMENT
PROCEDURE
ALARM
ROPERTY
ORRELATION RULE
causing the alarm.
ALARM
RM STATUS
VENT TYPE
(X733)
We can have lot of different dimensions,
e.g.
all properties of an alarm can be a
Contains information about alarm, thresholds
crossed together with a reference to the resource
propertiy.
ALARM
– Detailed Business Objects
– Detailed Object Groups
MANUAL
WARNING
TREATMENT
PROVEDURE
RESOURCE TYPE
Ericsson Internal | 2012-03-06 | Page 11
CONFIGURATION
ITEM
Analyzing how requirements impact
Capabilities and information
Requirement spreadsheet
1
Capability Requirement Model
2
› Purpose & Scope
– Ensuring high precision in capabilities, their
collaboration, Information requirements and Vision
architecture
Requirement:
Possibility of linking Work done on PT with Time
Reporting (the way it works for SMS tool in Customer
Support);
› Prerequisites
– Defined Service Collaboration and information
models
The description of the developed Problem Management
tool must be used as specification for the MSDP tool and
it must support migration of the existing data.
› Deliverables
– Defined functional requirements on capabilities
– Defined Information requirements
– Calibrated Vision Architecture
Object Group Model
3
MS Domain Collaboration Model
4
L2
PROBLEM
INVESTIGATION
PLAN
Incident & Problem Management
L4
L4
Incident
L4
Known Error
Problem
PROBLEM WORK
PROBLEM WORK
TYPE
PROBLEM WORK
STATUS
SOLUTION
INVESTIGATION
WORK
ROOT CAUSE
INVESTIGATION
WORK
PROBLEM
EVALUATION
WORK
SOLUTION
DEPLOYMENT
WORK
Planned, Ongoing, Complete
L3
L3
ACTIVE
MONITORING
REQUEST
ACTIVE
MONITORING
CONCLUSION
Network Performance Management
L4
Monitoring
Activity
› Brief Description
1. Identifying the functional requirements via users,
SMEs and SLCMs
2. Analyzing how requirements impact capabilities and
information
3. Securing the information requirements by ensuring
that the input /output from capabilities correspond to
what is stated by the requirements
4. Calibration of the Vision Architecture
› Methodology Conclusion
– By utilizing the available requirements model quality
is increased. Designing into them into the
architecture creates the baseline for development.
Analyzing requirements is vital for ensuring that solutions meet desired business value
Ericsson Internal | 2012-03-06 | Page 12
SYNCHRONIZING INTERFACES BETWEEN
DIFFERENT business service AREAS
1
IM Capability Collaboration Model (draft)
2
CM Capability Collaboration Model (draft)
› Purpose & Scope
– Synchronization of capability collaboration for
different process areas, e.g. IM an CM.
› Prerequisites
– Capability Collaboration described
› Deliverables
– Capability Collaboration synchronized between
different process areas
› Brief Description
3
Contradicting Capability Collaborations
4
Capability Collaboration Model (approved)
1. Describing Capability Collaboration for a process
area
2. Describing Capability Collaboration for another
process area
3. Identifying dependencies and possible contradictions
between SA for different Business Service areas
4. Analyze and resolve contradictions and update the
Service Architecture
› Methodology Conclusion
– The amount of synchronization will vary depending
on the prerequisites for the teams responsible for
different parts of the architecture development.
Synchronization of architectural part developed in parallel
ensures a coherent architecture
Ericsson Internal | 2012-03-06 | Page 13
Developing the basis for landscape
planning and consolidation analysis
MS Domain Collaboration Model (initial draft)
1
2
Capability Collaboration Models
Request Fulfillment
– Creating a foundation for calibrating the Vision
Architecture
Problem
Management
...
CAPACITY /
PERFORMANC
E PROBLEM
PROBLEM
STAATUS
REPORT
Capacity &
Performance
Management
PROBLEM
STATUS
REPORT
RCA REPORT
KNOWN
ERROR
INFORMATION
PM EARLY
ENGAGEMENT
INCIDENT
REPORT
INCIDENT
TREND
Incident Management
Collaboration
Management
HIERARCHICAL
ESCALATION
Access
Management
Riktning? Komplettera med EMERGENCY CHANGE?
Security
Management
Why is this going to PM
and not CPM?
ACTIVE
MONITORING
REQUEST
EMERGENCY
CHANGE
REPORT
CHANGE
REQUEST
INCIDENT
STATUS
REPORT
SERVICE
HANDOVER
RESOURCE
HANDOVER
ALARM
INCIDENT
EVENT TREND
ACCESS
REQUEST
ACCESS
APPROVAL
CHANGE
SUPPORT
CHANGE
ASSESSMENT
& EXECUTION
APPROVAL
Change Management
Event Management
CHANGE
MONITORING
Deployment Event
Fall-back procedure
Monitoring Request
APPROVAL
PROCEDURE
AGREEMENT &
REVISION
› Purpose & Scope
SERVICE OR
RESOURCE
CONFIGURATI
ON REQUEST
AVALABILITY
IMPROVEMEN
T
OPPORTUNITY
Availability
Management
Field Operations
Management
WORK ORDER
NOTIFICATION
STANDARD
ORDER
EXECUTION
REPORT
Release &
Deployment
Management
INCIDENT
NOTIFICATION
END USER
SERVICE
PARAMETER
CONFIGURA...
Request Fulfillment
END USER
COMPLAINT
Collaboration
Management
STANDARD
ORDER
REQUEST
› Deliverables
– MS Domain Collaboration
› Brief Description
Information Architecture Model
3
SNIAMOD PDSM
1L
ygetartS ecivreS
ecnanrevoG ssenisuB
1L
tnemeganaM yrevileD ecivreS
1L
ngiseD ecivreS
noitisnarT ecivreS
ssenisuB
erutcetihcrA
2L
& gninnalP ssenisuB
lortnoC
tnemeriuqeR
tnemeganaM
dnameD
tnemeganaM
ssecorP sounitnoC 2L
tnemevorpmI
2L
ssenisuB
ecnegilletn
tnemeganaM noitarugifnoC & tessA
tnemyolpeD
tnemeganaM
ssenisuB
tnemevorpmI
ytinutreppO
ssenisuB SM
dnameD
ssenisuB
tnemeriuqeR
tnemeriteR & tnempoleveD noituloS
2L
/ kro W
nalP ecruoseR
ssenisuB
erutcetihcrA
tnevE tropeR
2L
esaeleR
tnemeganaM
noituloS
tnemyolpeD
2L
tnemeganaM eugolataC ecivreS
2L
2L
2L
resU dnE
ledoM ecivreS
noituloS
noitarugifnoC
metI
esaeleR
4
MS Domain Collaboration Model
1. Creating Domain Collaboration Model as a starting
point for framing capability collaboration development
2. Detailing each Business Service by identifying
capabilities and information flow
3. Create/Update the Information Architecture Model
based on acquired information knowledge
4. Complement the MS Domain Collaboration Model
with acquired insights
tnemeganaM ecnamrofreP & yticapaC
tnemeganaM egdelwonK
tnemeganaM ecruoseR
2L
noitarepO yrevileD ecivreS
sseccA
tnemeganaM
gninoisivorP ecivreS2L
2L
yrevileD ecivreS
noitanidrooC kro W
tnemllifluF tseuqeR 2L
snoitarepO dleiF
tnemeganaM
yticapaC
gninnalP
tnemeganaM tnevE
2L
ecivreS
tseuqeR
evitneverP
ecnanetniaM
redrO kro W
ecnamrofreP
tnemerusaeM
tnevE ecruoseR
yevruS
2L
resU dnE
sthgiR sseccA
tnemeganaM ytilibaliavA
tnevE
tnemeganaM niamoD krowteN
tnemeganaM egnahC
resU dnE
tcartnoC
2L
› Methodology Conclusion
2L
ycnegnitnoC
nalP
egnahC
2L
tnemeganaM melborP & tnedicnI
remotsuC
ecivreS
4L
melborP
rorrE nwonK
tnemeganaM ytiruceS
tnedicnI
resU dnE
tcudorP
tnemeganaM ytiunitnoC ssenisuB
leveL ytiruceS
tnemeergA
PDSM
tnemeganaM slooT
ataD latnemnoirivnE 2L
tnemeganaM
2L
noitacilppA
latnemnorivnE
atad
tnemeganaM mralA 2L
mralA
ecnamrofreP krowteN
tnemeganaM
tnemeganaM yrotnevnI krowteN
gnirotinoM
ytivitcA
krowteN
noitacoL
ssenisuB
nalP ytiunitnoC
2L
krowteN
noitisnarT snoitarepO remotsuC
yrevileD ecivreS
tnemeergA
SNIAMOD SGUB
SNIAMOD NOMMOC NOSSCIRE
tnemeganaM esuohera W
noitacinummoC
lennahC
ecnaniF
ecnaniF
tnemegagnE selaS
tnemeganaM niahC ylppuS
troppuS ssenisuB
noitarugifnoC nosscirE
tnemeganaM
2L
tnemeganaM yhpargoeG 2L
lacihpargoeG
aerA
noitaroballoC
tnemeganaM
tnemeganaM tcatnoC
noitacinummoC
tnevE
redlohekatS
tcatnoC
tnemeganaM ytilicaF
tnemeganaM tce jorP
gnidliuB
tce jorP
straP erapS
esuohera W
looT
selbamusnoC
redrO esuohera W
tnemeganaM
rodneV
tnemeganaM
esahcruP
/ reilppuS
rentraP
tcartnoC
/ reilppuS
rentraP
remotsuC
1L
tnempoleveD tcudorP
– Based on both information usage and structure, the
MS Domain Collaboration provides a stable
foundation for further analysis.
1L
ecivreS SM
remotsuC
tcartnoC
tnemeganaM latipaC namuH
ssecorP ecrofkro W
tnemeganaM
ecrofkro W
tnemyolpeD
lanoitazinagrO
tinU
tnemeganaM tnalaT
lennosreP
ecnetepmoC
eloR
Service Delivery Operation
L2
Event Management
L4
Event
L2
Incident & Problem Management
L4
L4
Incident
Problem
Describing both information structure and information usage within the same model
creates a solid foundation for balancing of the Vision Architecture
Ericsson Internal | 2012-03-06 | Page 14
using scenarios to DESIGN AND
CALIBRATE the vision architecture
L1
L1
Service Delivery Management
Service Strategy
Business Governance
Service Transition
Business
ntelligence
L2
L2
Asset & Configuration Management
L2
Configuration
Item
Deployment
Management
Report Event
Solution
Deployment
Release
MS Domain Collaboration Model
1
L2
L2
Release
Management
L2 Continuos Process
Improvement
L2
Business
Improvement
Oppertunity
Vision Architecture (partial)
2
Requirement
Management
MS Business
Demand
Business
Requirement
Work /
Resource Plan
L2
Business
Architecture
Business
Architecture
› Purpose & Scope
Knowledge Management
Resource Management
Demand
Management
Business Planning &
Control
Service Delivery Operation
Resource Event
Event Management
L2
L2
– Identifying aL2 vision architecture
that organizes
Access
Service Provisioning
L2
Management
information and capabilities in
a balanced way to
End User
ensure data quality,
eliminate redundancy and
Work Order
Access Rights
reduce complexity.
Survey
Event
Network Domain Management
Change Management
L2 Request Fulfillment
L2 Service Delivery
Work Coordination
Field Operations
Management
Service
Request
Preventive
Maintenance
› Prerequisites
End User
Contract
Change
L2
Incident & Problem Management
– SC and IA described
Customer
› Deliverables
L4
Incident
Problem
Known Error
Service
End User
L2
Network Inventory Management
Network Performance
Management
Network
Location
Monitoring
Activity
Network
Hypothesis & Scenarios
3
4
L2 Alarm Management
Alarm
Product
– Vision Architecture
and recommendations for further
L2
MSDP
development
Tools Management
L2 Envirionmental Data
Management
Environmental
data
› Brief Description
Application
1. Using Domain Collaboration to identify areas of
investigation
2. Drafting VA and identifying uncertainties,
hypothesizes and scenarios to examine.
3. Analyzing scenarios, domain boundaries and
information relationships by examining dependency,
frequency, criticality, strategic intent and reference
models (eTOM / ITIL), and updating VA
4. Identifying unresolved issues and creating
recommendations for how to proceed.
Recommendation (example)
“The optimal architecture is best
determined by detailing the
Configuration Management
Process and using new business
models as scenarios”
BUGS DOMAINS
L1
Product Development
MS Service
› Methodology Conclusion
ERICSSON COMMON DOMAINS
L1
Sales Engagement
Customer
Supply Chain Management
Vendor
Management
Warehouse Order
Management
Supplier /
Partner
Contract
Purchase
Warehouse Management
Warehouse
– Identifying and analyzing possible scenarios were a
engaging and effective way
to resolve uncertainties
Business Support
within core
areas
of
development.
L2
L2
Spare Parts
Geography Management
Finance
Geographical
Area
Finance
Scenario analysis of the Vision Architecture successively sets focus
on areas in need of architectural development
Customer
Contract
Supplier /
Partner
Consumables
Ericsson Internal | 2012-03-06 | Page 15
Human Capital Management
Tool
Contact Management
Collaboration
Management
Stakeholder
Contact
Communication
Event
Ericsson Configuration
Management
Communication
Channel
Balancing VISION- AND INFORMATION
ARCHITECTURE
Object Group Model for Service Delivery
Agreement (first hypothesis)
1
2
Domain Collaboration Model (first hypothesis)
Sales Engagement
Customer Operations
Transition
CUSTOMER
SERVICE
ELEMENT
WORKING LEVEL
AGREEMENT
SERVICE
LEVEL
AGREEMENT
Customer
Contract
ERICSSON
ORGANIZATION
UNIT
OLA ROLE
delivered by
– Identifying a vision architecture that organizes
information and capabilities in an balanced way to
ensure data quality, eliminate redundancy and
reduce complexity
CUSTOMER
CONTRACT
Service Delivery Agreement
NOC
ORGANISATION
USER GROUP
› Purpose & Scope
› Prerequisites
Service Delivery
Agreement
– Vision Architecture hypothesis
– Information Architecture hypothesis
CUSTOMER
SERVICE
ACTIVITY
OPERATIONAL
LEVEL
AGREEMENT
CUSTOMER
ORGANIZATION
UNIT
› Deliverables
COMMUNICATION
PROCEDURE
– Synchronized and optimized IA and VA
› Brief Description
CUSTOMER
CONTRACT
Object Group Model for Service Delivery
Agreement (second hypothesis)
3
4
Domain Collaboration Model (second
hypothesis)
Service Delivery Agreement
for
SERVICE DELIVERY AGREEMENT
SERVICE LEVEL
AGREEMENT
(SLA)
SERVICE
DELIVERY
AGREEMENT
ROLE
CUSTOMER
CONTRACT
PRIORITY
MATRIX
OPERATIONAL
LEVEL
AGREEMENT
CUSTOMER
CONTRACT
PRIORITY
MATRIX ITEM
SECURITY LEVEL
AGREEMENT
WLA
MS SERVICE
DELIVERY
PROCESS
L2 Customer Operations
Transition
relevant for
CUSTOMER
CONTRACT
Service Delivery
Agreement
SERVICE
DELIVERY
LEVEL
AGREEMENT
INCIDENT
CATEGORY
1. Draft Object Group Model based on BO:s
2. Draft Domain Collaboration based on OG:s and BO:s
3. Updating OG:s based on analysis of Domain
Collaboration
4. Updating Architecture Collaboration
› Methodology Conclusion
– Analyzing architectural building blocks from different
perspectives - how information is structured as well
as how information is used –may significantly impact
the resulting architecture.
CUSTOMER
CONTRACT
The Operational Agreement Specification is a
complex object representing service level
objectives such as "Availability of a specific
service of 90%" or
"Time To Resolve for Priority Critical = 4h for 90%
of incidents, 8h for 100% of incidents". It should
be possible to specify this on a low level, e.g. for
a specific node.
E LEVEL
ZATION
SET
Service Delivery Agreement
for
CUSTOMER
ORGANIZATION
UNIT
SERVICE DELIVERY AGREEMENT
SERVICE
DELIVERY
AGREEMENT
ROLE
ERICSSON
ORGANIZATION
UNIT
SERVICE LEVEL
AGREEMENT
(SLA)
OPERATIONAL
LEVEL
AGREEMENT
WLA
SECURITY LEVEL
AGREEMENT
CUSTOMER
CONTRACT
PRIORITY
MATRIX
MS SERVICE
DELIVERY
PROCESS
relevant for
CUSTOMER
CONTRACT
PRIORITY
MATRIX ITEM
VENDOR
ORGANIZATIONA
L UNIT
CUSTOMER
CONTRACT ITEM
INCIDENT
CATEGORY
3PP
ORGANIZATIONA
L UNIT
The Operational Agreement Specification is a
complex object representing service level
objectives such as "Availability of a specific
service of 90%" or
"Time To Resolve for Priority Critical = 4h for 90%
of incidents, 8h for 100% of incidents". It should
be possible to specify this on a low level, e.g. for
a specific node.
CUSTOMER
CONTRACT ITEM
part of
specifies terms & conditions for
SERVICE
DELIVERY
AGREEMENT
OBJECTIVE
KPI
SERVICE DELIVERY AGREEMENT SPECIFICATION
REPORTING
SPECIFICATION
REPORT TYPE
SECURITY
SPECIFICATION
COMMUNICATIO
N SPECIFICATION
REPORT
CHANNEL
PRIORITIZATION
RULE
CONSEQUENCE
TYPE
- Escalation
- Reporting
- Notification
- Other communication
- Etcetera.
SERVICE
DELIVERY
AGREEMENT
specifies terms & conditions for OBJECTIVE
CUSTOMER
OBJECT OF
SERVICE TYPE
CUSTOMER
OBJECT OF
SERVICE
CONFIGURATION
ITEM
CONFIGURATION
ITEM
TYPE
SERVICE
DELIVERY
SPECIFICATION
APPLICABILITY
SERVICE DELIVERY
AGREEMENT
CONSEQUENCE
SERVICE LEVEL
PRIORITIZATION
RULE SET
SERVICE
DELIVERY ROLE
TYPE
CUSTOMER OBJECT OF SERVICE ROLE
ESCALATION
CONFIGURATION
ITEM OWNER
CONFIGURATION
ITEM SHARER
ERICSSON
CUSTOMER
INCIDENT
CATEGORY
SERVICE
DELIVERY
GROUP
SERVICE
DELIVERY
GROUP TYPE
part of
KPI
SERVICE DELIVERY AGREEMENT SPECIFICATION
REPORTING
SPECIFICATION
SECURITY
SPECIFICATION
COMMUNICATIO
N SPECIFICATION
SERVICE
DELIVERY
SPECIFICATION
APPLICABILITY
Balancing the Vision Architecture results in an architecture that ensure data quality,
eliminate redundancy and reduce complexity.
SERVICE DELIVERY
AGREEMENT
CONSEQUENCE
Ericsson Internal | 2012-03-06 | Page 16
PRIORITIZATION
RULE
CUSTOMER
OBJECT OF
SERVICE TYPE
CONSEQUENCE
TYPE
- Escalation
- Reporting
- Notification
- Other communication
- Etcetera.
Identifying current it support and
gaps to target it support
1
System Component Model
2
Business Collaboration Model
› Purpose & Scope
– Ensuring that Process Capabilities and IT Functions
matches and no gaps exists
– Identifying GAPs between the AS-IS and TO-BE IT
Systems
› Prerequisites
– Decomposed systems into IT Functions
– Stable Service Architecture
› Deliverables
– A Gap model showing missing Business Capabilities
and IT Functions
3
IT Function and Capability
Gap Model
4
› Brief Description
IT Function and Capability
Gap Matrix
– Verifying System decomposition
– Collecting Process Capabilities for mapping to IT
Functions
– Comparing Capabilities and IT Functions and
creating a Gap model
› Methodology Conclusion
– A good way to ensure the quality of the outcome and
a starting point for identifying GAPs in IT Support
IT Functions and Process Capabilities resulting in a gap of unsupported Capabilities and
increased quality in Capability Models
Ericsson Internal | 2012-03-06 | Page 17
Ericsson Internal | 2012-03-06 | Page 18