ALIGNING INFORMATION SYSTEMS DEVELOPMENT WITH SERVICE ORIENTATION: THE SERVICE ORIENTED SYSTEMS

MODEL

Thomas, Manoj, Virginia Commonwealth University, School of Business, Richmond, Virginia, USA, mthomas@vcu.edu

Weistroffer, H. Roland, Virginia Commonwealth University, School of Business, Richmond, Virginia, USA, hrweistr@vcu.edu

Abstract An information systems development framework is proposed to specifically deal with the characteristics of service oriented architecture (SOA) systems. The paper points out the limitations of existing development methodologies in dealing with systems in an SOA environment, and describes a new approach, the Service Oriented Systems Model (SOSM), to better align information systems development with service orientation. Keywords: Service Oriented Architecture, Service Oriented Systems Model, Service Compositions

1 INTRODUCTION

Traditional information systems development (ISD) approaches tend to neglect an important fact − that organizations are not closed systems – but rather exist in dependency with other organizations or agencies (Wheatley, 1999). These dependency relationships are often overlooked during the systems design process or when reengineering business processes (Alonso, Agrawal, Abbadi and Mohan, 1997). This limitation may be traced to a desire to protect and isolate the processes and operations from rival organizations in an environment where businesses focus on gaining competitive advantage.

ISD methods and tools were originally developed based on assumptions that system developers perceived as important in their day-to-day activities (Hirschheim and Klien, 1989). Business process modeling (BPM), object oriented analysis and design (OOAD), Unified Modeling Languages (UML), and Rational Unified Process (RUP) are some examples that come to mind. But times are changing, and innovation has exceeded most expectations and foresight. The growing popularity of semantic Web standards along with the vision of Web 2.0 to create a 'web of data' (Web 2.0, 2006) has brought forth new concepts of organizational intelligence, encompassing quick, efficient, and reliable sharing of information between partnering institutions. To operate successfully in today’s increasingly open marketplace, companies must be agile and require systems that allow information to flow freely and openly (Kettinger, Tang and Guha, 1997; Wheatley, 1999). Recognizing the importance of rapid and reliable means for information exchange, companies are now investing heavily in third party software solutions, which were not requisite functions when the existing systems were originally conceived and designed. In the fast growing and evolving field of information systems, this situation cannot be blamed entirely on oversights during system analysis and design, but rather, has to do with the pace of development of new technologies. ISD approaches tend to fall behind in this catch-up race, and inadvertently, traditional systems development methods and activities are unable to sufficiently adapt and include evolutionary technologies. Consequently the real challenge facing researchers precisely reflect the propositions of Hirschheim and Klien (1989): determine means to incorporate technological advances and changes to further the development and refinement of information systems development methodology (Hirschheim and Klien, 1998).

1669

Service oriented architecture (SOA) perhaps represents the latest craze in information technology, fueled by the ever-changing face of internet technology and the relentlessly evolving state of conducting business online (web reference 1, 2006). Borges et al. (2006) describe SOA as “an architectural style that supports loosely coupled services to enable business flexibility in an interoperable, technology-agnostic manner” (Borges, Holley and Arsanjani, 2006). SOA consists of a composite set of business-aligned services that support a flexible and dynamically re-configurable end-to-end business processes realization using interface-based service descriptions (Borges, Holley and Arsanjani, 2006). As SOA is evolving as a powerful means of using web services for information exchange, adjustments in business processes need to be made. SOA specifications promote creating application code as components of business logic that are reusable and available to other business systems. These reusable service components can be choreographed to build systems and applications on the fly. Component-based service architecture thus offers promising approaches for managing complexity and reusability (SCA, 2005) among partner companies that have adopted some form of SOA implementation.

