Tools & Consulting for the webMethods® platform

Tools & Consulting for the webMethods® platform

Auditing for configuration management

Keeping track of changes is a critical functionality in every configuration management system. Not only for operational reasons, but also because there are legal requirements like SOX (Sarbanes-Oxley Act) that require it. This article looks at different approaches to handle things.

One of the most critical parts of a configuration management system is to keep track of  changes. Fundamentally that importance comes from two areas. The first is operational safety. Being able to trace back your steps, when (not if) something goes wrong, is crucial. The other reason are legal requirements like SOX (Sarbanes-Oxley Act).

For the implementation there are basically two ways:

  1. Feed the configuration management with data that are already audited.
  2. Have the configuration management system do the audit itself.

The first approach will usually involve a Version Control System like Git or Subversion. This has the huge advantage that it is already established in the organization and its processes. It also means that dependencies between a certain configuration item and the code that makes use of it are implicitly covered. In other words: If you check in your code change, make sure to include all relevant changes to configuration items and everything will work.

That sounds great, doesn’t it? No additional tools, processes, or organizational challenges to deal with and everything works by definition. Unfortunately life is not that easy. Here are just a few areas where this approach falls short:

  • Emergency changes: If every seconds counts to fix something, you don’t want to wait even for the best CI/CD pipeline in the world. If you have the latter, that is.
  • Non-developers: You typically have people involved in changing configuration details who are no developers. Good luck teaching someone Git just for performing a small configuration change.
  • Separate process: It is more than likely that some configuration changes (although not an emergency) need to happen outside of the normal deployment cycle. It may be an option in your organization to just adjust the deployment. But what if that is not an option?
  • Approval process: If you have an approval process, hopefully implemented in some kind of workflow tool, how do integrate that with your Version Control System or CI/CD pipeline?
  • Security: You typically have different rules and people involved for production systems vs. earlier stages (especially development). Quite often it is therefore not even allowed to have certain values under version control.

The list above, although certainly not complete, should be more than enough to convince you that relying only on something like Git is not a great idea.

So the configuration management needs to support auditing by itself as well. The detailed functionality can, to an extent, be derived from the aforementioned situations. So whenever a certain requirement or situation does not lend itself (well) to be dealt with by a Version Control System, that is already a candidate.

As a minimum the delta of every change needs to be saved, together with relevant metadata. So the old and new value, the user that performed the change, the IP address from the change originated, etc. In addition it should be possible to provide some kind of information as to why the change was done. The rational is the critical aspect here. Because we can automatically capture the old and new value(s) with much more precision than what people will usually enter. But to know the intent behind the change is really important.

If required, and you should assume that this will come up sooner or later, it should be possible to connect the audit with a GRC system (Governance, Risk Management, and Compliance) or legal frameworks like the aforementioned Sarbanes-Oxley Act.

But the possibility for integration should not be limited to GRC systems. Ticket systems like JIRA and workflow tools are just as important. And with proper APIs only your fantasy will limit the options. Experience teaches us that customers have always many more idea for connecting software than the developers who build it. So to not only have specific integrations (which are usually very comfortable to use) but a generic way for connecting is crucial.

That’s it for today. I am aware that there is a lot more to this subject than what I have covered. But I wanted to start with the fundamentals first and take it from there.

If you want me to write about other aspects of this topic, please leave a comment or send an email to The same applies if you want to talk how we at JahnTech can help you with your project.

© 2024 by Christoph Jahn. No unauthorized use or distribution permitted.



One Response

  1. Good one Jahn .
    I completely agree that a robust configuration management system should support auditing by itself and capture not only the changes but also the intent behind them. Your mention of integration possibilities with GRC systems, ticket systems, and workflow tools highlights the need for flexibility and adaptability in such systems.

    Overall, this article serves as an excellent foundation for understanding the fundamentals of configuration management, and I look forward to reading more on this topic in the future

Leave a Reply

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

On Key

Related Posts

Update connection details for JDBC adapter on webMethods Integration Server

Connections to a an external database are mostly environment specific. So they must be adjusted whenever a new instance of Integration Server gets deployed. In some situations that can be done manually, in others automation is mandatory. The tool described here can do this for you and is ideal for use in a container scenario.

Performance tuning for webMethods Integration Server

Having spent a lot of time with performance tuning on webMethods Integration Server, I wanted to share some thoughts here. They will equip you with a starting point and the flexibility to go wherever your project takes you.

Understand the problem. Truly.

If you want to solve a problem, you must first understand it. What may sound silly, is actually more nuanced than people often realize. Here is a bit more detail on this and why an outside view is often helpful.

One secret of good demos

Here is a short article on what I consider an often overlooked reason for how well software demos go and why you need to prepare hard.

CI/CD and change logs

If you release software multiple times a day, what does that mean for change logs? Here is my approach to convey relevant information to various target groups like end-users or sysadmins.