Release Management should be utilized in a SOA environment

Release Management is one of the Service Support ITIL processes that allows planning and overseeing the successful rollout of software and related hardware. Deploying Release Management will encourage IT Management to designin and implement efficient procedures for the distribution and installation of changes to IT systems, and will ensure that hardware and software being changed is traceable, secure and that only correct, authorized and tested versions are installed. IT Operations groups that are implementing ITIL Release Management in a SOA context should collaborate with Application Development leaders to extend those processes for new kinds of distributed applications and services.

IT Service Management and SOA Governance concepts

Application Development teams building SOA solutions either internally or externally or mixing both approaches must consider the ITIL Release Management process to rollout any software and hardware components.

ITIL is a set of Best Practice recommendations for IT Service Management. ITIL consists of a series of publications giving guidance on the provision of Quality IT Services, and on the Processes and facilities needed to support them. These services which are used by the user/customer can take the form of applications that they use (e.g. email services, components of HR systems, ERP and financial systems) or other services which are utilized, such as internet access, printing services, etc.

A SOA Service is defined as a unit of work to be performed on behalf of some computing entity, such as a human user or another program. SOA defines how two computing entities, such as programs, interact in such a way as to enable one entity to perform a unit of work on behalf of another entity.

The SOA Service is much more granular that an IT Service and the latest can be the aggregation of several SOA Services. For these reasons, more and more IT Service Management and SOA will relate to each other and be part of an SOA Governance framework which should really be considered as part of a broader IT Governance strategy.

SOA is introducing many independent and self-contained moving parts, components that are typically widely reused across the enterprise and are a vital part of mission-critical business processes; it becomes critical to properly manage the life cycle. SOA governance usually includes:

• Lifecycle management. This involves the definition, the implementation and the enforcement of policies and processes across the entire SOA lifecycle.


• Policy management. This process is used for a successful web services deployment ensuring that services, XML messages and transactions comply with local and global security and operational policies. This woulde include access-control list management, identity management authentication and authorization policies.


• Contract management. This activity consits of managing the relationships between service consumers and providers. Policies, capabilities and Service Level Agreements (SLA) are negotiated. Service Level Management is an ITIL Service Delivery process can be used.


• SOA metadata management. More and more data services are created based on various information sources, metadata centric visibility tying data services to their associated information sources participating in Data Integration techniques is critical. SOA Metadata management can be based on SOA Metadata repository and SOA Registry.

Activities within Release Management must also cover SOA solutions but have additional constraints

Release Management helps to communicate and manage expectations of the Customer during the planning and rollout of new Releases. It also allows agreeing the exact content and rollout plan for the Release, through liaison with the Change Management process. New software or hardware releases are then implemented into the operational environment using the controlling processes of Configuration Management and Change Management. Also, a Release should be under Change and Configuration Management and may consist of any combination of hardware, software, firmware and document Configuration Items.

Release Management activities in the development, control, test and live environments include:

• Release policy and planning. The Release Policy document covers Release numbering, frequency, the level in the IT infrastructure that will be controlled by definable Releases. The SOA policy defines configurable rules and conditions that affect services during design time and at runtime. The SOA policy is used to validate services at design-time, well before they're released to consumers, and is used to enforce specific standards and behaviors at runtime. The Release Policy has to include instructions such that deployed SOA solutions have to comply with the SOA Policy. Release Planning would also have to include applications running on SOA infrastructure.
  


• Release design, build and configuration. The Release design of a SOA application differs from a classical application as several web services can be aggregated for a composite application from in-house developments or from third party components. License, support a and Service level Agrements will have to be defined at the web service level and Application Development groups will have to negotiate at the component level with the different vendors. The Release Build will require additional efforts because of the highest granularity of software components and also because an impact analysis is required to identify what other applications could be affected. Configuration will require detailed procedures for installation from all web services providers.
  