Developing information systems that support SOA specifications requires a new way of thinking, i.e., placing strong emphasis on the interaction capabilities of the participating systems. Service components are unique in their qualities and have the potentials to support a level of application integration and flexibility (SOM, 2004) that previously would have been considered outlandish, due to the distinct nature of each organization’s ISD approach. With the development cycles for Web applications, portals and e-business market places getting shorter and shorter, service components will become pertinent and significant artifacts of business process planning for the future (Web reference 1, 2006). SOA offers a layer of abstraction based on open standards, which in turn allows technical, philosophical and methodological disparities to no longer pose major integration threats. However, there exists no formal ISD approach that views SOA as a natural, evolutionary extension to traditional methodologies, nor are there any new methods that offer a systematic approach to sustain development and modeling issues associated with a SOA. The objective of this paper is to propose a Service Oriented Systems Model (SOSM) that incorporates the service discovery and retrieval tasks of SOA with information systems development efforts. The goal of SOSM is to help organizations architect a well planned service composition structure in line with business objectives intended to add value to organization at an enterprise level. The methodology used is essentially design science, though the proposed model still needs validation.

The rest of this paper is organized as follows. We first provide a high level overview of SOA, and discuss the features that are unique to service compositions and that warrant suitable development methods. The limitations of existing methodologies in addressing the new way of thinking about distributed service discovery and dynamic composition are expounded in the next section. In the following section we present the SOSM to address these limitations. We conclude the paper with a summary section that looks at application of SOSM and future directions of research and development in this area.

2 SERVICE ORIENTED ARCHITECTURE

In simple terms, SOA can be viewed as an architectural style for developing loosely coupled services that can be used across more than one application (Babcock, 2005). SOA provides flexibility and dynamic re-configurability, thereby enabling businesses to meet their end-to-end process realization (Agarwal, Bayardo, Gruhl, Papadimitriou and Vinci, 2002). One of the main pillars that enable enterprises to subscribe to an SOA model is the capability to determine service functions that other organizations offer. Effective service discovery is reliant on extensive catalogue (registry) searches for appropriate services across multiple application domains (Paul and Ghosh, 2006). Universal description, discovery and integration (UDDI) has evolved as a core Web service based standard that enables this process. UDDI is an XML-based public registry that businesses use to publish their

1670

service listing, discover each other’s services and define how the services can be accessed so that software applications can interact with the services in an automated manner. The service component of each organization has an interface description that can be determined by a web-query on the UDDI. Although Microsoft, IBM, SAP, NTT and others used to provide UDDI business registries (UBR), these public access registries are now integrated services from each software vendor’s product offerings. For example, the Microsoft Windows Server OS now includes Application Program Interface (API) for automated access to UDDI registries hosted on the server. UBR services hosted on the server also provide human-friendly navigation pages for quick and easy retrieval of information from the registry. Once a Web service has been developed and deployed, it is listed on the URB, and applications can consume the right Web service by identifying the network location of the web service (in most cases, a URL) from the registry. The deployed services may reside on multiple servers, on geographically disparate systems, or may be hosted on dissimilar operating systems. Irrespective of these differences, a business function whose application logic involves invocation of services can be structured by identifying the series of services based on simple UBR lookup. For example, a customer requesting a quote can call the web service implemented by the supplier, which synchronizes the response by invoking the retailer’s web service after checking the warehouse for availability. The UBR acts as the runtime broker by mediating the web service calls and propagating changes to applications whenever the access endpoint information is updated or changed.

SOA can be viewed as the guiding principle that defines these concepts and the Web services are the software implementations of the evocable component services. The Gartner group defines SOA as the software design principle, and defines Web services as the technical specifications (Natis, 2003). Based on the functional requirement of the business process (the composite service), the target functional modules (the components) are identified by referencing the UBR. SOA orchestrates the evocation of services and synthesis of the components in an automated manner to accomplish the objective of the composite service. Service data objects (SDO) are used to ensure the smooth flow of information between components and to ensure uniform access to business data in a secure fashion (SCA, 2005). The composition of services in this manner is illustrated in figure 1 (adapted and edited from Chatterjee and Webber, 2004).

Businesses gain advantage from the use of SOA through the inherent ability for automated service compositions. Given a set of services, S, determined from a public UBR, a client can request a component and automatically create a composition schema that fulfills the requisite end-to-end process by suitably orchestrating the functional components. For illustrative purposes, let S = {s1, s2, …, sm} be a set of component services, and let p = x1+x3+x5 define the business process consisting of component services s1, s3, and s5. Automatic service compositions are evoked when dynamic composition of components is choreographed to meet a certain functional goal. Choreographing the automated composition of components that go into the business process p can be fulfilled by suitably orchestrating the requisitions from S as determined from the UBR.

