Oracle Fusion Middleware and SOA Products and Solutions

Ashish Mohindroo

Subscribe to Ashish Mohindroo: eMailAlertsEmail Alerts
Get Ashish Mohindroo via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Oracle Journal, SOA Best Practices Digest, SOA & WOA Magazine


A Guide to Ensuring the Success of Your SOA Governance

Where to start? How much is enough?

SOA is continuing to gain widespread adoption and find success beyond pilot and project implementations, according to recent surveys. There is a steady increase in organizations moving to enterprise-wide SOA deployments. Those that have found success maturing to large-scale SOA have one thing in common: they all have effective governance practices to keep SOA on track with the business.

But what is SOA governance? Every organization seems to have its own definition, and one thing SOA governance is not is a discipline separate from existing IT and enterprise architecture governance. It's an extension of existing governance disciplines that adds additional elements or considerations that are specific to a SOA environment. If an organization has good governance practices in place already, its SOA governance will follow suit. However, the converse is true as well. If an organization has non-existent or ineffective IT governance, SOA governance won't fare much better.

What's required to establish an effective and successful SOA governance program? Technology alone can't solve a governance problem. In fact, governance is more about the people than anything else - not controlling their actions, but fostering behavior that's desirable. That's why most organizations that are successful with SOA governance incorporate a balance between people, process, and technology.

A Guide to SOA Governance
When it comes to SOA governance, there's no magic bullet or cookie cutter solution; every organization has unique characteristics and is at different points within its SOA maturity. There are, however, key best practices that are common in design that have found success across multiple organizations. While this article isn't a comprehensive guide to everything SOA governance-related it does focus on some key best practices that warrant consideration by any organization attempting SOA governance. Many of these best practices are addressed early in the formulation of the governance framework itself.

Properly establishing a governance framework from the start will result in a more effective governance program longer-term. As stated earlier, SOA governance is not a separate, unique silo of governance. It's a natural extension of the existing IT and enterprise architecture governance practices that most organizations already have in place. When establishing a SOA governance program, leverage the existing governance disciplines and augment them with the best practices (outlined below) to ensure a successful SOA governance program.

Know Your Business
One of the most common reasons organizations struggle to move their SOA past pilot projects to a more enterprise-wide scale is failure to align with business objectives. SOA is an architectural discipline or approach to solving a business problem. Piloting your SOA program on something deemed an IT benefit does little to show the business value it will bring to the table.

For example, a large financial organization struggled to get new products into production in less than six months. However, every six to nine months, the regulations that governed their product offerings would change, providing little opportunity to capitalize on and optimize revenue streams. The business needed a way to get to market faster, so they predicated the investment necessary for SOA on the idea that it would decrease their time-to-market for new products by 50%. This established immediate alignment between business and IT goals and set the basis by which their SOA and SOA governance programs would be formed.

SOA governance is based on the need to have continuous alignment between IT and business. All other factors of a governance program will be responsible for enforcing that alignment. Without a base understanding of and alignment with the business, it's difficult to establish the proper parameters for the governance program beyond base IT policies, such as WS-I compliance. Knowing your business will better align the business case surrounding SOA and provide direction on how the governance program needs to be established.

Define Key Metrics for Success
A key element of successful SOA governance is identifying and defining key metrics for measuring success. In the customer example above, the overarching measurement of success was to reduce time-to-market for new products by 50%. These overarching success factors, however, must be broken into measurable milestones. Begin by breaking down how the overall business benefit will be achieved and establishing milestones for measuring progress. As these are established, the process around how your SOA will need to be governed will begin to take shape.

Measuring achievement of the macro and micro success metrics has two major benefits. The first is that measuring the micro-metrics (key milestones) provides visibility into the progression and evolution of SOA as well as ensuring continuous alignment with the business. The second major benefit is that it supports the business case for continued investment. For example, the financial services customer mentioned earlier was able to realize a measurable 70% decrease in time-to-market, resulting in greater investment from the business for continuing the SOA program.

Once key metrics are identified, it's also critically important to understand how they'll be measured. Simply knowing what the key metrics are can drive governance decisions, but part of the governance program should also be to help measure the achievement of those key metrics. This is greatly supported by identifying the proper process and procedures for measurement, but may also require investing in software that aids in surfacing key metrics.

Create a Communications Plan
Communication is the most underrated, and overlooked, key to SOA governance success. The term SOA governance tends to evoke feelings of Big Brother controlling one's actions, which, in most cases, will be resisted. The best way to overcome this resistance and encourage adoption is to involve those that are affected.