• Release acceptance. This activity is responsible for testing a Release, and its implementation and Back-out Plans, to ensure they meet the agreed Business and IT Operations Requirements. Additional consideration has to be given to existing applications already using some component of the release. An impact analysis will conduct to a non-regression testing for other applications already using some components. A controlled test environment must be configured to replicate the current live version also taking into account external web services. Vendors should be able to contribute to the release and provide as well a test environenment.
  


• Rollout planning. First of all it is almost impossible to agree a rollout plan without consulting the customers; indeed they are an integral part of the planning. So to meet this goal companies will need to work closely with the customers to prepare a release or rollout plan that not only meets IT needs but also takes into account customer availability and their business deliverables. Once the plan is agreed, the IT department will need to provide constant feedback to the customers during the processing of the Release or rollout. Ideally the customers should be able to view the plan on-line any time and should receive regular reports from the plan team leader. SOA applications do not really impact this activity as customers are often not aware of the underlying architecture.
  


• Extensive testing to predefined acceptance criteria. Testing of a Build or Release to ensure that the parts including the web services work correctly together. SOA will require additional non-regression testing because of the potential share of components between old and new applications. Tests may have to include vendors’ components when used and will require dedicated tests vendors environments even if the web service is hosted somewhere else.
  


• Signoff of the Release for implementation.
  


• Communication, preparation and training.
  


• Distribution and installation. This will cover the installation of new or upgraded hardware and the distribution and installation of software. The ITIL Definitive Software Library (DSL) which is the storage of controlled software in both centralized and distributed systems will also contain the SOA hardware and software components. External components will have to be documented in a SOA registry-repository as they will be hosted externally.

SOA Repository and Registry

The ability to register, discover, and manage Web services is an essential requirement for any SOA implementation. This need may not be fully appreciated in the early stages of an SOA rollout when dealing with a small number of services but becomes almost mandatory when there is a need to support a large number of Web services. When the number of services deployed grows to dozens or hundreds, centralized facilities for access and control of service metadata and artifacts becomes critical. A service registry provides these capabilities and becomes a key infrastructural component. First generation service registries were based on the UDDI standard but new products have recently emerged from various vendors inspired by the standard.

SOA Repositories and registries should integrate with CMDBs (Figure 1).

Figure 1 Registry and Repository linked to a CMDB

Product choices and strategies

• Systinet is a mature solution but requires further integration in the HP IT Service Management suite. The roadmap for HP’s IT Service Management soultions identified Peregrine ServiceCenter has the evolution for the HP OpenView Service Desk. However as HP also acquired Mercury, the future of the HP CMDB will target Appilog (Now Mercury Application Mapping). In January 2006 Mercury extended its offering with Systinet which provides the foundation for SOA Governance and lifecycle management. Mercury ITG for the time being manages Change and Release Management, Peregrine ServiceCenter manages Change Management, and Systinet 2 manages SOA Changes. The Governance Interoperability framework (GIF) developed by multiple SOA vendors does not seem to cover the integration with a federated CMDB[i].
  
• IBM proposes its Websphere Service Registry and Repository V6 which integrates with the Tivoli CCMDB. This solution will communicate with Tivoli CCMDB which manages Changes and Configuration. The Tivoli CCMDB also integrates with IBM Tivoli Release Process Manager and Tivoli Configuration Manager which are other Release Management modules. The end to end solution will have to be validated.
  
• Flashline which joined in august 2006 the BEA Aqualogic product family is a new offering but BEA until now distributed Systinet. Flashline is now the BEA Aqualogic Enterprise Repository, has out of the box connectors source code management systems but does not have yet integration with ITSM suites.
  
• Webmethods acquired Infravio but seems more focused on new clients acquisition with an integration with Fabric. Its governance edition integrates with System Management suites such as IBM Tivoli, BMC Patrol, CA Unicenter but custom development would be required.
  
