Introduction to Service Technology

by James P. Lawler and H. Howell-Barber

This is an unedited version of Chapter 7 from Service-Oriented Architecture: SOA Strategy, Methodology, and Technology

The complexity of service-oriented architecture (SOA) is apparent from the deployments of the business firms in our prior section. Although all of the firms have deployed and expanded web services based on SOA or deployed services, integrated process and services architecture and restructured organizations and staff, few in the studies have deployed and exploited services based on service-oriented enterprise (SOE). SOA is not easy to develop from the hype of technology firms (vendors) marketing service technology.² In our studies there were collectively different technology firms marketing diverse product technologies and tools, of which the foremost of the firms are indicated below in Table 7.1.

The decision on the appropriate technology firm and the best service technology can be difficult for technical managers, and especially for business managers, because of the myriad technology firms and technologies coupled with the immaturity of some of the technologies and the tools.³

Difficulty of SOA Technology
The difficulty of SOA, and in general technology,⁴ can be addressed both as a challenge and an opportunity for a business firm. Firms have to concentrate on the business capabilities and dimensions of SOA, not on the difficulties of the technology. Business managers, in close collaboration with technical managers in the information technology department, have to consider the business needs, the processes to be improved by SOA, the applications behind the processes, and the core services to be included in SOA.

Focus on improvement of business processes is already considered a goal of technical managers.⁵ Governance of SOA as a business proposition in improving processes is considered a growing issue for managers.⁶ Technology can clearly be difficult for decision-makers, but it may be a distraction from critical business challenges that could be approached first by technical and business managers.

The evolution of SOA continues to advance with improved functionality of products marketed by technology firms, as large-sized technology firms continue to acquire small-sized firms and hype integrated SOA solutions and suites.⁷ Such suites and technologies may be appealing to a business firm, but managers and program participants may better evaluate and decide these technologies in contrast to existing internal technologies and levels of services skills of the technical staff, as these might impact the integration of the external suites and technologies. Managers may also best decide to exclude proprietary technologies of technology firms.

The decision on SOA technology is frequently among a number of technology firms, as few technology firms, technologies and tools are likely to be the SOA solution suite, and the decision is appropriate in an SOA that can conveniently integrate diverse and numerous technologies.

The technology firms, technologies and tools of SOA are furnished as a reference for our readers in the next chapter on service technology firms, technologies and tools.

Enterprise Architecture Strategy
The focus on business processes and strategy of SOA can be continued by a concentration on enterprise architecture,* before deciding on the technology of SOA. The architecture is a blueprint of the dimensions of flexible services that can deliver the improved processes, as conceptually displayed in Figure 7.1. The architecture describes business logic, data management, access control criteria, interface, messaging and organization of applications, and metadata of applications, of future services and existing services, enabling eventual infrastructure and process standardization throughout the business units of the firm in an SOE. The metadata is the glue to the properties of the business processes. Description of the processes and the architecture is in business terminology. Such dimensions of enterprise architecture are not dependent on specific technologies.

Architecture is the foundation of SOA strategy and is effectively independent of the technology. To benefit from an SOA, the focus of managers has to be on business processes and on an enterprise architecture plan and not purely on the technologies.⁸

This plan may include recommendations for integration of legacy applications in an SOA. Managers might integrate legacy applications in an Enterprise Service Bus (ESB) from a technology firm. The bus is essentially a messaging bus and a platform for orchestrating and provisioning services. An example of a project with an ESB is the municipal energy utility in Case Study 10 in Chapter 5, but another example might be order processing of securities, which has complex procedures and requires synchronization of transactions. Managers might alternately not integrate applications in an ESB, which is akin to enterprise application integration (EAI); they might interface them in XML gateways to the services, as interfaces are likely to be more loosely coupled and dynamically linked to applications than integration. The plan for infrastructure architecture may likely recommend a number of technology options that would be included in the SOA strategy.

Other issues include the performance and the scalability of the architecture, which may negate the benefits of SOA, and on which the focus of managers in specifying performance and scalability requirements are more important than the inherent technologies of the technology firms.

The decision on investment in technology of SOA is subordinate to enterprise architecture and business process strategy.

Security of SOA
Though the focus on business processes and enterprise architecture strategy is critical in an SOA, managers in the technology department have to consider the dimensions of the security of services and of SOA before deciding on the technology firms, their technologies and the tools.

The ease in exposing internal applications and furnishing core services to internal and external consumers and intermediaries causes concerns for a business firm.¹⁰ Securing services is a critical consideration for managers and program participants evaluating products of technology firms.

To ensure security of SOA, access control to services, authorization to the services and authentication of authorized consumers for specific services can be designed by managers and staff, defined in a security policy during the initiation of projects, and modified by the staff during product realization.

Managers might develop procedures from a Web Services Description Language (WSDL) design, in order to ensure that affected applications and all services of the firm are enabled by security from the design. They might develop common security for all of the applications and the services for all of the consumers in the firm, distinct security for designated application domains or for designated services for designated internal consumers in the firm, and exception security for services for consumers in external firms and for individual customers. To do this, they might merge the SOA security policy with existing practices on security and not have conflicting security.

The design of the procedures of a security policy can be done during the gathering of technical and business requirements for services. Managers and staff might consider the existing functionality of marketplace security tools as they design a security policy and then decide on the tools of a technology firm. The management of the policy and of the security technologies and the tools of the technology firms is important in SOA strategy.¹¹

