Ironically, not having governance in a service-oriented architecture (SOA) helps to underscore the actual need for such a policy. Without the presence of governance, you will, quite simply, miss some of the key tenets of what youýre attempting to do with SOA in the first place. Youýll find that you donýt have reusability of applications. You wonýt have a sufficient adoption of services, and you certainly will not have reusability of services. You will be saddled with a fragmented approach to your IT infrastructure that doesnýt allow the interoperability you were looking for at the outset.
Whatýs worse, you will create an IT quagmire that does not operate within the parameters of your business procedures and policies, which can lead to a Pandoraýs Box of problems and negative consequences.
Before examining this scenario further ý as well as how it can be avoided ý it is instructive to first offer a working definition of SOA. At its core, SOA is an approach to systems and to systems design based on distributed computing (where information is consumed by many different kinds of systems that can communicate with one another).
SOA is essentially a collection of services (functions that are well-defined and self-contained) that are intended to communicate with one another. This communication can involve a process as elementary as ýdata passing,ý or it might incorporate two or more services coordinating a specific activity. Some means of connecting the various services to each other is necessary; thatýs where SOA comes into play.
Perhaps most importantly, SOA is not a product or a system. It is a high-level business philosophy, married to a grass-roots methodology, which is meant to help users share services more efficiently ý to the greater benefit of the business and its goals.
SOA in the Real World
An instance where SOA would have been of great use but was not available is Hurricane Katrina. This terrible natural disaster was exacerbated by the fact that the government agencies responsible for providing assistance were unable to communicate with one another.
Although many agencies had information that would have proven useful to their brethren in other agencies, the data could not flow back and forth because there was no common means to allow that ýconversation.ý With a SOA in place, reusability of information and sharing of data would have been a relatively simple process ý and the rescue efforts may have proven more effective.
A critical aspect of SOA that is too often overlooked, governance is the process of creating overriding policies and procedures that regulate the use of the distributed computing system. Here is how Wikipedia, the popular online encyclopedia, describes SOA governance: ýSOA governance is a concept used for activities related to exercising control over services in an SOA. SOA governance can be seen as an overlay on IT governance, but its focus is more organizational, since services are closely related to business activities.ý
Anne Thomas Manes, a research director with Burton Group and a respected expert on distributed computing technology, defines governance as: ý[T]he processes that an enterprise puts in place to ensure that things are done ý in accordance with best practices, architectural principles, government regulations, laws, and other determining factors. SOA governance refers to the processes used to govern adoption and implementation of SOA.ý
Governance can mean different things to different companies ý thereýs no one way to do it. In the end, it incorporates whatever elements are consistent with the policies and procedures of the company that is instituting the governance initiative.
In a government organization, for example, policies related to security and access would be of prime concern. Secondary issues, though still vital, would be areas such as service connectivity ý whatýs available, when it is available, what standards are being used within it, the language being used, the schema that identifies the content, the authentication, the encryption, and the routing of the data. Ultimately, SOA governance provides optimum service quality, consistency, predictability, and performance, while simultaneously helping personnel follow the companyýs prescribed guidelines.
There are many considerations in a governance scenario, depending on the type of business or government organization. As mentioned earlier, one of the key items is security and who will ý and wonýt ý have access to certain types of information. For example, personnel in a law enforcement agency will have access to different kinds of information than would the general public. The same guidelines apply in the business environment. Customersý credit information shouldnýt be available to everybody ý just to certain departments and employees.
There are also integration issues that must be addressed in a governance scenario; language is a prime consideration. If your systems donýt employ a common language, there will be no practical way to share essential information.
In many SOA implementations, legacy systems are being connected, with service interfaces being put on existing applications to either consume or provide data. Chances are the systems being connected use different nomenclature for the same kind of data. There has to be a kind of ýmediationý piece in between: i.e., governance.
There is also a very strong need for a common vocabulary. What will the XML schema look like? How will the data silos that exist all over the agency be shared?
Governance in Justice and Security
An example of creating data standards can be found in a project undertaken by the Department of Justice (DoJ) about four years ago. The Global Justice XML Data Model (GJXDM) was created by various people and organizations that developed or used software in the law enforcement arena.
This model provided a common language so that no matter what system someone was using within the law enforcement field, they would have this ýintermediaryý piece that would allow data to be effectively shared. This was a major part of the DoJýs governance policy.
About two years later, the Department of Homeland Security (DHS) expressed interest in the GJXDM. However, that agency had a different perspective from DoJ. Where justice is a very ýpeople-centricý discipline, homeland security is more ýincident-centric,ý encompassing first-response issues, border protection, and, unfortunately, catastrophic events.
Consequently, the data model for DHS would require slight modifications; the result was the creation of the National Information Exchange Model (NIEM). Using GJXDM as the underpinning, NIEM gives DHS personnel a way to share data in a way that is more suited to the agencyýs business model while conforming to its unique policies.
Other key elements of a governance policy include:
- A failover policy: that is, an approach to dealing with the system when it fails
- Managing the portfolio of services: planning development of new services and updating current services
- Managing the service lifecycle: that is, ensuring that service updates do not cause a disruption to current service consumers
Once businesses or organizations ý primarily large enterprises or government agencies ý make the decision to go down the SOA path, it is imperative that a trip down the governance path be planned as well. The issue must be discussed internally, and policies should be constructed to explain how the SOA implementation will work. Doing so will not only afford significantly greater control over the system but will also mean consistent success rather than some arbitrary wins and losses.
But how does the governance issue really get addressed? More to the point, who is responsible for addressing it? Naturally, the IT department will shoulder a major portion of the responsibility, but thatýs just half the equation. Like SOA, governance is not, at its heart, an IT issue. Certainly IT is the execution arm, but governance is a corporate policies and procedures issue that involves every department. The purpose for undertaking a SOA initiative is to provide value based on the business requirements of the organization. Within the organization, there are people at the enterprise level who examine the business process on a daily basis. These are the people who should map out how things are done within the company, how and where data flows, and who should have access to it. Doing so will inevitably touch on multiple areas and systems. It is then possible to take that understanding of the business process and convert it into the foundation of an effective governance policy.
Who Governs the Governance?
While multiple people at the executive level will certainly provide input for a governance strategy, one person must assume a leadership role: that is, someone must take ultimate ownership of the process. But who? The title can vary depending on the structure of the organization.
In many enterprises, it can certainly be the chief information officer (CIO). Traditionally, the CIO is savvy about business and can communicate with the commercial side of the organization, understanding the companyýs mission and goals and how the SOA/governance implementation will help the organization achieve its long- and short-term business objectives.
The chief technology officer (CTO) can also be an effective champion of the cause, since CTOs often have a good working knowledge of the business but also the technical acumen to ensure that the actual architecture of the SOA/governance implementation is effectively performed. The input from the different stakeholders ý i.e., the various audiences that will have access to the system ý is required, but in the end, there must be one person who can truly proclaim, ýThe buck stops here.ý That person should be a business visionary who possesses a solid working knowledge of IT infrastructure.
What it all comes down to is the ýintersectioný of SOA and governance, where SOA is the IT side and governance is the business process side. Itýs somewhat like the beginning of a marriage: How do the two parties get married? Who does the marrying? Whoýs in the wedding party? There are a variety of ways for two people to get married, but it usually comes down to the one person who oversees the ceremony. It is a journey, not a destination, and if consensus around governance cannot be gained early, the SOA marriage will be on rocky ground from the outset and should be reconsidered.
A critical point in the governance and policy approach is to make sure that, in deploying a SOA, there is a mechanism to ensure that all ýexposedý services ý the ones that are open to all personnel in the organization or to the public ý are compliant with the companyýs established policies. There are free open-source tools that provide the ability to ensure that the services being published are actually complying with the policies of the organization. This is a part of any SOA that cannot be overemphasized.
It has been said that SOA is the new silo ý a humorous comparison that, unfortunately, is often accurate. In the end, you want to be careful not to create a SOA just to have another way to silo your information, to have it sit in a place where it is of limited or no practical use to anyone. Governance is the piece of the puzzle that will bring functionality and reusability to systems and services.
The bottom line is, itýs vital to think through the entire SOA ý including the governance policies ý before it is implemented. Because, as weýve seen in many instances, once the implementation is done, it may be too late.
Richard Tews is a strategic consultant and subject matter expert in SOA development and implementation. He helps owners of SOA initiatives establish written and automated guidelines and practices to enhance the success of their projects. He serves as director of principal projects at the engineering firm Innoventor, Inc. For more information, e-mail Rich at richtews@gmail.com.
