Coordination of a Service Oriented Architecture

As e-commerce models and applications have been widely employed in today’s business environment, a new movement to so-called dynamic e-business has been urged to advance e-commerce applications to the next level: simplifying business interaction over the Web through effective and widely accepted messaging and data encapsulation standards (Chen, Chen, & Shao, 2003). Gisolfi (2001) defined dynamic e-business as the next generation of e-business focusing on the integration and infrastructure complexities by leveraging the benefits of Internet standards and common infrastructure to produce optimal efficiencies for intra- and inter-enterprise computing. Infrastructure for both inter- and intra-organizational computing has undergone a significant maturation process from centralized mainframe computing to early distributed client/server environments, and most recently taking on a service orientation (Roure, 2003). Service-oriented architecture (SOA) represents the framework for the latest generation of service-based computing where once proprietary and monolithic applications are broken down into components and exposed through open standards for use by both internal and external enterprise partners. The SOA paradigm is argued to include in its list of benefits a higher return on investment, increased software reuse, and the capability to support dynamic service assembly (Stevens, 2005). An increased return on investment is achieved through the componentization of application capabilities. The argument goes that the usefulness of a component (defined here as bounded by its functional capabilities to one distinct business domain) outlives the usefulness of an application (since applications are developed to support a subset of processes in a domain while a component is not constrained, by definition, to any particular process set). Within the SOA paradigm, the development of applications to support a set of business processes is replaced with the connecting of components from distinct business domains in order to address the computational needs of a particular process. It is clear, then, that SOA has a positive impact on software reuse as components are leveraged across many configurations to address the specific computational needs of many different processes. To this end, one can map the reusability of components in an SOA context to the third argued benefit—dynamic service assembly. Dynamic service assembly means that components are not developed with the complete set of application scenarios in mind. Instead, components are created to exemplify the information and computational contribution of a specific business domain. The choice of how these components are used later on is therefore not limited to assumptions of usage made at the development stage. Indeed, it is possible that the most valuable use for any given component may not exist at the time of component development. As business processes evolve dynamically over time and business needs for information and computational support change, a service orientation leveraging components that are developed in the absence of constraints for how they might be utilized allows for dynamic reconfiguration of services in order to adapt to changes in the business processes themselves. This ability to reconfigure increases reuse and extends the lifetime (from a value perspective) of the components that are developed. This, in turn, feeds back to an increased return on the investment in software development which is typically the primary motivation for buy-in to the SOA paradigm. Similar to the shift from a mainframe to a client/server architecture (Malone & Smith, 1988), however, the shift to a service-oriented architecture requires consideration of costs associated with coordinating activities in this new environment. Management of these coordination costs will be necessary in order to preserve the purported increases in return on investment. Put simply, if the return on investments in software development increases but the costs associated with leveraging the developed information technology artifacts for business value also increases, then it is possible that the value created will be diminished or even overrun by the operational expense of coordinating use. In order to ensure that this is not the case, this article leverages a coordination theory approach to first understand the impact that a shift to service-oriented architecture will have on the cost of coordinating activity both within and across the firm, and second to make recommendations for how these coordination costs can be addressed to preserve the return on investment from a shift to service-oriented architecture.