Service Oriented Architecture

The classic organization is now very complex, with dozens of different applications, databases, and processes all trying to interoperate at once. Though the perfect circumstances would be that all these poles apart pieces would come together and act as a single, well-oiled machine, in realism the image is very different – the pieces of the puzzle are more probable to get in the way with each other, causing system failures and crashes, than they are to mesh together. This is a serious business problem, and various approaches have tried to solve it – some of the most recent involve the use of advanced technologies and business models, such as Service-Oriented Architectures.

The ideas and dealing of most Service oriented architectures (SOAs) have made tremendous but important contributions in our modern technology. In fact, it all the rage at least conceptually. Large organization and industries are attracted to the idea that SOAs can develop business practice and workflow control, as well as the flexibility and cost efficiencies that SOAs promise. While most organizations have some distributed systems that could become part of an SOA in the future, few have the high-level mandate or the experience to develop and deploy an enterprise-wide SOA at scale. While attempting more concentration towards implementing ERP systems successfully is laden with jeopardy. It needs effective leadership, a clear strategy, a regular watch on the specific budget, and a precise stake in the project for own choice of business units or Service oriented architectures (SOAs).

Enterprise resource planning (ERP) systems allow business organizations to replace disparate computer systems with an integrated suite of applications, resulting in a seamless flow of information across the entity. ERP advocates argue that the net benefit of ERP systems becomes manifest in firms’ increased financial performance and enhanced competitive position. However, precisely quantifying the extent to which ERP systems add value to firms is problematic due to the qualitative nature of many of the benefits derived from ERP implementations.

The costs associated with ERP implementations can be staggering. For instance, as of 1998 over 6,000 firms had implemented ERP packages supplied by SAP, just one of many ERP software suppliers, at an average implementation cost of $20 million (Cooke and Peterson 1998). When planning an implementation, it is difficult to get a firm grip on the cost side of the equation. In many cases, ERP implementation projects end up costing considerably more than initially budgeted due to a variety of underestimated and hidden costs, such as training, integration, testing, conversion, and consulting (Slater 1998). However, once the ERP system is online, implementation costs are relatively easy to quantify ex post. On the other hand, ERP system-related benefits are more difficult to assess either ex ante or ex post.

Acclaimed ERP benefits arise from increased firm efficiency and effectiveness. For example, efficiency gains can be realized from consolidating multiple data entry points, pushing decision-making authority down to lower organizational levels, reengineering operational processes, and automating business processes. In many instances, efficiency-related savings are quantifiable, as they are often reflected in lower labor and inventory expenditures. Effectiveness gains can be achieved in a variety of ways, such as increased customer resource management, improved product/service quality, and enhanced strategic-planning capability. The latter effectiveness indicator, improved strategic planning, is believed to be one of the greatest potential benefits offered by ERP systems.

In this modern era of technology and development we have gone through various experiments related to the ides of service-oriented architecture. So, these attractive and valuable systems are planned such that their parts can offer help to other elements. The efficiencies, flexible deployment options and cost reductions enabled by using a services paradigm are the goals of all SOAs, be they based on the Simple Object Access Protocol (SOAP), a Representational State Transfer (REST) architecture, Enterprise Service Bus technology (ESB) or any combination of these.

Such technical advances mean credit card processing is a frequently cited SOA example: today, a normal application that needs to process credit cards in an SOA simply asks a credit card processing service to do the work on its behalf. Rather than agreeing to the details of the operation beforehand (known as “tight coupling”), the two applications (as part of a “distributed system”) exchange the necessary information at the time of the request. In this case, the one application knows the other is a credit card processing service, and learns how to make the processing request as part of the transaction. In SOA-speak, they are “loosely coupled.”

As we have noted that during the years of late 1990s, most large architectural industries installed enterprise resource-planning (ERP) systems that was, massive computer applications offering a business to manage all of its operations (finance, requirements planning, human resources, and order fulfillment) on the basis of a single, integrated set of corporate data (James, Wolf, 2000). On the other side, ERP promised huge improvements in efficiency for example, shorter intervals between orders and payments, lower back-office staff requirements, reduced inventory, and improved customer service. Encouraged by these possibilities, businesses around the world invested some $300 billion in ERP during the decade.

