What CM Professionals Need to Know about Business Requirements

Configuration management (CM) has always been a particularly technical endeavor. Software engineering professionals who focus on application build, package, and deployment are obviously folks who don’t mind getting into the details of how things really work. One of the most enjoyable aspects of being a build engineer is that you often get to assemble all of the components, building each in turn, and deploying the finished product into QA, UAT, and production. This holistic perspective gives CM gurus a uniquely wide scope and understanding of the system, whereas many of our colleagues only get to focus on one particular aspect of the system. While we know the technology, some CM experts don’t always have a strong enough business focus and this can be a real problem. Read on if you would like to understand what CM needs to know about business requirements and how CM can directly impact the business itself.

Business leaders have a tough job. The global corporate environment has many challenges and can be difficult to navigate. Yet our senior managers must always assess existing conditions and help steer the ship in the right direction. I have always been a technical guy, although with a strong interest in industrial psychology, including human factors and process improvement. Recently, I participated in a business continuity simulation with a group of colleagues connected with a large New York City-based financial services firm. Each of us selected roles from help-desk technicians to service delivery managers as part of this exercise. I selected being the end-user business representative. This was very different than my usual role and allowed me to consider how our business leaders operate and manage incidents, especially from a disaster-recovery perspective. Throughout this exercise, I focused on considering the requirements of the business and what my options were for meeting our needs from a global business perspective.

Many IT shops are highly siloed with database administrators (DBAs) and Unix administrators often operating within their own worlds, seemingly cutoff from our development colleagues, writing the systems that we will be deploying and supporting to run the business. DevOps puts the focus on breaking down the barriers between development, QA, and operations. But, we also need to understand that technology itself is too often siloed from the business folks using our systems. IT professionals need to consider whether or not our systems are “fit for purpose” and “fit for use.”

The ITIL v3 framework does a great job of explaining these concepts. Fitness for purpose refers to whether or not the application meets the business requirements as designed. Fitness for use takes this a step further by considering whether or not the system will meet the agreed upon level of warranty. As CM professionals, we need to consider whether or not the system meets the requirements necessary to run the business. My colleague (and mentor), Carl Singer, discusses this issue in his recent article, “Why Good Design Is Important in CM.” CM also plays a vital role in developing both business and technical requirements in several ways.

Requirements need to be under version control because just like any other configuration item requirements tend to change over time and may be different for a specific release (e.g. bugfix). Traceability is essential (especially in industries that are regulated, such as banking or high-speed trading) as well as good CM tools and process-enabled traceability between requirements, related test cases, and the source code changes made to implement these features. CM also helps the entire team to understand requirements through rapid iterative programming, such as is common in agile. In case you forgot, some folks also practice waterfall in an iterative fashion, which is how it was envisioned by Winston Royce and described in his original paper. But there is something that is even more important about how CM enables business requirements and that is the cognitive process of designing requirements itself.

It is often very difficult to envision how a system will be used. I recall one situation in which I suspected that the business users were not communicating effectively with the developers. I asked the business liaison to spend an hour with me writing test cases. We simply wrote down what we were going to test and what we expected the results to be. Within that first hour, the business representative picked up the phone and called the head of development and said to him, “What I have asked for is not what I need and I just realized that as I was thinking about how we would test the system.” By asking this gentleman to write test cases with me, I caused him to go into an active mode of thinking where he realized how the system really needed to work. Now my role in that company was to build, package, and deploy the code. But I was perfectly willing to help out with developing requirements, test cases, or anything else that would help get the job done.

Configuration management is a full lifecycle endeavor. We help create, track, and control requirements just like any other configuration item. We rapidly build, package, and deploy code to facilitate iterative development, which is inherently a more productive approach to software development than trying to design everything upfront (as is sometimes attempted in a non-iterative waterfall lifecycle). But we also need to help the team envision how the system will work from a global business perspective, and we always need to remember that we are part of the business and a full participant in the efforts that bring profitability and success to the entire organization.