• Amberpoint is a Web services management product which completes a repository-registry. Amberpoint integrates into any IT environment and specifically system management suites, but does not consider yet ITSM (although it does deliver a module related to SLM).
  
  

Release Management is a pre-requisite to properly manage the service lifecycle

IT infrastructure and operations/engineering professionnals using IT Service Management and starting SOA programs should evaluate the maturity of their Release Management process or consider its implementation. The acquisition of a SOA Governance platform must take into consideration existing IT Service Management suites in order to have as a target an end to end view of the SOA components deployment. Without any integration, operations staffs will not be able to quickly track the end to end life cycle and carry out root cause analyse in an efficient way in case of problems.

• Review the process activities and ensure they take into consideration components based on SOA infrastructures. Release policy and planning will be adapted to SOA solutions implementations taking into consideration the use of potential external and distributed web services. Design and build of a Release will have to integrate more granular components which can be hosted externally and sold by vendors. Service Level Agreements will have to be defined not only at the IT Service level but also at the Web service level. Testing will have to cover non-regression for shared application components and situations were componets are hosted externally.
  
• Evaluate cautiously SOA Governance platfoms. SOA Management platforms, metadata repositories and registries should take into account not only Release and Change Management, but also Service Level Management from Service Management suites. Identify the vendor’s strategy in terms of either partnership with ITSM vendors, or internal roadmaps such as IBM and HP.
  
• Understand the level of integration required between products. A complete integration would be ideal but the existing solutions are not yet there. Some vendors have started to understand the need for integration between a SOA Registry and repository and a CMDB in a federated way, the repository-registry being considered as a specialized database in this federation. Some others are only provinding APIs to system management solutions.
  
• Ensure that Underpinning Contracts are covering Release Management for third party components. Companies building applications either composite or integrating in BPM activities third party web services should define in a SLA with the vendors how new external components versions should be managed in the Release Management process. Vendors should not be allowed to upgrade customers web services without any authorization if hosted externally. The contract should specify that any new component modification will be part of the customer’s IT Operations Releases covering testings.

What It means...

Convergence between the SOA registry, repository and the CMDB

The registry and repository of SOA has allowed convergence of the development time asset repository with the run-time service registry. We must now proceed into the management repository. As we frequently see another repository associated with that space called the Configuration Management Database, or CMDB. A convergence across this space is required in order to be able to correctly track the end to end life cycle of Web services as well as to maintain an up to date software and hardware information. Part of the metadata associated with a service needs to be the machines where it is deployed. The chances are that information may already be in the CMDB.


Non ITSM shops will integrate SOA Governance Platforms with adhoc deployment solutions

Companies which have not considered ITIL as an IT Operations framework can deploy a SOA Repository and Registry without fully considering the Release Management process. They will be able to manage the service lifecycle and if they have a software deployment product, they will use it for deployment. Reconciliaton between the various products will have to kept manually or integration development will be required. However IT Operations group haven’t yet endorsed IT Service Management and starting to embrace ITIL will gain substential benefits in terms of customer’s quality of service. Release Management among other processes such as Change and Service Level Management will definitly improve the quality of SOA solutions.

[i] Ten leading SOA vendors have partnered with Systinet for the GIF, including Above All Software, Actional, AmberPoint, Composite Software, DataPower, HP, Layer 7 Technologies, MetaMatrix, Reactivity, and Service Integrity.

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

Urbanisation des Systèmes d’Information & Architecture d’Entreprise 2007

Urbanisation des Systèmes d’Information & Architecture d’Entreprise 2007

Communiquer et Vendre son Projet d’Urbanisation comme un Investisssement de long terme & Estimer la Valeur et la Rentabilité de cet Investissement

Event Date: 26-27 March 2007

Location: A Five Star Venue To Be Announced Shortly, Paris, France

14:30 Mise en Oeuvre d'une Gouvernance Informatique, démarche, standards, processus et outils

