Below is a brief recap of some of the topics that came up in my discussion with a senior IT executive:Don’t model your governance after any other process in your organization
Okay, I’m not suggesting you start from scratch exactly; in fact there are likely a number of existing processes that can be leveraged. The reason for my bold, possibly misleading header for this paragraph is that in his case he had a process that existed for years, which defined how a particular department worked on business requirements and how the workflow occurred of handing those off onto IT for architecture and implementation (all in a vacuum, without regard to stuff already in place or things needed by other departments). He indicated that he tried widening that very process to include multiple organizations working in SOA fashion. This attempt resulted in frustration and ultimately failed because each department had their own methods and mechanisms, and no one was prepared for the paradigm shift of interfacing in a common way. Each silo resulted from disparate thinking, so pulling one into the other didn’t seem to work.
Governing a federated service-oriented process requires a dramatic culture change, differing from most other approaches to workflow for IT than most existing paradigms. A large part of figuring this out stems from understanding and accepting that principle. In an SOA, we proliferate services that may originate from previously disconnected departments. Functions are then brought together to form solutions in composite form with common services and reuse. Infrastructure services like databases, service busses and security are normalized across the platform so that economies of scale and common standards can be taken advantage of. So, the first suggestion is to throw away any notion that an existing process can merely be spread across the organization.
Consider the types of business processes
There are levels and paradigms involved in a business, therefore SOA governance should be patterned after each organizational role. Consider the business, how it captures requirements, consider the IT organization and how architecture is defined, where it’s defined and why. Remember there are operational attributes that work in certain ways, such as run-time environments, production support and networks. Think about the security requirements (from user authentication to entitlements to data protection and privacy), not to mention regulatory compliance, which happens to be a key topic for banks. All things considered, SOA governance must involve characteristics deeply embedded throughout the business.
Ensure certain attributes in each area are covered
We discussed a bit about what each area of the process needs to include and we brainstormed over some key characteristics. The first was measurements, meaning objective attributes that could be used to hold certain departments and people accountable to important parts of the workflow. We reviewed the importance of incentivizing key stakeholders in each department to ensure compliance with SOA requirements, and to hold them accountable to the process for proper discipline. We discussed open communication and availability of measurement in the process, for complete transparency.
The Gartner ICC
Gartner preaches a concept referred to as the Integration Competency Center. I’ve found that concept to be solid, and in practice it’s a key part of putting an SOA governance model together, in particular with organizations involving disparate silos. I mentioned this concept and related some examples in our experience at SunGard in terms of a central team to manage the overall process.
Putting the pieces together
Through the previous topics, a lot of ground work was laid to piece together the parts of a service-oriented governance process. We first discussed standards. It’s important to lay down what data models, what busses, what databases, what server architectures, what interfaces will be accepted. Including how development is done and what tools are used. There’s far more in those standards than can be defined initially, so the process needs to consider how the standards are amended, extended, modified, and how they live.
Next, the framework that implements the standards needs to be considered, so the actual architecture of the run time infrastructure can come together. This should describe the overall network, how software executes and how computing resources are provisioned.
Eventually we got on the topic of policies. We discussed things like scoping and lifecycles of services, version control, regulatory constraints and conditions for quality and production deployment, including maintenance and SLA’s. Which lead us to operational management, which deals with how to operate the production environment and the support from a user perspective.
Whew… and that’s just the tip of the iceberg. In a nutshell, any successful global governance model for SOA will be a combination of the standards, policies, as well as the interoperability of departments, functionality and requirements. The process must define everything from requirements gathering to architecture to development to deployment and to operation management and support. A central team (the ICC) optimizes the governance where disparate silos of teams and departments are involved. It ensures that control and accountability remains in place. It needs to provide standards for data, for technology and for interoperability, as well as guidelines for teams to work together, find common ground, abstract the variable and normalize the reusable parts.
As I indicated toward the beginning, you can leverage existing processes (SOA is all about leveraging existing stuff anyway), but keep in mind the paradigm shift involving a central team for measuring, ensuring accountability and overall governing the process with possibly a new way of interfacing with each team.