All in all we can say that, the aptitude and elasticity of SOAs comes from the reality that operations are implemented at the service level for example; we need a credit card processed. The static, hard-to-change parts of the application the detailed levels of semantics and syntax are abstracted by the architecture and the protocols used to implement it. This makes it easier to change providers of the service, since the detailed aspects of the requested transaction are communicated as part of the transaction itself.

Additionally, in our daily routine we use telephone calls and other services for specific advantages. Placing a “phone call” is the same as asking the telephone system to do work on our behalf. Usually we enter the phone number and expect the system to handle the rest of the process. If we need to be connected to voice mail, or if we are joining a conference call, or if we hear music played to us while we are on hold, we are subject to the operations of the service that is the telephone system. Probably, the interface to the service is the same regardless of the provider of the service: we dial the phone the same way at home and at our work station. Our mobile allows us to place calls, check our voice mail and forward our calls just like our desk phone, although the underlying technologies that implement the service can be enormously different.

From Phone-Centric To Service-Centric

Traditionally, each PBX has had its own APIs, and various applications that wanted to amalgamate had to be written for these particular interfaces and system. They often had to have knowledge of the inter-workings of call-control and signaling systems. This integration model was closed, proprietary and often complex and expensive. It was not application-centric, but phone-centric. While this model was perhaps sufficient in the early days of computer telephony integration (CTI) 10-15 years ago, it certainly is not appropriate today, when the enterprise focus clearly is on the desktop, the datacenter and IP applications.

As much as the mater is concerned, a best model would not require so much detailed integration. Instead, it would follow the service model, which is the way in which we commonly use phone services today: Dial the number and the service does whatever is needed to accomplish the request, whether that is placing the call, accessing voice mail or joining a conference call. In other words, the service is operationally opaque from the point of view of the application requesting the service. (If the application cares, such as for the time and charges information on a call, it can request the appropriate level of detail.)

Additionally, we are starting to see the emergence of service-oriented APIs from a small, but growing number of vendors, including Microsoft and Avaya. Examples include Avaya’s PBX API, which wraps the PBX in SOAP technology, as well as Microsoft’s systems-oriented approach with Live Communication Server and the .NET environment. Such technologies promise service-oriented (specifically Web Services) interfaces for communication-intensive workflows, such as training applications, customer support and relationship management, as well as enterprise resource and planning applications (ERP). While this is necessary, it is not sufficient. To truly leverage next-generation voice and video and create more efficient and productive telecommunications networks, external services also need to be incorporated into the enterprise SOA.

Here in a different style we can say that this is what service-oriented architectures are all about: building complex solutions by leveraging external services to create something that would not be economical without the external service. This is a very useful tool indeed.

Creating An SOA With Interactive Services

To create a new SOA has become an art. Although the PSTN is an SOA, traditional carriers do not yet think in terms of making PSTN services available so that they can be leveraged as part of an enterprise SOA. In contrast, services from some of the emerging IP-based services providers (such as those offered by Verisign, NeuStar and NetGeo) are much more interesting. And its effects can be numerous.

For example, NetGeo’s IP service can be utilized in a different ways to create an application that enables least-cost PSTN and IP call routing plans based on geographical information. Likewise, Internet-based local weather forecasting information (e.g., from nws.noaa.gov, weather.com, etc.) could be incorporated into telephone call policy control to reroute calls away from call centers which might not be fully staffed due to inclement weather. In both of these examples, the SOA architecture controls the telecommunications infrastructure and the IT application writer has full control of the underlying infrastructure and services.

Theoretically, there is no difference between leveraging these Internet and IP-based services and leveraging a long-distance carrier. That means the enterprise “phone person,” with his/her PSTN-carrier-interconnect experience, is the natural choice to manage the evolution of these services as both the enterprise and the carriers develop more flexible and complete instantiations of SOAs, including their ability to flexibly switch among multiple service providers.

