Archive for December, 2009
December 30th, 2009 by Bracken
Configuration management is a support management technique that has been around for over 50 years, and is use by many organizations and companies. Originally created by the US Military, the ideas of this modality have been adopted, and adapted for use in many different industries.
Configuration management is a model of product, information, or process life cycle. It is a blueprint adapted to specific projects. Generally there are four elements to configuration management:
Identification – is the process of determining the attributes of a configuration item (Any intermediate work product, product component, or product placed under configuration management, for instance, a piece of equipment or software).
Change Control or Management – is the approval process required to change a configuration item.
Status Accounting – is the capacity to check an item against the “blueprint” provided by the configuration management model resulting from the identification process. For the purpose of making sure that a change made in a configuration item has gone according to plan.
Verification – answers the question “Have we made the right thing?” This is answered by, among other things, analyzing tracing reports, to ascertain that all requirements have been met, or by usability assessments, to determine the usability of the system. This check can be done when the change is made, or once the product is finished, preferably both.
This type of software exists to make tracking and managing your process, steps, or cycles a relatively simple task. Configuration management is also greatly used outside of the military, configuration management is used by project managers in a variety of fields, most notable in the software development field.
Much like a complex weapon system, a piece of software goes through many step before emerging as the finished product, and configuration management software can take some of the sting out of watching over this sometimes labyrinthine process. Dozens of options are available for those interested in using this concept of software, many available for free on the internet.
Some of these are made for a very specific set of tasks, while others are made for a wider scope of projects they can handle. No matter what field you are in, configuration management is an effective model for keeping a track of complicated development and production cycles and processes. Configuration management software can automate a great deal of this for you.
Configuration management may sound very complex, and it can be. However, it is perhaps the best method of project management to dealing with complex and intricate project requirements. Working with a configuration management system makes implementing incremental changes in a process or product over time much less of a challenge.
December 29th, 2009 by Bracken
Here are some common Configuration Management terms and definitions.
Audit: Checking that a configuration item released for usage meets demands—that it fulfills specifications and, when released, is complete according to configuration management information. In this book, this is regarded as a quality assurance activity.
Baseline: This expression is not used in this book, except in direct quotes from standards or maturity models.
Binaries: Files whose contents are translated (compiled) into binary presentations, with variables of only yes or no (0 and 1).
Check-in: Placement of a configuration item in storage in the controlled library.
Check-out: Release of a configuration item from storage in the controlled library to production.
Configuration Control Board (CCB) or Configuration Change Board: A group of people responsble for assessing, and approving or rejecting, proposed changes to configuration items and responsible for the performance of approved changes.
Configuration item: Any intermediate work product, product component, or product placed under configuration management.
Configuration management system: All the procedure descriptions, templates, and tools that collectively support configuration management performed in a given context.
Dynamic library: A repository used during production. It is not regarded as belonging to the configuration management process area.
Library: A repository for a collection of items.
Life-cycle-dependent process: A process in operation for a limited period during the product’s lifetime, such as design or unit test. Such a process may be repeated throughout the product’s lifetime in an iterative development model.
Life-cycle-independent process: A process that must be in effect throughout a product’s lifetime, such as project management or configuration management.
Master library: A controlled repository for storing configuration items. Also called a configuration management library.
Metadata: Information about configuration items. For instance, a document placed under configuration management is a configuration item, while the name and number of the document are metadata for the item.
Process description: A description of the techniques, methods, conventions, and procedures employed in connection with a certain activity.
Product: Something produced. It may be for internal use, such as a design sketch, or for delivery, such as an entire software system.
Release or Baseline: A collection of configuration items that together form one configuration item. The collection is formed to be deliverable and useful as an entity.
Static library: A repository for items in use. It is not regarded as belonging to the configuration management process area.
Support process: Processes used in all other processes at various points in a software project’s life cycle. Support processes in themselves make no sense; they make sense only with other processes. For instance, naming is a support process; naming only makes sense if another process has created a product to name.
December 27th, 2009 by Bracken
It is quite difficult to explain configuration management to someone who has not actually experienced it firsthand. Configuration management has been considered the “holy grail” of development and information technology companies. While there are limitations in defining the inner workings of configuration management, it can be described by its goals and purposes in which it is setup for.
Configuration management makes it easier for computer systems to evolve with the changes in software and computer technology. Constant upgrades to computer systems, networks, and products are required, because of the ever increasing complexity of information technology. In a nut shell, configuration management can reduce instances of errors caused by upgrading computer systems to newer version. This is done by tracking the changes and components of a computer system. This will reduce network downtime and unintentional outages. In addition, configuration management maintains the integrity of the entire computer system, by assuring that all changes and configurations have been deployed appropriately for all components in the system.
Configuration management reduces the risk when making changes or configuring new computer systems. Systems and even security solutions such as firewalls tend to be more hazardous when a mis-configuration occurs. Configuration management makes it easier to change configurations and setups of computer systems, by providing a restore point option when a new configuration version or upgrade fails to work properly. Configuration management software enables a turn back to a previously good configuration when new configuration changes fail. This will not only reduce configuration risks, but will also minimize network downtime, which constitute a loss of productivity.
Configuration management enhances the security features of a computer network. With a configuration management software in place, all processes, configurations and changes that take place in a computer system or network can be tracked. This greatly reduces the vulnerabilities of computer systems intrusions.
December 24th, 2009 by Bracken
Where should you start when building your CMDB?
Many consultants and vendors suggest purchasing a tool before beginning the building a Configuration Management Database (CMDB). However, this is unnecessary since most IT organizations have very little idea exactly what type of information will eventually be added into the database.
To start, an MS Excel spreadsheet will work fine. The idea is to begin by mapping out the entire Configuration Management process prior to the purchase of a fancy, and expensive tool. Often one of the biggest dilemmas associated with building the CMDB is deciding where to begin.
It is considered good practice to involve other process owners in the design of the CMDB. This way, you can ensure that the database contains information that will be immediately useful and beneficial to the organization. This also helps in getting started.
Most organizations usually already have some form of Incident and Change Management processes in place. These processes are sometimes referred to as the “customers” of the Configuration Management process.
In this sense, Incident and Change Management will benefit directly from the data to be stored in the CMDB. Starting with the requirements from these two processes is also an effective way to resolve the often lengthy discussions regarding the CMDB strategy and design.
For example, the Change Management process uses relationship data from the CMDB to help in determining the potential impact and/or risk, to IT service availability, associated with changing a particular Configuration Item (CI). This is helpful in the planning and coordinating of changes so as to prevent unwanted downtime.
Likewise, the Incident Management process (with the Service Desk) utilizes the relationship data in the CMDB to determine the impact of an unplanned outage event on the user community or on defined service levels. The Service Desk can also use the CMDB to discover whether the CI is associated with any known defects or errors. In this event, workarounds may also be available to resolve the situation and thereby minimize the impact on the IT service.
It’s also helpful for the Incident and Change Management processes to have a certain level of maturity before beginning Configuration Management. This is mostly because, there should be some idea as to what type of information will be best in helping these processes to be effective in achieving their objectives.
For example: what level of detail is required for the Incident Management process to be able to adequately resolve breakdowns in order to meet agreed service levels? For Change Management: What level of system detail is necessary to accurately assess the risk associated with a particular change so as to maintain the required level of stability.
In practice, these thresholds are usually different for different IT systems and services. Therefore, the decisions regarding the breadth and depth of your CMDB will depend largely on the level of control required for each IT system/service. This control will depend mostly on the importance and required system availability.
For each service, start with those CIs that:
- Are subject to change
- Are necessary to deliver a service
- Can be managed
- Can be uniquely identified
Once the scope of the CMDB has been decided, a detailed project plan should be created. This plan should probably be divided into several phases with discovery and CMDB population for each IT Service. This means that once the level of detail is defined for each IT Service within the project scope, this master plan should be divided into roll-out phases and outline all services included for each phase.
Each phase will include CI discovery tasks followed by CMDB population tasks. Additionally, auditing and verification (of data) tasks are also very important as the accuracy of the data is critical to the success of the database.
Each CI entered into the database should have an owner or someone who will be responsible for making sure that the data regarding that CI is both complete and accurate. The CI should also be assigned a unique identifier, CI name, that will never change throughout the entire life cycle (i.e., CI purchase to retirement.) This means, that you should think twice before including any intelligence in the naming convention that references things which are subject to change (location, owner, host names etc.)
The name should make sense (i.e., servers begin with the letter s, perhaps) but should not be such that the name no longer makes sense when circumstances change (data center move, for example). This information can always be included in the CI attributes.
The naming convention should also be consistent across all environments. When deciding which relationships to map for each CI, consider first only the important relationships. This means, begin by describing in the CMDB, the most obvious relationships between CIs.
For servers, the important relationships might be what the server is connected to, which applications are running on the server, which services are dependent on the server, etc.
Once this has been decided, it is time to begin the population of the CMDB. Again, the CMDB can start off being something as simple as one or more excel spreadsheets.
What’s important is the process. A sound and well thought out process regarding the design of the CMDB as well as the ongoing maintenance of complete and accurate information are the keys to creating a successful and effective repository.
danielle j. baker
IT PROCESS IMPROVEMENT PROFESSIONAL
Master Certified ITIL Service Management Specialist with advanced knowledge and practical experience in leading the end to end design, delivery and management of customized ITIL based best practice solutions for Fortune 500 companies across multiple industries.
Article Source: http://EzineArticles.com/?expert=Danielle_J._Baker
December 19th, 2009 by Bracken
The concept of software configuration management can be very hard to understand, unless you received a well guided introduction to it. However, many new comers will simply be placed in front a computer running an open source data CM package. The prerequisite for working with such software in CM is ‘grade A’ knowledge of C++, Java, and the basic working knowledge of Linux. This can be initially overwhelming and induce a black stare.
Configuration management literally means managing change or managing information for change. So if two users are trying to access the same Word doc in a local network they will usually be unable to edit the doc at the same time. This is because the network cannot accommodate two sets of changes at once. Without any configuration management system there is the potential for two users to open the document, do separate work then for the last one to save to overwrite the work already done. The CMS is there to avoid these types of errors.
The example is a very basic one and with CMS both users can check out their copy of the file, while the system keeps a record of every version saved and merges the changes to the document. The Word doc example is not where CMS is most important as the real value of CMS is in software development. If you have scores of software developers working on the same source code files then a software configuration management system is essential.
SCM systems work on the basis of a central database of all files. Users can check out the files, make alterations and then check them back in again, and then the files are available to all users again. The system can check changes against the original file and update them keeping an archive of each generation. Every SCM will have concurrent management and versioning.
Concurrent management is a feature that allows multiple changes from different users a2nd tfhen merges the changes. Dependent on the system configuration the SCM system will either process the changes itself, minimize the users, or it will notify the user to do so manually.
Versioning is the feature that stores archive copies of every file in the database so that users can open previous versions of a file. They also can track the history of files to establish who checked what files out and when. Synchronization is the process of a user submitting their file to the database so that the SCM system can update the file.
December 18th, 2009 by Bracken
When people find out a configuration management database (CMDB) is being created, many people will have data they feel should be included. The list of potential sources for data is as varied as the organizations that can benefit from a CMDB. Although specific types of data and sources will vary for every industry and company. You need to create a plan how to identify what data is need to be a part of the new CMDB.
Your plan will include a set of steps to collecting each type of data you identify. Start with a series of meetings with the all managers to understand what they have, and more importantly, what they don’t have that you need. If the data is managed by a part of the organization different from that sponsoring your configuration management team, you will need more detailed meetings to work out what format the data can be sent, how the data will actually be transferred, the owner of the data, and what processing must happen after the data is received. Finally, your project plan should include some set of tasks for confirming that the data was correctly received.
December 15th, 2009 by Bracken
Configuration management (CM) is a field of management that focuses on establishing and maintaining consistency of a system’s or product’s performance and its functional and physical attributes with its requirements, design, and operational information throughout its life. For information assurance, CM can be defined as the management of security features and assurances through control of changes made to hardware, software, firmware, documentation, test, test fixtures, and test documentation throughout the life cycle of an information system.
History
Configuration management was created by the federal government and is currently required for all military contractors. This was in response to the problem the military was having with contactors not being able to duplicate their prototypes exactly.
The concepts have been widely adopted by numerous technical management models, including systems engineering, integrated logistics support, Capability Maturity Model Integration (CMMI), ISO 9000, Prince2 project management methodology, COBIT, Information Technology Infrastructure Library (ITIL), product lifecycle management, and application lifecycle management. Many of these models have redefined configuration management from its traditional holistic approach to technical management. Some treat configuration management as being similar to a librarian activity, and break out change control and change management as separate areas of discipline.