Today's enterprises face growing regulatory pressures with legislation such as the Sarbanes-Oxley Act, the Gramm-Leach-Bliley Act, HIPAA, the Patriot Act and others. As a result, corporate and IT governance - the processes, controls and reporting infrastructure over business and IT activities, respectively - are becoming progressively more pervasive as a means for providing the compliance infrastructure necessary to satisfy this list of complex regulations. Combine this increased pressure for corporate traceability and visibility with the "next big thing" in software, service-oriented architecture (SOA), and you have a challenging governance environment to say the least. SOA's loosely-coupled nature forces IT away from monolithic application development and deployment, and as a result it greatly increases the number of moving parts that must be managed and governed.
Corporate governance establishes business goals and objectives and the rules, guidelines and processes that must be followed by the organization when working towards those goals. IT governance, in turn, starts with establishing goals for broad IT efforts as driven by business needs and then distributes these goals to each department (applications, networking, security, etc.). IT governance goals must address the many components of the IT environment such as infrastructure, packaged applications, application development and deployment. SOA governance is one type of activity that falls under IT governance and focuses on the means by which reusable services are produced and how composite applications built on those same services are developed (i.e., how reusable services are consumed).
What is SOA governance? Governance involves the application of organizational mandates, best practices, and guidelines to IT projects, usually through a set of well-defined review
Advertisement
checkpoints (e.g., requirements complete, design complete, pre-deployment) identified as part of the organization's software development lifecycle. SOA governance gives organizations the ability to track the life of each service from architectural inception, through design and development, and finally into its deployment environment. Effective SOA governance will be the primary way that companies can establish principles for the control of their organizations.
SOA governance introduces the notion of domain ownership, where domains are managed sets of services sharing some common coarse-grained business components. For example, a team may define and develop a currency conversion service to support an enterprise's retail and wholesale sales activities (invoicing, RFQ, and so on) as well as its internal currency management operations. Such a service may be mapped to a currency management business domain within the enterprise's business domain model. These domains drive the business aspects of the IT organization's enterprise architecture. IT organizations clearly have a need to consistently apply these components to the SDLC through integrated governance processes and policies. Review checkpoints typically include both automated validations and manual role-based reviews by various personnel (e.g., architects, business analysts, security, QA) throughout the development lifecycle.
Organizations that don't apply governance processes from the architectural stage forward run the risk of ending up with a collection of point-to-point services that simply add another layer of technology spaghetti. Services need to be treated like "products," managed across multiple versions as they mature, with a closed loop communication vehicle established between service producers and service consumers. Without such governance, IT will find it difficult to advance the business because the services implemented will not effectively support multiple business processes and applications.
Proper SOA governance ensures that organizations continuously have control of their services and are communicating the status of those services across the IT organization. Corporations applying appropriate governance techniques are more likely to realize the potential of loosely-coupled application development promised by SOA. Delivering business value and flexibility to the enterprise through the definition, implementation and deployment of broadly reusable business services that support multiple business processes is the starting point from which the organization's SOA-based business architecture is derived.
I only have a handful of services. Isn't SOA governance overkill?
No! In order for SOAs to realize their intended business objectives-improved agility and reduced IT cost - organizations must always be in control of the services that are created and then used and re-used. With SOA projects just getting off the ground, many organizations today are dealing with a small number of services so governance may not seem necessary. More realistically, for these organizations governance has been implicitly occurring through heavy ad-hoc involvement from architecture and project leadership - an approach that is workable for initial pilot efforts but does not scale to support a broad-based SOA initiative. As the volume of services quickly grows, businesses will soon find themselves playing catch up, and in some cases it may be too late - an example of an organization becoming the victim of its own success.
I have a UDDI registry. Isn't that enough for SOA Governance? No! Governance is far broader that reuse through a registry, although an effective registry will provide the baseline for a governance program. A common misnomer is that service registries are solely implemented via a run-time discovery protocol such as UDDI. Remember that there are many other important registry protocols and implementations, such as JNDI, LDAP, Active Directory and ebXML, all used to support various IT activities and processes. An integrated design-time SOA registry should provide access to all available services in a way that is most useful to the software developer - presenting access to searchable information and relevant artifacts natively within the developer's IDE. In this way, the developer can quickly find, understand and incorporate candidate services to his or her development project.
Within the SOA design-time lifecycle (for both production-side and consumption-side activities), a registry specifies or points to a set of available services and their supporting artifacts (e.g., work products like WSDLs, requirements documents, models, test plans, usage guides) while a repository manages services through their full architectural, development, and deployment lifecycles. In other words, registries expose services for consumption, while repositories manage services through their production SDLC.
The integrated design-time repository/registry is the ideal vehicle for driving SOA governance. It allows organizations to manage services and other supporting software development assets (SDAs) such as components, application APIs, design patterns and the like from initial requirements gathering through design to production and consumption. The repository/registry is the place where policies are administered as new services are proposed and managed, and where the services are exposed to application developers directly within their native development environments.
Finally, let's distinguish between run-time and design-time tools. Run-time tools manage available deployed services. A good analogy is Windows registry, which is used to manage the list of installed programs and some of their configuration settings. Run-time tools not only manage access to deployed services, but also gather and present information about the performance and availability of those services, typically via integration with Web Services management and fabric tooling. On the other hand, design-time tools are used to manage and streamline the design and development of services and other SDAs. Both design-time governance and run-time management of services within an SOA are required. Design-time governance enables enterprise organizations to consistently capture, automatically deliver and apply knowledge across the entire IT organization. Run-time management ensures that the deployed services (and composite applications built to use those services) are operating effectively with sufficient performance, throughput and security to meet the organization's business and IT objectives.
The production/distribution/consumption model is core to SOA. It applies to both deployed services as well as those services under development or architectural review. Design-time governance tied back to architectural principles, best practices, and standards is the best way to ensure that an SOA will meet its intended purpose, which is to thoughtfully build out and manage reusable services that support the business.
About the Author Greg Coticchia is currently the CEO and President of LogicLibrary. He has over 20 years of experience at high technology start-ups, including executive leadership roles in strategic planning, marketing, business development, sales and general management. Earlier, Greg was with AXENT/Symantec, TruSecure, Mallet Technology, and Intraware. Greg is a guest lecturer and speaker at Duquesne University and Carnegie Mellon University and holds an MBA from the University of Pittsburgh, Katz School of Business, and a bachelor's degree in industrial engineering from the University of Pittsburgh.
Articles 
