Creation of a strategy for the consumption and management of Cloud Services in the TOGAF Preliminary Phase

In a previous article I described the need to define a strategy as an additional step in the TOGAF 9 Preliminary Phase. This article describes in more details what could be the content of such a document, what are the governance activities related to the Consumption and Management of Cloud Services.

Before deciding to switch over to Cloud Computing, companies should first fully understand the concepts and implications of an internal IT investment or buying this as a service. There are different approaches which may have to be considered from an enterprise level when Cloud computing is considered: Public Cloud vs Private Clouds vs Hybrid Clouds. Despite the fact that many people already know what the differences are, below some summary of the various models

· A public Cloud is one in which the consumer of Cloud services and the provider of cloud services exist in separate enterprises. The ownership of the assets used to deliver cloud services remains with the provider

· A private Cloud is one in which both the consumer of Cloud services and the provider of those services exist within the same enterprise. The ownership of the Cloud assets resides within the same enterprise providing and consuming cloud services. It is really a description of a highly virtualized, on-premise data center that is behaving as if it were that of a public cloud provider

· A hybrid Cloud combines multiple elements of public and private cloud, including any combination of providers and consumers

Once the major Business stakeholders understand the concepts, some initial decisions may have to be documented and included in that document. The same may also apply to the various Cloud Computing categorisations such as diagrammed below:

The categories the enterprise may be interested in related to existing problems can already be included as a section in that document.

Quality Management

There is need of a system for evaluating performance, whether in the delivery of Cloud services or the quality of products provided to consumers, or customers. This may include:

· A test planning and a test asset management from Business requirements to defects

· A Project governance and release decisions based on some standards such as Prince 2/PMI and ITIL

· A Data quality control (all data uploaded to a Cloud computing service provider must ensure it fits the requirements of the provider). This should be detailed and provided by the provider

· Detailed and documented Business Processes as defined in ISO 9001:

o Systematically defining the activities necessary to obtain a desired result

o Establishing clear responsibility and accountability for managing key activities

o Analyzing and measuring of the capability of key activities

o Identifying the interfaces of key activities within and between the functions of the organization

o Focusing on the factors such as resources, methods, and materials that will improve key activities of the organization

o Evaluating risks, consequences and impacts of activities on customers, suppliers and other interested parties

Security Management

This would address and document specific topics such as:

· Eliminating the need to constantly reconfigure static security infrastructure for a dynamic computing environment

· Define how services are able to securely connect and reliably communicate with internal IT services and other public services

· Penetration security checks

· How a Security Management/System Management/Network Management teams monitor that security and the availability

Semantic Management

The amount of unstructured electronic information in enterprise environments is growing rapidly. Business people have to collaboratively realise the reconciliation of their heterogeneous metadata and consequently the application of the derived business semantic patterns to establish alignment between the underlying data structures. The way this will be handled may also be included.

IT Service Management (ITIL)

IT Service Management or IT Operations teams will have to address many new challenges due to the Cloud. This will need to be addressed for some specific processes such as:

· Incident Management

o The Cloud provider must ensure that all outages or exceptions to normal operations are resolved as quickly as possible while capturing all of the details for the actions that were taken and are communicated to the customer.

· Change Management

o Strict change management practices must be adhered to and all changes implemented during approved maintenance windows must be tracked, monitored, and validated.

· Configuration Management (Service Asset and...)

o Companies who have a CMDB must provide this to the Cloud providers with detailed descriptions of the relationships between configuration items (CI)

o CI relationships empowers change and incident managers need to determine that a modification to one service may impact several other related services and the components of those services

o This provides more visibility into the Cloud environment, allowing consumers and providers to make more informed decisions not only when preparing for a change but also when diagnosing incidents and problems

· Problem Management

o The Cloud provider needs to identify the root cause analysis in case or problems

· Service Level Management

o Service Level Agreements (or Underpinning contracts) must be transparent and accessible to the end users. The business representatives should be negotiating these agreements. They will need to effectively negotiate commercial, technical, and legal terms. It will be important to establish these concrete, measurable Service Level Agreements (SLAs) without these and an effective means for verifying compliance, the damage from poor service levels will only be exacerbated

