Concepts & Beliefs

Purpose

Describe the underlying philosophy of configuration management.

Goal

Have an understanding of what is where, produced by who and when.

The need behind this is to have all parties involved in the creation of the solution and application architecture to be on the same wavelength when discussing application deployment matters.

Concepts behind this configuration management approach

This goal can be achieved without too formal structure for the documents.

Indeed, too formal structure hides the concept and makes everybody unhappy because of the tendency to build up a bureaucratic way of working. Trying to formalize too hard places a heavy burden on the shoulders of people and this leads to inefficiency as they loose creative and productive time fighting with paperwork. This makes them loose momentum and that is not good for productivity. The platform has to be an enabler, not a setback. In this, we want the platform to be very friendly to projects.

This approach is based on a non-fearful way of seeing things. If we were to consider a fearful approach (lots of formal things), this won't be any better since the complexity and rate of change of the IT environment are high and thus defy classification efforts. Trying to get secure about the structure by considering that documents are the reality is not a good long term solution as the reality is not the papers describing it (and reality always win at the end). The idea here is to have a map to navigate and make things happen. The map can also be used as a check list to see if all relevant aspects of the problem at hand have been considered. The focus is on the process of getting systems and applications implemented. We consider that without a map to unify and express the concepts, the support activities will ultimately be only fire-fighting as the team members react to stimuli without a chance to derive a model for managing those stimuli. First a model to work with, then support structured after the model. This model is by no ways meant to be perfect. Its goal is to be "good-enough" for practical purposes. Since formalization is not a priority, changes in the model to better reflect reality are easily made. We won't be striving for a "perfect" model, because this will just eat up too many resources which can be put to much better use to serve the customer.

Of course documents are needed to allow proper functioning of the configuration management process. The paragraph above just outlines that only documents relevant to the problems at hand have to be produced. The idea is : "If you feel that it helps to have this concept or system described, just do in with the model as a framework". Very simple yet very efficient.

Structure of the configuration management

The management of the configuration needs to build and work with the following deliverables:

1. Conceptual model of the "platform" . This means all relevant items for a platform-based solution.
2. Hardware infrastructure for the platform.
3. List of products and accountabilities
4. List of applications and relevant data
5. Deployment schema and licensing
6. View of deployed environments
7. Accountabilities summary

Each of those items is described in more detail hereunder.

Conceptual model of the "platform"

This model is depicted in ConceptualModel.ppt. I advise you to print it on a separate sheet. The depicted concepts are the following:

Hardware

Three other concepts have to be in mind when looking to the items on the chart, namely :

1. People accountable of types of hardware items
2. Deployment schedule
3. Component attributes

Product

Application

Solution - Deployment - Licensing

The licencing issue is quite difficult to address because various kinds of licencing schemes exists. A vendor may even change of scheme during the lifetime of a product.

An exemple of licencing types are:

• Site licence
• Per seat licence
• Per concurrent user licence
• Single user licence

Product interactions

Environments

An environment makes use of one or more components of the hardware infrastructure.

So every environment has references to hardware infrastructure components.

An environment is not a single machine, nor an area of disk space. It is a wider concept, encompassing users, data links, machines and running processes as well as related procedures. See "TBD" for an overview of a typical environment.

There are several type of environments, and each has a specific layout and characteristics:

• Environments differentiated by user base
  • Intranet environment
  • Extranet environment
  • Internet environment
• Environment differentiated by deliverable maturity
  • Development environment
  • Test environment
  • Training environment
  • Acceptance environment
  • Production environment

Hardware infrastructure for the platform.

This is the instantiation of the Hardware part of the conceptual model. This is to be built incrementally as the various projects come to the platform.

List of products and accountabilities

This is the instantiation of the Product part of the conceptual model. This is to be built incrementally as the various projects come to the platform.

List of applications and relevant data

This is the instantiation of the Application part of the conceptual model. This is to be built incrementally as the various projects come to the platform.

Deployment schema and licensing

This is the instantiation of the Solution - Deployment - Licensing part of the conceptual model. This is to be built incrementally as the various projects come to the platform.

View of deployed environments

This is the instantiation of the Environments part of the conceptual model. This is to be built incrementally as the various projects come to the platform.

Accountabilities summary

This is the list of people involved in the project and the list of accountabilites. They are cross referenced in a matrix to see who is accountable for what.

	Accountabilities
	Hardware	Software	Management	...
People
Joe
Jack
Sue

Related concepts of interest

• Design by contracts
• Service based infrastructures