We usually think of Configuration Management in the context of a Software Development Project, but CM also exists in the context of an Enterprise, having many projects and existing applications within IT and the Enterprise. In thinking about Configuration Management best practices, I wondered if taking the 20 principles used for an Enterprise Architecture Framework (TOGAF), we could see just how well Configuration Management stands up to supporting these general Architectural principles in an Enterprise context.
Often distilling a set of complex concepts down to some common basic principles helps gain a clearer understanding of our purpose. Best practices can then support these Principles. This paper does not derive the CM Best Practices from the TOGAF principles, but explores how well todays CM practices support the Enterprise Architectural principles. Introduction Frameworks are a good means of conceptually structuring the generic space in which people work. It helps ensure you do not forget certain areas. One such framework is an architectural framework called The Open Group Architecture Framework (TOGAF)[1] which defines an Enterprise Architecture. These ideas were further supported by a recent presentation entitled "Building a CM Platform to Achieve Speed and Control for Sustainable Compliance"[2], which suggested mapping CM to various frameworks for compliance. This particular presentation also mentioned a Goal, Question, Metric (GQM)[3][4][5] approach which I've found to be useful in the past for establishing software development project measurement metrics. I very loosely used this GQM approach by taking each of the 20 TOGAF principles and mapped them to a single simple question; "does todays CM support this principle?". This gave a rough metric of either "Yes", "Not there yet", "Yes Assists". Assumptions
In the context of Medium to Large organisations. This is not to say small organisations do not need architectural frameworks but probably don't have the bandwidth or resources to define and manage an Enterprise Architecture.Only one framework mapped. Many frameworks exist to which this mapping could be done, such as CMMI, COBIT, ITIL, Zachman, PMI, Prince2, RUP, etc.Personal Assessment. This is my own assessment based on my knowledge of the CM space currently and how it maps to the Architectural principles, please feel free to differ with me or discuss any of these points if you feel they are inaccurate. This is merely a starting point and some food for thought. The mapping works reasonably well. Some people may not agree with the point of mapping these two domains, my assumption is that it does seem to work reasonably well and gives the tool users and tool vendors another dimension to consider.Inside looking out or outside looking in? The reason I looked at CM from an Architectural and Enterprise point of view was because there seems to be a big focus on what I'd call an 'inside looking out' approach. The focus is currently on the CM detail, on being Agile, on Developing code, on Project specifics, etc. This is all good, and I'm fully supportive of these concepts. However you tend to run into difficulties are when you try and formally introduce CM (and other disciplines) into medium to large organisations. I thought I'd take the 'outside looking in' approach to see if there were any convincing arguments from the Enterprise Architecture requirements point of view that might cause them to want CM and help the case for CM supporting the Enterprise. Seems like there are many! Mapping TOGAF Architectural Principles to todays Configuration Management The tables below are structured according to the four layers of the Architecture Framework noted in the header title. The layers are Business, Data, Application and Technical, each have a few fundamental principles associated that are defined by short title in column one and in a sentence in column two. Column three is my assessment of how it answers the question of whether todays CM supports the principle with a short comment in column four. Business Principles
| TOGAF Architectural Principles for an Enterprise | Does todays CM support this principle? | | Primacy of Principles | These principles of information management apply to ALL organizations within the enterprise. | Not there yet | Currently CM tends to focus on Software Development (Models, Code and Tests) mainly, but needs to focus on all IT artefacts and even Enterprise artefacts in the longer term. | | Maximize Benefit to the Enterprise | Information management decisions are made to provide maximum benefit to the Enterprise as a whole. | Yes | Configuration Management directly assists in the management of information and its business systems. | | Information Management is Everybody's Business | All organizations in the Enterprise participate in information management decisions needed to accomplish business objectives. | Yes | Cm is supportive of this management but mainly in IT software development. | | Business Continuity | Enterprise operations are maintained in spite of system interruptions. | Yes | CM is crucial to supporting this principle. | | Common Use Applications | Development of applications used across the Enterprise is preferred over the development of similar or duplicative applications which are only provided to a particular organization. | Yes | CM is crucial in assisting the enterprise manage these, particularly Service Oriented Architectures. | | Compliance with Law | Enterprise information management processes comply with all relevant laws, policies, and regulations. | Yes Assists | CM helps report on this and could assist in mapping tables of policies and regulations to releases of software. Configurable yes, but not out the box. | | IT Responsibility | The IT organization is responsible for owning and implementing IT processes and infrastructure that enable solutions to meet user defined requirements for functionality, service levels, cost, and delivery timing. | Yes | CM helps manage all this | | Protection of Intellectual Property | The enterprise's IP must be protected. This protection must be reflected in the IT Architecture, Implementation, and Governance processes. | Yes Assists | Cm tools helps control access to IP, although as a by-product of its data security principles. |
Data Principles
| TOGAF Architectural Principles for an Enterprise | Does todays CM support this principle? | | Data is an Asset | Data is an asset that has value to the Enterprise and is managed accordingly. | Yes* | Cm is crucial to supporting this data asset principle. | | Data is Shared | Users have access to the data necessary to perform their duties; therefore, data is shared across Enterprise functions and organizations. | Yes* | Cm is crucial in managing this shared aspect. | | Data is Accessible | Data is accessible for users to perform their functions. | Yes* | Cm is crucial in managing the accessibility aspect. | | Data Trustee | Each data element has a trustee accountable for data quality. | Yes* | Cm is crucial in managing this aspect. | | Common Vocabulary and Data Definitions | Data is defined consistently throughout the Enterprise, and the definitions are understandable and available to all users. | Yes Assists | CM indirectly assists in managing this aspect by configuration controlling the Enterprise Business Process and Requirements repository | | Data Security | Data is protected from unauthorized use and disclosure. In addition to the traditional aspects of national security classification, this includes, but is not limited to, protection of pre-decisional, sensitive, source selection sensitive, and proprietary information. | Yes | Cm is crucial in helping manages this aspect |
* The interpretation of the definition of Data layer Some of my conclusions with a "Yes" in the table above are dependent upon how one defines the word 'Data'. If one defines 'Data' in a very generic way, where source and other files are enterprise data as opposed to atomic fields of data like a 'Surname' field in a Database Management System for example, then I believe that CM does fulfil these Architectural principles. If not then this opens up a whole different debate about the boundaries of Configuration Management of Data. i.e. Keeping the data how it was at a point in time, relative to other data at that point in time. Application Principles
| TOGAF Architectural Principles for an Enterprise | Does todays CM support this principle? | | Technology Independence | Applications are independent of specific technology choices and therefore can operate on a variety of technology platforms. | Yes | The Cm tool selected should be based on this principle. Many support this principle. | | Ease of Use | Applications are easy to use. The underlying technology is transparent to users, so they can concentrate on tasks at hand. | Not there yet | This aspect has improved rapidly in the last five years but must improve a lot more if it is to become pervasive generally within the enterprise and not only for software developers. |
Technical Principles
| TOGAF Architectural Principles for an Enterprise | Does todays CM support this principle? | | Requirements-Based Change | Only in response to business needs are changes to applications and technology made. | Yes | CM is crucial in assisting management of the requirements based change | | Responsive Change Management | Changes to the Enterprise information environment are implemented in a timely manner. | Yes | CM supports the ability for this principle to be implemented, especially the aligned iterative and Agile methods. | | Control Technical Diversity | Technological diversity is controlled to minimize the non-trivial cost of maintaining expertise in and connectivity between multiple processing environments. | Yes | CM is crucial in assisting with technical diversity at both a hardware and software level, especially if the next principle is adhered to. | | Interoperability | Software and hardware should conform to defined standards that promote interoperability for data, applications and technology. | Yes | Most CM tools should also conform to this principle. A CM tools should be chosen on this basis. |
Principles that need more work The areas that are shaded yellow and are marked 'Yes Assists', can be defined as either out of bounds for CM tools, or where the tools have the ability to assist, but have to be specifically configured to do so. Alternatively this could fall into the realms of supportive services such as Security, Authentication, and Reporting for example. Principles That Will Take Longer to Mature Looking at the red areas where the principles appear not to hold too well such as the 'Primacy of Principles' and the 'Application Ease of Use' above, I believe that while the tools have the technical ability to support the enterprise in many instances, the level of knowledge and user sophistication still have a long way to go if these tools are to become prolific and used in general areas of the business as opposed to software development only. People have to want to fulfil these principles and the tools have to support them seamlessly for it to succeed. To expect the average user in some accounting or marketing department to configuration manage their artefacts by checking excel spreadsheets in and out is probably a little far off happening any time soon. While it is obviously very achievable from a tool perspective, one questions whether the tools are user friendly enough to become used in such a disciplined manner in this way? The nearest I've ever seen was the use of a MS SharePoint intranet being used in the IT department, where many (not all) files were only version controlled. No concept of Configuration management and not integrated with Change Control management. Once again at an enterprise level I'm sure this still has even further to go. In fact, one could go as far as to say, people should have tools so they do not even realise their artefacts are being configuration managed. The file system of the operating system should have an added layer that just controls the versions against changes. A specialist Enterprise Configuration manager could then manage and build up the Enterprise configurations, etc. Conclusion In general it seems as through CM is currently very well positioned to satisfy most of the Architectural Principles. Certainly from a technical point of view the answers are available, its really a matter of getting people to want to use these concepts at an Enterprise level. There are two places for improvement in CM. One is getting the tools more ubiquitous and easy to use, the other is in ensuring they move out of software development domain and into the Enterprise for general use. They are both inextricably linked. For Enterprises that value the concept of an Enterprise Architecture, this list shows that in virtually every way, CM helps you manage your Enterprise Architecture by conforming to all the principles in one way or another. In many cases one could argue that they are central to the success of many of the EA principles. Going further one could say that without CM an Enterprise Architecture would not be complete.
References - The Open Group Architecture Framework - TOGAF - version 8.1 (2006) - www.opengroup.org/architecture
- Achieving Speed and Control for sustainable compliance - Uttam Narsu & Kurt Sand, (June 2006)
- GQM - Goal Question Metric - http://sel.gsfc.nasa.gov/website/exp-factory/gqm.htm
- GQM - http://www-ivs.cs.uni-magdeburg.de/sw-eng/us/java/GQM/
- GQM - http://www.goldpractices.com/practices/gqm/index.php
Charles Edwards has been involved with software development for 22 years. He is a contributing editor for CM Crossroads and an independent consultant who performs RUP implementation for organizations that recognize the need to improve their software development process. He works with and contributes to the www.processwave.net web site for process engineers. You can reach Mr. Charles Edwards by email at charles.edwards@processwave.com
Trackback(0)
 |
TrackBack URI for this entry
Subscribe to this comment's feed