Automatic compositions are powerful service functions that provide effective capabilities for loosely coupled co-existence with other partner organizations. For example, Amazon.com’s E-commerce service offers component APIs that outside businesses can use to connect with shoppers. Even though Amazon constantly updates its internal service architecture, the orchestration process is seamless since the external API remains fixed, stable and unchanged (Babcock, 2005). Although numerous organizations have taken initiative to establish similar service composition capabilities, the lack of an appropriate formal systems development model has resulted in adaptations that are ‘patch-on’ artifacts rather than well planned and implemented solutions.

1671

Figure 1. Dynamic composition of services using SOA

Implementing imperfect service compositions simply for the sake of joining the bandwagon may do more harm than good. Such a solution approach may be incapable of reaping the benefits of service composition, create a lack of awareness among end users and be cost ineffective for use on a broader scale. What is needed is a formal ISD method specifically to cater to the uniqueness of service composition − an approach that can be an extension of existing systems development methodology or an entirely new proposition. Determination of information requirements, design concepts, software testing and evaluation, time estimates, clustered hardware, distributed software design linkages, and planned exposition of consumable services are decisions that need to be coordinated in a systematic manner.

3 MOTIVATION

Practitioners who have undertaken SOA implementations and researchers who have a consummate understanding of ISD methodologies and theories will agree that existing development processes, techniques, and tools such as OOAD, RUP and UML, go a long way in helping identify and model processes, event flows, and logical structures. Many agile methods such as Extreme Programming (XP), SCRUM, Crystal, etc. have achieved popularity by embracing the qualities subscribed by the Agile manifesto (Lindstrom and Jeffries, 2004). However, the development process in the SOA context requires a different perspective.

The concept of service compositions that surround SOA is build upon two major elements (SCA, 2005) – implementation of components to perform a distinct function of the composite business process, and assembly, which is the orchestration of components to build the composite process. SOA induces dynamics into systems development through the use of three elements, namely: services,

1672

flows, and components (SOM, 2004). While component design can clearly benefit from adhering to OOAD principles (such as encapsulation, inheritance, modularization and polymorphism) for retaining the convenience of an intuitive natural structure, service composition and choreographing the conversation flow between components need a new way of looking at systems development. Awareness and identification of services from a self replenishing pool of internet URI (uniform resource identifier) references, and flow composition at run-time are some of the factors that cannot be adequately addressed through UML, RUP, or BPM.

The difficulty to adapt popular development methodologies for service composition is predominantly due to the unique mechanics associated with SOA. For example, consider some of the service characteristics fundamental to SOA. The services may be hosted off differing hardware with organizational specific configurations to integrate with legacy functional modules developed internally. The development and testing of SOA is extremely challenging due to the highly distributed and dynamic nature of the application. The deployment and use of the system is unlike any controlled internal environmental and developmental characteristic of traditional systems architecture.

There is also the duality of security concerns. To ensure effectiveness, the architectural requirements of SOA should be adequately open to allow execution of native component code accessible through services, while ensuring no compromise to internal security. Service Oriented Systems Model precisely addresses these issues and makes it possible to synthesis business processes in a loosely coupled fashion. It is also important to realize the role of participants in an SOA environment. Participating service providers can be both the service providers and the service consumers. For example, any functional modules built for some predetermined line of business processes can be uncoupled and exposed to business partners. The partners can discover and combine requisite modules to create applications for their specific business needs. The organizations supplying components are now service providers, while the partners orchestrating new workflows through component reuse take the role of service consumers (SOM, 2004).

Clearly, service choreography, component wiring, service lookup repositories and related themes in SOA require explicit attention during the analysis and planning process. OOAD and use case modeling using UML definitely play a role within SOA, but only at a micro-level of abstraction to model the granular components of a business process. Object oriented principles focus on creating levels of abstractions (classes) which can be linked through associations (has-a relations) and inheritance (is-a relations), thereby creating a sense of tight coupling. On the other hand, a necessary condition for service orientation is loose coupling between the components (Zimmermann, Krogdahl and Gee, 2004). Object oriented methodologies also offer no easy way for cross-system object-sharing other than using tedious programmatic logic, involving remote object invocation and access through complex adapters like DCOM, CORBA or EDI. This severely limits its use as an ISD methodology for SOA based information systems. Where use-case modeling is useful for centering component development based on use-case scenarios, it is important to remember that SOA on a global scale, is more or less process driven. The goal of service orientation is to transform the components into discoverable entities that can be orchestrated automatically into bigger composites. BPM methodologies can help in accomplishing this role by defining the activities in a business process which in turn serve as guidelines to identify the right components and piece them together into complete solutions. A distributed software architecture where the participants’ roles are hazy (being either a consumer or a provider or both at any given instant in time) mingled with many disparate systems and architectures, create a porridge that cannot be modeled completely using RUP and UML.

