Service Oriented Architecture Standards

By Jim Rubert

This paper describes the most important software standards within the domain of services, from the perspective of a large company that will build and consume services. The areas described are in order of importance. We recognize there could be more that need to be supported.

The most emphasis should be on these areas, in this order:

  1. Business Process Management (BPM) and Service Oriented Architecture (SOA)

  2. Security

  3. Metadata

If these areas are not dealt with soon, then the success of SOA in the industry will only come with additional code created by a company wanting to use the SOA technology or purchased from software companies. We do not like the spectre of buying this code from a software vendor, as we will likely be forced to buy into their entire suite of software, which is usually not feasible for a company of our size.

Business Process Management and Service Oriented Architecture

The areas of Business Process Management and Service Oriented Architecture need to converge. Companies cannot both connect a human-centric workflow that is part of a documented business process, and leverage the services. This would require support for event-driven services through request and reply, and publish and subscribe services, all within the context of human process automation (workflow).

Once a process is modeled, most process owners will identify all possible system automation to reduce costs. Human-automated workflow is the next huge step in increasing a company’s bottom line. Human-automated workflow will provide a solution to the time consuming data insertion into applications, and event-driven task lists within an employee’s daily work activities. The use of human-automated workflow and SOA can be leveraged to increase an employees’ productivity.

If one contemplates SOA as being the top priority for companies to adopt, a business analyst will need to run some general Internal Rate of Return (IRR) and Net Present Value (NPV) numbers to determine if SOA is within the cost and value to a company. These two numbers need to be high enough to make SOA something to pursue. Currently, SOA is an expensive endeavor to accomplish because of the extensive infrastructure needed and additional costs in development and design. To achieve the right cost numbers, the BPM automated human workflow and SOA domain have to converge to get to the level throughout industry that will make an impact to the company pursuing the functionality.

The current recommendation from most knowledge experts is to adopt process modeling and develop a process architecture. The process architecture is comprised of the enterprise operational processes that are customer or consumer-facing, to achieve the organization's mission statement. The standards that influence the process architect are BPMN, BPEL and BPDM. The next steps would be to study the model and identify the areas that require greater flexibility than possible in their currently implemented form, and to look for common activities and tasks across the process architecture where flexibility is desired. This recommendation is stated so that everyone can be positioned to use the BPM convergence with SOA.

Security Model

The basic WS-Security model is in place with the support of SAML, X.509, WS-Policy, and username tokens. Standalone use of XML Signature and XML Encryption also fares well, but is not supported by software companies that do not support SOA. A more complex model needs to be addressed to use services that are outward-facing from a company’s network. Secure transactions through a service are mandatory to use a service technology on the outside interface of a company. The specific standards that need to be established are for transactions. Besides the above standards, WS-SecureExchange and WS-Federation could also be leveraged. The reason Web service security is important is that transactions are typically the next cost savings that a company can introduce to drive down their cost.

Data Model required for services

Once a company has business objects identified that are used through their business processes, there will be some data translation issues. This occurs because different organizations within the company view and call data differently -- mostly because brick-and-mortar companies have so much history with internal groups calling widgets different names in the process. This requires a translation of data, which then requires a metadata repository. The metadata repository also provides a vocabulary for the company.

Technology and techniques exist to exchange information across organizations, but highly-distributed services have issues with technology mismatches (in both messaging and security). The use of WS-MetaDataExchange (WS-MEX) is the key to successfully using services across a large company. The real issue is the cost of exchanging this data and controlling it.

MetaData is in the top three emphasized areas to a company using Web services because of the data translation issues. Once a company has their processes automated and is comfortable with the level of security within the area of service transactions, the problem of data replication and exchange will become high enough to spend money on the problem. The cost of building a metadata repository will be less than maintaining all the translations throughout the company. This will cause the implementation of a metadata repository for data exchange.


Boeing highly prefers building upon open, interoperable standards. However, in a highly competitive environment, companies cannot wait on the standards to be published to start building the services and core code to make services a reality. Companies are faced with the dilemma of either buying a product from a company to support their strategy, or building their own, and giving up on the vision of an open, interoperable standard.

Companies can either rely on the current state of service standards, or purchase their solution from a software supplier that promises to provide the functionality the company needs at a reasonable cost. If the company chooses to buy the solution from the vendor, that vendor typically is not willing to support the standards, or will try watering the standards down so they still have an advantage over their competitors. This type of activity is called market driven standards. Besides having this chaos within the standards, the cost of buying a vendor suite solution also erases a large part of the company’s projected cost savings.

Boeing is concerned this is starting to happen now as Business Process Management is beginning to make in-roads into companies, because it is getting easier and cheaper to do. Actually, it is so easy that domain managers can model their processes themselves.


Boeing is a very large company. There are many different subgroups scattered throughout the world that leverage different vendor solutions. The use of BPM and SOA (specifically, Web services) is the key to reducing our cost of integrating applications and reducing our operating costs. The subgroup integration includes the need to leverage metadata. Services passing through the company firewall will require a very secure protocol. These three items together will require companies like Boeing to spend the infrastructure dollars to implement solutions based on these standards.