As this unfolds, however, several sets of issues will arise. First, of course will be the overall consideration of how applications will make use of the voice and video services. This will, in turn, drive requirements for services that the voice and video services themselves may leverage. Considering which applications will want voice and video service means adopting a new viewpoint: That talking, listening and seeing are features of the applications themselves. Presence and directory policies also must be considered, since applications can have access to these as well. Once these issues are settled, the desired voice and video services can be “published” into the SOA–that is, made available via a service-oriented interface from either internal or external system and service resources.

For example, applications could use dialing information (in the form of the phone number) to ask for the service of placing a call. The service itself whether it is ultimately provided by the internal PBX or leveraged from a PSTN-based Centrex-type offering would handle all the details from that point on.

Applications like voice-response-units (VRUs) and automatic-call-distribution systems (ACDs) that need deeper knowledge and interoperability with the telephony system or service would make these needs part of their requests for service. There is no technical reason why these functions cannot be offered in a service-oriented manner.

Voice And Video Underscore Basic SOA Requirements

Notably, as is the case with other services in the SOA, IT must deal with identity management, service provisioning and monitoring of voice and video services, as well as with the specific, real-time network needs of voice and video traffic. Identity management means that service requests must be authorized and authenticated at each corporate (or other security domain) boundary. Some SOA architectures account for identity management; for example, Web Services has WS-Federation, WS-Security and WS-Trust. There is no explicit statement in these standards that they apply to telecommunications nor need there be, because telecommunications is no different from other applications or services in the enterprise, other than having a requirement for real-time network services.

Identity management issues were never faced in the PSTN, because identities are maintained in the network: A real or virtual circuit connects the endpoints on a leased line and the calling and called parties on a call. When these functions are delivered as VOIP or are reachable from other IP applications, however, the user’s identity must be repeatedly confirmed throughout the ad hoc combination of services that are encountered in satisfying the user’s request. Service provisioning and management also can present problems to an enterprise that tries to incorporate voice and video in their SOA. By definition, SOA architectures are loosely coupled, and that means service provisioning takes place in a loosely coupled manner. Since peered (or federated) service environments do not have a central authority to broker the set-up and resource allocation of leveraged services, the interconnecting enterprises themselves must commit resources during the provisioning process and manage those resources. Today this is a manual and static process, which can be expensive and inefficient.

Consider an enterprise extranet. There’s no conceptual reason why voice and video between partners can’t be carried over that same extranet, eliminating some of the costs and complexity associated with separate voice and data nets. Without a carrier as the middleman, enterprise partners could form a team to use SOA standards such as the Service Provisioning Markup Language (SPML) and the WS-Provisioning standard to provision the service, handle alarms, verify connectivity and troubleshoot complaints, without exposing security holes or imposing architectural constraints on one another. The SOA’s higher-level representations would allow the integrated provisioning process to rely less on the physical make-up of the network and focus on the services.

Focusing on services rather than the physical infrastructure doesn’t mean that physical attributes lose their importance, only that they are abstracted for example, with respect to their transport mechanisms (IP or TDM) and the enterprise’s geography (Centrex or PBX, branch-office or datacenter). Such abstraction keeps the service definition intact within the overall architecture and solution set, while letting the enterprise flexibly choose service providers, transport mechanisms, long-distance providers, naming and numbering solutions and directory infrastructures. Having more choices, and not having to change the SOA to accommodate changes in the enterprise operation, reduces cost and dependencies, and increases productivity.

The deployment of standard software is an essential feature in modern business process optimization. Although SOA’s characteristic abstractions can greatly simplify application development, they also can hide important details, and enterprises need to be on the lookout for visibility problems that can result. For example, when enterprises first started deploying applications that use XML as a replacement for legacy protocols they were surprised to find their network utilization substantially increased.

The main reasons for this are that the political will is there and that, because of the structural weaknesses in the UK public services, e-government can bring processing costs down, increase response times and improve the service to citizens.