Without a formal ISD methodology that considers the unique nature of orchestration and composition of component services, the best that can be expected through the use of traditional development methodologies is the construction of a meta-model that describes the activities involved in SOA. What this discussion converges on is a context where the concepts and principles from traditional ISD approaches need to be integrated into a new systems development process that can appropriately address future SOA development and implementation. The SOSM discussed in the next section addresses these concerns.

1673

4 SERVICE ORIENTED SYSTEMS MODEL

What makes SOA attractive to businesses is the ability to automatically discover services, negotiate contracts and deliver results by combining components needed to fulfill business process requirements. By relying on workflow rules as the guiding principles, SOA promises great opportunity for incremental development, deployment, maintenance and extension of business applications across organizational boundaries (Natis, 2003).

Whether the goal is creating aggregator services whereby, for example, advertising services from Google can be leveraged to extend product offerings through EBay.com or Amazon.com, or the goal is to consolidate vacation packages by combining hotel reservations, airline bookings, and car rentals as unified services, a methodology that describes the full life cycle of SOA is essential for completing the architectural patterns of modern, agile enterprise IS solutions (SOM, 2004). The systems planning, analysis, and design workflows for SOA within an organizational context can be best modeled using the proposed SOSM, shown in figure 2.

For the purpose of illustrating SOSM, consider the case of a home buyer requesting a loan. To the potential home owner this is where the rubber meets the road, as the mortgage qualifying process essentially determines the type of home the applicant may buy. To the loan officer, it’s a critical process that can identify red flags prior to the loan approval and sanction. In reviewing the loan application, the loan officer, in his attempt to paint the most accurate picture of the borrower, can use a service composition based architecture to bring together relevant information from various sources. For the sake of simplicity, assume that the loan officer accesses specific data sources pertaining to the following three categories of information: employment history, financial stability, and credit record. Information from these sources will help the loan officer to determine the correct loan amount based on an applicant’s credit and employment history, income and debt, and property investment goals. The employment history provides pertinent information regarding employment dates, addresses and salary data, while financial stability resorts to multiple other data sources to validate information regarding investment accounts, stocks and bonds, checking and saving account balances, retirement plans, life insurance policies and such. In addition, the final loan amount is also a factor of the applicant’s residential history (real estate rented, owned or sold) and the credit rating scores from one or many credit reporting agencies.

Developing an Information System to support the loan officer is complex and involved. The officer may interact with a finite set of known services to collect information or request additional information from other sources. The pre-determined set of services may cease to exist or the functional structure of the services may change over time. New services may become available that might offer better information at cheaper rates. Changing from one service to another can be complicated, requiring tedious software changes, especially if the systems are incompatible. Consequently, a tightly coupled IS solution that binds a set of inter-organizational business functions will be costly in the long run, and limited in flexibility, effectiveness and expansion opportunities. SOSM offers a development method to build an information system that can reduce the complexity of automating the qualifying evaluation by tying into remote components that provide data on credit reports, financial stability and so forth. The result is an efficient system that can accommodate changes irrespective of the middleware technologies used to implement the independent service modules. The flexibility of service interfaces allows easy setup of new service-level agreements as they become available, rather than reconstructing the entire application. SOSM consists of four important phases: synthesis, design & develop, realization, and education. They are described below.

4.1 Synthesis

The characteristics of completed information systems depend on the problem that was to be solved, the development process and the resources employed for development (Naumann and Jenkins, 1982). Synthesis is the step that captures the essence of the planned information system, the objectives to

1674

