Every industry develops its own jargon, often repurposing familiar words for new contexts. In US federal government IT consulting, particularly relating to service integration and management (SIAM), these differences can lead to confusion or conflict, especially when private-sector terms meet legacy federal definitions. This article explores two such terms from ITIL and SIAM frameworks — “configuration management” and “integration” — based on my experience transitioning from private-sector IT to a Department of Defense SIAM project.

Configuration Management

The first term that generated friction was “configuration management” (CM). In my previous experience, I understood CM as the ITIL-defined practice of managing and maintaining information about the service environment to support delivery processes such as Incident Management, Asset Management, and Request Fulfillment. Change Management also aligns closely with CM as the process that controls changes to those items catalogued in the form of a CM database (CMDB). This information repository records the identities and attributes of various technical configuration items such as servers, switches, and application servers.

My DoD clients — government employees and contractors — viewed CM differently, focusing on managing product documentation, not technical systems. Their Change process was the method used to systematically control changes to those documents over the product’s lifetime. This understanding was embedded in their thinking, and the result was confusion and misunderstanding as we worked together to design the customer’s CM and Change processes.

I recall a meeting where a certain captain and I got into a heated discussion about whether the CM plan would include documents as configuration items. He and another federal consultant were adamant that artifacts should be prioritized while I pushed for focusing on technical systems. We eventually bridged the differences with the help of an ITIL-certified expert, also on the customer side, who reframed my approach into familiar terms the captain understood, and a glossary in the process guide solidified our alignment for future reference.

This disconnect stemmed from the federal origins of CM. Many of the prominent federal IT contractors spawned from large weapons manufacturers that historically built complex systems like warplanes and tanks in a multi-vendor model. Industry frameworks such as the Configuration Management Standard (EIA-649) were developed to harmonize practices across contractors in service of the government. Applied to a jet fighter, thousands of documents are produced detailing its design, construction, usage, training, and maintenance. Changes to the product meant documents to update, requiring a disciplined process to ensure the concurrence of the documentation.

In this process model, Configuration came first, and Change had a supporting role focused on documents, not technical systems as it does in ITIL. Private sector IT organizations often first deploy their Change process without a comprehensive CMDB and may never deploy a fully mature CM practice. For my DoD consulting engagement, however, our primary focus was on defining the process model for a SIAM ecosystem, and eventually the parties came into alignment on the ITIL-based goals and practices for Configuration Management.

How to Bridge Terminology Gaps

First, remember that every environment may have its own jargon. Those like the federal government tend to value continuity and tradition and may not be familiar with industry frameworks like ITIL or SIAM. Consultants should be on the lookout for misunderstandings and overloaded terms and be prepared to acknowledge existing practices while introducing the new. This can be done with steps like:

• Facilitate collaborative workshops to identify conflicts and define key terms.
• Build a shared glossary for inclusion in document artifacts and manage it as an online knowledge article.
• Provide training to stakeholders with visual aids to describe the new concepts.

Challenges aside, whether you are a consultant or other subject matter expert, embrace the new concepts and terminology as a learning opportunity to extend your understanding for future applications.

Integration

That same SIAM project highlighted another word with deep roots in federal IT industry, “integration.” As with configuration management, usage of the term in the federal sector generally meant “the process of combining diverse components of a system into a functional system”. In practice, this was often executed by multiple parties contributing hardware, software, and operational capabilities as a large project per a schedule to achieve some end state.

What I observed during my consulting was the legacy federal employees’ initial expectation of the “integration” in SIAM was to bring together multiple IT service providers into a shared customer IT environment. This might include connecting networks, onboarding staff, implementing software tools, discovering technical assets, and applying configurations to enable service delivery to the customers.

This understanding was correct as far as it went, but it largely neglected the ongoing “run” efforts to operate and improve the services as promoted by the SIAM methodology. Eventually, to extend the definition beyond project work to include sustainment efforts, I began referring to “integration and orchestration” to be inclusive of both one-time and the continuous, focused run activities.

In the context of a SIAM services proposal, one hazard of this incomplete understanding is to see a SIAM contract primarily as a project to stitch together the services from multiple providers using automation tools, networks, and data integration. Processes and AI then seal the seams between service providers to build a self-sustaining fabric of service delivery between customers and service providers.

Experience shows, however, every multi-sourced service tapestry will have weak areas and borders where the pieces don’t exactly meet. Even with the aid of AI, the efforts of real people are required to:

• Oversee process outcomes.
• Devise solutions to service gaps.
• Recognize opportunities for improvement.
• Guide automation efforts.
• Collaborate to adapt to changes in customer requirements and unexpected events.

As the environment matures over time, manual effort may then be reduced for efficiency and error reduction or reapplied to innovation and productivity improvements.

Practical Application

Remember that in the SIAM context, integration is an end-to-end lifecycle activity. When developing a SIAM transformation plan, ensure that you:

• Account for orchestration activities, like process facilitation and continual improvement, in the Run & Improve stage.
• Include key people-dependent decision-making activities, such as demand management and governance, in the solution.
• Consider the dimensions of people, process, tools, and data for all solution elements through the entire SIAM life cycle.

Summary: Navigating Terminology Conflicts

In this article we have addressed how terms like configuration management and integration can have dual, sometimes conflicting meanings in certain organizational contexts, particularly with SIAM consulting for the government. Many other overloaded terms used by SIAM exist including “operations”, “governance”, “risk”, and even “change management”, which has at least four specific meanings in the contexts of IT, systems integration, contract management, and organizational transformation. By watching for these and other conflicts and proactively aligning language—through shared definitions, open dialogue, and tailored training—you can foster collaboration and deliver value.

 

– Matt Reprogle, March 2025 – [bio]