· Vendors Management

o Relationship between a vendor and their customers changes

o Contractual arrangements

· Capacity Management and Availability Management

o Reporting on performance

Other activities must be documented such as:

Monitoring

· Monitoring will be a very important activity and should be described in the Strategy document. The assets and infrastructure that make up the Cloud service is not within the enterprise. They are owned by the Cloud providers, which will most likely have a focus on maximizing their revenue, not necessarily optimizing the performance and availability of the enterprise’s services. Establishing sound monitoring practices for the cloud services from the outset will bring significant benefits in the long term. Outsourcing delivery of service does not necessarily imply that we can outsource the monitoring of that service. Besides, today very few cloud providers are offering any form of service level monitoring to their customers. Quite often, they are providing the Cloud service but not proving that they are providing that service.

· The resource usage and consumption must be monitored and managed in order to support strategic decision making

· Whenever possible, the Cloud providers should furnish the relevant tools for management and reporting and take away the onerous tasks of patch management, version upgrades, high availability, disaster recovery and the like. This obviously will impact IT Service Continuity for the enterprise.

· Service Measurement, Service Reporting and Service Improvement processes must be considered.

Consumption and costs

· Service usage (when and how) to determine the intrinsic value that the service is providing to the Business, and IT can also use this information to compute the Return On Investment for their Cloud computing initiatives and related services. This would be related to the process IT Financial Management.

Risk Management

The TOGAF 9 risk management method should be considered to address the various risks associated such as:

· Ownership, Cost, Scope, Provider relationship, Complexity, Contractual, Client acceptance, etc

· Other risks should also be considered such as : Usability, Security (obviously...) and Interoperability

Asset Management and License Management

When various cloud approaches are considered (services on-premise via the Cloud), hardware and software license management to be defined to ensure companies can meet their governance and contractual requirements

Transactions

Ensuring the safety of confidential data is a mission critical aspect of the business. Cloud computing gives them concerns over the lack of control that they will have over company data, and does not enable them to monitor the processes used to organize the information.

Being able to manage the transactions in the Cloud is vital and Business transaction safety should be considered (recording, tracking, alerts, electronic signatures, etc...).

There may be other aspects which should be integrated in this Strategy document that may vary according to the level of maturity of the enterprise or existing best practices in use.

When considering Cloud computing, the Preliminary phase will include in the definition of the Architecture Governance Framework most of the touch points with other processes as described above. At completion, touch-points and impacts should be clearly understood and agreed by all relevant stakeholders.

Aligning ITIL V3 Service Design with TOGAF 9

ITIL V3 is structured in 5 modules, one of them being The Service Design book. This book refers to technology-related activities (requirements engineering; data/information management and application management). It also covers some of the practicalities: functional roles analysis; activity analysis; roles/responsibilities; and even service design and management tools. Service Design processes are important because they provide organizations with information that will affect their decisions on designing solutions for new or changed services-

Service Design has five aspects:

• Design of the service solutions
• Design of the Service Portfolio (and other supporting systems)
• Design of the technology architectures and management systems
• Design of the processes
• Design of the measurement systems, methods and metrics
  

Section 3.6.3 on page 35, provides a specific context for the terms “architecture” and “system” which is well aligned with ISO/IEC 42010:2007 definition used by TOGAF 9.

”Architecture” is defined as:

“The fundamental organization of a system, embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.”

”System ” in this definition is used in the most general, not necessarily IT, sense:

“A collection of components organized to accomplish a specific function or set of functions.“

”architectural design” as :

“The development and maintenance of IT policies, strategies, architectures, designs, documents, plans and processes for the deployment and subsequent operation and improvement of appropriate IT services and solutions throughout an organization.”

