The Barefoot Cobbler's Child: an Enterprise Architecture for IT Service Management, Resource Plannin

1
The Barefoot Cobbler's Child an Enterprise
Architecture for IT Service Management, Resource
Planning, and Governance

• Charles T. Betz
• Enterprise Architect
• Author, www.erp4it.com

2
Trying to make sense of the enterprise IT world

• IT Governance
• Portfolio Management
• Project Portfolio Management
• Application Portfolio Management
• IT Portfolio Management
• IT Service Management
• Change
• Incident
• Config
• Asset
• Release
• Capacity
• Continuity
• more
• Standards
• ITIL, COBIT, CMM, TOGAF, IEEE/ISO/ANSI,

• Business Service Management
• Enterprise Architecture
• Configuration Management
• Application/Technology Relationship Mapping
• Application Profiling/Reverse Engineering
• IT Discovery
• Data Metadata Management

3
The basic elements of architecture

• Process
• What you are doing
• Data
• The information you need
• System
• How you are doing what you are doing

4
The major IT functional areas
5
The IT digital dashboard - Planning

• What are the most promising future investments in
  my IT portfolio?
• What current investments are good? questionable?
  bad?
• For an application/service, what are the total
  costs (w/drilldowns) of acquisition and
  operations? Including shared or amortized costs
• What are the steady-state drivers of my
  operational costs?
• What cyclic events (lease, capacity, technology
  refresh) do I need to plan for?
• What are the impacts/dependencies?

6
The IT digital dashboard Construction/evolution

• I need to upgrade service or system X
• What is its complete bill of materials?
• Top to bottom interdependencies their nature?
• What systems use data element Y?
• What does it mean?
• What is its lineage?
• What security/privacy policies apply to it?
• What is the current status of the software
  development lifecycle across within projects?
• What major changes are upcoming?
• What is the current overall degree of change in
  my systems?

7
The IT digital dashboard - Managing

• How am I spending my IT dollars?
• Development
• Support/Operations
• What is the operational status trending of my
  systems?
• Incident Problem
• Support Maintenance
• Change
• How do my incident/problem metrics relate to my
  change activities?
• Business impact of technical issues

8
Current process frameworks

• COBIT
• Val IT
• CMM
• ITIL

9
IT framework maturity model
Level 1
Level 2
Level 3
10
Generic value chain
IT

• Michael Porter
• IT is just an enabler

11
Run IT as a business?
IT

• A firm whose business is IT
• or, an internal IT provider considered as its own
  value chain

12
Cross-functional integration

• Identify portfolio entries once
• Governance to development ops
• Identify dependencies once
• Development to operations
• Development feedback to governance
• Suitability of standards as well as adherence!
• Operations feedback to development
• Hold teams accountable for quality of systems as
  well as time/cost/features

• Operations metrics to Governance
• Based on same portfolio as Development

13
Process challenges

• Defining portfolio management
• Service entry points
• Customer Relationship Management
• Demand Management
• RFCs
• Service Requests
• Incidents
• Proper scope of config and change (ITIL issues)

14
Service Desk debates

• Can all business/IT interactions be effectively
  channeled through the Service Desk?

(see book, p. 93)
15
Who is this man and what does he want?

• Ralph Szygenda, CIO, General Motors
• The next thing is IT ERP. At GM, the complexity
  of managing IT is an astronomical thing.

16
What is ERP?
17
First generation enterprise resources money,
productive capital, goods, and people . . .
18
Next generation ... relationships, intellectual
property, and information
MyCo Inc
Enterprise Ltd
19
In the first four resources . . .

• Documents and transactions rule
• Quantity workflow

20
information a fundamentally different
enterprise resource

• The data sets are smaller and more intricately
  linked
• Managing complexity, not scale
• How to add, change, or remove without unintended
  consequences?
• This is usually not a problem in the other
  domains.
• The importance of a model

21
Why do we care about data?

• We want to apply performance optimization
  techniques to IT itself
• This requires metrics management i.e., business
  intelligence
• Metrics provide the information we need to
  optimize processes
• Information is nothing more than
  context-relevant, actionable data
• Therefore, IT process improvement depends on a
  foundation of clean, high-quality data

22
Core IT information is currently mis-aligned and
mismanaged

• Multiple conflicting portfolios
• Applications
• Hardware
• Projects
• No recognition of portfolios as reference data

23
Conceptual data model
24
Data architecture challenges

• Service offering, service request, service,
  non-orderable service
• Business process, service, application
• Technology vs. application
• Server vs. machine
• General principle data should be captured in
  primary value chain, not supporting processes!
• Matrix data to process and system. Determine
  systems of record for each entity.

25
Example process/data interaction pattern
26
An iterative approach to the CMDB
27
Systems in scope

• Plan/Control
• Portfolio Management
• Demand Management
• Service Management
• Capacity Planning
• Enterprise Architecture
• Business Continuity
• Risk Management
• Contract Management
• Asset management
• Vendor/Procurement
• Build
• Project Management
• Requirements Management
• Software Asset Management
• SOA Management
• Issue Management
• Software Configuration Management
• Software Test Management

• Run
• Security Management
• Element Management
• Change Management
• Enterprise Monitoring
• Incident/Problem
• Service Request Management
• Build-run
• Job Scheduling
• Release Management
• Computer Assisted Software Engineering
• Integration Management
• Information
• Metadata repository
• Configuration management database
• Knowledge management
• Document management

28
Simplified system model
29
Systems architectures

• Need enterprise-class, modern architectures
• Object/relational
• Admin-level flexibility
• Configurable forms
• SOA

30
Configuration Management and Metadata Management
Two sides of the same coin?
31
What is metadata?

