SOA Governance Best Practices – Architectural, Organizational, and SDLC Implications
Taking the management of services to the next level
Jan. 29, 2006 10:00 AM
The fact that you're reading this article means that you are probably planning a service-oriented architecture (SOA) initiative and recognize that some level of governance is required in order to be successful. If you are like most people in this position, you are also somewhat confused as to the meaning of SOA governance. Governance is the current buzzword, and combining governance with SOA creates a phrase that every independent software vendor (ISV) wants a piece of. How do you sort out what is marketing hype from what is truly valuable and relevant to your organization's SOA efforts?
Governance Scope Within an IT Organization
However, while operational governance and management is necessary for a successful SOA initiative, it is not sufficient. For an organization to effectively define and implement an SOA (and not simply implement a series of point-to-point services masquerading as an SOA, but in fact creating another layer of technology spaghetti), it must extend SOA governance back to the development and architectural perspectives. To be successful with SOA, you must find a way to bind these perspectives together as seamlessly as possible to enable effective information flow in both directions: from architecture to development to operations, and vice versa. Let's investigate each of these governance perspectives in turn.
Design-Time (Development) Governance
How do we map these governance disciplines into an organization's structure and roles? Because of the loosely coupled nature of SOA, SOA governance is a new discipline that has implications for existing corporate and IT institutions as well as for new organizational structures and processes (and the politics associated with those structures and processes). Proper focus on what governance is, how it can be achieved, and its implementation can help make governance a valuable and necessary function to support your SOA migration.
SOA governance has an impact on current IT governance processes. Some of these processes include the budgeting and project approval process, portfolio management activities, and ongoing oversight of projects to assure budgetary compliance. Applying governance to SOA activities is critical because there may have to be changes to the normal IT governance processes for budgeting and portfolio management.
Think about the budgeting process of your organization. That budgeting process has a tremendous impact on the behavior of various organizations and their IT representatives. If there is no budgetary control of projects to influence them to adopt SOA and reusable services as their fundamental design concepts, then projects will go their own way as driven by the requirements of that particular business unit or project. The same goes for the portfolio management process. If there is no mechanism to surface SOA and reuse opportunities for all projects and then apply budgetary pressure to converge them toward an SOA, then they will similarly go their own way. SOA governance, budgeting, and portfolio management are ways to influence behavior of business units, as well as the IT and business personnel within them, to more aggressively support SOA and reuse.
Enterprise architecture processes may undergo similar changes given the advent of an SOA initiative in an organization. Often the architecture process and organization will have to be restructured to accommodate the requirements of an SOA initiative because the skills, roles, and functions of an EA team are not completely appropriate for an SOA initiative. Think about the process of architecture as two tiers of activities: one tier is the architecture strategy and goals, followed by the definition of the elements, standards, and organization of architecture to accomplish those goals. The second tier is the application of architecture to funded projects, the acquisition or implementation of various technologies and standards, and the enforcement of compliance to the enterprise architecture goals (see Figure 1).
These are two related yet distinct processes, and often they are not as interdependent as CIOs would like. Think about the cases where there is a chief architect or central architecture group at corporate headquarters, and then also present are the solution architects assigned to projects. They actually build systems and implement technologies and standards. Who has the most direct bearing on the architecture that ultimately is implemented in a given organization? Naturally it is the person assigned to the budgeted project that was sponsored by a specific business unit that ultimately funded the project. The behavior associated with enterprise architecture is similarly related to the organization and processes used to achieve the goals of SOA, architecture compliance, portfolio management, and budgetary compliance.
Reader Feedback: Page 1 of 1
Latest AJAXWorld RIA Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week