Project Overlord
Any computer system, whether it is centralized or distributed, needs some form of governance, i.e., the act of monitoring and managing the system. Such governance may be as simple as ensuring only authorized users have access to services, or as complex as guaranteeing the system and its components maintain a level of availability or reliability in the presence of failures or increased system load. Managing distributed systems has always been a critical aspect for users, developers and administrators. As those distributed systems grew in scope and scalability, spanning multiple organizations with different infrastructures and trust boundaries, governance became more difficult but even more important.
Governance deals with the processes by which a system operates. In order to have successful governance, some form of management, monitoring and administration is required for these processes. SOA governance is the discipline of creating policies and communicating and enforcing them.
In order to govern a SOA infrastructure such as an ESB, there needs to be a framework in place that allows policies and Service Level Agreements (SLAs) to be defined, enforced and audited across multiple security and identity domains. Such a framework must be able to define policies for individual services and then either enforce them or provide means by which they can be managed and enforced by some other component within the SOA. One aspect of SOA governance that is implied by most definitions but often overlooked is the necessity to communicate such policies to users of services.
Any implementation of governance provided by an SOI should be centered on the four principles of enterprise architecture: the people involved, the processes, the technology and services. A good governance implementation needs to be supported by a hierarchical organizational reporting structure. This impacts on an SOI in several ways, with the most obvious being that the different levels in the reporting structure (e.g., developers, business managers, service sponsors etc.) need different views onto the system as services are built and deployed. Unfortunately at this stage in the evolution of the Enterprise Service Bus as a SOA infrastructure, many implementations present only a single view (the developer view) and organizations must rely on ad hoc mechanisms to cover the other cases. This inevitably leads to an impedance mismatch (translation difficulties) as managers try to understand how to map low-level details onto their expectations. Within Overlord we believe strongly that all good SOIs must eventually cater for everyone involved in the SOA development and runtime within the same environment.
Building blocks
Comments