Although we usually think of configuration management in the context of a software development project, CM also exists in the context of an enterprise. I wondered if taking the twenty principles used for an enterprise architecture framework, we could see just how well configuration management stands up to supporting these general architectural principles in an enterprise context.
Often times, 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) 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 today's 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 organizations. This is not to say small organizations 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 when you try and formally introduce CM (and other disciplines) into medium to large organizations. 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 Today’s 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 artifacts and even enterprise artifacts 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 help 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 fulfill 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
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 fulfill 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 artifacts 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 realize their artifacts 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, it’s 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
1) The Open Group Architecture Framework - TOGAF - version 8.1 (2006) - www.opengroup.org/architecture
2) Achieving Speed and Control for sustainable compliance - Uttam Narsu & Kurt Sand, (June 2006)
