In his Behaviorally Speaking series, Bob Aiello discusses hands-on software configuration management best practices within the context of organizational and group behavior.
While we know the technology, some configuration management (CM) experts don’t always have a strong enough business focus, which can be a real problem. Read on if you would like to understand what CM professionals need to know about business requirements and how CM can directly impact the business itself.
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.