In ITIL V3, IT policies and strategies are defined by senior management during the Service Strategy phase of the service lifecycle. These policies may be also be reused during the Preliminary Phase of TOGAF 9. The Preliminary Phase allows us to establish the business context, customize TOGAF, define architecture principles, and establish the governance structure. Architectural Principles are general rules and guidelines that support the way in which an organization sets about fulfilling its mission. These principles should be the source for the creation of IT policies.

Service Architects and Designers will need to consider several resources such as (budgets, infrastructures, applications, information, and people) and capabilities (management, organization, processes, knowledge, and people) of the organization defined by TOGAF 9. This will have to be coordinated with the business requirements which may have been collected from a Business Scenario (TOGAF). Using inputs from the business and Service Strategy in ITIL V3, the design needs to take into consideration, people, processes, products, and partners. Also designers will have to take into consideration, the vision, mission, goals, and objectives in order to translate them into critical success factors, key performance indicators, metrics and measurements.

Documents in ITIL V3 may be considered as being artifacts in TOGAF 9. Artifacts consist of plans, contracts (Architecture contracts or other forms of contracts), job descriptions, organizational structures, process workflows, procedures, instructions, configuration, diagrams, catalogs, lists, and databases among many other document types.

One of the major difficulties for the designer will be to sort through this documentation and remove that which is obsolete, duplicated, incomplete, or erroneous. TOGAF with its Architecture repository may also help to store documents related to IT Service Management. You may also think of combining a CMDB with an Architecture Repository…but that would be another topic to discuss.

Although plans should be considered as documents, it is important to identify and sift through the myriads of plans that are in use in the organization. Plans may be produced by different lines of business including IT, issued by business planning committees, PMO, etc. Some of the difficulties will include gathering them (business plans, IT plans, operational plans, contingency plans, financial plans.etc.) , making sense of them and more importantly, making sure they are aligned. For these reasons, the TOGAF Migration Planning phase helps to coordinate different business areas and create a common plan.

The term architecture within ITIL V3 may be aligned with the 4 architecture domains from TOGAF:

• Business Architecture: for Business, organization and enterprise
• Data Architecture: for data and information, databases
• Application Architecture: for applications
• Technology Architecture: for hardware (desktops, mobile devices, servers, and mainframes), network, telephony and software
  

Some aspects may not be covered by architecture domains such the Environment (heat, ventilation, AC, etc.), or the physical workspace including safety (this would be covered by Security Architecture considered during the ADM phases).

Services would be a combination of the four domains.

The Service Design activities and processes covers:

• Service Level Management
• Availability Management
• IT Service Continuity Management
• Supplier Management
• Information Security Management
• Capacity Management
• Service Catalogue Management
  

These processes can be designed when building the Technology Architecture with the Technical Reference Model (TRM).

Page 37 of the Service Design book refers to many documented practices available for designing, deploying, and operating service architecture. It lists Enterprise Architecture frameworks, one of them being TOGAF!

Do not miss Enterprise Architecture Governance!

Many people are considering Enterprise Architecture as a way to align IT to Business not only through the use of formalized processes. When looking at the various components of enterprise Architecture such as baselines, all kind of principles, modelling, target architectures, views, impact analysis among other of things….governance often appears as something maybe secondary. To be successful, Enterprise Architecture governance should be at the core of any program.

To build baselines, gap analyses, target architectures without a proper EA framework may end in a dead end. All new business initiatives should be validates against the current Enterprise Architecture, all exceptions have to be monitored, documented, and probably escalated. All changes on existing services, applications or infrastructure have also to be compliant with the existing Enterprise Architecture. This could be at any level, Technology Architecture (or infrastructure), Application Architecture etc..

When starting to think about your Enterprise Architecture initiative, there are two very important considerations that needs to be considered:

-How do we implement governance in the Enterprise Architecture and what are the associated processes
-How do we ensure adherence and a real collaboration in the processes

Furthermore, it is important to identify the differences between IT Governance and Enterprise Architecture Governance. Standards such as ITIL, COBIT or CMMi focus on IT Governance but none of them really refer to this EA Governance.

