Governance applied to SOA, SaaS, BPM, ECM, etc.
Governance is one of those terms, which when applied to IT tends to mean different things to different people. SOA Governance, for example could refer to policy management, design repository processes, quality control, and even development methodologies. Wikipedia provides the following definition of SOA Governance:
“SOA Governance is an emerging discipline which enables organizations to provide guidance and control of their service-oriented architecture (SOA) initiatives and
programs.”
That’s pretty broad, but what does that mean in practice? First, to set the context a bit, I think of Governance in terms of not just SOA, but also any key IT initiative used to support the business from a technology perspective and solve real business problems, such as SaaS, BPM, ECM and others. “Guidance and control” of prevalent IT methods sustaining the business is indeed useful and appropriate.
With the awareness of the key initiatives taking part of the “guidance and control” identified, next it’s helpful to understand where governance can be applied in the lifecycle of an IT solution providing a benefit of some kind. Two distinct points in time exist along the lifecycle with different tools and methods applied at each. They are design & implementation and production.
Governance at the design & implementation stage requires the definition of policies to be enforced by consumers of services and processes. An integrated registry/repository that manages a service or process from design through to production deployment is a useful tool. Tracking design, security, policy, implementation and testing artifacts is all part of the governance at this level. Design tools such as service modeling, business process management, dependency tracking, code profiling, policy creation and others assist in the design of services and processes, and are all part of “guidance and control”. Some environments supply links to testing results, tools and services as well as the test planning and scenarios. Modeling tools help with defining the underlying data schema, maturing it into metadata, abstracting the data, and from there defining the services that interact with the data, data services, and then transactional services and from there orchestrating processes and creating the end-solutions. All this occurring with design time information managed within the design time governance system.
The deployed production environment requires guidance and control as well. This involves process enforcing runtime policies such as availability, service levels, managing errors/exceptions, upgrades/versioning, security, auditing/logging, capacity monitoring and planning. Other policies may include service discovery and delivery to mashup or composite solutions.
With a proper understanding of where governance can and should be used, an appropriate amount of “guidance and control” can go a long way. The caution I’d apply to the equation however is that it’s possible to have too much governance, i.e. where the overhead outweighs the benefits. If an organization isn’t working with SOA or other modern IT disciplines such as SaaS and BPM, or perhaps is merely scratching the service of these principles, advanced governance is probably not in the cards just yet. The key is to understand the benefits and track them along the way and ensure IT has people who understand governance as a mechanism to control and drive the right policies and management around the solutions that are being managed (at both the design and production stages).