How To Design and Build A Solid Architecture For SOA Policy Management
Building Your SOA Policy Infrastructure
You now have a logical architecture for SOA policy as strong foundation, but you can't run your business on a logical architecture. As you evolve the physical implementation of your SOA platform to support SOA policy, two tasks will prepare the way:
1. Finding SOA policy functions in existing products. Infrastructure for SOA policy acts as an extension to an SOA platform, not as a separate platform of its own. The SOA policy functions identified in your logical architecture may be provided by: 1) traditional software infrastructure products; 2) general SOA specialty products; and 3) products built specifically to support SOA policy or to support policy more generally. To develop your infrastructure for SOA policy, identify, for example, how your SOA appliance, enterprise service bus, SOA management solution — or other non-SOA products — might provide functions outlined by your logical architecture.
2. Set your strategy for SOA policy management standards. As part of identifying SOA policy in existing products, decide how to use industry standards. Although they cover only a small part of the full scope of SOA policy management, certain specifications and standards do provide important integration points between the parts of your SOA policy infrastructure. Still, it is early days for SOA policy, and the specifications are not yet widely adopted, so you should plan carefully for how and when to use related specifications.
As general rules of thumb when considering a specification related to SOA policy:
• Use a specification if your existing SOA infrastructure supports it — but only after you have tested it carefully.*bull; Always include a specification in your product selection criteria — unless it clearly does not apply to you or you have specifically opted against it.
• Do not make a specification a mandatory product selection criterion unless, based on your requirements, your strategy, and the maturity of the spec, you have specifically decided to adopt it.
• All other things being equal, buy a product that supports a specification — but in general, favor a product's fitness for purpose over its standards support.
• In using (or not using) any specification, consider carefully how you will evolve your architecture and platform if the specification loses (or gains) industry support.
Once you have defined a logical architecture, determined how your existing products fit with the logical architecture, and decided your use of industry specifications and standards, you'll have the technical foundation you need to determine what products you might need for SOA policy management. Your strategy will vary based on your aggressiveness in adopting SOA policy, your timing for using various SOA policy domains, your existing infrastructure, and your plans for evolving your SOA platform. Use these tips to establish a strong architectural foundation to facilitate planning for both near-term benefits and long-term evolution of your SOA policy management infrastructure.