Create a communications plan that keeps the entire community informed of the goals of the SOA program, why SOA governance is important, how it's to be applied, and what impact people can expect in their work. Make sure to communicate what metrics have been defined for success and results of maturity assessment. It helps keep everyone educated about the purpose of SOA governance and its goal of maintaining alignment with the business.

Education, however, is not the only charter of a good communications plan. The other aspect, and most overlooked, is the ability to encourage and reward. Communicate successes with the governance program and the impact that success has had on a project or the bigger picture. Establish rewards for those that follow the governance process and communicate receipt of those rewards to encourage others to follow suit.

Define a Reference Architecture
Remember that the "A" in SOA stands for architecture. Establishing a reference architecture upfront is a key characteristic of any good SOA governance model. A SOA Reference Architecture, as in Figure 1, defines the target architecture and the principles to be used by an organization's architects to make architecture and design decisions on their projects. It should include guidelines and multiple views, derived from viewpoints addressing the concerns of many stakeholders (not just other architects). These guidelines direct architects and designers how to implement the architecture principles in given scenarios. They should drive convergence to the reference architecture over time. A result of this effort will be the establishment of discrete policies that can be enforced at various stages of the lifecycle to ensure compliance with established business policies and identified standards.

A reference architecture should also include a defined set of relevant IT, industry, and enterprise standards; along with a glossary establishing a common vocabulary with which to discuss a particular problem space and relevant solution(s). When analyzed alongside the identified milestones, a clearer understanding of investment decisions becomes possible. At this point, the overall foundation for how governance will be applied is established. The next steps are to assess the organization and identify what should be governed.

Assess the Organization
Assessing the organization is important to get an understanding of where its SOA maturity resides. Mapping the organization to a maturity model as in Figure 2 is essential to understanding where the focus of the governance program must reside. This is not a one-time effort, however. The organization should be reassessed at each macro-milestone to determine where adjustments in the governance program need to be made. As SOA evolves, so too will the governance program. Priorities and efforts will shift as SOA becomes more mature in the organizations, and as such, the governance program will need to shift its emphasis on what needs to be governed and where.

Identify What Is to Be Governed and How
Identifying what is to be governed is a key element of any successful SOA governance program. Identify what is most critical and important to accomplishing the goals of the SOA program and establish how rigid or flexible the governance needs to be. Does everything need to be governed down to each line of code or can development teams be given some flexibility so long as they abide by certain standards? For example, requiring that each service be WS-I 1.1-compliant may be important to your SOA if your reference architecture depends on WS-I for interoperability.

Likewise, certain business policies driven by government regulations drive the decisions around what is to be governed. Data privacy laws, for example, dictate that no external entity has access to personal information. Therefore, policies must be put in place so that services accessible to internal and external parties provide a mechanism for scrubbing a customer's personal information if a request comes from the outside. And appropriate auditing tools must track compliance.

While some of "what is to be governed" is mandated by business policies, others, such as WS-I compliance, are standards IT simply wishes to enforce. This step is critical, however, for establishing the basis for how SOA projects will comply with the architectural standards and policies as part of the reference architecture. The identification of the rigidity and flexibility of what is being governed is enforced through established processes and policies. Policies tend to be the crux of "what is to be governed" as things like WS-I compliance and data privacy compliance are considered policies of the governance program. Processes are put in place to ensure compliance with those policies.

The process element is where the rubber meets the road. Governance, after all, is a process. For organizations with established IT and EA governance, processes will already exist that can simply be augmented with SOA-specific activities. These processes may or may not be automated, depending on your organizational culture and requirements, but in most cases, organizations have a mix of automated enforcement and manual compliance reviews.

For example, it's a best practice to establish a project justification process. This is a review of the business case surrounding a business application, the investment needed, etc. In most cases, this is a manual review done by the governance committee. Furthermore, a design review may be necessary to ensure the project is being designed in compliance with the reference architecture and reuse is occurring where possible. These two processes together, while described at a high level here, result in much higher rates of success and investment justification.

Create Incentives
Gaining adoption of SOA governance processes isn't without its challenges. Most organizations will encounter resistance to the governance process without an incentive program to encourage their participation and compliance. Most adopt some element of the carrot-and-stick approach to incent their organization to adopt governance activities. Organizational culture typically determines how much carrot and how much stick to apply.

Some organizations choose a pure stick approach. One customer in Europe chose to make compliance with the governance process a mandatory part of everyone's MBO. Essentially, an employee may hurt his chance of a bonus or continued employment if the process wasn't followed properly. While this approach works for this particular company, it's not typical. This approach can be demoralizing and discourage understanding the true value of governance. Gaps in the governance program that need correction can also be difficult to identify for fear of stepping outside the bounds of the established system.