• Vision de XXXXXX des composantes d'une Gouvernance IT (ex: ITIL, CMMi, TOGAF, Cobit, ISO)
• Les standards des domaines de Recherche et Innovation, Architecture d'Enterprise,
• Service Management ainsi que leurs relations
• Définition et démarche des processus clés de Gouvernance
• Choix d'outils pour le support des standards de Gouvernance IT
• Intégrer l'Architecture d'Enterprise comme composant clé de la Gouvernance
• Faire fonctionner le tout ensemble!

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.

Are there any relationship between Demand Management, Requirement Management, Request Management and Change Management?

In the context of IT, Demand Management is a process which manages the complex and strategic IT demand requests issued by the business. In this process we prioritize, consolidate, schedule the requests, enabling the business users and IT to collaborate efficiently at every step, cutting costs and accelerating resolution. Normally, this is an activity belonging to Portfolio Management which is the the process of determining (and monitoring) how much money the enterprise should spend on the various categories of IT-enabled business investments. Demand Management works with both business and its IT peers through an ongoing and iterative process that aggregates demand for IT services, represents the resources requested and their costs to the business, and helps optimize the deployment of IT resources over time. Demand Management is often covered by Portfolio Management solutions or Request Management solutions.

A few examples are Mercury ITG, Clarity (Niku) from CA, Compuware Changepoint and Borland Tempo.

These suites are more in the PPM market than anything else and these vendors should be considering to link PPM suites with IT Service Management suites for several reasons.

Requirements Management is the science and art of gathering and managing user, business, technical, functional requirements, and process requirements within a product development project. The project could be for a new consumer product, a web site, a system or a software application. In all these cases, the five classes of requirements should be represented.

Solutions such as RequisitePro from IBM and Telelogic Doors support that process.

Here we see in some way some identical concepts with Demand Management and potential links also with IT Servie Management.

But let’s still define two additional concepts.

ITIL doesn't have a separate process for Request Management as it does, for instance, with Incident Management in version 2. The Request Management will manage (from request to fulfillment) the goods and services requested by users based on the catalog provided. Standardized goods and services can be made available to the end users through self-service interface or by calling the Service Desk. When handling the request the Request Management will also refer to the SLA.. Version 3 should clarify the situation and define a new process, where Service Requests are now a function of Request Management which ties on the Change Management process (In version 2, Service Requests were a part of the 'Incident Mangement' life cycle).

The Change Management process ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to minimize the impact of change-related incidents and improve day-to-day operations. Changes are issued either from Incidents, Problems or customer’s requests. There are also touch points between Project Management and Change Management.

Finally and to keep it very simple, everything is about a user asking something to an IT department, with different levels of importance. From a new product to a new service, from a additional or new feature to a physical piece of hardware, allowing the business to be more efficient.

There should be a clear alignment of these concepts with an end to end process, integrating IT Service Management at the end. All demands should end up in the ITIL Change Management process and vendors should integrate their platforms to facilitate that integration.

IT Research and Innovation: Preparing the future

IT Research and Innovation provides a framework for an organization to achieve IT objectives through the systematic and sustainable applicatoin of innovative processes and methods. Innovation encompasses everything from product development to process improvement and employee engagement.

To run such initiative, it is important to define an IT Research and Innovation framework describing a flexible, structured process achievable within any organization. A framework helps to tap into human capital and creative potential of the IT department within the context of a focused approach of delivering business value to drive a variety of innovation-related activities: new service development, process improvement/development, new technologies and IT methodologies, the implementation of IT services and systems.

An IT Research & Innovatoin pipeline consists of a new approach to help the IT Department to put innovation into a wider context within the IT organization.

As research progresses, specific areas of an Innovation Pipeline is expanded with the goal of developing a coherernt and consistent framework aimed at achieving strategic IT objectives through the systemic and sustainable application of innovation through an IT department.

Various solutions supporting Innovation as a process do exist and can easily be implemented in any company. As an example: Brightidea.

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?

