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”?

Configuration Management: Are there any Auto discovery tool companies left?

Eighteen months ago, the market counted something like a dozen of companies which were selling interesting products named “Auto discovery or mapping tools” (refer to my other post: Configuration Management: How to really build a CMDB with an auto discovery tool). Among them, there were, Appilog, Collation, Relicore, n-layers, Tideway Systems, Cendura.

Since that time, important software companies have considered these tools as probably being highly strategic because they would help to materialize Configuration Management , one of the most complex ITIL process.

IBM, Symantec, Mercury among others have acquired some of these companies, and the remaining ones would soon be considered for acquisition. That was my impression… end of last year.

Today Computer Associates has acquired Cendura, a small company (50 people) located in the Silicon Valley which also provide a nice Auto Discovery funtion with lots of granularity (the level of drilldown is quite impressive). This demonstrates clearly that without such functionality, Configuration Management was an unreachable ITIL process and irrealistic to be correctly implemented.

BPMs and SOA

A very interesting article has been published by Celia Wolf and Paul Harmon in BPTrends on the 26th of September. The content is related to the BPMs Market and the Majors.

I have found the following paragraph a little bit exaggerated…

"Probably the major development, over the course of the summer, is subtler. All of the software/infrastructure vendors are continuing to put a lot of marketing cycles into promoting Service Oriented Architecture (SOA). At the same time, there has been a growing recognition that SOA, without BPM, doesn't mean much. You don't do SOA just as an exercise in technology; you do SOA to provide better support for business processes, which you define in BPM. This is the clear message in all IBM's WebSphere advertising and it is increasingly the common theme of all of the major vendors who are promoting the move to SOA. Thus, increasingly, the attention that was focused on BPM is becoming mixed with the SOA marketing effort."

Even if SOA can be (or should be...) coupled to BPM initiatives, there are many situations where companies implement SOA for other reasons:

- Composite applications
- Portal integration
- Information Hub
- Migration from “old” client server applications to new architecture models
- Mash-up applications
- B2B

In fact, software vendors simply try to sell at the same time BPMs with the underlying technology...and all the associated professional services…

There are cases where SOA is justified only by the above mentioned reasons.

Configuration Management: How to really build a CMDB with an auto discovery tool

Service management projects that use a Configuration Management Database (CMDB) as central pointer to enterprise IT asset data should double in number over the next year; an independent research has concluded (Tertio Service Management Solutions). Configuration Management Database uptake is expected to double from 20% to 39% within a year, said the vendor behind the research. The reason for the increased popularity is down to a desire to adopt an ITIL based framework among 44% of respondents.

According to ITIL best practice recommendations, the CMDB should provide accurate information on the configuration of IT assets and their documentation in a way that will support all the other service management processes. For 70% of the organizations polled online during Tertio's research, the perceived benefits that results from implementation of a CMDB is expected to be an improved and coordinated picture of the application infrastructure, and the overall better management of IT assets.

Many companies who deployed Configuration Management have associated this process to the Asset/Inventory Management process/systems for the following reasons:

- Desktop Inventory is often based on inventory existing solutions
- Server Inventory is usually done with System Management solutions such as Tivoli, CA Unicenter, BMC Patrol, etc…

However, there is one activity missing from a Configuration Management view: the building of relationships based on Cis (configuration Items).

To be successful at Business Service Management, companies first should map applications and Services. This is probably the only way to know which IT failure is mucking up Business Services.

To address the issues with the Configuration Management process, companies should find a solution which would avoid creating manually the relationships between the various CIs (Configuration Items) which are identified with the various Inventory tools.

Companies need tools that collect systems configuration data, decode packets and watch kernel I/O to determine application dependencies. These are not service, performance or status monitors rather, they map all the servers, systems, applications, processes, services, users and sometimes even network devices to decipher what applications depend on, and what depends on them. This mapping also makes diagnostic, capacity and Service Management application delivery easier.

These tools should be able to:

- Improve the quality of data in a CMDB
- Be in real-time
- Populate data into the Service Desk
- Avoid to maintain manually the systems
- Keep in real time the relationship between CIs
- Improve all ITIL processes, but specifically Incident Management and Change Management
- Provide Change Impact Analysis features
- Track people changing the infrastructure into production
- Deliver Business Services views
- Map ITIL processes
- Integrate smoothly with both the Service Desk and the System Management solution
- Replicate these relationships into Business Service Management solutions
- Send alerts to the System Management console when for example a change on the Infrastructure is done in production
- Replicate these relationships with Enterprise Architecture platforms such as Mega, Troux technologies, Casewise, Popkin, etc..
- Provide out of the box connectors
- Cope with the long term strategy around Service Management and Enterprise Architecture


There used to be more that 10 to 15 vendors in that space, half of them have been acquired by companies such as Mercury, IBM, Symantec, BMC and others who integrated these tools into their Service Management products.

Companies haven’t yet considered implementing such solutions but this is slowly starting. Auto discovery tools are a must!

EGEE'06 Capitalising on e-infrastructures

The EGEE’06 conference is the major event of the EGEE project where Grid user communities, decision makers, resource providers and developers will discuss how to capitalise on past investments and plan a sustainable future for the Grid. The EGEE’06 conference will be the focus point of a large number of grid projects featuring prominently in both plenary and parallel sessions during the 5 days of this event. Welcome to the key European grid event of 2006!


QA standards overview and (company) implementation choices and benefits

The first part of the presentation will introduce QA standards such as :

- Service Management (ITIL, ISO/IEC 20000-1/-2:2005)
- CMMi
- Quality Management ISO 9001,
- Security Management ISO 2700

The second part will present (company) implementation choices and benefits

Id: 109
Place: CICG CICG,
17 rue de Varembé,
CH - 1211 Geneva 20
Switzerland
Room: Conf. Room 7+8
Starting date: 27-Sep-2006 11:00
Duration: 45'
Primary Authors: Mr. THORN, Serge (Director IT Research & Innovation)