• Skip to main content
  • Skip to primary sidebar

This view of service management...

On the origin and the descent of managing services. We put meat on the bones.

  • Kanban Software
  • Services
    • Kanban Software Solutions
    • Consulting & Coaching
    • Training and Seminars
  • Posts
  • Events
    • Events – Agenda View
    • Events – Calendar View
  • Publications
    • Our Publications
    • Notable Publications
    • Quotes
  • About us

Lean configuration management: a conundrum

2 June 2017 by Robert Falkowitz Leave a Comment

How does a purely internal activity like configuration ma­nage­ment add value to customers? Would a customer gladly pay you for your configuration ma­nage­ment ac­ti­vi­ties? Keeping your con­fi­gu­rations under control is hardly value adding in the same way as, for example, increasing the utility of a service. And yet, good configuration management under­pins virtually all service management activities. How do we resolve this conundrum? What could lean configuration ma­nage­ment be?

value adding activities from the customer's perspective
Fig. 1: Lean takes the customer's perspective in deciding whether an activity is value adding

Configuration management according to the standard frameworks

Before getting into the details of what lean configuration ma­nage­ment might be, I first need to clarify how I understand the scope of configuration ma­nage­ment in the standard service management frameworks. Al­though there have been various published discussions of lean configuration management, they are essentially limited to the specific practices of software development. I  broaden the dis­cussion here while at the same time relating lean configuration management more closely with service management practices.

The discipline of configuration management encompasses many different scopes and practices according to many different people. For those coming from a U.S. military background, con­figuration management is es­sen­ti­ally what other frameworks consider to be change control.[1] It is fundamentally about keeping under control changes to configurations of tracked com­po­nents, and secondarily about documenting those con­fi­gu­ra­tions, as they change. In the service management realm, change control and con­fi­gu­ration control are split into two separate disciplines, although they are intertwined in an elaborate tango. Nonetheless, an echo of the change control responsibility of configuration management re­ap­pears in ISO 20000:2-2005: “…configuration ma­nage­ment plan(s)…should include or describe…the con­fi­gu­ration ma­nage­ment pro­cesses to…control changes to the configurations”. But it surely does not make sense for one discipline (change management) to control changes to configuration items and another discipline (con­fi­gu­ration ma­nage­ment) to control changes to the configurations of service components. See further below on this confusion.

ITIL® groups together under the rubric “Service Asset and Configuration Management” a wide array of activities. It follows the general practice of dis­tin­guishing between any component of a service system, called a “service asset”, and the subset of service assets whose configurations can be managed individually, called “con­fi­gu­ra­tion items”. We see a similar distinction, for example, in the aviation industry, where only a subset of all the objects that compose an airplane are actually tracked and are under control—the so-called “hard time” components.

If the distinction ITIL makes between a service asset and a configuration item is lucid, the distinction made by ISO-IEC 20000 between a configuration item and a service component is muddied, if not downright ob­scure. A configuration item is defined as an “element that needs to be controlled in order to deliver a service or services.” The existence of unmanaged services puts the lie to this definition. Further on, a service component is defined as “[a] single unit of a service that when combined with other units will deliver a complete service.” That sounds much more like the definition of a software application function than anything else. Recognizing the fuzziness of such a definition, the standard continues to give as examples of service components, “Hardware, software, tools, ap­pli­ca­tions, documentation, information, processes or supporting services.” But in ISO-IEC 20000-4:2010, the distinction between CIs and service components is largely lost when it proclaims the tautology that “The purpose of the configuration management process is to establish and maintain the integrity of all identified service components” (assuming that “identified” means the output of the configuration management Iden­tify activity).  Are we to understand then, that a configuration item is the same thing as an “identified service component”? Or are there service components that have been identified, but are not treated as CIs (as per ITIL)?

CobiT retains ITIL’s distinction between asset management (BAI09) and configuration management (BAI10) and speaks of “assets” and “configuration items”, dispensing with the concept of service components.

Patterns of configuration management

So much for the theory of configuration management in the frameworks. Out in the field, configuration management sig­ni­fies many different types of responsibilities, activities and tools, as varied as there are service providers. Yet there are several patterns that appear to dominate the landscape:

Traditional software development

In a traditional software shop, configuration ma­nage­ment concerns the documentation and control of the code and the libraries used to create applications. Since the same repositories control component versions and are the sources of the code used to create deployable applications, there is little chance that only a partial selection of components are kept under control. (Although I suppose that truly creative engineers find ways of getting around this.)

In addition, the technical procedures for creating applications may also be components under control. In contrast, the platforms on which applications are created, tested and ul­ti­mate­ly run are generally not within the scope of the “traditional” software de­ve­lopers’ configuration con­trol. Either these com­po­nents are under the control of a separate infrastructure team, or they are controlled only in the minds of the developers, or they are simply not under control at all. Components such as testing protocols are similarly controlled in an ad hoc way, if they are under control at all.

It might be noted that in many organizations, espe­ci­ally those influenced by the U.S. military, what we call today “change ma­nage­ment” was, in fact, a part of configuration management.

Continual deployment software development[2]

Within the past 10-20 years, certain software developers have attained a continual deployment capability.[3] This cap­a­bility implies that not only the software components themselves, but also the build procedures, the tests and the platform con­fi­gu­rations are all part of an integrated management sys­tem. This system allows for highly automated, “push-of-a-button” releases. Thus, a developer can commit a change to code, create an executable and the environment in which it shall execute, run a comprehensive series of tests and qualify the result as releasable, even deploy the release to production—all at the push of a button.

Such high levels of automation depend heavily on the virtualization of platforms and en­vi­ron­ments and descriptions of the configurations of those environments that are de­tailed enough to create (and destroy) any given system in which the soft­ware executes.

While this capability may be applied especially for the development and test environments, nothing pre­vents it from being applied to pro­duc­tion en­viron­ments, too, assuming that the physical hardware is available and configurable as required. Unfortunately, we are not yet able to create networks and com­pu­ters out of thin air.

Automated discovery IT production

A technical response to the unsatisfactory situation in the previous pattern is the installation of software that “discovers” and auto­ma­tically documents sys­tem components. Such approaches make mis­lead­ing metrics such as “per­cent­age of components documented” look much better. But they fail in the realm of improving the management of services. This is largely due to the incomprehension of the data collected, the vast quantity of data collected and the complexity of the relations detected. While many of these issues may be addressed by com­pli­cated con­fi­gu­ration and customization of the dis­co­very system, discovery tools do not increase the motivation of the per­sonnel to use the data.

But more importantly, there is a tendency to assume that the con­fi­gu­ration docu­men­ta­tion pro­vided by discovery tools is sufficient to meet the needs of configuration management. Unfortunately, it is not. One of the key goals of configuration management is to keep the con­fi­gu­rations of com­po­nents and system under control and in an authorized state. This is impossible unless the authorized configurations of components and re­la­tions are documented, together with the actual configurations. No dis­covery tool can determine what is authorized unless authorized states are documented separately.

Old-fashioned IT production

In this pattern, there are no configuration ma­nage­ment links between the teams responsible for creating applications and the teams responsible for operating IT. Furthermore, each operations team maintains its own ap­proach to configuration management and its own tools. In some cases, they depend on the data in the management tools to con­trol con­fi­gu­rations. This is common, for example, among network ad­mi­ni­stra­tors or mid­dle­ware engineers. In other cases, they rely on spreadsheets or similar semi-structured or unstructured documents to hold whatever con­fi­gu­ration information they deem important. In most cases, when the con­fi­gu­ration data is separate from the management tools, it is updated manually, as an afterthought, and only if someone has the time to do so. Multiple versions of the same data are common in this pattern, with no clear responsibility for ensuring the overall coherence of data.

CMDB IT production

In response to the confusion and lack of consistent authority that reigns in the preceding pattern, frameworks such as ITIL have recommended the creation of centralized, authoritative databases to hold configuration data. This pattern tends to have limited success because the personnel often have no clear understanding of how they will use the data in the CMDB. As a result, they are not motivated to maintain it. The gran­u­la­rity of the data is typically based on seat-of-the-pants estimations and theory rather than real use cases. Only a small percentage of com­po­nents are doc­u­mented, that doc­u­men­tation is not maintained in a timely way and the res­pon­si­bility for doc­u­ment­ing relationships between components is poorly de­fined, if defined at all. In general, the personnel are overwhelmed by the vol­ume of data that could be documented.