Innovation has to be the result of an Enterprise Architecture program

One of the steps of an Enterprise Architecture program is to look at Business Architecture. The Enterprise Architect or the Business Architect (sometimes a Business Analyst) starts to describe the current Baseline Architecture. This is usually done through MS Visio types of diagrams or with either the use of an Enterprise Architecture or a Business Process Analysis tool. The Business Architecture defines the organization value chains and how all its business processes fit together, are managed, monitored, measured, etc.

Then that team starts to develop a target Business Architecture describing the product and/or service strategy, and the organizational, functional, process, event, information, and geographic aspects of the business environment.

There must be then an analysis related to the gaps between the Baseline and the Target Business Architecture. As with the Baseline artifacts, the Target architecture information should be captured in with a phased approach with the organization Enterprise Architecture stakeholders and senior management. Once populated, the variance between the existing baseline, view and the transitional and future, target, views is used to identify the performance gaps in the Enterprise Architecture. The Performance Gap (also know as the transition strategy information to migrate the organization from its “As-Is” architecture to the organization “To-Be” architecture) information is then used to help identify what investments need to be supported for funding and implementation.

But during this Gap analysis phase, the Enterprise Architect plays a fundamental role in enabling business innovation, and facilitating the provision of a flexible and resilient infrastructure. His role will be to manage and incubate successful ideas through to implementation, as the Business is always looking at innovations in products, services, and business models to drive growth and profits.

A good Enterprise Architect also needs to be an innovator.

Innovation is critical, especially in today’s rapidly changing technology and business landscape. Having a n Enterprise Architecture that supports an IT Strategy and provides the flexibility to achieve the right balance between IT efficiency and business innovation is a keystone to business adaptability and growth.

"The CMDB Initiative..”, but where is the evolution?

Late April, a group of system and service management vendors decided to propose a standard related to a repository for IT assets, and their configurations items change over time.

In other words, BMC, Fujitsu, IBM and HP decided to create a model for a CMDB which would allow storing information such as desktop and laptop client images or configurations, servers, storage pools or networks and so on.

Very often information is spread among various sources and no standards exist on how to exchange meta data from all these potential sources of CMDB information. Today, the CMDB interfaces that exist are all proprietary, which is the problem that this group wants to tackle.
This working group will issue a white paper within the next month that will spell out their initial goals in more detail. And by the end of the year, they hope to have a draft specification proposal, at which point they hope to formalize the process by choosing a standards body.

But is that enough?

Focusing on data exchange is fine but shouldn’t they also consider the CMDB Meta data and propose a common model eventually re-usable by third parties?

All vendors’ CMDB have their own Meta model and as from now I have never seen from any vendor a roadmap related to the repository. As an example, with the acquisition of both Mercury and Peregrine, HP initially announced the migration from the HP Openview Service Desk, to Service Center, and now has announced that next CMDB would be the one from Mercury, which is in fact…Appilog… (An acquisition from Mercury). So what!

There is a need for a “next generation CMDB” for the following reasons:

- BPM based on a SOA architecture invoque IT components (software on hardware…) and we should have a link between a Business Process and the underlying Cis. A CMDB should also be process based.
- Relation is important that’s for sure but dependencies is another key topic. How does infratructure relates one to the other, how information relates one to the other, how physically components relates one to the other, how does application code relates (Cendura acquired by CA is maybe one of the only company which deleivred that capability) etc… A CMDB should be also able to add dependencies on the top of relationships.

This initiative will help the concept of federated CMDB and information exchange but will not really look at today’s requirements… A unified Meta model could be an interesting initiative for these vendors as this would create a new generation of unified Service management/Business Process management solutions.

IT Processes, Business Processes, who is coordinating what?

More and more IT departments refer to IT Governance, Best Practices, quality and processes. To run efficiently an IT shops, processes are supposed to help companies to excel. The disctinction between best practices and processes is not so clear but let’s assume that this is complimentary. Processes are either standardized; refer to existing frameworks such as ITIL, Six Sigma, eTOM and other best practices.