Governance lies at the heart of the Enterprise Architecture processes. It should be a framework that there is a logical consistency underlying the enterprise architecture structure. This structure in its broadest context means that we understand all the relationships between artifacts which are formalised.

Looking at the various EA frameworks it appears that these processes are never really clearly identified and documented.

I have identified 6 of them. Obviously each company will have to design them in a way which fits the company’s structure:

Enterprise Architecture Governance - PPM

This process identifies how any new demand or business initiative is routed to an Enterprise Architecture team for a first level assessment and impact analysis. The process also integrates at a high level Project Management and ensure that deliverables are still aligned with the initial architecture definitions.

Enterprise Architecture Compliance

All changes to business processes, information, technology, application and solutions are subject to architecture compliance. This step ensures that all changes are compliant with the existing Enterprise Architecture. If not compliant, request for exceptions go through review. In the case of an exception, the Architecture review board may issue a waiver to approve the exception. Alternatively, it may deny the exception.

Enterprise Architecture Waiver

In the event that a project sponsor's petition for an exception to the Enterprise Architecture is denied by the Architecture review board, the project sponsor may opt to appeal that decision to the Executive board, which has the authority to overrule the Architecture review board.

Enterprise Architecture - Standard Management

New company’s Standards should be the result of an investigation. Once a study or a proof of concept is finalized and presented, the latest may become a standard.

Other situations may occur when an existing standard is upgraded or there is a need for harmonization and consolidation. In both cases, standards have to be documented according to existing templates, be validated and approved by the Architecture review board, and finally approved by the IT Management team (eventually the CIO).

Enterprise Architecture – Standard Waiver

In case of exception, a waiver exception form has to be completed and be approved by the Architecture review board and the IT Management team.

Enterprise Architecture Requirements

Architecture often deals with drivers and constraints, many of which are beyond the control of the enterprise (changing market conditions, new legislation, etc.).
Architecture requirements are therefore invariably subject to change in practice. This process collects, identifies, stores and feeds requirements.

Enterprise Architecture Annual Revision or Changes

The architecture team is responsible for creating Enterprise Architectzre and revising it as an example, each year as recommended in many frameworks. Industry analysts and subject matter experts should be involved as needed in the process.

The Enterprise Architecture is updated at least on an annual basis to:

1 Incorporate amendments that were previously approved
2 Incorporate new technical standards, patterns and services, information, solutions, and business processes
3 Evolve the future-state road maps to reflect changes in business strategy

The structured architecture creation/revision process is defined by the architecture team in place and approved by the Architecture review board.

At the completion of the annual revision cycle, the updated Enterprise Architecture is submitted to the Architecture review board for approval and adoption.

Enterprise Architecture and ITSM Changes

There is a need to determine if a change (RFC) has to go through architecture compliance. If, in the opinion of the architecture team, the project has a low architectural risk, they may conditionally exempt the project from the architecture compliance process. This should be a step in the Change Management process.

There may exist additional processes…every company can extend its Enterprise Architecture governance the way which is appropriate.

That governance is put in place not just for ensuring compliance but also for ensuring enterprise wide collaboration.

Enterprise Architecture governance must ensure that decision makers across all disciplines in the company apply the same design patterns and are aligned to common design objectives.

Service Level Management and SOA. more confusion?

Service Level management in an ITSM context

Everyone into ITSM may use the Service Level Management process to maintain and improve IT Service quality through a constant cycle of agreeing, monitoring and reporting to meet the customer’s business objectives.

Service Level Management is the name given to the processes of planning, coordinating, drafting, agreeing, monitoring and reporting on SLAs, and on the on-going review of service achievements to ensure that the required and cost-justifiable service quality is maintained and gradually improved.

One of the activities related to that process, is the creation of a Service Catalogue which was subject to another post: “Service Catalog, what do you exactly mean?” where I tried to distinguish the different types of catalogues when we refer to either an ITSM or an SOA environment.

Most of the time companies which have implemented a service desk have a SLM module which allows defining different kinds of level agreements:

• Service Level Agreement (SLA): Which are written agreement between an IT service provider and the IT customer. SLAs are normally used for internal customers
  
• Operational Level Agreement (OLA): Which are agreement between two internal IT areas/departments e.g. Network Management and Operations
  
• Underpinning contract: Which are contract between an external supplier providing services to an IT department
  

Many vendors have dedicated modules which manage the SLM lifecycle with requirements collections, monitoring, escalation, and various dashboards. These modules are obviously linked to other ITIL processes and information is kept in the CMDB. Among various solutions we have different SLM modules from HP-Mercury, HP-Peregrine ServiceCenter, CA Unicenter Service Assure, BMC Service Level Management, Assyst for Service Level management, Expertdesk.

These solutions allow managing the end to end SLM process in an efficient manner through an ITSM view and sometimes the content is routed to a Business Service Management solution or specific modules managing SLAs in dedicated dashboards such as Tivoli Service Level Advisor among other system management solutions.

Service Level management in a SOA context

In a previous post I was referring to one of the intersection between ITSM and SOA. “Amberpoint proposes a module to manage web services, their performance and availability. It can monitor failures, send alerts, display useful information related to problematic web services, automate performance and so on.

HP Mercury Systinet 2 has a module title Contract/Consumer Management which promotes trust between consumers and providers by facilitating service-level agreements and other terms and conditions that bind these two key stakeholders.

Progress Actional Looking Glass provides dashboard and reports which define, sort and prioritize by business or IT metrics (customer, transaction or service type). SLAs are also monitored, managed, measured and alerts are generated. We can also easily monitor and report on SLA's for a specific customer or class of customer such as gold, silver, etc.

For some consistency we should differentiates SLAs in an ITSM framework from SLAs in a SOA. For these reasons a good thing would be to create a new acronym: WSLA for Web Service Level Agreement!!

A WSLA could either be attached to a specific service or to a composite service. WSLAs should then be linked to SLAs. An end user does not have to know what the underlying architecture of his applications is. The Service Level Manager (if such a position exists…) has to negotiate with the customer SLAs. If an IT service is based on various technologies including SOA, he should take into considerations OLAs, Underpinning contracts and WSLAs!!!

WSLAs could also be attached to Underpinning Contracts is web services are either 2rd party services or hosted externally.

Most of the SLM activities remain the same however some of them may differ:

The Service Level Requirement activity will have to be taken into consideration the definition of the WSLAs. It will not be necessary to specify to the customer the underlying technology.

The building of the Web Service Catalogue is different from the Service Catalogue and probably the responsibility should be shared between the SLM manager and the SOA experts.

The SLAs creation and review taking into consideration OLAs and UCs should also consider WSLAs. If possible a hierarchy should be built.

Monitoring should be done at two levels:

• At the SOA level (eventually in SOA center of excellence or an operation dedicated team


• At the ITSM Level (the Service Manager should have a global view on all IT services)

Coming back to Service Level Management and solutions available in the Service Desk arena, companies should be able to only deliver one and only one SLA per service and monitor it. IT and business dashboards should aggregate all underlying categories of SLAs. In other words SOA Governance vendors should be able to provides APIs to upload data related to WSLAs into any IT Service Desk/System Management solution covering the SLM process.

ITIL 2007

Le forum pour tous les DSI et les responsables d'ITIL

22 - 23 mai 2007, Hotel Concorde LAFAYETTE, Paris

Les relations entre IT Service Management et Service Oriented Architecture (SOA)

• Les liens entre IT Service Management et SOA
• La relation de certains processus ITIL avec SOA. Ou sont les intersections ?
• La gouvernance SOA, ses composantes, le cycle de vie des services
• Un exemple, comment le processus de Release Management s’intègre dans une gouvernance SOA
• Les outils qui peuvent supporter les processus, l’architecture et la gouvernance

The relationship between IT Service Management and SOA

INFOTECH for Pharma & Biotech

12 - 15 March 2007 Novotel London West, UK

15.05 The relationship between IT Service Management and SOA

Is IT Service Management an emerging subset of SOA? There is a high level of correlation between success at SOA and commitment to ITIL. ITIL is a standardized approach and series of documents that are used to aid the implementation of a framework for IT Service Management. This customizable framework defines how ITSM is applied within an organization, covering processes such as service desk management, incident management, problem management, configuration management, change management, and release management among others.

Service oriented architecture is an architecture that allows to loosely couple capabilities that can be described as reusable services to support a business process. Processes such as availability management, change management or release management “are just business processes that are particular to IT”. We now use this service-oriented architecture to link the business processes associated with IT, with the technology components that make up the IT infrastructure to an integrated platform that includes a configuration management database, an enterprise service bus, and a process orchestration layer. So we can think of IT service management as another use case or usage scenario for SOA. This session will cover xxxxxx's roadmap and reflections in these two domains.

Business Processes and Services are not always correctly associated

For a few months, discussion around processes and services has been a hot topic in my company. Everybody has his own interpretation and very few information exist related to the subject.

This post is the follow up to a previous article I wrote a while ago:

What is a Service?

It is important to specify that sometimes when people talk, the term Service has to be considered either as an ITSM Service or an SOA Service-web service. This is clear to me that BPM and SOA should be tightly integrated, but let’s look at this slightly differently…

A Business Process has activities. An activity could be one to many Services.

But you can also look at this in another way...

A Service is one to many Business Processes. A Business Process has activities, and as already said, an activity is one to many Services. Isn’t this confusing?

What I try to say is that we need to be clear (at least for me...) when we talk of a Service. Are we talking of Service in Service Management terms, or in SOA Terms?

As an example:

The Service "e-mail" has several Business Processes such has:

Creation of email, classification, forwarding, etc...
Calendar Management, invitation for meetings, reminders, etc..
etc..

If for example we define the Calandar Management process and look at activities, maybe at some stage we would define a Service which lookup for availability of people in a meeting. This would be an SOA Service "Availability of people"...

To summarize and be clear, I would claim that ITSM Services could count one to many Business Processes, and Business Processes could one to many SOA Services. “E-mail” is an ITSM Service and “creation of an email” being a transaction is an SOA Service.

Does this make sense?

Service Catalog, what do you exactly mean?

These days everybody is referring to a Service Catalog whatever that means. Unfortunately there is some misunderstanding between people as sometimes they are referring to SOA and sometimes to IT Service Management.

An ITSM Service Catalog describes all services that are offered by a service provider. In some cases, all services offered by the IT department of a company. The Service Catalog is part of the entire Service Level Management process. The Service Catalog describes the standard services offered, based on which agreements are made with clients. These agreements are subsequently covered in Service Level Agreements. It also becomes the basis for documenting procedures and processes in an IT organization.

Depending on the purpose the organization hopes to achieve, the service catalog may be rich in detail or simply provide a top level explanation of services. An IT department manages, maintains and supports part of the IT infrastructure of the Organization. This infrastructure consists of a large quantity of products with which services can be provided.

These services are described in the Service Catalog.

To first identify services, we have to work from the perspective of the core business purposes. Then, look at what IT offerings support those services. After the core purposes, we have to move into those supporting areas that IT also serves, such as administrative or general organizational support. The entire Service Catalog should be viewed from the customer’s perspective. Some services can be further broken down into sub services as well.

For every service a clear description and all relevant characteristics are included. Based on this a client can assess the business application and the usefulness of a service for their own organization.

After looking at services from the business perspective, we start to define each service with the following information:

-Service Name (a simple description, preferably the same name the customer would use)
-Service Description (high-level description of the service written in language customers can understand)
-Support Contact Point (Where should the customer begin an inquiry or report problems regarding the service?)
-Responsible Manager (Contact person responsible for the service)
-Customers/Users (What set of customers (specific or general) utilizes this service?)
-Detailed Specifications (Some items may not require all of these elements, but possible elements to include in specifications are):

• Inputs (hardware, software, infrastructure, customer inputs, etc.)
• Outputs (final products viewed from a customer perspective)
• Default items always included
• Optional items the customer may request or pay extra for
• Excluded items which are never included
• Service hours of availability
• Up-time and service availability goals
• Support provided
• Performance standards for the service
• Customer procedures for starting, changing or ending the service
• Charges (if appropriate)
• Disaster/recovery
• Data Integrity
• Security
• Training
• Etc.

A Service Catalog is intended for all clients of an IT department, in other words, the business unit managers and/or their representatives that want to be extensively informed about the services offered by the IT department of his company.

An SOA Service Catalog has another goal: to manage, organise and reuse services. One of the key promises of SOA is reuse on a much more granular level than one could ever hope to achieve with pure object oriented techniques, but reuse isn't something that we get for free. Particularly, reuse problems arise when others within a teamdepartmententerprise don't realise that we have already defined and/or built a particular service that they could reuse.

To achieve in some way that objective, a SOA Service Catalog needs to exist and document the basis of each service. To build such a Service Catalog is not an easy task as you will need to first define the granularity of your services (please refer to my previous post: What is a Service?) which decribes the differences between an SOA Service and an ITSM Service).

