Most important for building a continuous configuration architecture is first deciding on the methodology and process you will use and then picking the most appropriate tools. The idea of having a data architecture dedicated to configuration management is a principle of the IT Infrastructure Library (ITIL) service management framework and of DevOps.
A configuration management architecture spans multiple systems and applications, including services, servers, applications, and databases. It is helpful for change management — users can audit the relationships between integrated systems before configuration changes are made. It’s also a useful tool for provisioning, as you can glean all identifying information for objects like servers. When a system is properly configured, automated, and managed, you can expect certain outcomes, such as delivering continuous infrastructure as a code and configuration as a code.
In hybrid cloud environments, organizations are looking for more modern continuous integration solutions. On one side there are tools like Jenkins that are fully open source — you deploy it in your own environment, soup to nuts. And then you either own the architecture or pay someone like CloudBees to own the architecture for you. Conversely, tools like Travis or CircleCI are fully cloud SaaS. Then the tradeoff becomes how much your job environments will resemble your production environments, as well as how to bridge those gaps and assure their security.
Newer tools provide all of your orchestration, visualization, reporting, and access control functions. Also available are open-source self-hosting agents for running workloads. The ideal outcome is to get the best of both worlds, where you're able to work completely behind your firewall. You can run code on your choice of infrastructure that you want to run your production systems on, so you retain that parity, and your test environments, without also having to eat the management expense of the platform itself.
Try to give developers and engineers the tools they need to more easily build the orchestration, so they can focus on building their apps and functionality. Teams are outgrowing other solutions, either having a hard time keeping up with technical debt or just hitting limitations of the more vendor-managed solutions.
They need some next-generation tooling.