Some organizations choose the carrot approach. One customer in North America uses a rewards program for complying with various aspects of its governance program. Much like a credit card reward program, development teams and individuals earn points that can be turned in for gifts, such as an iPod or iPhone. This is often a fairly successful approach since it fosters a competitive environment between teams to see who can make the most points. The drawback is there are few penalties for not being in compliance.

The best case is to provide a mix of carrot and stick. Another organization in North America uses funding as its carrot and stick approach. The teams that follow the process correctly are assured of continued funding for their projects; those that don't aren't. This approach provides the most flexibility. Projects that find gaps in the governance process that prevent them from accomplishing their goals can state their case. This often leads to needed adjustments in the governance process that may not have been identified otherwise.

Whatever incentives an organization chooses to offer, they must be well communicated. An understanding of what rewards and penalties are at stake encourages adopting and following the process.

Identify Technologies for Automation
While technology by itself can't solve a governance problem, it's one of the more essential elements to establishing a successful program. The technology used in SOA governance is there to simply automate as many of the governance activities as possible. Automation not only makes it easier to enforce and track compliance, but it also creates a non-disruptive mechanism for applying governance to those that are being governed. The more invisible and seamless the technology elements to the governed are the higher probability of adoption.

When looking for what technology elements are right, start with where the pain is biggest. For example, if it's simply visibility of existing assets and their dependencies, start with technology, such as SOA management, that provides visibility and discovery capabilities for existing assets and their relationships. If the biggest pain is having a central location for asset visibility to encourage reuse, look at a registry/repository. However, when determining what technology to use, focus on components that provide the most automation for your organizational processes and address the SOA lifecycle from end-to-end.

Key to the technology foundation for SOA governance is a registry/repository. This is the nucleus of the governance program because it provides complete visibility into the SOA portfolio. The best registry/repositories will provide complete visibility of all assets and their relationships to each other, from consuming applications and processes all the way down to the back-end legacy components, not just services.

Other components of SOA governance technology include:

  • Validation and testing suites to ensure compliance with architectural design policies as well as testing of policies enforced at execution to ensure proper compliance
  • Policy management tools for automating governance compliance through management and enforcing policies across the lifecycle
  • Provisioning tools for managing consumption and deploying services under established usage agreements
  • SOA monitoring for continuous monitoring of operational behavior for service-level assurance and closed loop feedback for complete visibility and control

Implement Incrementally
Finally, take a pragmatic approach to SOA governance. Experience shows that pragmatism leads to SOA success. It lets the governance program apply just what's needed for SOA maturity. As the organization's SOA evolves, the governance program will evolve with it. Be prepared, however, to reinvent. As the organization progresses up the maturity curve new challenges and priorities will present themselves. In many cases the governance program will need to evolve to reprioritize with these new developments. A solid foundation, as outlined here, will minimize the amount and effort required to reprioritize and will make the impact of the change more seamless.

Even with the best practices outlined above, establishing an effective SOA governance program can seem overwhelming. How do you know where to start? How much governance is enough? Take advantage of the services vendors offer that help your organization to identify where you are in the SOA and SOA governance maturity curve and where to concentrate your efforts in creating a governance program.

Supplement your governance efforts with technologies that put intense focus on automating governance activities. Automating these activities provides multiple benefits, but one of the most important is it decreases the resistance to adoption from the governed body. Focus on technologies that provide a non-intrusive approach to automating governance to decrease the probability that the governed workforce will circumvent the process, ensuring your governance program remains effective.

As a final thought, don't treat SOA governance as a separate, distinct discipline. Doing so will lead to a failure of your governance program. Be sure to identify the unique aspects that SOA requires from a governance program and augment existing governance disciplines already established with these new activities and policies. Doing so will provide more seamless integration of SOA governance disciplines to the existing culture.

More Stories By Ashish Mohindroo

Ashish Mohindroo is senior director, Product Marketing, at Oracle. He manages a team that is responsible for product strategy and global marketing for Oracle Fusion Middleware and Service-Oriented Architecture products and solutions. He launched and continues to lead the global Go-To-Market Initiatives for Oracle's Service-Oriented Architecture (SOA), Complex Event Processing, Business Process Management (BPM), Master Data Management (MDM), and Developer Tools product offerings and is a major driver behind Oracle's recognized leadership in SOA. Under Mohindroo’s leadership, Oracle’s SOA products are the fastest growing components of Oracle Fusion Middleware. He regularly keynotes industry conferences, is interviewed by publications worldwide, and briefs industry analysts for Oracle.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.