ITIL V3, Enterprise Architecture and Project Portfolio Management, where do I start?

Recently I have attended the ITIL V2 to V3 bridge course and took the examination. It is clear that one day is not enough and a day and a half would have been convenient. IIL V3 is supposed to be an evolution and not a revolution… Pretty sure that a day and a half would have frightened some IT decision makers… and the decision was from trainers to only offer that single day.

As I was prepared for the course (I did some reading before), this was not a real issue...

This being said, after a few days I was wondering how companies would present ITIL V3 to the IT Management team, to a CIO, and obviously the business! The introduction of the Service life cycle is a new concept which requires the buy-in and the sponsorship maybe beyond the IT department! Service Strategy has to be sold, and demonstrates a real value, but this not the point.

Let’s imagine you are in a mature IT department where IT Governance is your daily culture. You may have different IT Governance pillars and among them:

• IT Service Management


• Project Portfolio Management


• Enterprise Architecture

Usually, different teams take care of these initiatives and unfortunately they do not always work together.

The Project Portfolio Management team (PPM) collect business demands and requirements, classify, categorize them, and on an annual basis, do some sort of planning after a budgetary exercise with the business. The PPM team may collaborate with the Enterprise Architecture team to better understand the impact of new demands on the company’s architectures. They may also interact with the IT Service Management for Capacity Management and Service Level Management to better assess these demands.

The Enterprise Architecture (EA) team who already has documented a baseline architecture, define a target architecture (or transition architecture) based on the business drivers, business strategy and with a gap analysis, identify new opportunities, new projects. These new initiatives may afterwards be included in the list of projects and be processed by the PPM team.

With V3, the situation becomes more complex as we have a new way of starting projects! The view is based on the creation of new services which are then included in the Service pipeline and Service Portfolio. In the past, with V2, operational people only had a reactive position. With V3, Service Strategy considers the business view and proposes ITSM as a way to launch new projects!

Isn’t this confusing? Do you think that companies which already have implemented PPM and eventually EA would change the way they classify and launch new projects? Would you go to your CIO and tell him….”...now with V3… we should start with a Service Strategy and consider PPM and EA, either in parallel or afterwards”?. No way! Would you go to your business partners and claim that V3 is a new way of creating new projects and services? Maybe not…

Below I have tried in a diagram to describe various scenarios related to how companies may approach the three domains:

• The PPM view considers new projects with PPM has the core methodology to address business needs. It refers first to Enterprise Architecture and then IT Service Management.
  


• The EA view consider PPM first and finally ITSM.
  
  
• The ITSM view (in fact V3) consider first PPM (Service Strategy) and then EA (Service Design)

It is clear that none of these approaches can be considered as better than the other one. All frameworks include bits and pieces of the others. I may imagine that V3 will make the choice event more difficult and mature IT department will have to evaluate where Service Strategy and Design fits in their IT Governance framework…or consider V3 has being the more innovative and change the company’s culture.

Requirements Management and Enterprise Architecture

I was describing a while ago the relations between Requirements Management and other types of user’s demands.

Let me restate my definition of what that is. 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.

The objective of the Requirements Management activity is to define a process whereby requirements for Enterprise Architecture are identified, stored, and fed into and out of the relevant Enterprise Architecture development phases. As such it forms part of the activities and steps carried out in each of these phases though it is not referred to implicitly in any projects I have managed.

(Requirements Management is also a discipline for both Quality Management (ISO 90001:2000) and Project Management (PMI)).

Target architecture must be based on credible assumptions about future business requirements. Getting these future requirements is not a simple matter of asking business management for them, and analyzing them is not the linear technique used to develop the design for a project. Instead, we have to use a combination of requirements aggregation and scenarios to gather and analyze long-term requirements. This will lead to more credible architectures with appropriate flexibility and evident business value.
For ease of use, it is convenient to think of requirements as belonging to a type.

• Business and Functional requirements

They are the fundamental or essential subject matter of the service or product. They describe what the service or product has to do or what processing actions it is to take.

Business Cases or Scenarios should be used as a useful technique to discover and document these requirements.

Project and Portfolio Management (PPM) addresses the decisions regarding what projects to undertake, with what priority, and in what sequence. Before a project has gone through the necessary requirements definition activities, its scope is based on high-level requirements derived from business drivers, plans, and needs. If these requirements are viewed in isolation, then solutions will be defined in isolation, and they will ignore synergies or dependencies between projects and undervalue foundational projects that provide capabilities that can be leveraged across future projects. Business Requirements also have to be a source for Project Management methodologies.

• Non-functional requirements

They are the properties that the functions must have, such as performance and usability. These requirements are as important as the functional requirements for the product/service’s success.

• Project constraints

These are restrictions on projects due to the budget or the time available to build a product or service.

• Design and architecture requirements

