At the moment most of the SOA software configuration management discussion is dominated by service version control issues and the use of service registries to capture change management data. Since most enterprises have both SOA development efforts and operational Configuration Management Database (CMDB) projects on the table, I suspect this discussion to expand into either a service registry vs CMDB argument or a lot of lip service to the idea CMDB must federate the service registry. The problem I see with either situation is that the real issue will be lost – the widening gap between what ‘software configuration’ is from a development perspective and an operational perspective.
Most IT operations groups do not truly grasp the full implications of applications orchestrated from individual services. The concept of an application as a software package that is installed on one or many servers as a unique working unit is deeply ingrained. In many ways, this concept still shapes the operational approach configuration, change and compliance management. As such, the operational perspective of ‘software configuration’ starts with the SOA infrastructure stack. Real SOA infrastructure contains many of software packages, including application servers, enterprise service bus (ESB), portal products and so on, each with dozens of configuration parameters. Even within a SOA suite from a single vendor, each one of these products has different installation, configuration and change management requirements.
On top of this SOA infrastructure are deployed the services, each with their individual configuration files and service registry information of varying levels of completeness. (I know what you are thinking: “why does she think there would be incomplete registry information?” Just ask your network manager about the completeness of the SNMP management data provided by network device vendors. Documentation of anything is always the last thing done with the least amount of time spent on it.) Then on top of that are the business logic files which the SOA infrastructure uses to determine the actual operational structure of the business transaction or process (aka the application).
As you see, there are many layers between custom business logic configuration files and the configuration options of IBM WAS v6.1 with Feature Pack for EJB 3.0. Yet in their heart of hearts, most operations folks are still looking to draw a nice clean boundary around some of those layers to create ‘the golden application configuration’ – the application configuration that works – the application configuration that is controlled by well known change approval processes. Why the longing for this golden configuration? Because it is the operations group that gets the angry calls when there is trouble. Configuration management, change management, and policy compliance efforts are often used when the post-problem finger-point starts to prove that the operations group was trying to prevent trouble.
However, with SOA applications the notion of a singular application configuration is replaced by a mesh of infrastructure, service and orchestration components that are individually configured. The way I see it, operations’ approach to configuration, change and compliance management is in need of transformation and developers should have a keen interest in making this transformation occur as quickly and smoothly as possible. Without this transformation, developers will be dragged into every troubleshooting incident, and it is likely that operations will use the service registry versioning tools as ‘proof’ that all disasters occurred after a software change (it is human nature to point fingers away from oneself).
But what should the new approach be?
One possibility is to mirror the enterprise’s reference architecture. Enterprise reference architectures often encapsulate SOA infrastructure which implements creation and orchestration capabilities. This leaves developers free to create new services that are ‘good orchestration citizens’ and to assemble applications (processes, transactions, whatever you want to call them) from those services. It can also simplify some of the operational configuration issues, but only if:
- Portions of this reference architecture are directly linked to ‘golden configurations’ of the SOA infrastructure.
- Operations and architects have a clear and collaborative process to refresh the reference architecture.
- There are strong development controls that prevent tight bindings where there shouldn’t be (like service bus components including business logic) which may end up as unexpected configuration dependencies in the production environment.
- Operations and developers can create a clear and collaborative processes manage deployment, versioning, rollbacks etc for services and service orchestrations.
That’s a lot of ifs – and what happens if there is no formal reference architecture? Many enterprises have organic SOA projects that have produced many web services but no unifying architecture or common suite of SOA infrastructure. It is likely that after some time organic patterns of service reuse will emerge as applications will share similar groups of services. For example all the marketing applications will use the find-logo, copyright-lookup, and acronym-generator services which all use the same SOA infrastructure suite. Therefore, one possibility is to use these service reuse patterns to drive operational configuration consistency and control.
The big if with this approach is whether operations will be tuned into this ‘architectural evolution out of organic service chaos.’ If it is the group can start streamlining and automating their configuration, change and compliance management processes around these patterns. However, this requires a significant break from past developer-operations relationships where development efforts and patterns have been visible only to development managers and operations has no clue what to do with that information even if it was available.
In either case, I think the key success factor is thinking through how SOA transforms not just the developer community, but the operations organization as well.