• A view from the data analysis community
• Metadata describes critical elements of data
  scattered across the organization. (Jahn)

32
Scope, scope, scope

• All of the following are metadata according to
  current metadata experts
• Software portfolio (application inventory)
• IT assets (hardware inventory)
• File, database, object, class, and component
  definitions
• Business process documentation
• Organizational structure as it relates to IS
  system control (e.g., data stewardship, business
  process ownership)
• Data transformations
• Batch job operations
• Data quality statistics
• Software configuration management

33
Problems withthe metadata vision

• Keeping it up to date
• Data warehouse before the operational system?
• Technical metadata
• Integration metadata

34
Configuration management according to ITIL

• The Configuration Management system
• identifies relationships between an item that is
  to be changed and any other components of the
  infrastructure,
• thus allowing the owners of these components to
  be involved in the impact assessment process.
• Whenever a Change is made to the infrastructure,
• associated Configuration Management records
  should be updated in the CMDB.
• Where possible, this is best accomplished by use
  of integrated tools that update records
  automatically as Changes are made.

35
A useful but problematic picture
The Service-Support Process Model
Approximation of well known ITIL graphic
36
Comments

• Poses challenging concept of a centralized IT
  coordination system, which certainly did not
  exist at the time and arguably not even now
• It is the closest thing ITIL has to an
  architectural drawing
• The most obvious reading starts top left, with
  incident. This is indicative of ITILs
  operational bias. The true IT value chain starts
  with ideation, as ITIL admits in other volumes.
• This picture will almost certainly not be seen in
  ITIL v3

37
Decomposing the troublesome word configuration

• A configuration item a discrete object of a
  given type.
• The router, the server, the software, the
  application.
• The configuration of the item itself - the
  value of its attributes, parameter settings, etc.
  
• The router's IPv6 support is turned off.
• The server has 6 hard drives, and "Wake on LAN"
  is turned OFF.
• The Apache installation is running on port 8080.
• The configuration of the item with respect to
  other items dependencies, associations, feeds,
  etc.
• Oracle Financials receives a feed from CA
  Clarity.
• Price Lookup at the POS register requires
  Enterprise Catalog to be on line.

38
Three kinds of configuration management

• Software
• Element
• Enterprise
• Enterprise configuration management conceptually
  may include
• Enterprise architecture
• Metadata management
• Core CMDB products and their associated suites

39
The fundamental business purposes of
configuration management

• Providing on-demand insight into complexity
• Saving research time
• Especially during crises
• Ensuring the right people are talking to each
  other

40
Scope of CMDB

• From ITIL Service Support volume
• Infrastructure servers
• Mainframes
• Customer and supplier databases why stop there?
• Operational environments and applications
  supporting regulated business systems
• Mission-critical services

• Desktop builds and software licences
• Networks.
• Items that could affect regulatory compliance for
  the organisation
• EDI and database feeds, e.g. payroll feeds
• External interfaces to trading partners,
  suppliers, Customers and business partners
• Interfaces to branches with Customer systems

41
Other possible CMDB data sources

• From ITIL Service Support volume
• Requirements analysis and design tools, systems
  architecture and CASE tools
• Database management audit tools
• Document-management systems
• Distribution and installation tools
• Comparison tools
• Build and release tools
• Installation and de-installation tools

• Compression tools
• Listing and configuration baseline tools
• Audit tools (also called 'discovery' or
  'inventory' tools)
• Detection and recovery tools
• Reporting tools

42
Metadata repository vs. CMDB
43
Integrating data management and configuration
management

• Data models and databases are (or should be)
  configuration items
• CIs can be logical as well as physical most
  notably, Service and Application are seen as
  CIs by ITIL.
• Data definitions? Entities? Tables? Data
  elements? Why not? especially if sensitive.
• Instituting formal change control can strengthen
  data QA (DA/DM should be a formal change
  approver).
• Both CMM and ITIL can help here.

44
Can my metadata repository also be a CMDB?

• Possibly, but
• Most ITIL suites integrate at least change,
  config, and incident.
• More convenient, but also greater vendor lock-in.
• Stand-alone CMDBs do exist
• One can decouple the CI inventory from process
  applications through unique IDs (e.g. URLs/URIs)
• Your repository starts to turn into an OLTP tool
  be ready
• Note There is no such thing as ITIL-Certified
  or ITIL-Compliant with respect to software.

45
Repository as CMDB - 2
Are you ready for complex data?
46
Challenges of complex data

• Deep inheritance from highly abstract supertypes
• Recursion (trees and networks)
• Many many-manys
• All of the above result in object/relational
  mapping layers in advanced repository products
• Industry standards

47
CMDB metamodel

• Want to model table/column containment using
  this?
• Far too close to the data modelers inside joke

48
Problems of unconstrained any to any

• Columns can contain databases, tables can contain
  servers, and so on.
• Logical consequence black belt team emerges
• Cant outsource data entry
• Need standards!

49
DMTF CIM analysis

• Most dependencies are expressed via primary root
  object
• Encourages unconstrained any to any

• This is only a fragment, but data architecture is
  consistent throughout spec

50
An iterative approach to the CMDB
51
Summary

• Architect your IT systems with a value chain
  perspective
• Focus on functional integration points
• Apply a normalized conceptual model, mapped to
  process and system
• Manage your IT enablement systems as a portfolio
• Keep reading and trying new things... stay tuned
  in.

52
For more information

• Charles T. Betz
• charb_at_visi.com
• www.erp4it.com
• Book now available!
• Architecture and Patterns for IT Service
  Management, IT Resource Planning, and IT
  Governance
• Making Shoes for the Cobbler's Children
• Morgan Kaufman/Elsevier, 2007