The UK’s lead has come about through the inspired and innovative approach that is being taken towards the technology infrastructure. Most prominently is the increasing adoption of service-oriented architectures.

Without doubt service-oriented architectures could be dismissed as yet more marketing jargon. However, their aim is worth considering.

Service-oriented architectures are concerned with putting in place a flexible IT architecture that allows an organization to respond rapidly to change and to provide transparency and traceability of change in terms of processes and policies. With a service-oriented architecture, the organization will be able to define, implement and audit — in real time — processes and policies, from scratch or incrementally.

So how can a service-oriented architecture achieve that? The key idea is one of approach: business processes and policies, the dynamic parts of an organization that are subject to change, should be implemented separately and loosely coupled with the business services that support them.

Now technologies are available to deliver this with the convergence of enterprise application integration, workflow and business process management and the increasing success of the business rules management system as a method of implementing and automating rules-based policies.

The public sector is one of the early adopters of service-oriented architectures. Two years ago the then e-envoy, Andrew Pinder, in a visionary meeting with analyst firm Gartner, hinted at the importance of business rules and the need for information to be lifted out of back-office silos and made more dynamically accessible. Pinder may not have been referring to service-oriented architectures directly, but it was clearly a prerequisite for the coming e-government initiatives.

Recent public sector projects highlight this approach. In the National Assembly for Wales system for the distribution of more than £160m in EU subsidies to Welsh farmers, business process management and business rules were used on a service-oriented architecture. The patient records database for the NHS national program for IT could be the largest service-oriented architecture implementation in the world.

Today, in most of organizations, as the IT manager creates network and application topologies, the real-time needs of services like voice and video must be balanced against the generic data abstractions of an SOA. Adding application-specific elements like voice codec manipulation and call admission control services can improve the ability to manage the network, as well as the user’s experience when placing calls using applications in the SOA.

Conclusion

Today, in this modern world, Service-oriented architecture benefits government agencies or other large organizations to perform computer functions quickly by getting different parts of their software to work together on a single job, with each task done independently. (The Washington Times, 2006) In the same way, ERP systems have received much consideration for their prospective to guide companies make more effective decisions relevant to Service-oriented architecture.

Recently we have noticed that making the PBX reachable by SOAP applications is only a pace, an important tool, in the direction of making the telecommunications system both a publisher of and subscriber to services in the larger organizational setup. While challenges remain, and the architecture chosen by the enterprise must take into account issues that arise because of the addition of real-time applications into the SOA, enterprises that leverage services stand to gain economic and deployment advantages that are simply not available from traditional PBX/mainframe architectures. This is not to suggest that an ERP system cannot help company boost revenue, or that employees cannot learn to become more productive with the aid of ruler. But the difficulty and expense of deploying ERP mean that most companies should appraise such an investment purely in terms of its potential to cut costs.

Clearly, the future of service-oriented architectures rests not on one development, but on several. First, companies have to solve the reuse problem. To do this, they must become competent at modifying their existing software resources to help cope with the necessary up-front investment.

Mature development methodologies are important in a world where many companies are still sketching out software architectures on the back of an envelope. Until they reach this stage, they will be unable to tackle what is perhaps the most important step: the use of business process automation to help co-ordinate the provision of software services.

But the onus does not rest totally on the customer base. The industry also has to ratify more scanners to help create a robust control layer that will enable web services to be reliably connected together to form loosely coupled transactions, said Ferreira.

Some of the necessary web services protocols are now working their way through ratification, and others, in areas such as event management, still have a long way to go. The proof is in the pudding: Stack said that customers trying to create shared web services as the basis for a service-oriented architecture have only generated a handful, indicating that there is a long way to go before service-oriented architectures find a solid commercial footing — if at all.

References

James, Dorien & Wolf, L. Malcolm (2000) A Second Wind for ERP. The McKinsey Quarterly, p.100.

The Washington Times (April 4, 2006) “Firm Bets on Service Software”, p.C10.