They impose restrictions on how the product/service must be designed. For example, it might have to be implemented in the hand-held device being given to major customers, or it might have to use the existing servers and desktop computers, or any other hardware, software, or business practice.

• Project drivers

These are the business-related forces. For example, the purpose of the project is a project driver, as are all of the stakeholders-each for different reasons.

• Project issues

They define the conditions under which the project will be done. The reason for including them as part of the requirements is to present a coherent picture of all factors that contribute to the success or failure of the project and to illustrate how managers can use requirements as input when managing a project.

• Testing requirements

It is recommended to start testing requirements as soon as we start writing them.
We make a requirement testable by adding its fit criterion. This fit criterion measures the requirement, making it possible to determine whether a given solution fits the requirement. If a fit criterion cannot be found for a requirement, then the requirement is either ambiguous or poorly understood. All requirements can be measured, and all should carry a fit criterion.


Requirements Management and Enterprise Architecture cannot be dissociated.

Some vendors have perfectly understood the need of integrating this, such as Telelogic and the need to share a common metadata repository.

With that solution, there are possibilities to go from requirements, to enterprise architecture, to systems implementation and design, with tightly-coupled, bi-directional integration between DOORS (their requirements management tool), and Systems Architect.

IBM has it’s own requirements management solution but has (not yet) an enterprise architecture solution. This may change with the on-going acquisition of Telelogic, but I haven’t been really able to understand IBM’s strategy yet. Is this only a question of absorbing another market or a willingness to offer a full Enterprise Architecture suite in the Rational catalogue? (Requisitepro being obviously an issue….).

The HP approach seems to be the how to integrate the different application coming from the former Mercury and Peregrine world. HP PPM (and HP Quality Center for testing requirements). Their current approach is to use the Demand management module in PPM to manage business requirement at business level and using the module in Quality Center to specify the requirements at technical level to translate them in test case. Nevertheless, HP does not have any Enterprise Architecture solution.

Invitation to join the Enterprise Architecture Network Group on LinkedIn

I've just started a new LinkedIn Group dedicated to people in the Enterprise Architecture arena. I'm sending this invitation in the hopes that you would be interested to grow the community.

If you work in any of the following domains:

-Enterprise Architecture
-Business Architecture-Business Process Management
-Information/Data Architecture
-Application Architecture
-Technology Architecture
-Methodologies-frameworks :FEAF, DODAF, MODAF, TOGAF, Zachman, Gartner/Forrester (and obviously other frameworks or internal methods)
-IT Strategy
-Corporate and/or IT Governance

If you are:

-CIO/CTO
-An architect in any of the domains above either in the Business or in IT
-Consultants
-Other…

The goal of this group is to help members:

-Reaching other members of the Enterprise Architecture Network interested in any of the listed domains
-Sharing information, problems, solutions, ideas specific to Enterprise Architecture and the domains mentioned.
-Accelerate careers/business through referrals from the Enterprise Architecture Network Group members
-Know more than a name – view rich professional profiles from fellow the Enterprise Architecture Network Group members

This will be a starting point for those who wish to share ideas, network with other professionals, exchange advice. We may consider to use something like the Yahoo groups for interaction or anything else web enabled. Until then, this place should do.

Here’s the link to join:

http://www.linkedin.com/e/gis/36781/1FD7B029687F

I look forward to meeting you online! Many thanks.

Do not miss Enterprise Architecture Governance!

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

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

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

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

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

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

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

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

Enterprise Architecture Governance - PPM

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

Enterprise Architecture Compliance

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

Enterprise Architecture Waiver

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

Enterprise Architecture - Standard Management

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

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

Enterprise Architecture – Standard Waiver

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

Enterprise Architecture Requirements

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

Enterprise Architecture Annual Revision or Changes

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

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

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

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

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

Enterprise Architecture and ITSM Changes

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

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

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

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

Do not invest too much in building your CMDB now!

Interesting enough a few days ago a new version of the CMDB federation Whitepaper has been posted. The list of participants is impressive as we find every key players in ITSM including Microsoft…CA, IBM, BMC, Fujitsu, HP and Microsoft have worked together to propose a standard for federating data from ITIL compliant CMDB repositories. The intention is to submit their achievement to a standard body sometimes this year. For the time being, this is a draft which is reviewed by the main IT Service Management actors.

In this current version, there are explanations how to push or pull information from/to various CMDBs into a main CMDB. These “other CMDBs” are named: MDR, Management Data Repositories. Exchange mechanisms and technologies used to access these MDRs will be based on the SOA stack (HTTP, SOAP, WSDL, XML).

What does that mean concretely?

