What is Governance?
The first question on considering what sort of governance is required is what governance exactly is. The OASIS SOA Reference Architecture Foundation outlines governance as:
Governance is about making decisions that are aligned with the overall organizational strategy and culture of the enterprise. [Gartner] It specifies the decision rights and accountability framework to encourage desirable behaviors [Weill/Ross-MIT Sloan School] towards realizing the strategy and defines incentives (positive or negative) towards that end. It is less about overt control and strict adherence to rules, and more about guidance and effective and equitable usage of resources to ensure sustainability of an organization’s strategic objectives. [TOGAF v8.1]
Now this doesn’t necessarily help in understanding what Governance actually is. The question of governance is at one level easier to determine by what governance isn’t.
Governance is not about Requirements – Requirements is "specifying" and needsto be governed Governance is not Design – Design is "doing" and needs to be governed
Governance is not Coding – Coding is "doing" and needs to be governed
Governance is not WSDL or XML – These are artefacts that need to be governed
Governance is not a registry – This is a Tool not an answer
The point is that Governance is not about the doing of elements of IT, it’s about the direction of those elements and ensuring consistency. Thus Governance is about decisions and enforcement at all levels rather than about taking active control.
The objectives of Governance
If the objective of SOA is to have an IT estate that looks like the business, is managed like the business and evolves like the business then Governance needs to be focused on that goal. This means looking at SOA as part of a transformation program and setting up your governance to focus, drive and ensure that goal and not simply to ensure consistent use of technologies.
The challenge of transformation is that you are requiring people to work in different ways, you are not going to change all of the people and you are not going to change all of their historical views. The previous generations of IT systems will continue as will the learned behaviours of IT and the business. Thus Governance needs to be transformational to be successful.
Machiavelli and IT
Machiavelli’s "The Prince" talks of the challenge of taking over another city or principality and offers three choices for governing the new province
- Ruin them
- Reside there in person
- Permit them to live under their own laws, drawing a tribute, and establishing with it an oligarchy which will keep it friendly to you
Now the analogy for IT for these choices really map down to
- Green field replacement
- Centralized governance structure emplaced from the top and empowered by the business
- Cope with the mess and drive the cost down by having the CIO report to the CFO
Assuming that our goal here is to deliver transformation and that a green field replacement is the pipe dream that it normally is then our option is left down to a centralized governance structure which comes down from the top and is clearly seen as representing the business objectives.
The types of governance
Governance occurs at multiple levels, it is not right to consider governance as simply being one thing which will solve everything. Governance differs based on the place in the transformation lifecycle and on the type of thing being governed.
A single governance framework is not going to cover all of these areas, the important element is that the different governance elements are consistent and aligned to the overall objectives of the transformation. While this appears complex it is just about more formally codifying the governance elements that already exist and putting them in the right order.
If the objective is to move towards an IT estate that looks like the business, operates like the business, evolves like the business and is cost in line with the business value it delivers then all aspects need to become Service-Oriented.
Timeline for Governance
Rolling out Governance across an organization means understanding what the objectives of the governance are. Without a clear statement of the objectives and vision for the transformation towards SOA from a business perspective, the benefits from any effort are liable to be to be ill-directed or limited just to the scope of IT delivery.
The second element is making sure that the operational shift of IT in particular is made towards that vision. This provides the firm basis for the transformation and ensures that as the transformation is rolled out that it is moved into an operational environment which matches that vision.
Without Operation becoming service-oriented and aligned to the vision, any transformation will ultimately fail.
Governance for Business SOA
Having established what governance is not about, the next stage is to establish what will be accountable in the various different areas of the business and IT transformation. It is important to recognize the difference between the creation of standards and the enforcement of those standards. As with the overall vision, this is not in itself an act of governance - it is merely the job of governance to enforce that vision. To understand how governance needs to work it's worth considering a broader system and understanding how this works.
The Federal Model of Government
In the US system there are four branches of government. The Executive, the Legislative, the Judiciary and Dick Cheney.
- The Executive controls the army and the other branches that "do" stuff
- The Legislative defines the laws
- The Judiciary enforces the laws
- Dick Cheney makes up stuff about terrorism.
The Executive actually does the work and must "take care that the laws be faithfully executed," and "preserve, protect, and defend the Constitution". In other words, the executive is not itself responsible for creating the laws, but is responsible for ensuring they are effectively applied. From our governance model this is important as what we are interested in is the application and enforcement of laws. The executive are people doing things.
The Legislative is the body that makes up the rules, it signs off on the executive appointments and decisions and generally creates the framework under which change can happen. From a governance perspective this is important as it is these rules which will underpin the transformation and define the measures against which success will be tracked. The point to note is that the legislative branch works before the rest of the work is undertaken and thus sets out the framework.
Then we have the Judiciary: these are the folks who take the law and enforce it. From a governance perspective these are the people who decide whether a law or standard has been correctly applied, and are able to change decisions or even enforce discipline if there have been violations.
Finally we have Dick Cheney. Dick is one of those people who feels, like organized criminals, that the law doesn't apply to them. The problem is that people like this really do add to the complexity of a society as they break the rules by considering themselves above them. From a transformation governance perspective these are the people who think that they can just go and do whatever they want and are not accountable to anyone. It is very important to identify if you have any Dicks in your organization that will upset the transformation.
The states
The other point about the federal government system is that while the highest level defines the overall structure, it should not concern itself with elements that are specific to an individual state. The model here is that the overall structure for governance provides the laws which the states must obey but enables them to create their own rules that are specific to their domain as long as they do not violate the higher level rules.
For our governance model, this equates to letting the various sub-areas create their own policies and governance structures.
Process
The process of establishing firm governance is one of organizational change which means it needs to impact all aspects of an organization and the way that it approaches things. In the same way as the legal framework in a country sets out how people should work and behave so should the governance model for an organization.
Creating the vision
Getting the vision means having a clear service-oriented business architecture - this provides:
- The future business structure that IT must deliver against
- The KPIs and metrics against which it will be measured
- The business owners for the various business services
This business service architecture is the overall destination for the transformation program. This represents the first key artifact that has to be governed.
In order to create the vision and thus the business service architecture, this requires the various parts of the organization (both IT and the business) to assign a group of people to create the vision. This group thus becomes a legislative body. Their job is not to deliver the change but to define the structure, architecture and rules against which the transformation will be measured.
The Business SOA Judiciary
The objective of Business SOA Governance is to ensure that the business architecture is delivered.
At the transformational level the SOA judiciary, the governance organization, has the role of ensuring that business services and capabilities are delivered correctly. This means ensuring that:
- Business services and capabilities are clearly realized
- Ensuring that people are using the right business services
- Ensuring that rogue services are not developed
- Pollution doesn’t happen through tactical decisions
- That funding is shifted to align with the model
It is also the body that acts as the escalation point for lower level issues. The members of the transformational governance group need to be directly empowered by the legislative but ideally are made of people who are more focused on the correct application of the rules than in self promotion.
The job of the judiciary is therefore about the borders between services and does not concern itself what those services do internally.
Policing the border
The US system has a concept of federal vs. state responsibility and this model works really well in the business world. Being simple, there are some things that make sense at an enterprise level but behind those boundaries it really is up to the given business unit to decide the right way to work for its own business.
The point here is that there needs to be clarity on what the dependencies are between areas and therefore what is required for them to succeed, but how they choose to deliver these capabilities is not actually important. From the business service model above it's important that Finance provides a way for Sales to Bill the Customer, but how that customer is actually billed is of no interest to Sales.
What this means is that end-to-end design isn’t important, it’s about the specification of interfaces at a level which describes
- What capabilities the Service offers
- What the contract is for each capability (pre-condition, post-condition, ordering, etc)
- What SLA the service offers
The objective of the judiciary therefore is not simply to ensure that a given area delivers its business services to the right specification - it is also there to ensure that one area doesn’t care about the internals of another. This is important as it ensures that you don’t get implicit dependencies.
Constructing the Judiciary
The Transformational Judiciary is thus focused on business architecture and not on the technical standards or infrastructural elements. This means understanding and enforcing both the architecture and the financial transformation which will underpin the end result.
Business Architecture
Ensures the right area is delivering the right capabilities. Works at the business level understanding and looks at the long term viability and stability of decisions. The Business Architecture governance ensures that the structure laid down by the Legislative is rigorously enforced. These are the people who are normally closely allied with a given area of the business but are extracted into the judiciary to ensure that everything remains clearly aligned to the original strategy.
Good business architects should have a strong understanding of their business area and be able to clearly identify situations where that specific area or something it relies upon is not functioning correctly. Good Business architects must have very strong communication skills and be seen within the business as people that are empowered to make decisions and who have the personality to ensure those decisions are enforced.
Financial Control
Part of the challenge of driving single use of services and ensuring standardised delivery is that often the long term aspects of financial accounting are overlooked. Simple elements like who funds a capability can break programs, and the long term accounting of use against the consumers of a service is what marks a change from traditional project accounting into a more business aligned financial structure for IT.
This is not a trivial task and is an integral part of a long term transformation of IT. Rarely however do people look to the long term financial changes of shifting IT from a Capital Expenditure (CapEx) and Support model into a true Operating Expense (OpEx) model. Governance must include the management and enforcement of the changing financial models.
What Business SOA Governance decides
Business SOA Governance decides whether programs and projects are implemented in-line with the overall business architecture. They then look at whether the transformation being delivered by the program or project will result in the financial model for that area improving in-line with the business architecture and whether there are more effective ways for elements to be delivered.
The Business SOA Governance group will make decisions as to when a program is seeking to develop a capability that would be better delivered elsewhere or where they are failing to re-use a capability that already exists. This group therefore has sign-off on all projects and programs from a business perspective, if they do not get this sign-off then it needs to be made apparent that a given project or program is not part of the overall transformational program but is a tactical project which is expected to increase the total cost of the transformation.
From Business Into Operational SOA
The next stage of a transformation is to realign the current Operational approach against the future target state. This will tend to involve a re-organization of the IT staff, changes of management and, through the use of the business architecture, the clear identification of the business owners in each area. This transformation can take a significant amount of time depending on the current organizational structure and measures but ultimately the objective is to be able to ensure that any future operational decisions and change is done in line with the overall vision.
From a process perspective, using the latest Information Technology Infrastructure Library (ITIL) v3 framework represents a very solid foundation to establish this operational shift for the organization. With ITIL acting as the underlying processes and framework and the individuals, objectives and goals aligned against the overall business service architecture, this helps to ensure that operational governance through ITIL is aligned with the overall business architecture.
What Business SOA Governance decides
In Operation the Business SOA Governance body decides whether the new operational structure meets the overall business architecture objectives. It thus has sign-off on the staff re-organization and whether the right business owners have been assigned to the right business services. The Business SOA governance group also acts as the point of escalation for change requests and BAU changes which are considered to be polluting a given business service area as a result of local tactical decisions.
Delivery & Technology SOA Governance
The final aspect for governance is changing how new deliveries are undertaken and what the technical decisions are that need to be made. This is in itself a large area and works at ensuring that the business services when realized will utilize the right technical standards in a way that promotes single use development and reduces the total cost of ownership. From a governance perspective this area is primarily focused on Program Structure, Delivery methods, Technical Standards as well as Testing and Verification
Program Structure
A key change in delivery is to move away from application development towards Service-Oriented Development. This means that delivery teams are aligned against the services that they are developing rather than against application silos. This means that how programs are established must be changed and the manner in which releases and other elements are structured. Governance in this area is about ensuring that the underlying principle of service-oriented delivery is applied and that application-centric delivery is avoided.
Delivery Methods
Delivery Methods governance is about having a standard approach to delivery which enables services to be clearly documented and delivered and to be easily identified and managed as they transition into operation. Governance in this area is about enforcing the standard delivery methods and ensuring that the right deliverables are created.
Technical Standards
Technical standards ensures that everyone is working in the manner laid down by the legislative. This is about making sure that the interfaces technically meet the standards laid down. These are the XML police, the Schema librarians and generally the folks who ensure that everyone is talking the same technical language and that any changes to that language are rigorously policed. The focus of the technical standards is at the specification and design time of the lifecycle.
Testing and Verification
This isn’t UAT or System/Integration testing, its about the borders. This is the group that checks services for compliance at the border. It verifies that the services functionally deliver what they say they will do. In a technical delivery these are the bits that verify the on and off ramps for the service.
These are the border control agents of the judiciary. They ensure that an operational service meets its obligations, both before initial deployment and during operation. They also ensure that anyone who is trying to invoke a service obeys their obligations, for instance clean data, or bans them from entering into the exchange.
Testing and Verification is often overlooked in a transformation program or considered just simply part of integration test. Integration test makes sure things work together end to end (including the ether) but it often has challenges when things go wrong in pin-pointing where the actual error has occurred. It is the job of Testing and Verification to ensure that blame is accurately attributed.
What Business SOA Governance decides
In Delivery and Technology the Business SOA Governance body decides whether the new program and delivery approaches will meet the overall business objectives. It is also the group that will need to approve the proposed technical standards to ensure that they will meet the long term objectives of the organization. The operational governance group will also need to sign these elements off to ensure that they can transition them from delivery into operation.
With the Business SOA Governance group already deciding whether a program is correctly structured against the business architecture, it is the goal of the Delivery and Technology governance groups to ensure that this original structure is directly realized with the program. The Business SOA Governance group then has a role during the lifecycle and UAT to continually ensure that the delivery and technical governance is enforcing that original business architecture.
From Dick to Disaster
The final part of the problem is what to do about Dick. Every organization has individuals or groups which seek to break the rules or create their own rules by having individual "interpretations" on the rules. Often these individuals can have significant amounts of power in an organization and it is at this stage that you really find out whether you have a strong governance model or just a thin veneer or governance overlaying an inherently chaotic and ill-managed environment.
The Dicks in your organization are the ones who will propose using new standards rather than complying with the corporate approach. Excuses will be made about "local" optimizations or even worse a claim will be made of compliance when quite clearly there is no compliance to be found.
The point about Dicks is that they don’t really care about the overall transformation they just care about their specific viewpoint and in ensuring that this is driven in their area, and beyond, no matter what the impact will be.
Dicks might be the guys using WSDL 2.0 when you’ve agreed its WSDL 1.1 and WS-I Basic Profile 1.1 that you are using. They could be the guys "going agile" and not documenting their services to the level required by the enterprise. They could even be the business guy who plays golf with a vendor and agreed to buy a big raft of new software that doesn’t fit the organizations strategy at all.
The reason that Dicks bring Disaster is enshrined in the Mythical Man Month that architectural consistency is more important than individual optimizations. Business SOA Governance is there to ensure the consistency and prevent Dicks creating Disasters.
Summary
Business SOA governance is about the long term transformation of IT to align with the business. This means establishing a clear business architecture which represents the "to be" state of the business and then creating a business SOA governance group who will ensure that future programs and operations are aligned against that vision. This is a powerful group and needs to act in the same way as a judiciary. Their role is not to undertake the work but to enforce the boundaries and rules.