Standards of SOA
The difficulty of SOA in different technology firms and numerous product technologies is exacerbated by Web services standards. In order to evolve from web services to SOA, requirements have expanded for extension to existing standards. The specifications on the technologies and the tools are developed generally by groups of large-sized technology firms, such as BEA, IBM, Microsoft, SAP and Tibco,¹² and are forwarded by them to one or more of the foremost organizations¹³ on standards indicated in Table 7.2. Following a process of review, specifications may or may not be approved as standards, or the specifications may expire prior to approval. Technology firms however may develop and market products that adhere to specifications that are not approved as standards, further exacerbating difficulties.

Other organizations important in standards include the Association for Cooperative Operations Research and Development (ACORD), the Financial Services Technology Consortium (FSTC), the Interactive Financial Exchange (IFX), the Liberty Alliance, and the United Nations Center for Trade Facilitation and Electronic Business (UN/CEFACT).

The organizations in Table 7.2 are cross-referenced to current standards in Table 7.3.

The technology firms are evolving generally to common open standards, but current standards displayed in Table 7.3 are conflicting and overlapping, and it can be difficult for managers in a business firm to choose appropriate standards.

Managers may discover features in the simple web services specifications of the standards to be adequate for their firms, but may find a few of the functions in the extended SOA standards to be inadequate for several specific applications in the firms. An example of an application might be a designated service for designated external business firms that cannot be published without further security. Managers might not have technology-neutral services, due to legacy applications developed in closed proprietary protocols and technologies. They might be impacted by technology firms tightly coupling their software, so that they are effectively furnishing closed proprietary technologies. Such issues indicate the immaturity of the specification standards and the technologies.

To decide on a standards strategy, given the issues, managers and program participants can first determine business needs, choose products that address these needs, and ascertain that the products adhere to approved specifications or standards. Managers can ascertain that previously purchased products from different technology firms conform to the same standards. They could focus on the best-of-class technologies and tools of the large-sized technology firms that dominate the standards, in order to continue deploying initial services in SOA. However, managers have to consider matured and open specification standards of SOA technologies as a preferred requirement for technology firms, in order to enable a more stable foundation for the future growth of SOA. Technology firms committed to open standards and standard interoperability techniques enable an appropriate business and management strategy of SOA.

Version Control
The final difficulty in the management of SOA is version control of the services and of the product technologies and synchronization between technologies and versions of the services. Business firms continue to deploy more and more services and may have multiple versions of the same services, and technology firms continue to deploy numerous releases of their technologies. Managers can have difficulty maintaining bona fide reusability of the services, due to shifting of the technologies and the services.

Managers might map common consumer calls for a new service to an old service in a translation service, if data for the new service could be derived for the service in the translation. Management of the services and of the technologies is better in a policy aided by a registry or a repository containing characteristics of the services, standards and technologies and customized to the requirements of their firms. Multiple service versions may be included in a registry with cross-referencing between providers and consumers of the services. Service metadata with versions of product technologies that created the services may be further included in the registry. The registry would facilitate testing of related applications when services are updated and of related services when technologies are upgraded in the firms, in order to ensure changes in versions are not introducing new problems. Such a policy is important in version control of SOA strategy, as indicated in the service management framework of our program management methodology in Chapter 2 and in a number of our studies.

In short, the management of SOA technology, and of enterprise architecture strategy, security, standards and version control of services and technologies, can be Herculean for technical managers and business managers. Nevertheless, managers can collaborate on the capabilities and deployment methods of new technologies¹⁴ and influence and lead projects of SOA on the path to an eventual SOE. SOA is considered an organic process requiring participation of business stakeholder staff and technology staff for the duration and evolution of the projects and in the decisions on service firms, technologies and tools,¹⁵ which are categorized in our next chapter.

Notes

* Application of the Zachman Framework for Enterprise Architecture⁹ in the architecture framework of our program management methodology can benefit managers.
1. Wilson, C. 2006. Transparent IT: Building Blocks for an Agile Enterprise. Dallas, TX: Geniant, LLC: 187.
2. Fitzgerald, M. 2006. Getting Good Service. CIO Insight, October: 74.
3. Whiting, Rick. 2006. "SOA Toolbox Still Is Not Full." Information Week, October 9: 27-28.
4. McAfee, A. 2006. "Mastering the Three Worlds of Information Technology." Harvard Business Review, November: 142.
5. Alter, A. 2006. Top 30 Trends for 2007: Process Improvement Will Be Job No. 1. CIO Insight. December: 12.
6. Knorr, E. 2007. "SOA: The Great SOA Shopping Spree." Infoworld, January 1: 16.
7. Koch, C. 2006. "Service-Oriented Architecture: The Truth About SOA." CIO, June 15: 58.
8. Gruman, G. 2006. "True Challenge of SOA - It Is Not Technology." CIO, May 1: 25.
9. O'Rourke, C., Fishman, N. and Selkow, W. 2003. Enterprise Architecture Using the Zachman Framework (MIS). Boston, MA: Thomson Course Technology. 10. Goodin, D. 2006. "Shielding Web Services from Attack." Infoworld, November 27: 29.
11. Linthicum, D. 2007. "Budgeting for SOA Success." Infoworld, January 8: 20.
12. Newcomer, E. and Lomow, G. 2005. Understanding SOA with Web Services. Upper Saddle River, NJ: Addison-Wesley: 33.
13. Ibid., 33-34.
14. McAfee, Mastering the Three Worlds of Information Technology, 147.
15. Fox, S. 2006. "Sustainable SOA." Infoworld, May 8: 6.