· In a few months (years?) vendors could sell Service Management solutions with a different metamodel
· Instead of using autodiscovery tools, vendors could provide these push pull mechanisms for companies which already have in place other platforms such as Asset Management systems, or system management platforms, or other inventory systems
· It becomes maybe un-necessary to build proprietary bridges with systems which contain important information to build a CMDB. This could be postponed.
· Vendors which actually come with tactical scenarios such as HP-Mercury with their UCMDB could change their strategy sooner than expected!
· Companies in a CMDB project may have to “migrate” in the future to another approach, based probably on a hub and spoke architecture
· Taxonomy being a key challenge for such a project may impact existing CMDB implementation

Companies which started to build a CMDB should measure the impact of that initiative in the long term with their vendors as the CMDB landscape could change dramatically in the next months.

Efficient Enterprise Architecture needs waiver requests...

A waiver request can be a new document type in an Enterprise Architecture program. The purpose of such a document is to request an exception to an approved Enterprise Architecture for information systems and applications. It allows to document the business justification, risk management process, and costs associated with an exception. This document and the associated exception process could apply to any system, application, element, or practice that varies from the approved Enterprise Architecture. These include but are not limited to data, applications, security, integration, collaboration, systems management, network and telecommunications systems, components, practices, and protocols. An Enterprise Architecture Review Board which is the decision authority for all waiver requests and could use its discretion to classify all waiver requests in different categories and will formulate a recommendation for approval or disapproval.

Examples of an important exception request could be:
· The total remediation cost for the exception exceeds fifteen percent of the project value.
· The total remediation cost exceeds USD 0.5 million.
· The exception will introduce a service, product, technology, or practice not currently in use in the company or is categorized as "Emerging" in the architecture.
· The exception violates an Enterprise Architecture principle.
· The exception is a service, product, technology, or practice, which is identified for "Containment" or "Retirement" in the current Enterprise Architecture.
· The exception does not comply with the infromation standards for a system for which it creates, updates, or deletes data.

Whether the waiver request is for a minor or major change, The board domain expert stakeholder or the board team will use the same decision criteria when approving or disapproving a request. Specifically, the individual member or board must determine whether the benefits associated with implementing the exception request outweigh any negative impacts to the IT community. In exercising this discretion, the decision-makers will consider:

· the impact of not granting the exception
· the technical merit of the exception
· the collateral impact to other systems and business processes
· the impact to the Enterprise Architecture
· alternatives to granting the exception
· precedent setting effects

Decision-makers must consider the Enterprise Architecture principles (including Business principles, Information principles, Application principles, Technology principles).

The decision-makers may approve or disapprove all or a portion of a request, based on the complexity of the system for which the exception is requested. The board should develop a consensus in reaching its decision.

The requestor has several important responsibilities in the architecture waiver process. First, the requestor is responsible for documenting the information contained in this form. This information outlines the justification for the exception and is critical to the decision-making process. Second, the requestor is responsible for obtaining the approval of the business owner and the technical owner. Finally, the requestor may have an opportunity to present the exception request to the decision authority on a scheduled basis.

The technical owner must approve all exception requests proposed by the requestor prior to review. The technical owner is the individual responsible for supporting the impacted business process with information systems solutions.

The business owner must approve all exception requests proposed by the requestor prior to review. The business owner is an individual at the director level or above who manages the business process that the system supports or will support.

Mapping of TOGAF 8.1 with COBIT 4.0

A new white paper has just been releaseed: TOGA and COBIT. This is the mapping of TOGAF 8.1 with COBIT 4.0 By The IT Governance Institute(R) (ITGI(R)).

This document provides a detailed mapping of TOGAF 8.1 with COBIT 4.0 and also contains the classification of the standards discussed in this publication, as presented in the overview document COBIT Mapping:Overview of International IT Guidance, 2nd Edition. This mapping helps enterprise architects and auditors using the COBIT framework to consider the requirements and value-add of The Open Group Architecture Framework(TOGAF) 8.1, and vice versa.

This White Paper is available as two parts in separate documents.

Part I (Doc. No. W072) contains the actual TOGAF 8.1/COBIT 4.0 mapping. The research supporting the mapping is available in Part II (Doc. No.W072A) and consists of the following appendices:

* Appendix 1: Plan and Organize
* Appendix 2: Acquire and Implement
* Appendix 3: Deliver and Support
* Appendix 4: Monitor and Evaluate
* Appendix 5: Harmonization of Terms and Concepts

This is now freely available to members in The Open Group bookstore at:

http://www.opengroup.org/bookstore/catalog/w072.htm

and

http://www.opengroup.org/bookstore/catalog/w072a.htm

and also listed in the Architecture Forum White Papers index at:

https://www.opengroup.org/architecture/wp/

TOGAF and ITIL

Many people are interested to understand how does Enterprise Architecture fits with IT Service Management. For the Open Group, I have written a document which has just been published today.

