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.