accomplish, the problems to solve and the resources necessary. This is the first and foremost step in SOSM. In this phase, the results from two mutually exclusive but related steps, expectation and exposition, are synthesized to develop a dependable SOA based information system. Expectations address the social factors and organizational concerns, whereas exposition is oriented towards the intent of components and software options. The importance of planning and dedicating time for synthesis cannot be overemphasized.

4.1.1 Expectation

The purpose here is to conceptualize the objective and goals of developing the new system from the perspective of social requirements and organizational support. Failing to carefully conceptualize and communicate the overall mission only fragments the IT investment efforts (Amabile, Conti, Coon, Lazenby and Herron, 1996). The focus of this step is to create the working team, identify the members (business analysts, technical programmers, and project lead), define roles and responsibilities, and evaluate the technical expertise, creativity and tool skills necessary to implement the project. Clear development goals are necessary to reduce potential for fragmented and disjointed efforts (Cooper, 2000). Expectation seeks to clarify risk analysis (Baskerville and Stage, 1996), responsibility assignment, and resolution strategies, incase of conflicting ideas, before the team is ready to move forward with the design and development workflows.

Figure 2. Service Oriented Systems Model (SOSM)

4.1.2 Exposition

This affiliate step sets forth the meaning or intent of the services components that will be offered or consumed through the SOA system. Service components will be put to use depending on whether the role is a consumer or a provider. Analysis of requirement specifications of the components, review of software and technology, and feasibility studies for service compositions and orchestration are laid out in detail in this step. The nature of the business, requirement of particular applications, and the dynamics of developing a system that selects and consumes services on the fly make it a critical part of the synthesis phase. Using context scenarios reduces the risk on software projects by putting an early focus on the validity of requirements and thereby improving the maturity of the software development process (Dzida and Freitag, 1998). Rudimentary design proposals, intended use, software concepts, development maps and reviewing context scenarios are performed in this step to ensure that the systems development experience is clean and programmatically simple.

1675

The goal of SOSM is to assist organization with the dynamic composition of complex services by wiring components together efficiently. At the end of the synthesis phase, there is clear agreement and vision among the members regarding expectations and exposition of the system to be developed. Congruence and consistency of understanding are vital before progressing to the next phase in the SOSM.

4.2 Design and develop

The second phase of SOSM involves the actual development of the components that are at the core of service orientations. This phase benefits by borrowing heavily from existing systems development methodologies. Prototyping, OOAD and agile processes contribute in the design and development of individual component modules. Business Process modeling is useful in this phase to specify process chains representing the conceptual process flows (Zimmermann, Krogdahl and Gee, 2004). This is important since SOA is primarily a process driven approach rather than event driven. Process models can then be represented in Business Process Execution Languages (BPEL) or Ontology Web Language (OWL) for tag based description of operations (Thomas, Redmond, Yoon and Singh, 2005). A flow model described using BPEL or OWL helps identification of service components contextually and determines the flow of control necessary to orchestrate the coordination of services. The technical details of these advanced features are designed and tested in this phase. Once the flow model is developed conceptually, the technical team develops all SOA components, service descriptions and UBR repositories making use of agile processes, UML and OOAD principles. Following the principles of the agile manifesto helps deliver high quality working components in short time scales and promotes sustained development efforts (Agile Manifesto, 2001). Agile business process management benefits from SOA (Natis, 2003) and SOA benefits from agile concepts. At a granular level, the component abstractions, associations and modularization can be established using UML and optimized through object programming principles. Developing components as independent entities allow loose coupling, which is an essential criterion for composing business processes through service consolidation.

4.2.1. Parking

This is an important element of the design and develop phase and is a unique requirement in SOSM due to the nature of SOA. Service repository subscriptions, service repository lookup, service compositions and orchestrating communication between the components of a composite service are distinctively different and specialized concepts unlike in any standalone or distributed information systems applications. Consequently, these distinctions have to be formalized through a well defined set of procedures, quality factors and best practices. In this step, legacy system modules exposed through service definitions and components developed from the ground-up are hosted for limited access preview to check for security and quality analysis. Components in SOA and their listing in the registries are time sensitive in nature and therefore small releases are not possible until they are functionally complete and ready to be made available for consumption in the public domain (Lindstrom and Jeffries, 2004). Rapid prototyping is a development process that is well suited for quick release of components. Here prototyping will cover quality tests, controls, and security checks of the functional modules that exchange SDO. Since services are described and accessed in an inter-networked environment, the parking step allows hardware and software simulation needed to check security measures, host services and compose business processes in a test environment that is a close representation of reality. Parking provides direct feedback to its parent, the design and develop phase.