In this pattern, the typical response to these dif­fi­cul­ties is to centralize res­pon­si­bilities for con­fi­gu­ration ma­nage­ment, by naming configuration ma­na­gers and configuration li­bra­rians.

Virtual configuration management

This pattern is merely an extension of the pattern described above under Continual Deployment. The pattern depends on the system configuration tools to document what configurations should be (the au­tho­rized con­fi­gu­rations). These same tools are used to generate the systems themselves, there­by guaranteeing that the actual configurations cor­re­spond, immediately after an automated change is successfully implemented, with the authorized con­fi­gu­ra­tions.

In the current state of technology, this method of configuration control is possible if the components themselves are virtualized. For example, a virtual computing platform is not a metal and plastic ma­chine; it is software run­ning on top of a physical platform.

By including discovery functionality, the tools also allow for automated de­tec­tion and correction of configuration errors.

In the patterns described above, I have focused on IT configuration management. There are many other domains with similar levels of complexity and constraints, such as in aircraft maintenance or in transportation networks. The same issues of lean configuration management apply there, even if the historical development of management patterns in those domains has proven to be quite different from IT.[4]

Getting to lean configuration management

A facetious wag might remark that many organizations perform an extremely lean management of configurations, in that they ma­nage con­figurations little or not at all. Be that as it may, such organizations are likely to pro­duce a large number of defects in their products, while failing to address the under­lying con­fi­gu­ration problems in any effective way. Putting aside such dys­func­tional org­ani­za­tions, let’s look at how lean may be the various patterns described above.

The key issue in assessing the lean-ness of configuration ma­nage­ment is whether the necessary activities are, one the one hand, made part and parcel of the value added work and performed by the same actors, or, on the other hand, whether configuration ma­nage­ment and value added activities are performed as a separate process, by separate roles, fulfilled by separate people.

Let’s compare some cases.

Case of centralized CMDB update

In company A (see Fig. 2), it was decided that all CMDB updates are to be performed by a cen­tralized con­fi­gu­ration lib­ra­rian. The reasoning was that the people who know and understand changes in con­fi­gu­rations do not reliably update documentation in a uniform and timely way. Sound familiar? In other organizations, it is assumed that specialized and highly qualified engineers should not be spending their time performing lowly ad­mi­ni­strative tasks, such as documenting con­fi­gu­rations.

CMDB update using a configuration librarian. Not very lean configuration management.
Fig. 2: Procedure for updating CMDB when using a configuration librarian[5]