An IT Process is also a Business Process. It has only an “IT Flavour”.

Looking at the Business side, Business Process Reegineering (BPR) and now Business Process Management (BPM) are activities which also look at improving how a Business works. Some companies develop a target Business Architecture describing the product and/or service strategy, and the organizational, functional, process, event, information, and geographic aspects of the business environment.

Very often, based on my experience, and observations, IT processes do not have a process owner. If there are owners, sometimes they are siloed. As an example, the ITIL Incident Management process owner does not work in harmony with the ITIL Availability Management process owner, etc. Sometimes, politics, company’s mindset, or personnel agendas, prevent to do a consistent job.

On the Business side, it happens also that processes are siloed and not cross-functional. The integration between IT Processes and Business Processes is even not considered despite the fact that all Business Processes should be linked to IT Processes. The processes and activities of a Line of Business have Incidents, Problems, issues with availability etc…

The first step would be to have for the IT department a Service Manager (e.g. ITIL) to coordinate all the processes related to IT Service Management. On a parallel, the Business should also have owners for their processes.

Recently I was looking at some documentation related to the SAP ESA (Enterprise Service Oriented Architecture) and found a very interesting comment from Shai Agassi, member of the SAP Executive Board and president of the SAP Product and Technology Group (PTG). He claimed that “Chief Information Officer” function is morphing into two distinctive roles: the Chief Process Innovation Officer (CPIO), and the Chief IT Officer (CITO, to coin a new acronym). In this new model, the CPIO is in charge of innovative business processes and continuous process integration.”

All processes have definetly to be coordinated, IT or not in a consistent way. As improving processes allows to bring innovation, this new role (Chief Process Innovation Officer), would allow companies to create new synergies, between the Business and IT, considering the CPIO as a partner of LOBs, in charge of processes deisgns with the business’ network. That position would require new skills to be developed as part of the IT organization. Such a role would be the best way to create an harmony for IT/Business processes.

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.

Does an IT ERP make sense?

Despite the fact that some software vendors companies such as ITM Software are considered to deliver such a solution, I would rather qualify this product as a Project and Portfolio Management solution such as Primavera, Artemis, Mercury and others.

Many companies have a wide range of non integrated solutions covering several aspects of IT Governance such as:

-Project Management
-Portfolio Management
-Time Management
-Service Management
-Enterprise Architecture
-System Management
-Security Management
-Asset Management
etc..

For each of these components some of them have associated processes but no real touch points between them and the visibility is quite difficult to get in terms of IT Service quality. Some companies passed certifications such as ISO 9000, ISO 27001, went through COBIT, and are ITIL based etc... But from my various observations, they do not have a consolidated or integrated view of their IT Services which would contribute to the improvement of Business IT Alignment.

Very often, top management including the CIO ask for IT to deliver Dashboards where we can have in real time indicators (KPIs) on the department performance and then be able to benchmark against competition.

Among existing solutions we have, IT Governance suites such as Mercury ITG or CA Clarity, Service Management platforms such as Peregrine Service Desk, Remedy, CA, HP, Asset management solutions, and finally Time Management product. In the system management landscape, Tivoli, CA Unicenter, and lots of various monitor solutions to manage networks. Fiinally, Enterprise Architecure is often covered by companies such as Telelogic (Popkin), Casewise, Metis solutions etc…

My experience would be to claim that first we need to re-engineer the process, have integrated flows between domains in order ro be able deliver these dashboards, finally avoid duplicated activities within an IT Department.

As no vendors today is able to deliver such an “IT ERP” (but probably HP, IBM and CA will be able to deliver this but nor before a couple of years…), an alternative would be to consider services around these platforms and then from a portal, orchestrate those services, provide results in various dashboards. Obviously if we had an integrated platform, that would be easier.