Once the data designs, process designs, testing (through simulated context scenarios), quality checks, and security controls are completed, the development moves to the realization phase.

1676

4.3 Realization

This phase involves the actual implementation and use of SOA in the production environment. Once development has moved to this phase, SOA provides an enterprise-scale architecture that links resources to cater to the demands of a business process. A dynamically reconfigurable architecture style enables business agility that allows business analysts and functional teams to bind component services into composite business process solutions on the fly (SOM, 2004). From the perspective of a provider, this is the phase where discoverable services with externalized service description, accessible through URIs, are listed in the public UBR for consumption by others. Completion of component service design and development thus opens two avenues:

• Exposing services offered by the organization. This is important for expanding and advertising the organizations business offerings. At an enterprise level, this is highly desirable, as different service components can now describe their functions for internal and external consumption.

• Consuming a component in the most cost effective, secure and reliable manner. As a consumer, services are bundled together through orchestration to support specific use cases described by BPEL or OWL.

Assessment and monitoring of the new SOA system are other important activities that are carried out in the realization phase. This provides a mechanism to validate the quality, standard of use and capability of all APIs and services offered through SOA. Feedback from this activity is conveyed back to the design and develop phase for additional improvements or service reconfiguration, the necessity of which may have been observed during the actual system use.

4.4 Education

This phase of SOSM is educating enterprise users about the flexibility and convenience of composing business services in an ad hoc manner. SOA and related concepts of component re-use for creating composite business services are notions that require a different approach to systems thinking compared to traditional systems. UBR domains, deciphering services described in WDSL documents, and orchestrating service compositions are some important activities that require new learning. Unless internal stake holders and system users are trained in these areas, the project will fail to reap the rich benefits of SOA. Value added through component reuse and dynamic service creation represents an opportunity that may be lost unless organizational culture is willing to embrace and adopt the new technology. The project team lead should strive to develop cooperation and trust among users by helping them understand the merits of the system, listening to their needs, and keeping them updated on changes. The project leads should work with upper management to determine the best migration strategy that minimizes disruptions and risks. Value of interaction and communication at a social level is essential to muster the confidence and encourage use of the new system.

The goals and purpose of the different phases of SOSM is summarized in figure 3.

1677

Figure 3. The four phases in Service Oriented Systems Model (SOSM)

5 CONCLUSION

SOA offers a level of flexibility and reuse in organizational information systems design while opening channels of communication and collaboration with other organizations. Reliability and enhanced performance from the use of SOA can be accrued only if the chosen ISD process considers and includes component architecture specifications. Many new and innovative concepts are brought together in the service-based component architecture. A thorough understanding of the new standards and functional knowledge of service descriptions is necessary before an organization can venture to into the realm of SOA. This comes with its own set of virtues and liabilities. SOA offers incredible ability to adapt to the changing face of business contracts with minimal software reconstruction. Access to service interfaces is all it takes to create new service-level agreements with minimal technical intervention. Systems, software and processes can remain the same, irrespective of what underlying technological layer (programming languages, hardware architecture and software infrastructure) is used. This flexibility even allows hard to replace legacy system functions to be exposed as services through a simple URI reference. All in all, SOA presents immense opportunities

1678

for IT cost reduction, unmatched adaptability to myriad types of support structures, and quick response to changing business process requirements.

SOA adoption also comes with some added costs. The primary concern is the requirement among users of the system to learn new technologies and willingness to change. Without proper support and vision of higher management, SOA will be a difficult undertaking to accomplish. Accountability and reliability are other aspects of concern. Considering that a business process can literally be composed on-demand in a short interval by reusing existing external modules, there is a burden of trust and assurance that has to accompany the components. Currently there exists no dependable safeguard to ensure this expectation. Future research and development should address these issues. Although SOSM incorporates flexibility to address these concerns, the accelerated pace of technical changes and the recentness of SOA implementations calls for longitudinal evaluation in real world scenarios to identify issues that will help to refine the proposed model. Companies considering technology as an enabler are already using SOA capabilities as part of their core competencies. However, it is important to note that SOA is not the answer for every business process or application. The key is to identify the process components that might be captured as services and to think about new ones, through better understanding of the operating environment and the business goals to be accomplished. Inquiry into developing heuristics that will help practitioners adopt SOSM with relative ease also needs to be scrutinized. Given the changing face of the Web and open access standards, companies are almost guaranteed to be at the losing end, unless serious initiatives are pursued to include SOA as part of the overall IS strategy.

