This article is written from the perspective of a financial services industry consumer of technology and standards. The views expressed are those of the author and do not necessarily represent those of Citigroup.
WS-Policy is a soon-to-be proposed W3C standard that has received a great deal of focus from both technology product vendors and their customers. As is often the case, the vendor provides one useful view, and the customer provides another. Occasionally they agree. There seems to be agreement on the importance of a policy standard for Web architectures. This is not surprising for two reasons. One, from a business perspective, policy is how a company is managed. Two, Web architectures are an increasingly important part of the global business architecture.
Company policy influences and determines the decisions and actions of people, processes and systems. As such, company policy must extend well beyond IT. However, it is useful to note that we can identify a very important and large set of policies to which WS-Policy is well suited: operational risk policy. Let's look at operational risk.
Financial service companies have highly regulated, and probably the most sophisticated, operational risk management systems in the world---and they are currently being significantly upgraded through Basel II regulation. The bottom line is that operational risk systems are important because they guard against large uncovered financial losses and thereby contribute to financial stability in the global economy. The technical definition for operational risk policy is "the decisions and actions taken to manage the risk of financial loss resulting from inadequate or failed internal processes, people and systems, or from external events."
The above definition also establishes several categories of operational risk loss: internal fraud; external fraud; business disruption and system failures; execution, delivery and process management; clients, products and business practices; employment practices and workplace safety; and damage to physical assets. We'll soon see that WS-Policy in its current form can capture policy requirements in each of the first five operational risk loss categories. We need to talk about WS-Policy in more detail, However, we cannot until we have been introduced to service-oriented architecture.
Service-oriented architecture (SOA) consists of services and the service infrastructure to support said services. Our services will come in two types: data services and process services. By design, services in an SOA have no policy. This is done to separate application development from policy concerns. Therefore the infrastructure must be responsible for enforcing policy.
Enforcement is achieved in an SOA environment by introducing specialized bridges and gateways that consume and react to policy definitions. In the figure below, consumers appear on the left, services on the right. The policy enforcement bridges/gateways are denoted in red and mediate messages between consumers and services. The policy to be enforced is pushed to the nodes by the Policy Administrative Console, also denoted in red.
We know that some very familiar corporate operational policies already reside in enterprise infrastructure, for example, single sign-on security (SSO) authorization is routinely implemented in enterprise infrastructure, where policy can be centrally managed and locally enforced. For SSO, the enforcement can occur either at an HTTP server plug-in, or, in a reverse proxy.
We note that operational risk is distributed by nature---and therefore can benefit from Web architecture. Other types of financial risk, like market and credit risk, tend towards centralization and remote procedure-like calls. Service-oriented architectures must, of course, operate usefully and effectively in both environments.
WS-Policy introduces a standard policy formulation that can be correctly interpreted (in other words, inter-operable) and enforced across various elements of the infrastructure. WS-Policies are expressed as valid intersections of constraints and conditions that govern how a Web service and its consumers interact. A given policy assertion in WS-Policy identifies a domain (e.g. security, messaging, reliability and transaction) and a required behavior that can be effectively managed across departments, business units and partners. Compare the WS-Policy domains just mentioned with the first five operational risk loss categories defined by the regulators (above). They align.
It seems quite possible that the link between Operational Risk Policy and WS-Policy will yield insights into the evolution of business IT infrastructure, governance and WS-Policy.
It should be noted that WS-Policy is approaching an important milestone. The Candidate Recommendation drafts for WS-Policy 1.5 are nearing completion and a proposed recommendation appears likely to go to the W3C late spring or summer.
About the Author
Mark R. Temple-Raston is a SVP-Senior Architect for Citigroup Information Technology Systems (CITS), Citigroup. He designs and builds global enterprise systems that span across the business units and sectors at Citigroup. Mark has over 12 years experience in financial services, spending five of those years traveling globally as a consultant. Mark lives and works in New York City and has a doctorate from Cambridge University, UK.
