Post on 20-Aug-2015
transcript
© 2008 IBM Corporation
Making SOA Operational
- Service Management enabling SOA -
Dr. Stefan Pappe
CTO Middleware Services
IBM Global Technology Services
© 2008 IBM CorporationOperational SOA2
Content
1. Integration of Development and Operations
2. Practitioner point of view
3. Architecture with a vision
4. SOA management
5. Exemplary project approach
6. More best practices
© 2008 IBM Corporation3
Every CEO and CIO cares about operational aspects
Enterprise Goals:
Drive top-line revenue growth
Continue to deliver bottom-line profit growth
Run the business while changing the business
Drive IT goals:
Reduce the cost and complexity of IT operations
Address governance, operational risk and compliance challenges
Deliver new value from existing assets (information and people)
Increase the flexibility of the business
Partner with the CEO to drive innovation
»
»
»
Business depends on quality service delivery
Operational SOA
© 2008 IBM Corporation4
Integration of the development and operations life cycles
Development View of IT Operations View of IT
Requirements
Analysis & Design
Implementation
Project Mgmt
Change Control
Documentation
Human Factors Test
PackagingArchitecture
Act Surprised
Installation
System Admin
Help Desk
Asset Mgmt
Capacity Planning
Deployment
Managing Changes
Availability Mgmt
Backup / Restore
IT Strategy
System Operation
Compliance Risk MgmtIdentity Mgmt
ContinuityFinancial Mgmt
Problem MgmtSecurity Mgmt
Development
Testing
Throw over Wall
The lack of lifecycle integration between development and operations continues to drive costs up and operational service quality down
Quality service delivery depends on integration
Sometimes Development tends to underestimate Operations (and vice versa)
Most IT organizations spend 70-80% on operations
Operational SOA
© 2008 IBM CorporationOperational SOA5
Content
1. Integration of Development and Operations
2. Practitioner point of view
3. Architecture with a vision
4. SOA management
5. Exemplary project approach
6. More best practices
© 2008 IBM Corporation6
SOA Deployment Best Practices & Lessons Learned from 152 projects
Methodical, cross-IBM approach to capture, analyze, feedback SOA deployment experiences
Reusable Results
Feedback and reuse in IBM Products and Services White paper for clients with top 5 best practices published at:
http://www-935.ibm.com/services/us/its/pdf/wp_five-best-practices-for-deploying-successful-soa.pdf
1. Develop an architecture with a vision for the future
2. Foresee linkages from IT to your business processes
3. Create an organizational culture and skills to support SOA
4. Build a scalable infrastructure
5. Enable operational visibility through governance and service management
SOA Deployment Lessons Learned / Best Practices Conference executed through IBM Academy of Technology
Applied standardized Case Study Template – incl. project information, architecture, project experience, assets&innovation
2007+2008 conferences resulted in 152 case studies, with 950 lessons learned / 870 best practices
Operational SOA
© 2008 IBM Corporation
Functional and Non-Functional Requirements we typically find in projects confirm the need to focus on infrastructure and operational aspects
5%
21%
6%
13%
17%
14%
8%
16%
Reuse
Connectivity
Interaction and Collaboration Services
Business Process
Information as a Service
Governance
Design
Security and Management
13%
4%
9%
6%
30%2%
3%
3%
7%
5%
2% 3%
10%
3%Availability
Flexibility
Governance
Interoperability
Performance
Regulatory
Reliability
Reusability
Scalability
Security
Servicability
Standards
Technology
Usability
Operational SOA7
Sample Functional Requirements
Sample NFRs
© 2008 IBM CorporationOperational SOA8
Content
1. Integration of Development and Operations
2. Practitioner point of view
3. Architecture with a vision
4. SOA management
5. Exemplary project approach
6. More best practices
© 2008 IBM Corporation
Building an SOA architecture with a vision for the future
The Operational View identifies the IT operational capabilities that are needed for implementing and
operating an SOA infrastructure.
Processes, Services, Applications
Physical Infrastructure
Virtualized Infrastructure
Middleware
The Logical Solution View emphasizes a business or industry specific perspective.
The Middleware organizes technical MW components
that provide a set of enabling capabilities as services.
Characteristics of Reference Architectures
• Architectural templates with prescriptive
guidance
• Common representation, concepts,
terminology
• End2end functional and operational view
• Static and dynamic views
• Multiple levels of elaboration to support
multiple project phases
• Definition of specific products instantiation
• Conformance with architectural practices and
artifacts
• Architectural decisions and standards
Operational SOA9
© 2008 IBM Corporation
SOA architectural decision accelerator
Challenge: Hundreds of SOA implementation decisions are often done by “gut feel”
– identification – not systematical, decision making – driven by personal experience and preferences
Solution: Proactive, step-by-step method delivering best practices
– Governance with reusable, standardized decision identification, drivers, alternatives
– Navigation by role, phase, component, etc.
IBM Global Services architecture decision accelerator for SOA
- ~400 decisions captured
Architectural Decision Knowledge Wiki for Clients
– Web 2.0 tool & model for capturing decision available on alphaWorks with 20 sample decisions:http://www.alphaworks.ibm.com/tech/adkwik
– Can address any IT domain including SOA
10 Operational SOA
© 2008 IBM Corporation
Case Study: Telco client
– Client Situation• Challenges with workflow across
heterogeneous backend systems
– Project Domain• Order management
Sample Decisions─ Technical Executive Level
• Which process layer strategy?
• Which ESB?
─ Conceptual Level• Workflow pattern? Security concepts?
• Synchronous or asynchronous message exchange?
─ Technology Level• BPEL or other BPM/workflow language?
• SOAP or RESTful service invocation?
─ Vendor Asset Level• Single WebSphere Process Server and ESB or high
availability topology (cluster)?
– IBM Solution• SOA-based business process integration and integrity management
– Benefits of using SOAD• Faster project execution, esp. in solution outline phase • Less risk through reuse of proven recommendations
Sample Recommendations
Explicit process layer with executable workflows ensuring e2e data integrity
BPEL as a standardized WS-* workflow language
Pseudo-synchronous messages for guaranteed message delivery
SOAP to meet interoperability requirements
SOA architectural decision accelerator Faster time to value and less risk through proven recommendations
Operational SOA11
© 2008 IBM Corporation12
Business Process orchestrationMessage based communicationLoosely coupled application services
Flexible combination of servicesRapid provisioningVirtualisationHighly utilised shared resources
Business Logic Shared
Services
Business Logic Shared
Services
PooledComputeResources
PooledStorageResources
End-to-end Monitoring
ESB & Common Service Platform
Service Oriented Architecture
SOA Infrastructure
DemandSecure, Robust environments to support rapid deployments & access of services
On demand Server, Storage, Network, Security, Monitoring, Connectivity & Accounting Services
Supply
SOA Projects deal with Transformation of Functional Architecture And the Operational Architecture
Operational SOA
© 2008 IBM CorporationOperational SOA13
Content
1. Integration of Development and Operations
2. Practitioner point of view
3. Architecture with a vision
4. SOA management
5. Exemplary project approach
6. More best practices
© 2008 IBM Corporation14
From Silos … … to Services
SOA Represents a Marked Change in IT Prioritization And Requires a New Way of Thinking
IT delivers services designed to meet business goals
IT maintains IT resources that support the business
New ThinkingOld Thinking
Operational SOA
© 2008 IBM Corporation
SOA increases the need for a mature infrastructure
• A risk gap can arise if the
adoption of SOA is not
supported by underlying
infrastructure capabilities.
• Predicting, assessing, planning,
architecting, designing, health
checking the infrastructure in
order to keep in synch with the
business requirements.
Operational SOA15
© 2008 IBM Corporation16
IT Service Management is about people, processes, information and technology
You need well-trained people armed with the right information to execute well-defined, technology-enabled processes to deliver high-quality services to the business functions they support
People
Roles, teams and functions
Skill requirements
Job descriptions
Performance indicators
Process
Technology and information requirements
Policies and governance
Process design
Detailed workflows
Workflow implementation
Procedures
Information
Information requirements
Data model
Information flows
Interfaces and integration
Measurements
Reports
Technology
ITSM architecture
Tool requirements
Tool evaluation and selection
Tool installation
Staffing levels
Resource acquisition
Training curriculum
Staff training
Development environments
Customization and integration
Testing
Deployment
Operational SOA
© 2008 IBM Corporation20-Oct-0817
SOAManagement
How does SOA impact infrastructure & management?
Increased Business flexibility
Increased IT flexibility
- Loose coupling design of business processes
- Reusable business services & components
Controlled SOA operating environment
- SOA governance
- IT governance & organization
- IT services & processes
Service Contracts
Securitymanagement
Availability & continuitymanagement
Capacity & performancemanagement
Service Levelmanagement
Testmanagement
Releasemanagement
Event, Incident, Problemmanagement
Change & configurationmanagement
Financialmanagement
Business Servicemanagement
Non Functional Requirements
MeasurementDashboards
Consumer satisfaction
Control
Introduced through SOA
New managed elements
Potentially many services
Regular changes / reconfigurations
Composite apps spanning org boundaries
Decoupled infra & app
Shared / Virtualized infrastructure
influences
Operational SOA
detailed in next charts
© 2008 IBM Corporation
BLA: Business Level Agreementagreed quality of service, measured and reported in the context of business results
(e.g. revenue generation)
BSLA: Business Service Level Agreementagreed quality of service, measured and reported in the context of business processes
(e.g. date/time for payroll completion, business hours lost, value of invoices in process queue)
SLA: Service Level Agreementagreed quality of service, measured and reported against criteria of technical infrastructure and applications, aligned with client requirements via Service Level Management
(e.g. UNIX availability 99.998%)
Com
po
ne
nt
IT
Business Operations
Business Transformation
BLA
Process Operations
Process Mgmt /
BSLA
IT Operations
Systems Mgmt / Re-engineering
SLA
Business Operations
Business Transformation
BLA
Process Operations
Process Mgmt /Reengineering
BSLA
IT Operations
Systems Mgmt / Re-engineering
SLA
In the context of service level management, we see that service levels are being matured from traditional technical SLAs
based on IBM Academy Study into Business Level Agreements, 2004
E2
E
Business
Man
ag
em
en
t G
ran
ula
rity
Management Focus
Many clients are here…
Operational SOA18
© 2008 IBM Corporation
Aligning IT with business priorities well, requires a deep understanding, and continuous management, of the dependencies between IT business services and the underlying IT systems and resources.
BUSINESS PROCESS
BUSINESS SERVICE
LINE OF BUSINESS
IT MANAGEMENT SERVICE
IT SYSTEM
IT RESOURCE
Managed according to IT SLAs and KPIs
Managed according to E2E
Business LAs IT BUSINESS SERVICE
Application Request
ENTERPRISE
Tracked against E2E IT SLAs and KPIs
LOB Dependency Tree
SERVICE PROVIDERS
Business of IT Dependency Tree
SERVICES INTEGRATOR
service catalogue
Operational SOA19
Implement platform
define integrated IT /app view
define service contracts
© 2008 IBM Corporation
From Service Level Agreement to Business Service Level Agreement
Applications
Servers
Network Devices
Manual(User Initiated)
Monitors
Monitors
Monitors
Monitors
Correlation
ServiceImpact
BusinessImpact
Notification
Notification
KQIs
KQIs
KPIs
Collection
Indication
Indication
Dashboards
Service Quality Data
KQI calculation and correlation
BIM
BSLM
Data aggregation andKPI computation
SLA Violations
Impact analysisMonitoring Visualization
BQM
BusinessService & contract Repository
Operational SOA20
© 2008 IBM CorporationOperational SOA21
Content
1. Integration of Development and Operations
2. Practitioner point of view
3. Architecture with a vision
4. SOA management
5. Exemplary project approach
6. More best practices
© 2008 IBM Corporation22
Strategyand Planning Design Implementation Run
SOA Governance and Project Management
Test + Launch
InfrastructureDesign
InfrastructureRollout
Security, Orchestration,Virtualization
IT Monitoring
Service ManagementConfiguration
SOA Strategy
Process Modeling
Service Assembly
Business MonitoringService DevelopmentService Design
InfrastructureRoadmap
InfrastructureServices
BusinessServices
ProcessServices
Application &MiddlewareServices
FrameworkStandards and Project
Plan Definition
Service ManagementDesign
Non-functional requirements, SLAs +
OLAs, Capacity Planning
Resourcesfor Monitoring, Performance +
Test Plan Definition
Best Practices suggest a project approach with functional and operational activities running in parallel
Operational SOA
© 2008 IBM Corporation23
Step 3: Integration of Results
Strategic Roadmap for Service Management and SOA Infrastructure based on a Roadmap Model
Activities
Table XYZ (Page X of Y). Process Name Assessment Matrix.
Ad Hoc (1) Aware (2) Capable (3) Mature (4) Optimal (5)
Establishing the Process Foundation
Mission
Objectives
Organizational Clarity and Capability
Other
processes
Roles
Skills
Characteristics
Measurement
Satisfaction
Improvement
N
O
W
G
O
A
L
Carrying out the Process
Interfaces to Other Processes
Tool Considerations
Measuring and Controlling the Process
Ad Hoc Aware Capable Mature Optimal
Assessment Focus
Carrying Out the Configuration Management Process
Curr Goal
Establish Configuration Management Framework
Configuration Management process framework is not formally defined.
Configuration Management process framework is defined and some procedures exist.
Serious weaknesses corrected in process framework. Conforms to requirements. Configuration Management procedures are stated in the context of existing infrastructure.
Working on effectiveness and efficiency in the process framework. Process is competitive, adaptable. The Configuration Management Framework includes evaluation criteria, requirements, and is communicated to all process users.
Performs in a superior fashion to comparable benchmark processes. The framework has strong automated support and is aware of, and responsive to business objectives.
Identify Configuration
Items
No labeling/identification of Configuration Items (CI’s); only inventoried the first time installation configuration is performed.
Configurations manually captured for most major systems; connections not captured; ownership remains vague. CI identification details are inconsistent, and some redundancy occurs due to the lack of consensus on the level of granularity required.
Configuration captured for all CIs, but not maintained in real time. Some data must be manually entered. CI ownership only defined for major systems and networks. Attributes to be recorded are mostly defined; some naming conventions in place. Major connections recorded. Level of granularity recorded is in the medium range.
Configuration automatically captured for all CIs. Real time data only available for some of the components. Manually entered data reduced to minimum due to interfaces with supporting processes. Attributes to be recorded are defined and include ownership. Naming conventions are defined. All connections are captured. The CI level to be recorded is chosen to achieve a balance between information availability, the right level of control, versus the resources and effort needed to support it.
Integration of configuration data includes all components and connections in a central data store. Changes are captured real time and sent to the database automatically. Data is integrated with supporting processes (e.g., Change, Problem, Incident) to eliminate manual data gathering. Attributes to be recorded are dictated by solution design. The CI level chosen depends on the business and service requirements. CI documentation levels are reviewed on a regular basis.
Ad Hoc Aware Capable Mature Optimal
Assessment Focus
Carrying Out the Configuration Management Process
Curr Goal
Control Configuration
Items
No control over configuration data.
Limited control over configuration data; new/updated CI items are recorded on an ad-hoc basis. Users are responsible for maintaining configuration data related to their workstations.
Some procedural control in place. CI records are added / updated for major components only. Some license management procedures. Major changes lead to CI updates. For major components only, CIs and their associated records get updated when CIs are deleted / decommissioned. Users are responsible for some data relative to their workstations that cannot be gathered automatically.
Procedures are in place protect the integrity of the enterprise’s data, systems and processes. Procedural and technical controls ensure that unauthorized change is virtually impossible. Commands available to support personnel to validate configurations in real time mode.
Configuration information control is automated for all components; e.g. the CMDB is automatically updated after periodic checking for the existence of physical items against the CMDB to ensure accurate information is available.
Report Configuration
Status
Manually created configuration data for some of the major systems is available. Reports are minimal. Needs are not analyzed.
Hard copy documentation available for the major components, and some of the connections. Status reports created, but require a great deal of staff time to produce.
Configuration data available online in multiple locations and formats to suit the needs of several types of users. Status and trend reporting is partially automated, and is distributed mainly to IT staff.
Common configuration database is implemented with integrated data to support most types of users and supported processes. Data is available in text format and formats necessary to drive generation of software tables or systems. Status and trend reports created automatically, and reviewed with end users and responsible IT staff.
Automated access and update of common configuration database queries. Data is available in whatever format is required to support various types of users. Exception status reporting when configuration attachment rules are broken. Reports reviewed with users and IT. Exceptions are noted relative to service agreements. Actions defined on breached service levels.
Ad Hoc Aware Capable Mature Optimal
Assessment Focus
Interfaces to Other Processes
Curr Goal
Asset Management
No linkage between these processes.
Major components are recorded, but tracked independently from one another in both Configuration Management and in Asset Management.
Major configuration resources are reflected in an inventory database from Asset Management.
Most of components are integrated within an enterprise-wide asset database.
Data from Configuration Management and Asset Management are integrated to ensure data integrity and standardization. Includes license/usage management audits
Availability Management
Availability Management process unaware of any configuration requirements or changes.
Some information provided to and from Availability Management, especially about problematic CI’s.
Configuration Management information available for major components to support availability objectives.
Configuration management allows Availability Management process to identify most components for performing risk analysis and component failure impact analysis.
Full access and tool integration of Availability Management and Configuration Management.
Capacity Management
Capacity Management function is not aware of the actual configuration status.
Capacity and Configuration Management information shared on an informal basis.
Capacity and Configuration Management information integrated to support performance objectives.
Capacity and Configuration Management information integrated to support performance and capacity planning objectives.
Full access and tool integration of Capacity and Configuration Management functions.
Change Management
No linkage between these processes.
Coordination of configuration changes for resources under centralized control.
Coordination of configuration changes for centralized and departmental changes.
Coordination of configuration changes for most resources, including distributed system resources.
Full integration of Change and Configuration Management with respect to the build and update process steps of Configuration Management.
Incident Management
No linkage between these processes.
Informal notification of configuration problems to Incident Management.
Incidents with major components and connections create incident records.
Configuration incidents, including connections, automatically opened in Incident Management.
Configuration incidents, including connections and unauthorized configurations items, are automatically captured in Incident Management; monitored, diagnosed and communicated.
Ad Hoc Aware Capable Mature Optimal
Assessment Focus
Organizational Clarity and Capability
Curr Goal
Direction & Control Roles
No known owner. Multiple owners identified. Do not understand ownership role, unsure of authority. Overlap and uneven coverage of CI information. If one owner is identified, no significant improvement actions have occurred.
Single owner identified, feels responsible for the area.
Single owner identified, some improvements made, others planned for the future. Seen as focal point by all relating to the process.
Owner identified and actively promotes continuous improvement of the process, known throughout organization as focal point of all issues relating to the process.
Execution Roles
No roles or responsibilities defined.
Roles and responsibilities have been discussed, but not agreed to by all parties. Vague tie between actual roles, and mission and role descriptions. Role description may not be available. Few meaningful measurements.
Roles and responsibilities have been agreed to, but are not fully documented, nor are authorities established. Responsibilities generally tie to the mission and role descriptions. General qualitative measurements.
Roles and responsibilities have been agreed to and documented, authorities understood, but not kept current. Role descriptions provide the right blend of direction and flexibility. Specific qualitative measurements.
Roles and responsibilities have been agreed to and documented, authorities understood, kept current, and all feel empowered to fulfill responsibilities. Cross reporting boundaries (matrix) role descriptions are used effectively to ensure an optimal tie between mission and people’s tasks and accomplishments. Specific quantitative measurements.
Skills & Desired
Behaviors
Few Configuration Management skills in the organization.
Wide variety of skills; but few actions taken to assess needs. Primarily product -based skills.
Skills needs are known and inventory regularly assessed. Few education plans in place to improve skill levels. Primarily product and system-oriented skills. Do not have skills for all types of technologies.
Requirements have been analyzed, and education planned to fill the gaps. Primarily product, system, and modeling skills.
Skills sufficient and augmented by automation to allow effective Configuration Management and support of other processes. Current and future skill assessment and requirements regularly identified, gaps analyzed, and education planned to meet needs. Product system, modeling, project and design skills.
Ad Hoc Aware Capable Mature Optimal
Assessment Focus
Establishing the Process Foundation Curr Goal
Define the Mission
The Configuration Management mission has not been discussed or documented. Not all involved personnel understand the mission.
General awareness of the mission, but it is not fully understood or endorsed by all. Some feel it relates simply to “having an up-to-date inventory of the installed systems and networks”, or “managing the lifecycle of an asset”.
Mission defined and understood by most.
It reflects focus on IT priorities. It includes the need to have a complete, accurate database of resources and connections to support the other service management processes.
Mission defined and understood by all. It has been created with user input and reflects a customer perspective. It includes the need for on-going planning, modeling, and effective use of the latest technology in creating and maintaining the Configuration Management Database (CMDB). It is consistent with rest of IT and enterprise mission and objectives.
Mission defined and understood by all. It has been created together with the users and reflects a business focus. It includes the need to use all available resources in an efficient manner, and the need to support all business objectives. The mission defines who the customers are, what the process will and will not do, and defines key standards related to the mission. It is consistent with IT and enterprise mission and objectives.
Establish Objectives
No agreement or understanding of the objectives. No awareness and no perspective on the need for Configuration Management. No plans or strategy in place; no immediate-ate intention of defining them.
General awareness of the objectives, but they are not fully understood or endorsed. Not documented. Not all are measurable. Configuration Management is performed on an ad-hoc basis. Little planning or strategy in place; some procedures defined.
Objectives defined and understood by most. They are documented, but not all are measurable. They reflect a function focus and the need for accurate configuration of current resources. There is a yearly Con-figuration Management plan in place; it has a limited scope. Configuration requirements are designed to capture basic operational system status and connections. The plan also accounts for some tools to support the process. Retention and archiving periods are not defined for all components.
Objectives defined and understood by all. Consistent with IT objectives. All are measurable. They reflect usage of automation, ability to recognize changes to configurations, and reduction of redundancy of configuration data across the enterprise. The Configuration Management plan covers the next three to six months in detail, including strategy, scope, key success factors, process, policies, procedures, roles and responsibilities. Configuration requirements are designed to support multiple processes, including Change and Problem Management. CMDB and other tools are in plan to sup-port Configuration Management. Retention and archiving periods defined for most components.
Objectives defined and understood by all. Consistent with IT and enterprise mission and objectives. All are measurable. They include aspects relating to contribution to the business, such as reducing IT administration costs. Close relationships with the many processes supported by configuration data are included in the objectives. The Configuration Management plan covers the next six to twelve months in detail, including strategy, scope, process, policies, procedures, roles and responsibilities. It is regularly reviewed. Configuration requirements are designed to support the needs of the business and are integrated with the overall asset management process requirements. Clear relationships with other service management processes are defined and supported by appropriate tools. Retention and archiving period defined for all components, and in line with business needs/ regulatory requirements.
Silo
Level 1
Services
Level 4
Composite
Services
Level 5
Virtualized
Services
Level 6 Level 7
Dynamically
Re-Configurable
ServicesComponentized
Level 3
Integrated
Level 2
Modules Services
Process
Integration via
Services
Dynamic
Application
Assembly
ComponentsObjectsApplicationsApplications
Structured
Analysis &
Design
Service
Oriented
Modeling
Service
Oriented
Modeling
Grammar
Oriented
Modeling
Component
Based
Development
Object
Oriented
ModelingMethodsMethods
Ad hoc IT
Governance
Emerging SOA
Governance
SOA and IT
Governance
Alignment
SOA and IT
Governance
Alignment
Ad hoc IT
Governance
Ad hoc IT
GovernanceOrganization
SOA and IT
Governance
Alignment
Ad hoc IT
Governance
Emerging SOA
Governance
SOA and IT
Governance
Alignment
SOA and IT
Governance
Alignment
Ad hoc IT
Governance
Ad hoc IT
GovernanceOrganizationOrganization
SOA and IT
Governance
Alignment
Service
Oriented
Modeling
Process
Integration via
Services
Platform
Specific
Platform
Specific
Platform
Neutral
Dynamic
Sense &
Respond
Platform
Specific
Platform
SpecificInfrastructure
Monolithic
Architecture
Emerging
SOA
Grid Enabled
SOA
Dynamically Re-
Configurable
Architecture
Component
Architecture
Layered
ArchitectureArchitecture SOA
Platform
Specific
Platform
Specific
Platform
Specific
Platform
Neutral
Dynamic
Sense &
Respond
Platform
Specific
Platform
SpecificInfrastructureInfrastructure
Monolithic
Architecture
Emerging
SOA
Grid Enabled
SOA
Dynamically Re-
Configurable
Architecture
Component
Architecture
Layered
ArchitectureArchitecture SOAMonolithic
Architecture
Emerging
SOA
Grid Enabled
SOA
Dynamically Re-
Configurable
Architecture
Component
Architecture
Layered
ArchitectureArchitectureArchitecture SOA
Platform
Specific
Function
Oriented
Service
Oriented
Service
Oriented
Service
Oriented
Function
Oriented
Function
OrientedBusiness
View
Service
Oriented
Function
Oriented
Service
Oriented
Service
Oriented
Service
Oriented
Function
Oriented
Function
OrientedBusiness
View
Business
View
Service
Oriented
Step 1: Positioning and Capability Assessment
Usage of an IT Service Management Adoption and Maturity Model to define and position the required operational processes for a SOA environment
High Level Capability Assessment of those processes
Identification of optimization areas and prioritization of processes
Step 2: Detailed Assessment of Prioritized Processes
Detailed Maturity Analysis (incl. tools, roles, interfaces) based on Process Maturity Matrices
An assessment approach for Service Management for SOA
Operational SOA
© 2008 IBM CorporationOperational SOA24
Content
1. Integration of Development and Operations
2. Practitioner point of view
3. Architecture with a vision
4. SOA management
5. Exemplary project approach
6. More best practices
© 2008 IBM Corporation25
Other Service Management considerations for SOA
IT Governance for SOA• e.g. Who decides, who pays, what should be measured
Security management• e.g. Choose policy-based over programmatic approaches
High availability• e.g. E2e availability measured and monitored o a ncomponent, business service, process level
Release management• e.g. Manage component changes of a composite appliction as a single release
Event, incident, and problem management• e.g. Establish operational and business-focused perspecitives
Change and configuration management• e.g. CMDB updated as close to real time as possible, scan before change is closed
Financial management• e.g. To allow usage based pricing, include service consumption requests in charging mechanism
Test management• e.g. Test during steady state to check performance and availability
Capacity and performance managememt• e.g. Efficient resource allocation mechanisms for ensuring performance of shared infrastructure
(virtualization, clustering, provisioning)
Operational SOA
© 2008 IBM Corporation2626
SOA Management Whitepaper
135 pages book on challenges and recommendations to control an SOA operating environment
Describes an IBM practitioner view on SOA management
Based on real project delivery experiences
Content– IT processes and IT organization
– Key managed resources and management tools
– IT governance for SOA
– Security management
– Capacity and performance management
– Service level and business service management
– Change and configuration management
– Availability and continuity management
– Event, incident and problem management
– Financial management
– Release management
– SOA test management
Just released at:
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=SA&subtype=WH&appname=GTSI_MS_MS_USEN&htmlfid=MSW03003USEN
Operational SOA
© 2008 IBM Corporation27
There are tools and techniques available to help to analyze also already existing SOA Infrastructures for potential issues
Benefits
Recommend prioritized actions for healthy SOA infrastructure
Improve IT position as an enabler to drive the business benefits of SOA adoption
Highlight opportunities to optimize the cost of SOA service delivery while maintaining service levels
Improve infrastructure architecture and design
SOA PARA-medic tool
Engagement model
Non-intrusive IBM asset (patent pending)
Technologies independent (web server, web application server, enterprise service bus, portal, ...)
HW and SW vendor products agnostic
Infrastructure HealthcheckWorkshopfor SOA
Operational SOA