Stefan Pappe Making S O A Operational

© 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


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


Content




4. SOA management




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


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


Content




4. SOA management




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


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

http://www.alphaworks.ibm.com/tech/adkwik


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


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


Content




4. SOA management




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


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


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


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


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


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


Content




4. SOA management




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


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.


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.


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


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


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.


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.


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

http://w3.ncs.ibm.com/cspres.nsf/ad03cadb91a05a8f85256b1b005ae64c/8525688c004f938985256f70004c9680?OpenDocument


Content




4. SOA management




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


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


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