This White Paper considers how the Information Technology Infrastructure Library (ITIL) and The Open Group Architecture Framework (TOGAF) can be used together, with a detailed comparison and mapping between the two.

The re-birth of Enterprise Architecture?

Sadly enough, Enterprise Architecture has always been considered as a side IT Governance component and few big names were proposing services around products. Why? Simply because the IBM and HP like did not have any product offering…IBM always claimed that they were into Enterprise Architecture but they always tried to sell their Rational line of products without really understanding what is EA all about…. Probably when acquiring all Rational products, there would be a chance to do EA, but at what effort, what level of integration and also at what cost? Modelling processes with Websphere Business Modeler is still a techie activity and there were no indication that Business Analyst would be able to use such a tool. Very often business people were rather considering using Mega or Aris from IDS Sheer. HP also on its side was never per formant on IT Governance and acquired Peregrine and Mercury, for Service Management, Project and Portfolio Management. Enterprise Architecture has never been on their agenda, despite the fact they sponsor the Open Group. This may change…

In a recent post I was wondering why these companies did not take into consideration companies such as Telelogic, Casewise, IDS, Mega, Troux and others. My view was that in the next 12 months the market landscape would change and most EA companies would be acquired.

This has just been confirmed by IBM who acquired today Telelogic. Telelogic propose two components: DOORS and the ex-Popkin System Architect. Requirement is at the center of Enterprise Architecture and the Telerate offer was really appealing.

Now with IBM a few questions have to be raised:

• What’s going to happen with Requisite Pro and DOORS? These two products have similarities.
• What about Websphere Business Modeler and the System Architect process modelling tool? Same issue.
• How will Telerate integrate with the Tivoli CCMDB (Enterprise Architecture Artifacts and CIs). An Enterprise Architecture Repository should be maybe an instance of a CMDB.
• How will be integrated WSRR with the SOA modelling of Telerate?
• How will RUP for SOA /SOMA) fit the various EA framework supported by Telelogic?

Will IBM start to really propose professional services around Enterprise Architecture and support TOGAF as an open Framework among others?

Until now it has not been the strength of these well known companies to provide a consistent roadmap in terms of integration. As another example HP is doing a poor job in terms of integrating Mercury and Peregrine (the roadmap is absolutely unclear in terms of UCMDB.. and there are no indication how redundant service management functions between Mercury and Peregrine will be managed). Different contacts, different interpretation of the account managers…

Will IBM be able to better integrate their suite of modelling and architecting products? Will they be able to provide roadmaps, strategy and clear directions?

With this announcement there is a high chance that competitors such as CA, HP, Microsoft and others will soon start to consider Enterprise Architecture as a new source of income and a way to sell new products. Watch the space for acquisition! That story will be similar to the one related to the auto-discovery tools market and CMDB.

If most of the big names will soon have an EA offer in terms of products and service, this will launch a new wave of EA projects and will help standardization organization to better promote EA initiatives!

ITIL and CMMI synergies

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.

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 should be used in conjunction with a company’s IT processes found in Service Management (ITIL), COBIT, Project Management (SDLC/Prince 2), Enterprise Architecture (TOGAF), Quality (ISO 9000), Security Management (ISO 27001). 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).

CMMi is an important component of an IT Governance framework and has to be considered as a project.

Implementing CMMI and ITIL improves the Software Development Process and Software Quality and reduces the Cost Of Quality (COQ). In addition is time to market reduced and precision in estimation of effort and cost enhanced.

ITIL can combine with CMMI to cover all of IT, but doesn't address the development of quality management systems. Also it is not geared to software development processes and its use is highly dependent on interpretation. While CMMi is the de facto quality standard for software development processes, ITIL for many is the tool of choice for the operations and infrastructure side of IT, particularly for IT Services.

ITIL and CMMI best apply to different parts of the IT organization:

- Use CMMI in application development
- Use CMMI in ICT Infrastructure projects
- Use ITIL in IT operations and services

CMMi is very detailed. It is geared specifically to software development organizations, and focuses on continuous improvement, not just on maintaining a certification. It also can be used for self-assessment.