References

Alonso, G., Agrawal, D., El Abbadi, A., and Mohan, C (1997). Functionality and Limitations of Current Workflow Management Systems, IEEE Expert, 12(5).

Agarwal, R., Bayardo, R., Gruhl, D., Papadimitriou, and Vinci, S. (2002). A Service-Oriented Architecture for Rapid Development of Web Applications, Computer Networks, 39(5), 523-539.

Agile Manifesto (2001). www.agilemanifesto.org , accessed 27 May, 2006. Amabile, T.M., Conti, R., Coon, H., Lazenby, J., and Herron, M., (1996). Assessing the Work

Environment for Creativity, Academy of Management Journal, 1154-1184. Baskerville, R. and Stage, J., (1996). Controlling Prototype Development through Risk Analysis, MIS

Quarterly, 20(4), 481-504. Borges, B., Holley, K., and Arsanjani, A. (2006). Delving into Service-Oriented Architecture,

(accessed 11 March, 2006) http://www.developer.com/java/ent/article.php/10933_3409221_1 Babcock, C., (2005). SOA. Work in Progress, Information Week. Chatterjee, S., and Webber, J., (2004) Developing Enterprise Web Services, An Architect’s Guide, 1st

Ed., Prentice Hall Publications. Cooper, B.R., (2000). Information Technology Development Creativity: A Case Study of Attempted

Radical Change, MIS Quarterly, 24(2), 245-276. Dzida, W. and Freitag, R. (1998). Making Use of Scenarios for Validating Analysis and Design, IEEE

Transactions on Software Engineering, 24(12). Hirschheim, R., and Klien, H., (1989). Four Paradigms of Information Systems Development,

Communications of the ACM, 32(10). Kettinger, W., Teng, J., and Guha, S., (1997) MISQ Archivist for Business Process Change: A Study

of Methodologies, Techniques and Tools, MIS Quarterly, 21(1), 55-80. Lindstrom, L., and Jeffries, R., (2004) Extreme Programming and Agile Software Development

Methodologies, Information Systems Management, 21(3), 28-34. Natis, Y. (April 2003), Service-Oriented Architecture Scenario, Gartner Group, ID Number: AV-19-

6751. Naumann, J. and Jenkins, M., (1982) Prototyping: The new Paradigm for Systems Development, MIS

Quarterly, 6(3), 29-44. 1679

Paul, M. and Ghosh, S.K., (2006) An Approach for Service Oriented Discovery and Retrieval of Spatial Data, Proceedings of the 2006 International Workshop on Service-oriented Software Engineering, p. 88-94.

SCA - Service Component Architecture (2005) IBM Developerworks Library, (accessed 11 March, 2006)

http://www-128.ibm.com/developerworks/webservices/library/specification/ws-scasdosumm/ SOM - Service Oriented Modeling and Architecture (2004) IBM Developerworks Library, (accessed

11 March, 2006) http://www-128.ibm.com/developerworks/webservices/library/ws-soa-design1/ Thomas, M., Redmond, R., Yoon, V. and Singh, R. (2005) A Semantic Approach to monitor Business

Process Performance, Communications of the ACM, vol.48, 2005. Web 2.0, (accessed 27th May, 06) http://www.digital-web.com/articles/web_2_for_designers/ Web reference 1: (accessed 27th May, 06)

http://www.networkcomputing.com/channels/appinfrastructure/showArticle.jhtml?articleID=177104882

Wheatley, M. (1999) Leadership and the New Science, Barrett-Koehler Publishers, 2nd Edition, 1999. Zimmermann, O., Krogdahl, P. and Gee, C., Elements of Service-Oriented Analysis and Design

(2004), http://www-128.ibm.com/developerworks/webservices/library/ws-soad1/

1680