Methodology for Educating Information Systems Students on the New Paradigm of Service-Oriented Architecture (SOA) Technology James P. Lawler jlawler@pace.edu Bel Raggad braggad@pace.edu H.Howell-Barber h.howell@verzion.net Information Systems Department Ivan G. Seidenberg School of Computer Science and Information Systems Pace University New York, New York 10038, USA Abstract Service-Oriented Architecture (SOA) is being adopted aggressively by business firms. SOA is defined as an enabling framework for improving business processes for competitive advantage. This paper analyzes the challenges of deploying SOA through an experiment of case studies in industry and discloses that firms that lead projects of SOA with business and procedural dimensions have more success with SOA than those that lead projects with technical functionality. The paper posits a technology agnostic program management methodology on SOA that is adaptable in the curricula of information systems students. This paper will benefit schools of information systems attempting to educate students on SOA as a new paradigm of 21st century technology. Keywords: information systems curricula, program management methodology, project management methodologies, service-oriented architecture (SOA), Web services 1. BACKGROUND Our research into a methodology for educating information systems students on service-oriented architecture (SOA) began with an analysis of web services in 2003 – 2004 (Anderson, Howell-Barber, Hill, Javed, Lawler and Li, 2005). In that analysis, we found that firms which led projects in services with business factors, especially business benefit, customer demand and focus on process integration, had more success with web services than firms which led with the functionality of platform technology. Business strategy defined by business departments in the firms, not technology, was considered to be crucial in a web services strategy. These results, presented by us at conferences in 2004 and published in 2005, were beneficial for firms considering an approach to application automation and information architecture founded on web services. Since the completion of our analysis, we continued our research of services in 2005 - 2007, as SOA was and is being adopted by firms on actual applications. The best of the adoptions of SOA appears, as in web services, to be based on business considerations, not on applications and technology. Consulting firms disclose constant adoption of SOA projects in industry (Daniel, 2006). Gartner Inc. forecasts 80% of development to be on an SOA model by 2008 (Gruman, 2006). Despite a current absence of firms completing a composite of all processes of a business as services, composed in a fully deployed SOA in a service-oriented enterprise (SOE) idealized by consultants, firms in the software industry continue to develop and extend service solutions as tactics in an assumed strategy. SOA is not considered a fad but a development as consequential to industry as the Internet (Hurwitz, 2006). Because of the hype on services technology, we decided to expand our studies to SOA. Further study is appropriate, as business firms are beginning to achieve benefits of agility and flexibility in business processes. SOA, as applications exposing functionality and information as services accessible by different business client or “consumer” departments in a firm, is a concept defined extensively now in the literature of practitioners. The distinction of SOA, in contrast to earlier hyped technologies, is in the actual benefits now being achieved by firms. SOA is clearly a new paradigm that educators in information systems have to introduce into their curricula. 2. INTRODUCTION To achieve the benefits of SOA in a competitive differentiation strategy, technology managers and business managers in firms are confronted with a decision as to the best approach to deployment. Deploying to SOA is more complex in concept than deploying to client/server technology from legacy technology or deploying to web from client/server technology. Consideration of deployment of SOA as a first mover, fast follower, or follower firm is difficult for managers. Hesitancy may be from a culture where the technology department is not collaborative with business departments on technical solutions, not focused on business design or process integration (Chang, 2006), or not knowledgeable in the methodology of object orientation and service orientation (Bloomberg and Schmelzer, 2006) on projects. Developmental methodology on SOA is distinct from non-SOA methodologies, in that process and project requirements of different departments and business units for services in firms, in response to competitive conditions, customer demands or regulatory needs, are not fixed and frequently incomplete on pre- or post-deployed SOA projects. Non-SOA methodologies that include older “waterfall” models contradict enterprise demands of firms to be fast, flexible, incremental, innovative and iterative in releases of services. Non-agile models are serial and slow in an SOA strategy. The issues of SOA are not in the simple and tactical application and departmental deployment stages, but on the path of complex business unit and enterprise process deployment stages that lead to an SOE in an SOA strategy. As the path begins with a defined process in departments and embraces more processes in more business units on more projects in parallel with other projects and with more and more technical and business staff, and as competitive conditions, customer demands and regulatory scrutiny on the processes change concurrently for firms, control of the processes and the projects, and of the services technology, is complex but critical for ensuring an evolving strategy. The complexity of SOA creates a challenge in methodology for firms attempting to define an approach to the deployment of SOA and for schools of information systems attempting to educate students on SOA. 3. FOCUS In this study we define a practical program management methodology that can be complimentary to project management methodologies already established in business firms. Dimensions of service orientation and SOA are customizable in the project management methodologies by application of this program management methodology. Methodologies in the firms are assumed to be agile approaches (Beck and Andres, 2005), or characteristics of agile methods enhanced for control of complex systems, that are complimentary to our program management methodology. This methodology assumes flexibility for changing process requirements of SOA, because of external competitive conditions, customer demands or regulatory needs or due to internal technical or business needs. It advocates delivery of frequent benefits and releases of services on an incremental and iterative project path that leads to an enterprise or full firm SOE. It consists of frequent interaction of the technology department and the business departments and business units in the migration to full SOE. It includes diversely skilled technical and business staff on smaller teams. This methodology is a hybrid approach, which is top-down in design from business management models and bottom-up in design from operations and platform technologies, and is appropriate for tactical and strategic SOA. The program management methodology is an agile approach to an SOA strategy that contributes the benefits of flexibility, efficiency and agility to firms on the path to the idealized SOE, as depicted in Figure 1 in the Appendix. The intent of the study is to define a comprehensive and disciplined Methodology for Enabling Service-Oriented Architecture (MESOA) program management methodology, by which instructors can educate information systems students on SOA. The intent is not to define a new methodology for SOA project management but to clarify aspects of service oriented projects that can complement already chosen project management methodologies that instructors include in their curricula. The assumption, as in frequent literature on SOA (Krafzig, Banke and Slama, 2005), is that instructors can enhance elements of existing methodologies to integrate service orientation. Another assumption and distinction is that the methodology is technology neutral. The final assumption is that the students are already cognizant of concepts of service orientation and SOA, web services and Extensible Markup Language (XML) technologies, from earlier courses in their curricula. 4. PROGRAM MANAGEMENT Methodology The program management methodology is described in frameworks of best practices for participant technical, business and corporate staff on projects of SOA. The frameworks of this methodology, displayed in Figure 2, consist of governance, communications, product realization, project management, architecture, data management, service management, human resource management, and post implementation. These frameworks are coupled or related tasks for managing a program or a project of SOA. The frameworks evolve as the programs evolve in iterative phasing and in incremental steps towards an SOE. The frameworks are flexible for changing process requirements and technologies and for further releases of services. For a firm beyond exploration and deployment of pilot projects of web services, the formalization of the frameworks enables evolution of SOA in a fulfillment strategy towards SOE. Framework of Governance Governance enables the alignment of processes and services with business strategy and results in evolution towards SOE. Governance on projects of SOA ensures that the services conform to a consistent corporate SOA strategy that supports the business strategy of the firm. Because of the evolution in the maturity of projects of SOA, business and technical staff on a project have to learn new project management methods, if not unlearn old methods (Murch, 2000), and governance facilitates learning of program management methodology. Framework of Communications Communications enables emphasis on the business criticality of SOA in the firm, which is articulated by the chief information officer (CIO), if not the chief executive officer (CEO). Communications on a project of SOA ensures collaboration of business and technical staff in a continued plan on the endeavor, coupled with the other frameworks. Common reference of technical and business terminology in the firm is critical on projects of SOA. Framework of Product Realization Product realization enables the analysis and design, development, integration and testing, and deployment and implementation of SOA and is the core of established project management methodology. Product realization on a project of SOA is coupled with the other frameworks and ensures the focus of the projects is on business processes to be evolved into SOA and not on technology. The program to be realized may be implemented in interlinked iterations of internal department application projects to external firm process integration projects, but the iterations may or may not be sequential. Framework of Project Management Project management as a framework enables delivery of projects of SOA. This framework ensures that changes in business strategy are applied as appropriate on a project of SOA. Project management further ensures that processes and services are functioning and implemented as planned in the strategy. Framework of Architecture Architecture as a framework enables compliance of business processes with an SOA model. Architecture on a project of SOA ensures evolution from conversion of functions into services, creation of component services and integration into composite services, integration of internal applications, internal services and external services, to on-demand services in a gradual SOE. This framework ensures seamless integration of hardware and software that conform to service standards and technology. Framework of Data Management The framework of data management enables behaved SOA data services that do not disrupt applications of the firm. Data management on a project of SOA enables implementation of the services, based on access, availability, breath and accuracy of data already in the databases of the applications. This framework ensures consistency of data and control of data redundancy and fractal data replication (Fuller and Morgan, 2006). Framework of Service Management Service management enables continued conformity and coordination of processes and services to the business strategy defined in the above framework of governance. This framework is coupled with product realization on a new project of SOA. This ensures that requirements for new processes and new services or revisions to them are not redundant with existing processes or services and ensures reusability of services. Framework of Human Resource Management Human resource management enables identification of new and revised responsibilities and roles of business and technical staff on SOA. This framework on a project of SOA is also coupled with the other frameworks. This ensures that education of the business and technical staff on the change in culture of service orientation, and of the technical staff on the technology of SOA, is furnished throughout the projects of SOA. Framework of Post Implementation Post implementation enables service and process life cycle tasks following product realization. The framework ensures availability of the applications and services and of the technologies, tools and utilities of SOA. These are formulated in service level agreements (SLA) between the technology department, the internal business departments and the business units. These frameworks furnish the principles of service orientation and SOA in the methodology for an evolutionary SOE. 5. EXPERIMENT Management Methodology From January 2005 to March 2007, an analysis was conducted of 15 Fortune 10 – 1000 firms, based on available information on each of the firms in generic industry literature and on specific interaction with staff in a limited number of the firms. Firms were chosen from evidence of deployment of web services based on SOA (5 firms), deployment of services, integration of process and services architecture and restructuring of organizations and staff (8), and deployment of services based on SOE (2). Deployments in the firms were examples of commonly encountered practices in industry that were evaluated by us with the methodology. Firms covered the automobile (1 firm), banking (3), energy (1), health (1), insurance (2), manufacturing (1), technology (2), telecommunications (2), training (1), and travel and leisure (1) industries. These firms were headquartered in the United States. We analyzed the deployment projects on services in each of the firms with each of the frameworks of our methodology. To the frameworks were applied an evaluation by us of each of the projects perceived by us to be effectively enabled at a high, intermediate or low level of the methodology or not enabled at all. The evaluation highlighted key business, procedural and technical factors on the projects that were perceived by us as having contributed most effectively to SOA strategy. 6. EXPERIMENT FINDINGS WITH PROGRAM MANAGEMENT METHODOLOGY Frameworks The frameworks of the methodology for SOA demonstrated enablement for the projects in our studies. The projects are enabled at a high level of methodology (29.6%), at an intermediate level (34.8%), at a low level (20%), and not at all (15.6%). Table 1 in the Appendix displays the findings on the frameworks. Architecture, service management, post implementation, data management and product realization are cited as enabled more frequently at a high level than governance, human resource management, communications and project management, on the projects. Encouraging is the higher frequency of enablement at high (29.6%) or intermediate (34.8%) levels than at low (20%) or not at all (15.6%) levels, as most of the business firms continue to evolve on their projects to deployment and exploitation of services based on SOE, as further displayed in Figure 3. Findings are clear that business firms in our recent studies continue to evolve in the methodology of SOA strategy. Enabling Factors of Frameworks Key business factors (70.7%) in Table 2.1 continued to be more enabling than key technical factors (55.3%) in Table 2.3 in the frameworks of the methodology on the projects of our studies of SOA. Procedural factors (68.4%) in Table 2.2 are also more enabling than technical factors. Findings confirmed the results of our study of web services, in which business factors were found to be more important than technical factors of services in firms. Business Enabling Factors Service orientation, agility, efficiency and flexibility benefits, reusability of assets, financial benefits and executive technology leadership are cited frequently on the projects in the studies. Strategic planning and focus on improvement of process are cited as drivers on the projects. Business client participation, competitive, market and regulatory differentials, customer demand and culture of innovation are cited frequently as enablers of the projects. Procedural Enabling Factors Infrastructure architecture, process and service deployment techniques, control of program, risk management, and security management are cited frequently on the projects. Responsibilities and roles, change management, information management, process and service deployment environment and service management and support are also cited frequently on the projects. Knowledge exchange, common reference and standards management are cited as enabling in formalizing the methodology on the projects. Technical Enabling Factors Business process management product software, platforms of key technology firms, XML standard and messaging standards are cited frequently as enabling technical factors. External SOA domain on project and middleware are cited frequently on the projects. Internal SOA domain and platform specialty tools from platform technology firms are cited often on the projects. These findings of business factors (70.7%), and also procedural factors (68.4%), as more enabling than technical factors (55.3%), in fulfilling SOA, may be encouraging for business managerial staff that might be currently hesitant in pursuing SOA as a strategy. From the bulk of the projects of SOA in our studies, lessons learned are indicated to be the following: Close collaboration of the technology department with the business departments and business units on business requirements can contribute to fast deployment of an SOA solution; Enterprise governance of services based on strategic planning can ensure effective and economical reusability of services in an SOA; Evolution of functionality on incremental projects contributing immediate benefits, in contrast to investment on “big bang” projects contributing elusively later benefits, can be a prudent SOA strategy; Focus on service standards at the beginning of a project on SOA can help in creating a solid foundation of SOA solutions and SOA strategy; and Focus on service orientation training of internal technical and business staff from the beginning of a project, and continuous technical training during the projects, is crucial for deployment of an SOA strategy. Finally, few of the firms (2) in our studies are close to highest maturity of deployment and exploitation of enterprise services based on SOE. Half (8) are experimenting in integration of process and services architecture and in restructuring of organizations and teams. Several of the firms (5) are at a low maturity of department deployment and business unit expansion of web services based on principles of SOA. Almost all of these firms (13) are achieving competitive equivalency service solutions or competitive continuous improvement service solutions, but the few firms (2) at a high maturity are achieving the beginning of competitive differentiation service solutions. Figure 3 displays the maturity levels of SOA in the firms of our studies. 7. IMPLICATIONS OF STUDIES From the results of the experiment with the case studies, we believe that educators in information systems introducing SOA in the curricula in their schools may benefit from the emphasis on the business and procedural dimensions of SOA. Information on the technology of SOA is essential, but is not as important as business and procedural fundamentals. Educators may be guided by the findings of the studies. Collaboration of the technology department with business departments on business process improvement projects and requirements is critical to SOA. Collaboration on process improvement requirements if not SOA may not be effective enough in firms, contributing to the technology department becoming the expert on changing processes that are inherently business oriented not technical (Alter, 2006). This difficulty can cloud delineation of core enterprise goals and processes and deployed services, and current and future requirements and determination of technologies, in a competitive strategy. Enterprise governance of services based on strategic planning and initiated by the CIO in cooperation with the business units of the firm can ensure reusability of services in an SOA. To do this, the CIO cannot be perceived as a pure technologist, as that contributes to the perception of the technology department and him as not a strategic function nor a strategic player or partner in the firm (Alter, 2006). The CIO who can contribute to business strategy is one who can continue educating and engaging proactively the sponsors in the executive suite and those in the business units (Smith, 2006) on the importance of SOA and the impact of new SOA technologies. This CIO can be a leader (Hugos, 2006) in the improvement of enterprise processes and instrumental in strategy. Evolution of functionality on incremental projects of SOA contributing immediate benefits can be a prudent SOA strategy, and focus on service standards at the beginning of programs and projects of SOA can help in the foundation of an SOA strategy. Focus on service orientation training of technical staff and business staff and continuous technical training of technical staff are crucial for implementation of SOA strategy. For technical staff, substantial training in business process and firm and industry strategy is as important if not more important as technology training, in order for this staff to optimize processes with SOA technology. Training may include integration of SOA centers of excellence and communities of practice of technical and business staff, and councils of expertise of the technical staff (Alter, 2006), for improving synchronization of technology strategy with business strategy. Finally, SOA is a feasibly strong proposition for a business firm. Firms that hesitate in investing adequately in an SOA program may be hindered by not having competitive processes that might furnish an improved proposition of service to their customers and trusted partners. Managers might evaluate processes in their firms for future competitive advantage in their proposition and focus investment in SOA technology towards those processes. Because of the continued hype on service technology, the findings of the study are helpful in the extension of SOA in industry and in the introduction of SOA as a technical topic and as procedural and business topics in information systems schools. Together with the posited program management methodology, they are essentially a snapshot of SOA today that can be helpful to information systems students. These findings and implications convey the proposition that the excitement of SOA technology must be balanced with the prudence of SOA business strategy when introduced to information systems students. 8. LIMITATIONS AND OPPORTUNITIES FOR RESEARCH This study is positioned as a proposition for a new program management methodology to be included in the curricula for educating information systems students on the evolving paradigm of SOA technology. The findings of the studies in industry indicate that a new methodology that integrates procedural and business fundamentals of projects of SOA is more important than functionality of technology. These findings have to be extended in a further study of the methodology in the curricula with instructors and students and of the outcomes. The next step is to integrate the program management methodology of the study into the advanced curricula of the Ivan G. Seidenberg School of Computer Science and Information Systems of Pace University. The success or non-success of the integration will be the foundation of the next study. 9. CONCLUSION This paper analyzed the challenges of deploying service-oriented architecture (SOA) through case studies in industry. Findings indicated that firms that lead projects of SOA with business and procedural factors have more success than those that lead with the functionality and hype of technology. The paper posited a program management methodology on SOA that may be integrated into the curricula of schools of information systems, so that students may be up-to-date with the practice and theory of SOA. 10. REFERENCES Alter, A. (2006) “Pushing for a Process Edge: Lack of Cross-Functional Cooperation Thwarts BPI.” CIO Insight, October, p. 55. Alter, A. (2006) “SOA Success: Five Actions CIOs Say You Should Take – Coordinate IT and the Business.” CIO Insight, November 14, pp. 1-2. Alter, A. (2006) “Top 30 Trends for 2007: CIOs Strive to Be Strategic.” CIO Insight, December, p. 26. Anderson, D., Howell-Barber, H., Hill, J., Javed, N., Lawler, J. and Li, Z. (2005) “A Study of Web Services Projects in the Financial Services Industry.” Information Systems Management, Winter, pp. 66-76. Beck, K. and Andres, C. (2005) Extreme Programming Explained, 2nd Edition. Addison-Wesley, Upper Saddle River, New Jersey. Bloomberg, J. and Schmelzer, R. (2006) Service Orient or Be Doomed!: How Service Orientation Will Change Your Business. John Wiley & Sons, Inc., Hoboken, New Jersey, p. 165. Chang, J.F. (2006) Business Process Management Systems: Strategy and Implementation. Auerbach Publications, Taylor & Francis Group, Boca Raton, Florida, p. 49. Daniel, D. (2006) “SOA Adoption Gains Momentum.” CIO, April 15, 2006, p. 20. Fuller, T. and Morgan, S. (2006) “Data Replication as an Enterprise SOA Anti-Pattern.” The Architecture Journal, 8, p. 16. Gruman, G. (2006) “Pulling Together an SOA Strategy.” Computerworld, Next-Gen IT, April, p. 6. Hugos, M. (2006) “Ticktock, Ticktock.” CIO, November 15, p. 38. Hurwitz, J. (2006) “SOA and Unintended Market Consequences.” CIO, August 31, p. 1. Krafzig, D., Banke, K. and Slama, D. (2005) Enterprise SOA: Service-Oriented Architecture Best Practices. Pearson Education, Inc., Upper Saddle River, New Jersey, p. 280. Murch, R. (2000) Project Management: Best Practices for Information Technology (IT) Professionals. Prentice Hall, Upper Saddle River, New Jersey, p. 112. Smith, G.S. (2006) Straight to the Top: Becoming a World-Class CIO. John Wiley & Sons, Inc. Hoboken, New Jersey, pp. 84,86,226. APPENDIX Services Processes Figure 1: SOA Program Management Methodology Service Management Framework Governance Framework Post Implementation Framework Communications FrameworkCommunications Framework Product Realization FrameworkProization Framework Analysis and Design Phases (Multiple Iterations) Development Phase (Multiple Iterations) Integration and Testing Phase (Multiple Iterations) Deployment and Implementation Phases (Multiple Iterations) Project Management Framework Architecture Framework Data Management Framework Human Resource Management Framework Figure 2: Methodology for Enabling Service-Oriented Architecture (MESOA) Table 1: Frameworks of Methodology for SOA Frameworks of Methodology High Citation Intermediate Citation Low Citation Not at All Citation Governance 4 8 3 0 Communications 3 7 3 2 Product Realization 5 5 4 1 Project Management 1 4 4 6 Architecture 7 7 1 0 Data Management 5 1 6 3 Service Management 6 6 1 2 Human Resource Management 4 4 3 4 Post Implementation 5 5 2 3 40 47 27 21 29.6% 34.8% 20% 15.6% Table 2.1: Key Business Factors for Enabling Frameworks of Methodology Business Factors Citation Frequency Agility, efficiency and flexibility benefits 14 Financial benefits 13 Business client participation 11 Competitive, market and regulatory differentials 11 Customer demand 11 Culture of innovation 11 Organizational change management 8 Executive sponsorship 6 Executive business leadership 4 Executive technology leadership 13 Strategic planning 12 Enterprise architecture 4 Focus on improvement of process 12 Service orientation 15 Reusability of assets 14 70.7% Table 2.2: Key Procedural Factors for Enabling Frameworks of Methodology Procedural Factors Citation Frequency Control of program 14 SOA center of competency 6 Responsibilities and roles 12 Education and training 8 Knowledge exchange 11 Change management 12 Information management 12 Common reference 11 Naming conventions 9 Procurement of technology 9 Technology firm knowledge capture 2 Risk management 14 Standards management 10 Infrastructure architecture 15 Process and service deployment environment 12 Process and service deployment techniques 15 Service catalog management 6 Service management and support 12 Security management 14 Continuous process improvement 9 Costing techniques 8 Strategy management 5 68.4% Table 2.3: Key Technical Factors for Enabling Frameworks of Methodology Technical Factors Citation Frequency Internal Web services on project 1 Internal process domain on project 4 Internal SOA domain on project 11 External process domain on project 5 External SOA domain on project 12 Business process management product software 13 Data tools 6 Middleware 12 Platform of key technology firms 13 Platform specialty tools from platform technology firm 11 Proprietary technologies 9 Best-of-class tools 7 XML standard 13 Messaging standards 13 Service description and discovery standards 9 Transaction standards 3 Security standards 9 User interface standards 3 Web services best practices 9 Web services management standards 3 55.3% Deployment and Expansion of Web Services Based on SOA Deployment of Services, Integration of Process and Services Architecture and Restructuring of Organizations and Staff Deployment and Exploitation of Services Based on SOE Life Insurance Firm Investment Banking Firm Hardware Manufacturing Firm Hardware and Software Firm Travel and Leisure Firm Broadband Communications Firm Certification Testing Firm Investment Advisory Firm Insurance Firm Municipal Energy Utility Banking Firm Telecommunications Firm Software Firm Automobile Firm Health Care Consortium Tactical Services Strategic Services Figure 3: Maturity Levels of SOA in Firms of the Studies