However it doesn't address IT operations issues, such as security, change and configuration management, capacity planning, troubleshooting and service desk functions. This is why ITIL is used. CMMi sets goals, but doesn't say how to meet them. (For example, CMMI says to do requirements analysis but doesn't say how to do requirements analysis.) This is why we would use a Project Management methodology.

Important observations

The focus for CMMi is software development, integration, deployment and maintenance, while the focus for ITIL is service management/operations. In reviewing, the touch points between the two , the amount of duplication is small in comparison to the number of interfaces and touch
points. This suggests the need for:

- strongly synchronized work efforts
- clear definition of interfaces, roles, and responsibilities
- participation from both efforts at a level appropriate to the density of the touch points (e.g., joint process action team membership, subject matter expert guidance, and/or process reviewer)
- By identifying the touch points between the groups, and promoting best practices using the CMMI and ITIL in their respective areas, the organization can leverage expertise and experience from within and from without .
- The most significant touch point should be documented in the area of Configuration and Change Management. There is no contradiction between the two models (CMMI and ITIL), so the teams should develop a unified process (‘the what’), with targeted procedures (‘the how’).
- In CMMI, the Process Areas are ordered along a Maturity Model with maturity levels. The ITIL processes are ordered in sets.

Enterprise Architecture and change management

An Enterprise Architecture should be fully revised on an annual basis to incorporate new or changed standards, evaluate new technologies and realign with changing business priorities. Architecture will never be "complete" in the sense that it should be constantly reviewed and revised, and related efforts realigned. As the business grows and evolves, so should the architecture governing its systems and processes. Just like the business itself, the architecture must remain dynamic and able to change with the demands of the business environment.

An Enterprise Architecture core team (EACT) or one if its domain teams may propose amendments in mid-cycle. Such amendments must be approved by an EA Governance Board, which will issue an EA amendment bulletin. All amendments must be incorporated into the EA through the next revision cycle.

The EACT is responsible for creating EA and revising it each year as recommended in TOGAF. Industry analysts and subject matter experts should be involved as needed in the process.

The EA is updated at least on an annual basis to:

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

The structured architecture creation/revision process should be defined by the EACT and approved by the EA Governance Board.

An Architecture review and approval process should be designed.

The FEAF defines the external component of the Framework representing an external stimulus, which causes the enterprise architecture to change. The architecture drivers consist of two
sub-components: business and design drivers, but this does not specify precisely the process.

Phase H of TOGAF ADM is referring to a change management process which could be related to the ITIL Change Management process or PRINCE 2. Obviously this would make perfectly sense to “re-use” the ITSM Change Management process for architecture changes.

One of the activities in Change Management is the Change Advisory Board (CAB) Meetings (to be noted that this committee should have also a member from the Enterprise Architecture team). There should be some synergies with the EA Governance Board as well. The approval from the architects should be a pre-requisite before submitting an RFC to the CAB when needed.

However the EA Change Management process could slightly differ as stakeholders could be different. The EAGB, the IT executive management team and the EACT being the main actors in the EA Change management process.

To be noted that shortly a white paper will be published by the Open Group on the integration between TOGAF and ITIL.

Enterprise Architecture Tools: Why are IBM, HP, Microsoft, CA and others absent?

Enterprise Architecture tools are often used to analyze and optimize the portfolio of business strategies, organizational structures, business processes, tasks and activities, information flows, applications, systems, and technology infrastructure.

Many of these tools have been designed with different architecture goals such as modeling, storing, managing and sharing information.

These tools can be classified in two main categories: EA repositories, EA-modeling suites (Business & IT) including some EA models.

Choosing a category depends mainly on the approach toward:
· EA top-to-bottom approach
· EA bottom-up approach
and the relationships with existing development and modeling tools.


Looking at the various acquisitions from big names these last years and the increasing interest in IT Governance, we observed several vendors trying to extend their tools portfolio going from modeling to service management, from project management to portfolio management.

IBM acquired in 2002 Holosofx, a business process modeling capabilities product to extend Web sphere Business Integration which then was re-branded to Websphere Business Modeler, a component for the modeling of a Business Architecture. CA acquired in 2005 Niku’s Project Portfolio Management (PPM). HP acquired in 2006 Mercury and Peregrine, companies having IT Service Management, Project Portfolio Management (PPM), and SOA Governance solutions.

Project Portfolio Management and Enterprise Architecture

PPM and Enterprise Architecture should be integrated in some way. All investments which support a Business strategy should be organized. A categorization model has to be used, followed by an evaluation and a prioritization. Once approved, the investments or demands become projects. But, how to decide when and how to make changes? How do we understand what can and can not be changed? What are the opportunities?




This is where the impact analysis and the “What if” scenarios enable to analyzethe company’s portfolio and assess the business contribution of each proposal, project, or application to an entire portfolio which needs also to be governed and managed.

An investment, a new demand should also be validated against an Enterprise Architecture. What are the impacts on the Business Architecture, the Business Processes? Does that make sense for a company to add new layers of information to an existing Information Architecture? In the context of a new solution, how does the new application affect the existing Application Architecture? Same thoughts apply on the technology architecture.

Very often Portfolio Management teams do not take into consideration these issues and may only focus on real-time visibility into resources, budgets, costs, programs, projects, and overall IT demand, but without considering impacts on the architecture.

Mature IT Governance would consider a strong interaction between a PPM team and an EA team. Once validated, an investment or a demand should be routed to the Enterprise Architecture team (can vary on the size and the scope), which add value to the first level evaluation. After a second level validation, the EA team using preferably an EA tool where specific architecture views and viewpoints have bee documented, is in a position to deliver recommendations to the PPM team.

We then go back to the company’s PPM process which adapts if necessary the budget, the costs, the resources and the program. There can be situations where the impact analysis detects side effects, or identify alternatives (may be for example the re-use of existing functions), or recommend to abandon the initiative.

Some companies which have implemented an automated process with a PPM solution would be tempted to also integrate the activities related to an Enterprise Architecture impact analysis.

Enterprise Architecture teams often use tools but rarely in an integrated way with the customer or other teams such as a PPM team. The kind of tools like Mega, Casewise, Metis-Troux technologies do not integrate yet with PPM solutions. Eventually we can consider an evolution in that direction from Telelogic which started a while ago to integrate Popkin with DOORS, the latest being maybe more a Demand Management solution than a PPM solution.

So now where are the IBM, HP, CA, and others?

Wouldn’t that make sense to use the Rational RequisitePro with Rational Portfolio Manager integrated with an EA Tool? Wouldn’t that make sense to have HP-Mercury ITG integrated with an EA Tool knowing that Systinet is an SOA governance platform and SOA surely linked to an EA program? Wouldn’t that make sense to have CA-Niku integrated with also an EA tool?

With all the small EA vendors proposing standalone products, there is a high chance that the “big names” will consider new acquisitions and the integration of EA solutions.

The Relationship Between IT Service Management and SOA

The Open Group Enterprise Architecture Practitioners Conference Paris, France

April 23-25 , 2007

STREAM #15: SOA Frameworks and Standards

Wednesday April 25 11:30 – 12:00

The Relationship Between IT Service Management and SOA

Serge Thorn, Director IT Research & Innovation (Switzerland)

Synopsis: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 XXXXX's roadmap and reflections in these two domains.

13ème Congrès Romand du Management de Projet

Atelier 11 : La gestion de projet et ITIL : deux mondes opposés, complémentaires ou intégrés ? présenté par itSMF (Serge Thorn)

Jeudi 12 avril – 11h20 à 12h00

Complémentarité des processus de Project management et de Service management :

• Intégration de la gestion de projet dans une logique de "Gestion des changements"
• Intégration du recueil des besoins dans le Service Level Management
• Impact de la gestion de la demande sur le Portfolio management
• Comparatif des processus de prise de décision et de la gestion des risques.

Service Level Management and SOA. more confusion?

Service Level management in an ITSM context

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

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

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

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

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

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

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

Service Level management in a SOA context

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

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

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

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

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

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

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

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

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

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

Monitoring should be done at two levels:

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


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

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

Achieving IT Operational Excelllence

You may be interested in an article I wrote for a magazine: Pharma Focus Asia Issue 4 2007 titled :

Operational Excellence: IT governance, Enterprise Architecture and service management, which explains what are the components of such a program in my company.

The article will soon be downloadable from http://www.pharmafocusasia.com/magazine/ (issue 4), but I'm copying its content:

IT governance defines a structure of relationships, processes and measures to direct and control IT in order to achieve the enterprise's goals.

IT governance is currently a key topic for many IT functions. Its definition varies very often, but key themes remain essential for all companies: effectiveness, efficiency and reliability. Business value and risk mitigation are also at the centre of this domain. It represents a significant part of enterprise governance, and due to the horizontal nature of IT, wherein almost everyone in the enterpriseuses IT assets to complete their responsibilities, the impact of effective IT governance is most visible.

IT governance defines a structure of relationships, processes and measures to direct and control IT assets (e.g. people, finance, infrastructure) in order to achieve the enterprise's goals by adding value while balancing risk with return. It helps to define roles and responsibilities and specify accountability framework to encourage desirable behaviour in IT and accountability for the use of IT assets. ITgovernance also helps to standardise best practices and define monitoring methods.

For XXXXX International SA, IT governance has always been the responsibility of the IT management team, being an integral part of XXXXX's governance, and consists of the leadership and organisational structures and processes that ensure that the IT function sustains and extends the company’s strategies and objectives to deliver value. IT does this within acceptable risk boundarieswhile taking into account culture, organisational structure and maturity.

For the XXXXX IT function, IT governance ensures that delivery expectations are fulfilled, IT resource deployment is continuously planned, targeted and optimised while IT performance is measurable and that the risks are minimised.Among the various components of an IT governance framework, the following domains were retained as being key themes to reach a high level of quality and excellence through continuous improvement:

• Quality management
• Balance scorecard
• Risk management
• Skills management
• Project and portfolio management
• Service management
• Enterprise Architecture
• Information security management
• Audit management
• IT performance and value management

Quality management was initially the main focus for IT, and since 1999, has been certified worldwide in ISO 9001. For the last two years, quality management has also included risk management(identifying risks from strategy down to operations and providing mitigation) as well as skills management (ensuring that the staff in the IT function have the appropriate skills in line with the strategy).Since 2001, IT measures its business alignment, which is highly integrated within the business strategy, using the IT balance scorecard tool. For more than three years, service management and IT Infrastructure Library (ITIL) have been the drivers to improve the quality of services for the end users. XXXXX's IT function deployed the ITIL processes covering both service support and service delivery. Thepurpose of this initiative was to:

• Increase customer satisfaction with IT
• Enhance communication with clients
• Achieve higher reliability in missioncritical systems and infrastructure
• Improve the cost-benefit of services
• Create a “common sense” among staff

These processes are mostly supported by tools from HP-Peregrine and IBM Tivoli. Project management has always been a key practice for IT people. Based on a traditional System Development Life Cycle (SDLC), the methodology has been widely used by the IT function for manyyears. All projects have to comply with documentation, templates and checkpoints where project progress is monitored.Committees validate the various steps of the methodology and give their approval to move to the next phase.

Portfolio management is known internally as the “Funnel”. The portfolio governance process starts when a business user requests or suggests a new capability. The request is automatically routed to aninformation manager (internal relationship manager), then to a business analyst or team for an initial business case before being routed to the IT management committee for review and scoring. The ITmanagement team then evaluates the prioritised, ranked projects to determine the proper portfolio mix and whether to accept the recent request. The “Funnel” is:

• A categorisation model
• A common language for business and IT to:

> Support business strategy
> Organise investments
> Evaluate and prioritise IT projects
> Govern and manage applications portfolio
> Decide when and how to make changes
> Understand what can and cannot be changed
> Provide real-time visibility into resources, budgets, costs, programmes, projects, and overall IT demand

• An input to the IT strategic planSolutions from HP-Mercury help XXXXX to support both project and portfolio management. An Enterprise Architecture (EA) consists of the vision, principles, standards and processes thatguide the purchase, design and deployment of technology within an enterprise. EA describes the interrelationships between business processes, information, applications and underlying infrastructurefor that enterprise, and provides best practices for technology purchase, design and deployment. EA structures and processes govern adherence to an organisation’s technology strategy and provide amanaged environment for the use of new technology.

Enterprise Architecture

• Allows alignment with the company’s business model and strategy
• Enables business changes, technologically based business opportunities
• Easier introduction of new technologies
• Allows standardisation
• Drives information/data consolidation
• Reduces enterprise-application integration complexity
• Facilitates outsourcing as appropriate
• Utilises assets more efficiently
• Provides the facility to better assess the impact of changes
• Ultimately, reduces time to market

Architecture governance is essentially a control or series of controls in the development process which is efficient when supported by good documentation (principles, guidelines, standards) and communicated effectively. To build such an Enterprise Architecture, XXXXX considered the use of both the Zachman and the Open Group TOGAF’s frameworks. Such a programme requires solid processes with ownership and accountability.

Enterprise Architecture is a component of IT governance which interacts with most of the other frameworks such as project and portfolio management, quality, maturity and security management. To manage EA, the company decided to use the Metis-Troux technologies solution.

Security management is another component of the IT governance programme, covering both information security and technical security. The BS 7799 certification was obtained in 2005 for GenevaHQ and ISO 27001 obtained on a worldwide basis in 2006. At the beginning of 2006, a new position reporting directly to the CIO was created to further develop IT performance and value management. Keydrivers for this are: optimising IT value, demonstrating IT value as a critical component of business processes, improving the quality of IT value measurement and reporting and becoming a potentialsource of innovation.

Performance management is not a stand-alone initiative; it is a process that needs to be established and fully integrated in strategic alignment with the business, value delivery and company performancemanagement. This performance framework consistently ensures that IT:

1. Is adding business value to the corporation
2. Is meeting the real customers’ real needs
3. Is running well as a business

Control Objectives for Information and related Technology (COBIT) provides a set of best practices and tools for auditing IT processes and assessing standards compliance, maturity and associatedrisks. COBIT can be associated to other frameworks, as architecture can be audited with certain KPIs.

In the frame of an IT research and innovation initiative, CMMi has been under evaluation. It is the Capability Maturity Model Integration which has been developed by the Carnegie MellonUniversity – Software Engineering Institute, a suite of products used for process improvement. 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.

CCMi models could be used in conjunction with all XXXXXs IT processes found in service management(ITIL), COBIT, project management (SDLC/Prince), Enterprise Architecture (Zachman-TOGAF), quality (ISO 9001), security management (ISO 27001), but the programme has not yet been considered.IT governance at XXXXX encompasses many disciplines within the organisation including IT strategy, risk management, IT service management and compliance management to name a few. Understandably, this presents a significant challenge for companies seeking to identify a starting point for their IT governance initiative. Fortunately, best practice governance guidelines and procedures do exist within the industry. Firms, moving ahead with the adoption of a standard will be well served to utilise a phased implementation project approach and start with elements of the standard that will yield their organisation the most benefits—

• Optimised IT strategy and execution
• Improve resource utilisation
• Improve planning and resourcing
• Risk assessment
• Real-time management reporting

In 2005, a benchmark with KPMG positioned XXXXX’s IT as number one among 119 other companies in the life sciences industry. In 2006, the number one position was maintained while thenumber of organisations increased to 125. This recognition states that the IT functionis using IT best practices to support the business and that XXXXX IT controls can now be classed as “excellent”.This was driven by major improvements in the areas of IT operations (incident, problem, operation, and configuration management), security (ISO27001), control assurance (risk, audit, planning management)and Sarbanes Oxley (SOX).

BAM, CPE, BEM, or Operational BI, what are the differences?

Business Intelligence (BI) in many companies has been used for several years to monitor, report and analyze, and improve business performance. Until now, most BI applications have focused on managing strategic and tactical business plans, but now Business Activity Monitoring (BAM), Complex Event Processing (CPE), Business Event Management (BEM) and/or operational BI could add a new dimension to this otherwise mature software area.

Business success demands continuous visibility into operations and processes. Operational BI or “awareness” should reduce the time between the occurrence of a business event and initiation of a response, helping a company act on competitive opportunities. Practically all operational areas need increased operational BI - awareness. Order cancellation, a late order delivery, an imbalance between resource capacity and demand, and a stock-out are just a few examples of events that require immediate action.

Increasingly, lines of businesses realize that to become more responsive, they must accelerate the flow of information, analysis and the decision-making. Major benefits of operational BI - awareness, which extend beyond strategic and tactical decision-making to daily management, include:

• A real-time visibility into business processes (this would require automated processes through the use of Business Process Management suites (BPMs)
• An increased business agility and flexibility
• A maximized use of resources (human mostly)
• Minimized risk
• A collaboration with a broader set of participants
  

Business Activity Monitoring (BAM) is an event stream capture and has been around for many years. This is a technology and a technique that provide real-time access to key business metrics. The reasons for deploying BAM are to monitor key business objectives, anticipate operational risks, and reduce the time between a material event and taking effective action.

There are many BAM products from platform (e.g. IBM Websphere Business Monitor, Oracle BAM, BEA ProActivity Process Analysis (PA), Aptsoft product.

Business Event Monitoring (BEM) is a way to get machines in real-time to alert people when a business process is going wrong and needs human attention to get back on track. BEM focuses also on the business rules and then alerts humans when something goes wrong. The goal is to speed processes up by minimizing time lost because of an exception. As previously written, BAM monitors business processes in real time in an effort to support operational improvements. Where BAM typically concerns itself with managing a single business process, BEM is generally concerned with monitoring all current processes to provide meaningful alerts and analytics to users. We should think of BEM as real-time data mining. While BEM is not yet part of many vendor offerings, this technology is making an appearance in some products. Vitria Technology's Resolution Accelerator provides BEM capability. Lombardi Software's Undercover Agents provide also BEM functionality.

Operational BI is also about the use of operational intelligence to manage and optimize business processes. When this is deployed, the huge analytical power of BI is unleashed on everyday processes that can generate improvements in real-time. This can exist alongside traditional BI, helping organizations to improve business operations both at strategic and business process levels.

Operational BI is the way BI vendors try to sell “type of BAM” applications, but…

Currently, most of Operational BI products refer only to data sensors.

Are they linked to BPM? It seems not because they still continue to use ETL and data access replication principles. Additionally BI vendors are not the best vendors to follow some of the trends about BEM which is often seen as an extension to BAM.

Some vendors like Systar pretend to be “BAM” but are in the same basket than the BI vendors in that case. And only BPM vendors with BAM features are able top provide such link. In counterpart BAM products often do not store good historical data like for example a BI do. It is then difficult to make comparison between operation data with historical data.

As already described, the ultimate goal of BAM environments is to immediately react from dashboards and the goal of BEM is to link the detection of events (including compound events collected for example by CEP) and then provide different management features like : diagnosis help, root cause analysis, management by exception. All of those require BAM (or operational BI) to work closer with the event generator: BPM in particular or other sensors. If we link those at data level only we miss the point. That means that every time we change a process we would have for example to reconfigure the data access, KPI and so on. Operational BI products are not
bad solutions but good for some customers and not enough for others.

The term BAM may become out of vogue in the future and vendors will turn to marketing their products under the banner of Operational BI. BI and BPM are two separate technology areas, complement each other and will converge over the next three to five years. Currently they are being used today in their respective worlds with very little overlap.

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.