Who Needs Standards, Anyway?

Many CM experts are familiar with the guidance found in the IEEE, ISO, and ANSI/EIA industry standards. But if you want to really accelerate your agile development, it is wise to learn what is involved with implementing such industry standards. Bob Aiello explains the different types of standards and how organizations go about creating them.

Configuration management consists of a number of essential best practices, without which you cannot really support agile development with DevOps, continuous delivery, or other popular best practices. Many CM experts are familiar with the guidance found in the IEEE, ISO, and ANSI/EIA industry standards, although others seem to be completely unaware of what they are all about.

If you want to really accelerate your agile development, then it is wise to learn what is involved with implementing industry standards such as those created by ISO and the IEEE.

The classic form of CM standards involves four functions: configuration identification, status accounting, change control, and configuration audit. For more information about them and others, the authoritative SEVOCAB online dictionary contains definitions and references to specific industry standards.

Configuration identification is best understood as establishing consistent naming conventions that help you to select the correct version of your code to be built and configuration items to be deployed.

Status accounting involves following the development of configuration items through development effort. I usually tell people to think of status accounting as your software or systems lifecycle; in more robust terms, we may call it application lifecycle management.

Change control is most often the gatekeeper to decide when your code can reach production. It exists in many organizations to review and approve important modifications, including infrastructure upgrades and application migrations.

Configuration audits can be physical or functional. The physical configuration audit ensures that you have the correct code running in production, while the functional configuration audit ensures that your code is doing what it should be doing.

The classic four functions are a good start, but there is a lot more to establishing effective IT controls, including ensuring that you have sufficient traceability throughout your software process. You should be able to prove that all changes were authorized and traceable to both requirements (perhaps agile stories) and test cases. Imagine someone working on a life-support system and accidentally forgetting to include a key feature!

Industry standards often require that you have a segregation of duties whereby whoever wrote the code cannot be the person to promote the code into production. Aside from being a federal law in many industries, it is also a good idea because it helps to ensure that you have more than one person who understands how to build, package, and deploy the code, addressing what is commonly known as keyman risk.

When you have a well-defined software development lifecycle, there is generally traceability between the work items that specify and authorize the work to be completed and the source code change sets created and safeguarded in your version control system. This approach is known as task-based development and is a fundamental requirement in many regulated industries where the consequences of a mistake could be catastrophic.

So, how are industry standards created?

The IEEE and other standards organizations engage experienced volunteers who work together as a high-performance team to create draft documents utilizing a variety of resources, including older versions of the standards (that need to be updated) and interviews with industry experts who offer their suggestions and best practices. Participants in a standards working group prepare presentations to share expertise and effectively educate each other.

The result is a document that is then reviewed by hundreds or even thousands of other industry experts. The standards process focuses on building consensus within the group and then with other knowledgeable colleagues.

Standards documents also are aligned and harmonized. This means your configuration management standard should be written in way that is consistent with related standards, such as testing and code review standards. Efforts are also made to ensure that standards are harmonized across organizations. For example, I have worked with ISO working groups to align IEEE standards. Being part of a standards development effort is an amazingly enriching experience that can significantly improve your knowledge and expertise.

The company you work for benefits even more because you now have the knowledge required to create effective IT controls that help accelerate your development while avoiding costly mistakes and rework. Standards-based development is also essential for many corporations, from large banks to medical pharmaceutical companies, that need to pass audits and ensure compliance with regulatory requirements. When you implement standards effectively, you are able to trust and verify that your code is built correctly from known baselines derived from documented requirements, and tested properly as well.

If you have ever required the services of an attorney, I am sure you had expectations that he or she was quite knowledgeable about case law. Similarly, you expect your doctor to know medical protocols, related studies, and best practices. I believe CM experts have the same duty to know industry standards and be able to apply them in practical and reasonable ways.

Let me know your experiences with implementing standards.

About the author

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.