For the time being, mash-up applications are probably the only way to produce an IT ERP.

Examining innovative Enterprise Architecture Methodologies, Getting SOA Experience and Enhancing Information System Agility to meet Organizat. Needs

MarcusEvans

Enterprise Architecture

Examining innovative Enterprise Architecture Methodologies, Getting SOA Experience and Enhancing Information System Agility to meet Organizational Needs

Event Date: 27-28 November 2006
Location: Dorint Sofitel Amsterdam Airport, Netherlands

09.55 Case Study

Presentation of Processes and Tools: Enterprise Architecture, Service Management and IT Governance Frameworks
• XXXXX's vision of the components: IT Governance frameworks
(e.g.ITIL, CMMi, TOGAF, Cobit, ISO)
• The standards for Research and Innovation, Enterprise Architecture,
Service Management and their relationships
• Defining the key governance processes and gaps
• Selecting the tools to support the frameworks
• Integrating Enterprise Architecture as a key governance enabler
• Making it all work together

Serge Thorn
Director IT Research & Innovation

Why do we not find yet links between Enterprise Architecture and Project Portfolio Management?

A Project Portfolio Management governance process should start when a business user requests or suggests a new capability. The request is automatically routed to a gatekeeper, then to a business analyst or team for an initial business case before being routed to the operations council and the architecture standards committee for review and scoring.

The business team then evaluates the prioritized, ranked projects to determine the proper portfolio mix and whether to accept the recent request.


Project Portfolio Management is:

• A categorization model
• A common language for business and IT to …
• Support Business strategy
• Organize investments
• Evaluate and prioritize IT projects
• Govern and manage applications portfolio
• Decide when and how to make changes (opportunities)
• Understand what can and can not be changed
• Provide real-time visibility into resources, budgets, costs, programs,
projects, and overall IT demand

• A hedge
• “What if” scenarios enable us to analyze
the portfolio and assess the business
contribution of each proposal, project,
or application to the entire portfolio

• Triggers, Thresholds

The Enterprise Architecture steering committee should be part of this governance process and be able to measure the impact at various level of the architecture:

- What is in the impact in terms of Business Procee
- What is the impact at the information level
- What is the impact at the application level
- And finally what is the impact on the technology

Assuming that a company has an Enterprise Architecture in place and an associated governance, the PPM process should be linked to the first one.

None of the existing solutions related to PPM have considered yet this type of integration. On one side we do have PPM tools such as Mercury ITG (now HP), CA Clarity Niku and on the other side EA platforms such as Mega, Casewise, and Telelogic (Doors can be considered as some sort of Demand/Requirement Management solution but can not be considered as a PPM) among others.

I’m still wondering why a company such as HP has not yet been considering an EA tool integrated with their future PPM product, or even IBM which has a PPM product with rationale but no EA solution neither.

There is a high change that the next wave of acquisition after Service Management and SOA platforms will be Enterprise Architecture tools as this would make sense to deliver a full IT ERP.

IT Service Capability Maturity Model

CMMI has been developed by the Carnegie Mellon University – Software Engineering Institute. It consists of best practices that address the development and maintenance of products and services covering the product life cycle from conception through delivery and maintenance.

CMMi provides a robust discipline to help developers achieve maturity in their software development processes. There are a number of factors that influence the maturity of the software development processes within an enterprise. These include the strategic plans of the enterprise, the enterprise’s own organization and culture, as well as the technologies that are adopted within the enterprise IT architecture.

A product can be an airplane, a digital camera, a drug or a software package available from a commercial retailer. It can also be a Service such as those defined into IT Service Management. CMMi integrates bodies of knowledge that are essential when developing products, but that have been addressed separately in the past, such as software engineering, systems engineering, and acquisition.

CMMi:
- Emphasizes the development of processes to improve product development and customer services in organizations.
- Provides a framework from which to organize and prioritize process improvement activities (product, business, people, technology)
- Supports the coordination of multi-disciplined activities that may be required to successfully build a product
- Emphasizes the alignment of process improvement efforts objectives with organizational business objectives