As for an ITSM Service Catalog, information has also to be identified and captured:

• Service name
• Description
• Type of service (e.g. business, application specific, data, etc)
• Service level agreements and other quality of service characteristics (e.g. performance, scalability, security, availability, etc)
• For each service operation
• Operation name
• Description
• Request/response messages input/output parameters and possible errors
• Pre-conditions
• Post-conditions
• Whether the operation is idempotent

SOA Service catalogs leverage both Web services (application services (provided by reusable software components) that are typically found further down around the middle of the IT stack) and BPM to eliminate an expensive burden on business. To be effective, that service catalog must contain services in the language of the customer, must be transactional and finally flexible.

For sure both Catalogs relate one to the other but what is contained inside is quite different. The SOA Service Catalog should be considered as a Service Registry. The future will tell us how to link both catalogs once synergies between ITSM and SOA will be better documented and companies will have reach an upper level of maturity in these two domains.

Is IT Service Management an emerging component of Enterprise Architecture?

There is a high level of correlation between success at Enterprise Architecture and commitment to ITIL. ITIL is a standardized approach and series of documents that are used to aid the implementation of a framework for IT Service Management. This customizable framework defines how ITSM is applied within an organization, covering processes such as service desk management, incident management, problem management, configuration management, change management, and release management among others.

Enterprise architecture consists of the vision, principles, standards and processes that guide the purchase, design and deployment of technology within an enterprise. It describes the interrelationships between business processes, information, applications and underlying infrastructure for that enterprise. Processes such as availability management, change management or release management are just business processes that are particular to IT. So we can think of IT service management as another use case or usage scenario for Enterprise Architecture.

Many frameworks such as FEAF, DODAF, Zachman and TOGAF among others do not yet consider the relationship to Service Management. Any component of architecture has to change, solves a problem, or relates to a set of software and infrastructure. Business Architecture is all about documenting, changing, viewing specific business processe and makes them more efficient. Business Architecture also allows to understand the business impacts of new products introductions or modifications. Products should be delivered as services and be manages by Service Level agreements.

New products also have to consider its availability and its capacity to perform, based on user requirements.

This demonstrates that running an Enterprise Architecture program, has a lot to do with Service Management! Service Management also has a lot to learm from Enterprise Architecture… As an example, the definition of EA Technical Services can help to build departmental IT Service Catalogues related to Customers Service Catalogues.

Enterprise Architecture and Service Management

Enterprise Architecture Practitioners Conference Lisbon
Lisbon, Portugal October 23-25 , 2006

STREAM #2:Enterprise Architecture Development Tuesday October 24

16:00 – 16:45 Enterprise Architecture and Service Management Serge Thorn, Director IT Research & Innovation (Switzerland)

Synopsis:

Is IT Service Management an emerging component of Enterprise Architecture? There is a high level of correlation between success at Enterprise Architecture and commitment to ITIL. ITIL is a standardized approach and series of documents that are used to aid the implementation of a framework for IT Service Management. This customizable framework defines how ITSM is applied within an organization, covering processes such as service desk management, incident management, problem management, configuration management, change management, and release management among others. Enterprise architecture consists of the vision, principles, standards and processes that guide the purchase, design and deployment of technology within an enterprise. It describes the interrelationships between business processes, information, applications and underlying infrastructure for that enterprise. Processes such as availability management, change management or release management are just business processes that are particular to IT. So we can think of IT service management as another use case or usage scenario for Enterprise Architecture. This session will cover (xxx) roadmap and reflections in these two domains.

Will Service Management solutions become SOA Governance platforms?

As a starting point, let’s re-define what a Configuration Management Database (CMDB) is… A CMDB is a database that holds a complete record of all configuration items (CIs) associated with the IT Infrastructure, software, hardware, including information about servers, storage devices, networks, middleware, applications and data, i.e. versions, location, documentation, components and the relationships between them.

Configuration Management which is one of the main ITIL processes requires the use of support tools, which include a CMDB. Physical and electronic libraries should be set up parallel to the CMDB to hold definitive copies of software and documentation.

Until now, several vendors have provided through their Service Desk offering, and out of the box CMDB which in some case could be altered. Among these vendors we can find, BMC-Remedy, HP, Peregrine (now HP…), Axios systems, Computer Associates, Mercury (now HP…), IBM, and many others.

Last April, some vendors like CA, BMC, IBM, and Fujitsu announced they would work toward developing "an industry standard for federating and accessing IT information" that would ideally integrate communication between disparate configuration management databases.

CMDBs have become one of central elements of enterprise IT management, so a standards-based approach to this critical functionality is necessary and valuable.

Looking at SOA and the way we define composite applications and services, we definitely need to build the latest on the top of existing IT Infrastructure, software and hardware. In other words, a CMDB could also be used to manage the catalogue of SOA Services!

I would be tempted to think that in the next 2 years, a CMDB will be a modular component, usable by either Service Management solutions, and/or SOA Governance products. A CMDB could become a sort of “plugin” available from various vendors with sets of APIs, and why not web services.

SOAs are distributed computing plans where companies often situate Web services and reuse code and other assets to create efficiencies. Vendors like IBM, Microsoft, BEA, Oracle, and Mercury are creating SOA infrastructure platforms to speed information exchange between different computing machines. A few months ago, prior to HP acquisition, Mercury acquired a SOA company named Systinet. This acquisition strengthened Mercury's position in the high growth SOA (Service-Oriented Architecture) market by giving the company leading SOA governance and lifecycle management products.

An integration point should be between the SOA metadata repositories and a configuration management database (CMDB) to manage the lifecycle through to operations. If HP considers the range of acquisition they recently did with Peregrine, Mercury...and Systinet…there would be a high probability, this integration occurs!

Another observation on this future integration is potentially visible with IBM. IBM released recently a CMDB titled Tivoli CCMDB, and also launched a management and security solutions for managing SOA based applications, IBM launched last April IT Service Management platform.

The IBM IT Service Management platform manages SOA based composite applications. It is supposed to offer an approach to defining a framework and solutions for IT service management, including extending self-managing autonomic computing to IT services.

“Tivoli CCMDB uses a Federated model that allows it to be implemented on top of an existing sources of IT data, and serves as an authoritative source of data for configuration items, their relationships, so that when a change needs to be made to any of the IT components, one can understand the impact of that change on other related components. IBM's ITSM platform along with, IBM Tivoli security and compliance products like Tivoli Access Manager and Tivoli Federated Identity Manager delivers a complete end-to-end solution for the "manage", "secure" and "compliance" of distributed SOA applications.”

IBM and HP are two companies which will probably compete in both IT Service Management and SOA. They probably understood the synergy between the two worlds, and we can predict a future new generation of CMDBs, modular, accessible from web services, and used for several companies needs: Service Management and SOA Governance.