I'm going to be doing a day-long tutorial on SOA governance at the InfoWorld SOA Executive Forum in New York on November 8th. If you register before October 7th, it's $695. After that it's $795 until November 5th. Then the price goes up to $895. Here's the details:
Counterintuitive as it may seem, SOA requires more organizational discipline than previous development models. Your intuition might tell you that flexibility results from less rules, not more, but that's not the case.
Standardization provides the underpinnings for SOA across an organization. To prevent IT from being overwhelmed by this new complexity, the industry has created a new classes of software, registries, repositories, and runtime management systems, that help keep all the rules straight. But creating an SOA for an enterprise demands more than using SOA-based tools -- it requires that IT organizations make serious choices about design, which result in design rules.
This tutorial will:
- Introduce SOA governance and effective governance models
- Discuss how to put a governance processes in place
- Talk about enablers and detriments to effective governance
- Describe policies and procedures you should put in place now
- Show you how to create an interoperability framework for your organization
- Teach you how to build and use reference architectures
- Describe, evaluate, and compare the tools available to manage SOA governance artifacts
This is a detailed outline:
Governance Models - One of the most important questions to answer is "How does my organization make decisions?" We're after loose coupling and that requires a way for making rules and ensuring that they're followed. Consequently, its important to understand what works--and what doesn't. Governance isn't something that happens once, it's an ongoing process. The governance lifecycle defines the process and provides a timeline. There are some things to watch out for--stumbling blocks that will make it hard to get going until you've moved the out of the way.
SOA Maturity Evaluation - Good governance depends on understanding your processes and where they can be improved and where they are simply incompatible with the loosely coupled organization you want to build. Process evaluation gives you the opportunity to reengineer how your organization gets things done by finding the gaps between where you are and where you want to be and then filling those gaps with best practices. Data architecture is equally important. If you can't find where your data is or if the same kinds of data is stored, formatted, and understood differently in different repositories, you can't succeed in creating an SOA.
Digital Identity for SOA - Digital identity plays a foundational role in SOA. We will discuss the role of identity systems in your SOA and how such systems can be defined, built, and managed in the enterprise.
Policies - Many people, especially techies are scared or distrustful of policies. We're all familiar with "computer end user policies" that spell out all the things employees can't do--and then are ignored. The fact is that well thought out, carefully planned policies are essential to building loosely coupled systems. We'll cover the types of policies that are needed for loosely coupled SOA and how policies can be effective. Evaluating policies is a key activity in the governance lifecyce and one that's critical to creating policies that work.
Building an Interoperability Framework - If there's one policy that's more important than all the rest, it's the Interoperability Framework (IF). The good news is that an IF is relatively easy to create. An IF is a list of internal and external standards that the organization supports and their current status. It's the most basic part of an SOA policy and critical to achieving interoperability. This is also a good time to talk about what standards exist, what they do, and why you need them.
Tools for Managing Governance Artifacts - Numerous tools exist for managing governance artifacts. Repositories and registries are used to enable service discovery and enforce enterprise policy at design time and deploy time. Web services management systems are used to manage running services and enforce SOA policies at runtime.
Reference Architectures - Reference architectures come in two flavors: "enterprise" and "system-level." An enterprise reference architecture provides the context that system architects need to ensure their designs will fit in with other systems in the enterprise and be able to interoperate. A system-level architecture gives examples and best practices for common enterprise systems that might be deployed in the organization and shows how those systems relate to the enterprise reference architecture.