A CCMi model is not a process but describes the characteristics of effective processes. CCMI models could be used in conjunction with all IT processes found in Service Management (ITIL), COBIT, Project Management (SDLC/Prince 2), Enterprise Architecture (TOGAF), Quality (ISO 9000), Security Management (ISO 17799). CMMi allows companies to assess their practices and compare them to those of other companies. The CMMi measures process maturity, progresses through five levels: Level 1 (initial), 2 (managed), 3 (defined), 4 (predictable) and 5 (optimizing).

The CMM has been applied to several disciplines within different industries. It is not surprising that maturity models have also been applied to IT Service Management (ITSM).

Recently, the Vrije Universiteit Amsterdam and CIBIT, published a very interesting document “The IT Service CMM” which is free to download and use. This should help companies to evaluate their level of maturity for their ITIL processes, using the CMMi framework.

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.

Training-evening SMP (Société Suisse de Management de Projet)

1st nov. Lausanne : Training-evening SMP:

ITIL : A Service Management implementation and the evolution to an Operational Excellence
by Serge Thorn (XXXXXX and itSMF Chairman)

Details and registration

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.

Business Continuity and Business Architecture

Are there any potential relationships between these two domains? Maybe yes…

Very often Enterprise Architecture programs start with a bottom up approach as this is easier to justify. A bottom-up approach involves setting infrastructure standards and introducing governance processes to ensure adherence to those standards, while a top-down approach dictates a formal analysis of the current state with respect to business process, application programs, data, and technology components.

Top-down start with Business Architecture once the Business strategy and organization is well known, but how to be able to quickly justify some sort of return on investment when no real Business Process Management initiative is associated?

Disaster recovery efforts can be extremely costly, both in terms of technology replacement and business interruption. But giving users access to the exact same work information through another connectivity path is a big step toward business continuity.

Often a major factor in the decision to provide only limited recovery facilities is the cost of having “redundant” office space ready to use just in case of an incident. These limited recovery facillities are associated to limited IT Services because rarely all applications and systems have redundancy. Choices have to be made… but on what criterias? How do we manage existing Business Processes if these are no more automated?

Business Architecture can be an answer!

Business Architecture programs limit the depth of the program to business architecture, and are typically driven from the top-down, with corporate planning and strategy, or change management as the sponsor of the program. The architecture team is typically comprised of business process experts, and has a close relationship to their specific Lines of Business. Business Architecture teams in companies that are “process organizations” typically have the mandate to define business processes that span the company.

Associating Business Architecture to Business Continuity can therefore help to quickly justify a top-down approach as key processes needs to be documented for a disaster recovery effort.

CMDB and SOA registries convergence

Without doubt we will see a convergence between Service Desk CMDB’s and SOA Registries and repositories. SOA Governance solutions should cover several features such as (this is not exhaustive) :

- The governance itself (design, deployment, amd the run-time)
- Policies management
- The Service Life cycle Management
o Service Deployment
o Service management and monitoring
o Service publishing
o Service specification
o Service acquisition
o Service assembly
o Service testing
o Service design
o Service integration
o Service build and test
o Service asset management and publishing
- Contract Management
- Impact Management
- The Service Discovery and mediation
- Etc.

But we can foresee more an integration in terms of relationship that a full integrated solutions. In others terms the Service Life Cyle will require a Service to be managed in Service Management terms. A Web service will have incidents, be changed be released etc…

As en example, IBM just announced Websphere Service Registry and Repository. This solution will communicate with Tivoli CCMDB which will manage Changes and Configuration.

HP which acquired Mercury and Peregrine….also acquired Systinet, another SOA Governance solution. All the first 3 vendors have their CMDB, and once eventually integrated, wouldn’t this make sense to have connections between the Systinet Repository and “one of the HP CMDB”?