Suppose the configuration of a cluster of servers changes. The person designing the change must inform the configuration librarian of the new au­thor­ized con­fi­gu­ration. The person exe­cuting the change must inform the con­fi­guration li­bra­rian of the actual new configuration (##3-5 in Fig. 2). The actual configuration after the change is not always identical to what was planned, for a variety of reasons, such as poor planning and poor execution.

In order to communicate to the configuration librarian all the in­for­mation required to update the CMDB, the technical expert most likely needs to write down that information (##3-4 in Fig. 2). One must ask why it is possible to write down that information for the con­fi­gu­ration librarian’s use, but it is not possible to write it directly into the CMDB? By splitting the update res­pon­si­bility into two roles, various forms of waste are inevitably introduced: waiting before the communication is prepared (#2); waiting between the receipt of the update details and its validation (#6); waiting for the librarian to do the update (#9); waiting for the technical expert to validate the CMDB update (#11); errors or incompleteness in the in­for­ma­tion com­mu­nicated to the librarian (defects) (#8); differences between the information received by the librarian and the information recorded in the CMDB (defects) (#13); or more information communicated than can be recorded (over-processing) (##7, 10).

Case of automated CMDB update based on a proposed change record

In company B, some of the issues faced by company A are addressed via technical controls and auto­mation. One form of control calls for the change designer to document the configuration changes in a tool such that the CMDB is automatically updated when the change is deemed to have succeeded (see Fig. 3).

CMDB update based on change planned in a change mgmt tool. Still not very lean configuration management.
Fig. 3: CMDB update using planned change details in a change management tool (change control activities not shown)

While this method reduces much of the waste found in company A, there are still various forms of waiting built in (##2, 4 and 8). In addition, it fails to handle the possible difference between the approved change (#5) and the actual change (which may be different from the details in #11).

Case of automated detection of changes, followed by reconciliation

A second form of control involves using discovery tools to document the actual change performed. This approach addresses the issue in the previous scenario (Fig. 4). There are potentially two parts to this automation (#9): the de­tec­tion of the implemented con­fi­gu­ration change; and the com­pa­rison of the detected change to the approved change. The issue of how to reconcile any detected differences remains an open ques­tion. In general, it requires an additional, manual task (#12). I do not expect reconciliation to be automated since, if such auto­ma­tion were possible, then the same tools would have automatically implemented the change, thereby ob­vi­ating the need for recon­ciliation.

CMDB update procedure with reconciliation of unapproved change. Automation leads to a little more lean configuration management
Fig. 4: CMDB update procedure with reconciliation in case of unapproved change detected

Note that even with this level of automation, there remain cer­tain types of waste, especially if the change designer and the change implementer roles are played by two different people. There is almost inevitably some waiting during the hand-off from the designer to the implementer (#4). Note that once again I skip any reference to change control between the design and the im­ple­men­tation. I prefer to dis­cuss in a future article the issue of change control in a lean en­vi­ron­ment.

Case of fully automated change implementation and configuration management

In the final case (see Fig. 5), company D has a layer on top of the physical infrastructure that can be entirely deployed and configured using templates and software configuration. The most common example of this would be a virtual computer whose cha­rac­ter­istics are designed entirely in software.

In such cases, the tool used to document component and system configurations can be identical to the tool that deploys and updates those con­fi­gu­ra­tions. In a ser­ver­less environment—that is, one in which the physical server infrastructure is hosted entirely with third parties—the need for a CMDB independent of the software configuration and deployment tool is reduced to a strict minimum. Until such time as all premises equipment can be deployed and configured by a corps of robots, we will not be able to dispense entirely with a manually maintained CMDB. However, the day when the deployment tool in Fig. 5 would combine software configuration of virtual components and robotic configuration of physical com­po­nents is probably not very far off. But until that day, the existence of the virtual layer on top of the physical infrastructure displaces a huge percentage of the con­fi­gu­ration changes.

When configurations are recorded as part of a value added activity, the procedure is part of lean configuration management.
Fig. 5: Configuration automatically managed in a tool blending configuration documentation and deployment

The procedure in this case is vastly simplified. The change designer describes the to-be configuration (#1), which is stored directly in the con­fi­gu&shyration tool (#2). When ready, the designer pushes a button to deploy the change (#3). If the change succeeds, the status of the to-be configuration is changed to an as-is configuration. If it fails, the system rolls back to the previous as-is configuration (#5). This approach to change deployment has a poka yoke characteristic, in that the only way to complete the change is to complete it correctly, as planned and authorized. There is neither any additional need to validate the change, nor to validate an updated CMDB, nor to reconcile a difference between an approved change and an implemented change.

The principal source of waste in this scenario would be in the design of the change (#1). It could be designed incorrectly (defect) or it could be designed with attributes that are not strictly necessary (over-processing).

I note that most organizations are likely to continue to need a place to document authorized con­fi­gu­rations to cover the cases where the components are physical and cannot be deployed and con­figured via software.

Configuration management and necessary waste

The lean management frame­work recognizes the concept of ne­ces­sary waste. Certain activities are not value adding from a customer’s perspective and do not significantly advance the trans­for­mation of inputs into the final product of a value stream. And yet, they cannot be eliminated.

The classic example of such activities are those required to demonstrate conformity to re­gu­la­tory standards. I recently dis­cussed with a former colleague from a bank how all banks are required to spend huge sums of money today to comply with the regulations of certain go­vern­ments. In fact, that compliance sometimes goes directly against the interests of certain clients.

Nuancing the distinction between value adding and non-value adding

A harsh distinction between value adding and non-value adding activities, whether man­da­tory or not, lacks nuance. On the one hand, the customer is not the only stakeholder from whose per­spec­tive we should assess value. On the other hand, there are many activities performed by a service provider that may ultimately pro­vide value to a customer, but which the customer might not re­cog­nize as such.

  • Organizations operate within marketplaces.
  • They use inputs and produce outputs that affect that phy­sical environment.
  • They have symbolic roles active in the realm of ethics.

A classic example of a necessary non-value adding activity to ensure the stability of a mar­ket­place is the intervention of J. P. Morgan in the Panic of 1907. Following the failure of the Knickerbocker Trust Company, a major competitor of Morgan’s, he convinced his surviving com­pe­ti­tors to inject capital into the market to shore up confidence in the marketplace and prevent a pernicious domino effect.

Many organizations perform activities to ensure that their outputs comply with en­vi­ron­mental pollution stan­dards. By so doing, they help ensure the long term health of the world and the continuing long-term operations of the organization. And yet, many customers would explicitly reject the need to pay for such activities. Thus, activities can add value to the broader eco-system rather than to the individual products it creates. And this, whether a customer recognizes it or not, whether the customer would gladly pay for it or not.

Risk management activities are a broad area where the value of the activity might never be re­cog­nized. Often, it is only in their omission that customer’s re­cog­nize their value. How many passengers on the Titanic would have gladly paid a higher ticket price to strengthen the hull of the ship to resist the impact of icebergs? Unfortunately, those who perished in its sinking were in no position to change their minds about such a need. Thus, customers may sometimes re­cog­nize the need to pay for certain activities, but only well after the purchase is completed. The buyer of a sports car might gladly pay for the power of the engine, the quality of the paint job and the styling of the body. But after an accident, that driver might thank his or her lucky stars that the vehicle had extensive airbags installed, an option that might not have seemed important at purchase time.

Configuration management performed as a kanban class of service?

The concept of delayed added value has its parallel in kanban’s method of applying classes of services to work. The intangible class of service—that is, a class of service where the initial cost of delay is not tangible and thus not something a customer would readily recognize as valuable or worth paying for—refers to work that is often absolutely critical in the long term. How many cus­tomers would ever willingly pay for the replacement of a provider’s network of coaxial cables by a system of structured twisted pair cabling? And yet, without performing such in­tan­gible class activities, the provider would ultimately go out of business. If all such providers went out of business, where would that leave the customers?

Treating CMDB update as an intangible class of service
Fig. 6: On the left, updating the CMDB is treated as a work item separate from the change itself and assigned an intangible class of service. On the right, the change and the CMDB update are part of the same work item, sharing the same class of service—much leaner.

A warning, however. The concept of applying the intangible class of service to configuration ma­­nage­­ment activities is appropriate only if those activities are performed as separate and distinct activities within the value stream (see Fig. 6). However, as we saw above, such an approach is hardly con­du­cive to lean configuration ma­nage­ment. I suggest a lean con­fi­gu­ration ma­nage­ment ap­proach would embed the configuration activities within other activities in the value stream, rather than treat them as separate activities or a separate value stream. See the following section for more details about this embedding.

In summary, I hope you do realize that many of the activities we perform to manage configurations do, ultimately, add value, even if they would not be recognized as such in a classical lean analysis of value addition.

Assessing the lean-ness of configuration management activities

We have seen in the above analysis that there is a place for con­fi­gu­ration management is the context of a lean management framework. But that does not mean that all the activities performed under the rubric of configuration ma­nage­ment are equally valuable in a lean approach. Furthermore, some of the methods for achieving the valuable goals of configuration management might be con­si­dered as lean, whereas others are very wasteful. Let’s review the activities described in the traditional frame­works.

Management and planning

I refer to the discussion of planning as part of my analysis of release ma­nage­ment. The same principles apply to configuration ma­nage­ment. To the extent that any planning is required, in a lean context that planning would be subsumed under the overall lean implementation and the continual improvement activities.

As Einstein said, “In theory, theory and practice are the same. In practice, they are not.” So it is for the planning of configuration management, even in org­ani­za­tions with a command and control, waterfall approach to doing work. According to ITIL, management “de­cide[s] what level of service asset and configuration ma­nage­ment is required for the selected service or project that is delivering changes and how this level will be achieved.” But this sort of planning is often wildly inaccurate, es­pe­ci­al­ly in organizations where the maturity level of con­fi­gu­ration ma­nage­ment is low. Simply stated, many organizations learn how to manage configurations by trial and error, not by “good” planning.

Identification of systems and components

For ITIL, configuration identification is essentially the planning of how to control configurations. Ideal­ly, this activity is performed with a clear understanding of how the controls will be used. But this is often not the case. Organizations discover, once again by trial and error, when components and relationships need to be identified and kept under control. As such, configuration iden­ti­fi­ca­tion is much like the planning and management activity.

In one organization with which I had worked, each team was given the re­spon­si­bility for the naming conventions of the tech­no­lo­gies they managed. It was only when the data was loaded into a CMDB that it was discovered that it was possible for a router and a Windows server to have the same name! Live and learn.

In my experience, org­ani­zations never get the granularity of con­fi­gu­ration items right from the very start. It is only later, when they see that certain attributes are simply not maintained and are useless to them, or other at­tri­butes would be useful but are not recorded, that information granularity starts to approach a useful and maintainable level.

Control of systems and components

According to ITIL,

Configuration control en­sures that there are adequate control me­cha­nisms over CIs while maintaining a record of changes to CIs, versions, location, and cus­to­di­an­ship/ownership.

There are really two separate “activities”: en­sur­ing adequate control me­cha­nisms and recording changes.

The former is one of those non-lean “ensuring” ac­ti­vi­ties that I discussed at length in the context of release management. Of course, we do want the integrity of components to be maintained. But main­taining integrity is simply an approach to any of the value adding activities that involve the handling of components, such as the purchasing, reception, de­ploy­ment and opera­tional activities. It is not a se­pa­rate activity, in and of itself. In a lean en­vi­ron­ment, an ensuring-type control is simply a policy according to which other activities must be per­formed.

The second activity, re­cor­ding changes, is really at the heart of the lean configuration management co­nun­drum. We surely must record this in­for­ma­tion, but what customer would gladly pay for our doing so? The vir­tu­al con­fi­gu­ration pattern described above comes closest to performing this activity in a lean way. This is de­scribed in detail in the final case documented in Fig. 5.

Status accounting and reporting of configuration information

I am not sure why ITIL groups these two activities together. In my view, status accounting is more ap­pro­pri­ately grouped with the recording of component attributes, that is part of the control of systems and components, q.v.

Reporting of configuration information is inherently non-lean as a distinct ac­ti­vity. Does this mean that there should not be any reports about con­fi­gu­ra­tions? Of course not. It only means that the cre­ation of a report is an ac­ti­vi­ty that should be pulled by the customer of the report, on demand. It should not be pushed—created and distributed whether anyone wants to use the report or not—an approach that leads to the waste of over-production. In any case, reports of configuration are useful as tools in the context of other value-adding ac­ti­vi­ties, such as the design of service systems.

Auditing of configurations

Auditing is another ac­ti­vity that is inherently non-value adding, but may be necessary, either for regu­la­tory compliance or as part of contractual obligations with suppliers of com­po­nents, especially software components. As such, it may be difficult or im­pos­sible to eliminate all au­di­ting.

Verification of configurations

Verification, like auditing, is inherently non-value ad­ding. However, unlike au­dit­ing it cannot be justified by the need to com­ply with externally generated obli­ga­tions. Furthermore, when verification is per­formed by a role that is distinct from the role of component ownership, it thereby en­shrines and per­pe­tu­ates a non-lean role. Those promoting ver­ifi­ca­tion ar­gue that individuals are unlikely to verify ob­jec­tively and in a timely manner their own pro­per­ty. This is rather like saying that a pilot should not be the person to check out the airworthiness of the air­plane she or he is about to fly. If the owner of a com­ponent does not have an inherent motivation to ensure the integrity of that property and its proper doc­umen­tation, then who else has a better mo­ti­va­tion? So the problem is not that component owners are inherently sloppy or for­get­ful. Rather, it is that people have been named as owner just to ensure that all components have owners, but there is no re­al­ity behind that ap­point­ment, no true un­der­stand­ing of what the role requires.

The fact remains that there are inevitably errors in the records of configurations. It behooves us to identify those errors, correct those errors, understand why the errors occurred and re­move the underlying causes of those errors. Whether you call this problem ma­nage­ment or continual im­prove­ment, there is no reason for imagining a dis­tinct activity to achieve the goals of improving how we work to keep con­fi­gu­ra­tions under control. The important point is that finding errors and cor­rect­ing them should be part of the mentality of every team member. It should not be considered as something per­formed by other people who specialize in finding out what you have done wrong. Thus, verification is much like quality assurance as a last step before delivery. The same ar­gu­ments about why such QA is expensive and ineffective apply also to configuration verification.

Resolving the conundrum of lean configuration management

We may summarize this dis­cus­sion as follows:

  • Attain the goals The high level goals of configuration as defined the standard frame­works are highly desirable to attain in a lean context.
  • No separate process
    However, the traditional ap­proach of independent con­fi­gu­ration management ac­ti­vi­ties and configuration ma­nage­ment roles is conducive to various forms of waste. In a lean approach, these forms of waste are to be eliminated wherever possible. A good ex­ample of this approach is a highly automated continual de­li­very method in the soft­ware development life-cycle.
  • Embed configuration ma­nage­ment ac­ti­vities The goals of configuration ma­nage­ment are achieved by embedding the necessary activities with­in other, value adding ac­ti­vi­ties and making those activities as mistake-proof as possible.
  • Empower and responsibilize roles So long as con­fi­gu­ration management is viewed as ad­mi­ni­stra­tive overhead, rather than ensuring the stability and reliability of services, the discipline will remain in­ef­fec­tive and, at the very least, inefficient. Empowerment of teams and making them res­pon­sible for improving their outcomes is fundamental for ensuring good, lean con­fi­gu­ra­tion management.

Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License The article Lean Configuration Management: A Conundrum by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Notes:

1 For example, MIL-STD-480, MIL-STD-481, MIL-STD-483. You may find a summary here.

2 I refer to the method originally described by Jez Humble and David Farley in their book Continuous Delivery.

3 Jez Humble claims to have been doing continual deployment already in 2000.

4 I have presented an overview of some of the key issues here.

5 The diagrams in this article follow pseudo-BPMN conventions. While the arrows are not really correct, I think their meaning should be clear.

Summary
The conundrum of lean configuration management
Article Name
The conundrum of lean configuration management
Description
Managing the configurations of service assets is demonstrably very useful, but would customers ever voluntarily pay a service provider for those management activities? This is the conundrum of lean configuration management. How can it be performed with a minimum of waste, when it is difficult to describe as a value adding activity?
Author
Robert S. Falkowitz
Publisher Name
Concentric Circle Consulting
Publisher Logo
Concentric Circle Consulting

Filed Under: Configuration management Tagged With: added value, aviation industry, change control, class of service, CMDB, configuration control, intangible, kanban, lean management, non-added value, poka yoke, value stream, waste

Subscribe to our mailing list

Click here to be the first to learn of our events and publications
  • Email
  • Facebook
  • LinkedIn
  • Phone
  • Twitter
  • xing
  • YouTube

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Kanban eLearning

Kanban training online

Recent Posts

  • Verbs, nouns and kanban board structure
  • The role of the problem manager
  • The Three Indicators

Tag Cloud

waste leadership cause lean management manifesto service request change management service management tools incident bias value stream risk ITSM kanban board process priority service manager kanban training rigidity knowledge work manifesto for software development lean problem tools resource liquidity knowledge management histogram incident management tools agile process metrics ITIL context switching flow impact Cost of Delay process definition automation Incident Management flow efficiency kanban
  • Kanban Software
  • Services
  • Posts
  • Events
  • Publications
  • Subscribe
  • Rights & Duties
  • Personal Data

© 2014–2023 Concentric Circle Consulting · All Rights Reserved.
Concentric Circle Consulting Address
Log in

Manage Cookie Consent
We use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage vendors Read more about these purposes
View preferences
{title} {title} {title}