Service-oriented architecture (SOA) policy adds important business and technical flexibility and control to an SOA-based solution. At runtime, SOA policy provides ready access to change key operating characteristics of a service, including business parameters like approval limits and transaction routing.
During development, SOA policy controls key aspects of how your services are built. It requires coordinated use of features and functions from multiple types of software tools and infrastructure products.
A big-picture perspective is a must for an SOA implementation. Even though certain products have “policy management” in their names, getting your infrastructure set for SOA policy should start not by evaluating products, but rather by understanding the major functions required for effective policy management and how they work together. Only then will you be able to assess how your existing products and any new products – whether or not they have “policy management” in their names – will provide the integrated environment you need for effective SOA policy. Designing Your Architecture For SOA Policy Management
Most organizations will find it best to use an incremental approach to SOA policy, starting with individual policy domains such as security or management. Before designing SOA policy infrastructure, be sure that you understand where your organization might first use SOA policy, your readiness for SOA policy management, and the general nature of the SOA policy life cycle. Because SOA policy management requires coordinated use of multiple products, architecture design is the right starting point – especially to set the stage for incrementally building the infrastructure.
Design your architecture for SOA policy iteratively across three design stages:
1. Conceptual architecture for SOA policy.
By first designing your conceptual foundation for SOA policy, you: 1) ensure that you understand SOA policy; 2) create a simple foundation for describing SOA policy to executives, developers, and other colleagues; and 3) construct a broad categorization scheme to understand where, how, and how extensively various products play a role in your infrastructure for SOA policy.
2. Logical architecture for SOA policy.
Building on your conceptual architecture, you should next add an additional level of detail that elaborates on the major structural elements of your infrastructure for SOA policy. As you develop the logical architecture, you will start to see how SOA policy will integrate into your organization’s full SOA platform, for example, by considering how an SOA repository might act as a repository for certain types of SOA policy.
3. Integration with your SOA platform strategy.
With a logical architecture (or a first draft of one) in place, map SOA policy functions onto your SOA platform plans to answer, for example, how SOA policy might integrate with the messaging and management functions in your SOA platform. The specific products involved and the roles the products play will vary based on each specific organization’s incremental development of its SOA platform and its SOA policy infrastructure. 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.
• 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.
Randy Heffner is a Vice President at Forrester Research, serving Enterprise Architecture professionals. He is a leading expert on architectures and design approaches for building enterprise applications that are secure and resilient in the face of continuous business and technology change.
