Modeling Information and Business Systems Architectures—a Team Project Annette Lerine Steenkamp (steenkamp@ltu.edu) Kevin Schiller (schiller@ltu.edu) College of Management, Lawrence Technological University Southfield, Michigan 48075, USA Kathleen Allour (KAllour@comcast.net) SAP-EBS Project, DTE Energy Company Detroit, Michigan 48226, USA Tony Lyons (Lyonstr45@aol.com) Information Technology, DaimlerChrysler Services Farmington Hills, Michigan 48334, USA Anene Nnolim (anene.nnolim@infotsg.com) InfoTSG, Inc. Belleville, Michigan 48111, USA Kamal Kakish (kamal@cobaminc.com) COBAM Inc, 4673 Tipton Dr., Suite100 Troy, Michigan 48098, USA Abstract The paper reports on an approach to conducting a team project on information and business systems architectures, adopted in a core course on information technology systems architecture in a Doctoral Program of Management in Information Technology. The rationale of the project is given with special reference to the project charter, the team work, the team approach, and the architectural approach. A number of key deliverables produced by the project team illustrates the architectural methodology followed by the team. A summary of the lessons learned are provided. Keywords: information architecture, business system architecture, architectural framework, methodology, team approach. 1. INTRODUCTION Information exists in a number of forms within the contemporary enterprise but is often not readily available in the appropriate form. Thorpe (1998) has written about the information paradox, concluding that “…neither the information nor the technology dollars are being consistently translated into business value”. It is generally agreed that information is data that is processed to render it meaningful to the user. This interpretation fits into the five categories of Ackoff (1989), ranging from data, information, knowledge and wisdom. Steenkamp and Konda (2003) have enhanced this hierarchy by introducing the dimensions of “value to the enterprise” and “forms of knowledge” (tacit and explicit) as shown in Figure 1. The organization’s users perform their roles in different managerial and operational contexts, requiring many levels of processing and types of informational granularity (Earl, 1996; Davenport and Pruzak,1998; Alavi and Leidner, 2001). The more useful the information is to the user the greater the value added to the processes that are served. Evernden and Evernden (2003) have identified three main categories of information: organizational or management information, business or operational information, and information about supporting technologies. They contend that information is an undervalued and underused asset in many enterprises. Organizations have made large investments in information technology (IT) but often do not have comprehensive models and supporting documentation of the information and business systems existing in the enterprise architecture (Steenkamp and Kakish, 2004). Figure 1. Enterprise Knowledge Assets. Source: Steenkamp and Konda (2003), adapted from Ackoff (1989). Practitioners and educators are faced with considerable challenges to understand and develop IT architectures aligned with the strategic direction of contemporary enterprises (Davenport et al., 1992; Turner, 1998; Watson, 2000; McManus et al., 2002; Mendonca, 2003; Andrade et al., 2004). Rechtin (1997) has explored the issue of architecting as a science or an art. Most of these authors agree that the information required by the processes and activities performed in the enterprise should be structured as a hierarchy of architectures, starting with an information architecture. This depicts the interdependencies and relationships of information entities and represents an abstract perspective of the information requirements of the enterprise. The information architecture (IA) is driven by the enterprise strategic plan which contains the goals and objectives of the enterprise. Using the contents of the IA, a business system architecture (BSA) may be developed which defines the structure and content of all business systems in the organization. This definition represents the business systems and main information stores required to support the IA. The BSA is used when a new business initiative calls for business processes and activities to be re-allocated to existing and new business systems (to be developed or acquired). Along with the IA, the BSA provides inputs to the technical IT architecture stage in which logical and physical models of the viewpoints of concern to the enterprise are developed. This paper reports and demonstrates an approach, proposed by the sponsoring faculty (and senior author) and the industry sponsor, which was followed by a project team, called the Information and Business Systems Architecture (IBSA) Team, in a core course on information technology and systems architecture to develop specifications for a given system in a real world enterprise. The IBSA team was concerned with two viewpoints, namely the information architecture and business systems architecture viewpoints of the target system. A viewpoint refers to the perspective taken by teams of the architectural domain of concern to the stakeholders or actors in the enterprise, and is modeled by means of a number of views or models. An example is the application viewpoint which focuses on languages, notations and representation schemes needed to develop the applications of the technical IT architecture. Views define specific needs of an actor in the architecture and may be used to cross check that: (1) A technical architecture will meet all aspects of the computational needs imposed on it, and (2) That a current architecture is fit for its intended purpose (IEEE Std1471, 2000). The other teams in the class focused on the application, data and infrastructure architecture viewpoints, respectively, and used the deliverables produced by the IBSA team as input additional to their project charters. These projects are beyond the scope of this paper. The project charter was presented to the project teams by the industry sponsor based on a case study concerning an enterprise information portal (EIP) for a tier-one automotive supplier. The goal of the project was to perform an analysis of the case study from the information and business system viewpoints to produce architectural specifications and an IT strategic plan. The resultant information and business systems architectures, and other project deliverables were made available to the three other teams charged to develop the EIP technical architecture. A summary of the project charter and architectural approach, as presented to the IBSA Team by the sponsors, and the teamwork approach followed by the team are presented below with a selection of project deliverables. The paper concludes with a discussion of the project experience. 2. PROJECT CHARTER The purpose of the IBSA team project charter is to define, at a high level, what the team should deliver and a justification of the resources needed. The project charter also represents a commitment to dedicate the necessary time and resources to the project. For this reason the project charter should be shared with all major stakeholders, securing sign-off when appropriate. The four project teams in the course were charged to deliver a number of team assignments and a team presentation about the project work to the class and project sponsors. The viewpoints allocated to the teams were: Team 1 (the IBSA Team) - Information and Business System Architecture; Team 2 - Application Architecture; Team 3 - Physical IT Infrastructure; and Team 4 - Enterprise Data Architecture. Additionally, all teams were required to submit a project binder containing the assignment deliverables, meeting minutes, and PowerPoint presentations. Project Summary The goal, objectives and a synopsis of the EIP problem statement for the ISBA Team, as presented to the team by the project sponsors follow below. Goal: To develop a set of specifications of IT and business systems requirements that can be used as input by the other three teams for developing their specific architectural viewpoint solutions. Objectives: Four objectives were identified, namely to * Provide a comprehensive set of specifications that Teams 2, 3, and 4 will use to develop their specific architectural solutions * Conduct a thorough analysis of the information and business systems architecture requirements that support the EIP environment * Develop an overall architectural proposal that Teams 2, 3, and 4 can utilize * Deliver an IA and BSA that is capable of meeting the enterprise objectives for the EIP, including scalability, integration and flexibility. Problem statement: The EIP case study gave a summary of the following challenges facing, and opportunities for, the host organization: 1) IT desktops are scattered throughout the world resulting in inefficient communications, 2) Access to portfolio applications is difficult, 3) Current infrastructure design results in increased security issues. These problems were phrased in terms of business and technical requirements that the architects and developers of the EIP must consider, such as the competition facing the enterprise, physical and geographical challenges, collaborative challenges, the IT infrastructure, IT operational issues, need for ease of use, and fulfillment of all the EIP requirements. Gannon (2000) and Phifer et al (2003) discuss EIP solutions for contemporary enterprises. The IBSA Team project requirements are given in Appendix 1. Team Assignments: The IBSA Team received the following specific team assignments, namely to develop: 1) A preliminary information analysis, 2) Information architecture models, 3) The business system architecture models, and 4) The IT strategic plan, as given in Appendix 2. 3. TEAMWORK APPROACH The IBSA team project began in advance of the other team projects, tasked to develop the technical architectural specifications, i.e., for the application, data and infrastructure viewpoints. The IBSA team consisted of four members supported by the project sponsors. Although the whole team participated in producing the deliverables, members were assigned specific roles by the faculty sponsor, namely team leader, information analyst, architecture modeler and IT strategist. Additionally, each team member was assigned to act as consultant to one of the technical architecture teams, with overall coordination falling to the team leader of the IBSA team. Teamwork proceeded in accordance with the ISO12207-2002 standard as described by Steenkamp and Kakish (2004) and was supervised, controlled and coordinated by the sponsoring faculty. The following sections discuss the sub-processes of project planning, execution and implementation. Project Planning The team functioned in collaborative mode according to the team project process shown in Figure 2. Planning was done jointly, with the team leader coordinating the allocation of assignments. In order to develop deliverables in a timely manner and in accordance to the predetermined schedule (refer Appendix 2) each team member volunteered to complete a sub-section of each assignment, referred to as section assignments and section deliverables. A quality assurance plan was used to jointly review all teamwork and deliverables drawing on the quality assurance life cycle processes of ISO12207-2002. The team had the advantage that all team members are employees of major corporations, with prior experience working on projects in the capacity of team leader and member tasked to produce specific deliverables. Project Execution The team utilized several tools to enhance communication, productivity and efficiency in performing the many tasks involved in the project. Group pages contained in the Blackboard Learning System environment were used to exchange versions of the deliverable sections among team members. Teleconferencing and e-mail were used to communicate progress and confirm team decisions among team members. In addition, face to face meetings were held once a week to confirm agreements and plan the next steps. A meeting agenda was prepared and minutes documented for each team meeting so that each member knew what was planned, agreed too and assigned. Following the team project process systematically contributed to team success by enhancing the team’s ability to work together according to the schedule. Figure 2. Team Project Process Although the team leader had the overall responsibility to guide the team to meet the deliverable due dates, each team member took individual responsibility to ensure that deliverables were completed by the respective due dates. Project Documentation Modeling and documentation of the various deliverables were done using CASE tools such as Provision Workbench (Proforma Corporation, 2004), and Microsoft Word, Visio and PowerPoint. Standard templates were used to format the architectural documents for the project binder, which was submitted both electronically and in paper format. 4. ARCHITECTURAL APPROACH The development of IT architectures should always take place in the context of the enterprise, its business processes, key principles, information requirements and existing IT systems (Zachman and Sowa, 1992; Feurer et al, 2001; Varga, 2003; Steenkamp and Kakish, 2004). Schekkerman (2003) has written about a number of critical success factors to the development of enterprise architecture, and stressed the importance of an architectural approach. During the course several approaches were explored such as promoted by Zachman (1987), Cook (1996), Boar (1999), the TOGAF ADM approach (The Open Group, 2000; Perks and Beveridge, 2003), Drobik (2002) and Steenkamp et al (2002). An analysis of the case study requirements, the host organization’s overarching principles and the ISBA project charter prompted the adoption of the architectural approach summarized in this section. The ISBA Team interpreted the enterprise strategy of the host organization to be based on the following needs: a ubiquitous solution for collaboration with all enterprise communities; a capability to address the collaboration and access issues; and to communicate effectively with stakeholders. Once the decision to create an EIP portal was taken the team formulated the information needs of the EIP in three categories, namely: 1) Strategic information, i.e., information that is of value to senior management, 2) Tactical information, i.e., information from the company’s markets, products, and channels, generally utilized by middle management, and 3) Operational information, i.e., information generally required at the operational level of the organization. The hierarchy of information requirements for the core business sub-portal is shown in Appendix 3A, and the corresponding information flows in Appendix 3B. Similar information hierarchies and respective information flows were created by the team for the other portal types. Architectural Framework One of the key tenets of the architectural approach followed by the project teams of the course is the adoption of an architectural framework. Several frameworks have been promoted in recent years when developing technical IT architectures (Rummler-Brache, 1990; Zachman and Sowa, 1992; Orlikowski and Gash, 1994; Cook, 1996; Boar, 1999; The Open Group, 2000; Frankel, 2003; OMG, 2004; Stewart, 2004). Based on earlier work in the doctoral program using the Index Model, the ISBA Team adopted this framework, shown in Table 1 (refer the shaded areas where the essential elements for the information, business systems and organization are depicted). The rationale for using this model is that it provides a definition of the key elements of an enterprise IT architecture (Boar, 1999; Steenkamp et al, 2002). Viewpoint Inventory Principles Models Standards Information Primary sources Information related Related to information architecture Information related Business Systems Existing business systems serving all user types Business systems related Related to business systems architecture Business Systems related Application Existing applications Application related Related to application architecture Application related Data Existing enterprise data Data related Related to enterprise data architecture Data related Infrastructure Existing infrastructure Infrastructure related Related to infrastructure Infrastructure related Organization Existing DSS EIS ERP systems Overarching principles, guidelines Related to organization - Strategy - Planning - Structure - Value chain Organizational Internet Table 1. Index Model for the Team Projects Viewpoints: The viewpoints assigned to the IBSA Team were analyzed taking into account the existing inventory of systems, existing principles endorsed by the enterprise architecture, the models to be used, and the standards to be adopted, as shown in Table 1. Appendix 4 provides detail for the EIP Index Model as developed by the IBSA team. The three viewpoints are: 1. Information: The focus is on the information requirements for the EIP. 2. Business systems: The focus is on the structure and content of all business systems in the organization. 3. Organization: Provides the context for the EIP as reflected the organizational goals and strategies. Principles: Directives and guidelines reflecting architectural decisions of the existing enterprise architecture, and guiding new architectural initiatives. These principles are overarching organizational, information, and business systems principles that must be consistently adhered to by all architects and developers. Models: Models are the main means of communication by architects with role players and stakeholders of an enterprise architecture. Models describe the structure and behavior of a viewpoint by means of appropriate notations and representation schemes. After the architecture is designed and implemented, models help to understand the operation of the systems of the architecture and the design of new updated architectures. Figure 3. Architectural Processes for Team Projects (Steenkamp & Kakish, 2004) Figure 4. EIP Strategy Process Model (adapted from Perks and Beveridge, 2003) Standards: Best practices and industry standards available to guide the design of architectural views. These standards support the intended “informing of practice” outcome of the course. Strategy Planning Stage/ Phase Step Viewpoint Model Enterprise Strategy Stage Adopt an enterprise architectural framework Review enterprise strategic plan for EIP Index Model Overarching organizational viewpoint principles Information Analysis Stage Determine enterprise information needs Define information entities and relationships Table of business facts or rules Information entity relationship model Business Systems Analysis Stage Perform business systems analysis Draw the new business system architecture System block diagram & Gap analysis worksheet Business Systems Architecture Table 2. Summary of Methodology Steps Strategic Planning Process Model The enterprise vision and strategy generally includes establishing a “best-cost producer” organizational environment, providing outstanding customer service, and identifying additional growth opportunities. To support this vision the IT organization must develop an IT strategic plan that can support and sustain those objectives. The IT strategy developed by the IBSA Team focused on the EIP initiative, deriving inputs from the Information Analysis Stage and the Business System Analysis Stage, as shown in Figure 3. EIP strategic planning comprised of the five processes shown in Figure 4. Teams 2, 3 and 4 developed the technical IT Architectures from their assigned viewpoints using the information and business systems architectures and the EIP strategic plan, as shown in Figure 3. 5. MODELING PROCESSES AND METHODOLOGY As stated above the processes of developing the IA and BSA are driven by the enterprise strategy, IT opportunities and existing IT and IS environments. The IBSA Team compiled a detailed list of business facts and rules for all user types (refer Appendix 5) during Information Analysis and reviewed the enterprise strategy derived from the case study and host organization presentations. The enterprise strategy guided the rest of the project starting with identifying the information and business systems assets relevant to the EIP to be developed. The team used the principles for the respective viewpoints to align the enterprise and IT strategies, a process that frequently fails in organizations. After reviewing several methodologies including those described by Monheit and Tsafrir (1990), Boar (1999), Perks and Beveridge (2003), and Frankel (2003) a methodology supporting the architectural processes was followed consisting of methods, techniques and representation schemes for modeling context, structure and behavior where relevant of the two viewpoints (Steenkamp and Kakish, 2004). Table 2 summarizes the steps of the three stages and their respective phases. A more detailed version of the methodology steps appears in Appendix 2. Viewpoint Models for the Information Architecture Stage As the IA is a representation of the information required by the processes and activities performed within the enterprise, it depicts the interdependencies and relationships of information entities. Figure 5 is a composite information flow diagram depicting the five major entity groups (sub-portals) within the EIP. Figure 6 is an information entity-relationship (ER) diagram for the core business portal. Similar diagrams were developed for each of the other four EIP sub-portals. Figure 5. Composite Information Flow Diagram (Pressman, 2001) Figure 6. Core Business Portal Information ER diagram Viewpoint Models for the Business System architecture Stage The structured information represented in the IA is used during the BSA stage to model the business systems that will satisfy the enterprise strategic goals and objectives. The BSA defines the structure and content of the these business systems. For example, the information entities of the EIP core business portal were identified as given in Table 3. Appendix 3B provides detail of the primary information sources and flows for each entity identified in Table 3. Similar listings, diagrams and flows were created for each of the EIP sub-portals. Core Business Portal Information Entities * Collaboration Management * Internet Services * Financial Management * User Groups * Performance Management * Internal Communication * External Communication * Network Sign-on * Document Management * User Publishing * Project Management * System Security * Engineering Applications * Manufacturing Applications * Inventory Applications * Business Applications * Materials Applications * IT Applications * Forged Products * Facilities Location Table 3. Core Business Portal Information Entities 6. DISCUSSION AND CONCLUSIONS The project described in this paper, one of four team projects, demonstrates the application of IT-oriented architectural theory to a case study taken from the real world. It illustrates how the knowledge base of enterprise architecture was expanded with special reference to information and business system architectures. The value of collaboration by a dedicated team contributed to the successful completion of the architectural project within the constraints of the university term. Four primary factors contributed to the performance of the IBSA Team: 1) Team members were enrolled in an academic program which requires students to attend classes in cohort format. Members of the team had been attending the program for five terms and were acquainted with each other; 2) Team members had experience of team projects in their work environments. This prior experience enabled each team member to quickly understand team dynamics and assume their assigned roles; 3) Since this was an academic assignment there was no corporate politics to be concerned about. Team members were not threatened by losing their jobs, or demotion if the project did not succeed; 4) The small team size of four members reduced the number of communication channels and enabled options to be quickly discussed, decisions made and implemented in a timely manner. Team members and other students in the course provided input about architectural approaches followed in their respective organizations. These include approaches of several Fortune 100 companies in the automotive, healthcare, service, IT, utility and service sectors. Sharing of ideas made it possible to contrast several approaches and facilitated meeting the “informing of practice” outcome objective of the course. The various course assignments made learning new theories more interesting and enabled students to learn from each other as they completed the assignments. By conducting this project, the team achieved the educational goal stated in Tutorial Letter 1 which states: ‘the goal is to provide a comprehensive perspective of the role that IT system architectures play in a competitive enterprise’. Team members are now equipped with additional skills and knowledge that will further their business value to their respective employers, including: (1) Identifying enabling opportunities for new business processes; (2) Enhancing best practices in the field of IT architectural design; and (3) Participating in architectural projects as lead designers. The team approach described here is continuously reviewed and refined. The intention is to achieve architectural integration of the various viewpoint architectures in future architectural team projects. This has been a challenge within the time constraints of an academic term. A project that is underway focuses on defining an approach to align deliverables from IT architectural projects with the enterprise strategy in measurable terms. 7. ACKNOWLEDGEMENTS The authors wish to thank the industry sponsor for providing the case study, and supporting the team by means of presentations and guidance throughout the project. The team also acknowledges insights gained from collaborating with the other teams during the project. 8. REFERENCES Ackoff, R. (1989). “From Data to Wisdom.“ Journal of Applied Systems Analysis, Volume 16, p3-9. Alavi, M. and Leidner, D. E. (2001). “Review: Knowledge Management and Knowledge Management Systems: conceptual foundations and research issues 1 and 2, MIS Quarterly Vol. 25 No. 1, pp. 107-136. Andrade, J., Ares, J. Garcia, R. and Pazos, J. (2004). A methodological framework for viewpoint-oriented conceptual modeling. IEEE Trans. on Software Engineering, 30, 5. Ashby, W. Ross (1956). An Introduction to Cybernetics, Methuen Press, London. Beveridge, T. and Perks, C. (2000). Blueprint for a Flexible Enterprise. Intelligent Enterprise, March. Boar, B. H. (1999). .Attitudes, Personality, and Behavior. The Dorsey Press, Chicago. Boar, B.H. (1999). Constructing Blueprints for Enterprise IT Architectures, Wiley. Cook, M. (1996). Building Enterprise Information Architecture. Prentice-Hall. Davenport, T. Eccles, R. and Prusak, L. (1992). Information Politics. Sloane Management Review, Fall. Davenport and Pruzak (1998). Working Knowledge: How Organizations Manage What They Know. Boston: Harvard Business School Press. Drobik, A. (2002). Enterprise Architecture: Far too Important to be left to the IT Team, Gartner G2 Report. http:// www.gartnerg2.com/site/FileDownload.asp?file=rpt-0702-0130.pdf Earl, M.J. (1996). Information Management. Oxford University Press. Evernden, R. and Evernden, E. (2003). Information First, Integrating knowledge and Information Architecture or Business Advantage, Elsevier. Feurer, R. Chaharbaghi, K. Weber, M. and Wargin, J. (2001). Aligning Strategies, Processes, and Information Technology: A Case Study, in Enterprise Systems Integration (J.M. Myerson, ed.), 11-28. Frankel, D. S. (2003). Model Driven Architecture: Applying MDA to Enterprise Computing. Wiley & Sons. Gannon, T. (2000). A Business Solution: EIP. DM Review, 10, 6, 18-20. IEEE Std 1058-1998. IEEE Standard for Software Project Management Plans. IEEE Std 730-1998. IEEE Standard for Software Quality Assurance Plans. IEEE Std 830-1998. IEEE Recommended Practice for Software Requirements Specifications. IEEE Std 1220-1998. IEEE Draft Standard for Application and Management of the System Engineering Process. IEEE Std 1471 (2000). IEEE Recommended Practice for Architectural Description. ISO/IEC15288 (2002). Systems Engineering – System Life Cycle Processes. ISO/IEC 12207 (2002). Information Technology – Software Life Cycle Processes. McManus, H. Warmkessel, J. and Kaliardos, W. (2002). An educational experience in developing conceptual architectures for complex systems. In Frontiers in Education, FIE, 32th Annual Conference. Mendoca, J.A. (2003). A model and sample case for teaching the business value of IT. Journal of IT Education, 2. Monheit, M. and Tsafrir, A. (1990). Information Systems Architecture: a consulting methodology. In CompEuro’90. Proc. of the IEEE Int. Conf. on Computer Systems and Software Engineering. OMG (2004). Model-Driven Architecture Standards. www.omg.org. Orlikowski, W.J. and Gash, D.C. (1994). Technological Frames: Making sense of Information Technology in Organizations, ACM Transactions on Information Systems, 12, 2. Perks, C. and Beveridge, T. (2003). Guide to Enterprise IT Architecture, Springer, New York Phifer et al. (2003). Portals and Web Services will boost business value in 2004. Gartner Whitepaper, Gartner. http://mediarpoducts.gartner.com/gc/webletter/bea_reprints/article1/arcticle1.html. Proforma Corporation (2004). ProVision Workbench Whitepaper. http://www.proformacorp.com/. Rechtin, E. (1997). Teaching systems architecting: Science and Art. IEEE Spectrum, 29, 10. Rummler, G. and Brache, A. (1990). Improving Performance: How to Manage the White Space on the Organization Chart (2nd Ed.), Jossey-Bass. Schekkerman, J. (2003). How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework, Trafford Publishing’s Webstore and OnDemand Publishing Offices. Steenkamp, A.L., White, T. and Kakish, K. (2002). A project-centered approach to teaching Information Technology and System Architectures, Journal of Informatics Education & Research, 4, 2, 1-14. Steenkamp, A.L. (2002). A standards-based approach to student projects in an IT curriculum, Proc. ICIER2002, Barcelona, Spain, December. Steenkamp, A.L, and Konda, D. (2003) Information Technology, the key Enabler for Knowledge Management: a Methodological Approach, International Journal of Knowledge, Culture and Change Management, Vol. 3, Monograph MC03-0070-2003, (Ed. M. Kalantzis and B. Cope). Steenkamp, A.L. and Kakish, K. (2004). An Approach to Developing Information Technology Architectures, Proc. ICIER, Washington DC, USA. Stewart, G. (2004). Developing a Systemic Understanding of Information Systems in Emerging IT Professionals using an Enterprise Architecture Approach. In Proceedings of the Americas Conference on Information Systems, New York, New York. Thorpe, J. (1998). The Information Paradox, Mc Graw-Hill. Turner, J.A. (1998). The role of information technology in organizational transformation. In Information Technology and Organizational transformation. (edited by Galliers and Baets), Wiley. The Open Group (2000). TOGAF-V6.0. http://www.opengroup.org/public/arch/p1/oview. Varga, M. (2003). Zachman Framework in teaching information systems, In Proceedings of the 25th Int. Conf. on information Technology Interfaces. Watson, R.W. (2000). An Enterprise Information Architecture: a Case Study on Decentralized organizations. In Proceedings of the 23rd Hawaii International Conference on System Sciences, Hawaii. Zachman, J. A. and Sowa (1992). Extending and Formalizing the Framework for Information Systems Architecture. IBM Systems Journal, 31, 3. Zachman, J. A. (1987). “A Framework for Information Systems Architecture”. IBM Systems Journal 3. Appendices and Annexures Appendix 1 summarizes the IBSA project requirements for the IBSA Team’s project. Activities to be performed, indicated in the Review of Current State column, included obtaining a thorough understanding of the requirements and management processes, utilizing management and analysis tools and techniques for requirements elicitation, specification, verification and validation, and control. Appendix 2 elaborates the summary of methodology steps given in Table 2. The steps of the Information and Business System Viewpoint Methodology are listed by stage and phase, as well as the viewpoint models and assignments to be completed. Appendix 1. IBSA Project Requirements Requirements Review of current state Project goals and objectives • Develop a set of specifications of information and business systems requirements that can be used as input by the Application, Infrastructure, and Data Architectural teams - Interpret the project requirements for the relevant viewpoints - Identify key architectural principles for each relevant viewpoint to guide the architectural decisions of the project • Adopt appropriate architectural framework • Adopt appropriate architectural process model • Adopt an appropriate architecture methodology Project deliverables • Documentation of challenges in organizational environment, namely: - Business - Physical and Geographical - Collaboration - IT Infrastructure - IT Operations - User Interfaces • Documentation of business processes pertaining to employees, suppliers, partners, and customers • Documentation of steps for portal implementation, including data structures, applications, and groups/users Performance goals and objectives • All commonly needed EIP features are identified and documented • All information and business requirements are translated into IT specific needs • Ensure the information architecture and the business system architecture is driven by and aligned with the enterprise strategy • Provide consulting services to other teams • Complete project binder • Conduct presentation to class • Validate information and business system architectures i.t.o. project charter and project requirements Costs and schedule thresholds Out of scope High-level constraints and assumptions • Teams will collaborate and develop integrated solutions • Timely completion of information and business systems architectures to serve the other teams • Documented problem statement is complete and consistent • Team members have adequate understanding of concepts, methodology, techniques and tools to complete project Business needs identification • Computing environment is disparate • Access to each application has its own set of policies, and requires multiple user sign-on • Lack of standardization in communication technologies • Simplification of organization’s technology landscape by providing a consolidated view to access all content and services that users require Project Manager responsibilities • Plan and coordinate teamwork • Manage team deliverables • Assure quality • Coordinate meetings • Report to project sponsor Project Sponsor responsibilities • Structure the teams • Assign team members • Define project deliverables • Assign team deliverables • Manage resources • Manage team conflicts Stakeholder(s) responsibilities • Establish project • Communicate organizational information • Provide guidance to teams Appendix 2. Information and Business System Viewpoint Methodology Strategic Planning Stage/Phase Steps Viewpoint Models/ Team Assignments (TA) Enterprise Strategy Stage 1. Adopt an enterprise architectural framework 2. Adopt a strategy process model Index model Generic Strategic Planning Process model 3. Determine/revise principles within context of chosen architectural framework. 4. Review Enterprise Strategic Plan for EIP 5. Review Project Charter Overarching Organizational, Information and Business System viewpoint principles Information Analysis Stage 6. Determine a set of business facts/rules Express them in terms of the enterprise’s information needs. 7. Identify the information needs of the initiative. Table of facts/rules List of information entities representing information needs TA1 due March 5 8. Define the information architecture. Draft Information entity diagram 9. Analyze functional dependencies. Use techniques such as decomposition, information flow diagramming, process flow diagramming and supporting representation schemes. Verify and refine functional decomposition by identifying the dependencies among functions. Functional model (leveled set of Information flow diagrams, Activity hierarchy diagram) 10. Define information entities and relationships. Perform corporate data modeling. Revised Information Entity Relationship model 11. Perform information needs mapping. Compare the list of entity types with the list of information needs. Information entity/information needs table 12. Analyze entity type usage. List the expected effects of the business functions on entity types, and validate and refine the activity hierarchy diagram and the entity relationship diagram. Activity hierarchy diagram refinement Information Entity Relationship Model refinement 13. Map functions and entity types to enterprise units. Relate data to the enterprise checking the activity hierarchy and determining how these elements are used. Function/entity table 14. Document Information Architecture Enhanced information entity diagram (the Information Architecture Model) TA2-1 due March 19 Business Systems Analysis Stage 15. Perform business systems analysis Map the current business systems to the new information requirements. System block diagram (Current Business Systems/ Information Requirements Mapping) 16. Perform business process modeling Show enabling IT/IS systems at business system level SHOULD Business Process diagram 17. Perform a gap analysis. Show the new business systems needed to meet the information Architecture Gap Analysis Worksheet 2. Draw the new business system architecture System block diagram of Business Systems Architecture TA2-2 due March 26 IT Strategy Planning Stage 19. Perform IT Strategic Planning for AAM IT Strategic Plan TA3 due April 16 20. Compile the Project Binder containing: * Information Architecture Description Document * Business System Architecture Description Document * IT Strategic Plan Project Binder due on April 23 Appendix 3. Two Views of Information Requirements Appendix 3 provides two views of information requirements for the core business portal: a hierarchy of the information requirements (Appendix 3A) and a summary of the information flow (Appendix 3B). Appendix 3A. Hierarchy of Information Requirements: Core Business Portal As may be seen in Appendix 3A the hierarchy of information needs of this initiative falls into three categories, namely: strategic, tactical, and operational information. These categories have been explained in the main body of this paper (refer Architectural Approach). In developing an information architecture, Perks and Beveridge (2003) caution that one should not get immersed in the detailed analysis of information at the operational level. The authors also maintain that it is necessary to understand the information requirements at all levels of the business so that these can later be aligned with the specific business systems of the organization (Perks, C., Beveridge, T., Guide to Enterprise IT Architecture, Springer, 2001, p.56.). Appendix 3B. Summary of Information Flow: Core Business Portal Appendix 3B illustrates the information flows in the new core business portal. On the left side primary information sources come from the previously identified hierarchy of information requirements. These are linked to respective business systems of the portal as inputs. Depending on the business system, the information can be strategic, tactical, or operational. Similar models were developed for the other portal types. One of the objectives of the new EIP architecture is to implement a single sign-on protocol, which would allow a user to sign-on once and be able to access resources throughout the system. The “Network Sign-on” on the right side of the diagram accomplishes this. The user is authenticated by “System Security” and can then access resources within the EIP. These resources are available as a result of integration of the various business processes, applications, and data bases within the EIP. Appendix 4. EIP Index Model Developed by the IBSA Team Viewpoint Inventory Principles Models Standards Information Primary sources: .Strategic. .Tactical. .Operational. Integrate platforms for content and services to all communities. Integrate security and flexibility for intranet, extranet, and internet. Capture data once at primary source. Share, manage, and control data corporately. Offer technology for pre-built communities in functional areas to accelerate time-to-market; increase ROI. Facts/Rules Data processes Functions/ Entities Entities/ Relationships Information flows Activity hierarchy Portal framework Corporate data standards IEEE 12207 IEEE 1471 ISO/IEC15288 Business Systems Existing business systems serving all user types: • Employee • Customer • Vendor • Partner • Supplier Web-based systems Provide portal access to all communities. Integrate existing applications with new technologies. Optimize business systems. Activity flow diagram Architecture process model Context diagram System block diagram Function table Tiered application architecture Platform technology standards Portal framework patterns/ template standards IEEE 730 IEEE830 IEEE1058 IEEE Std 1220 IEEE 1471 Organization Existing DSS, EIS, ERP systems Simplify complexity of technology environment. High security Enable community self-publishing. Provide Web Services and Community Forums Single sign-on to EIP Organogram Strategic Plan Value chain Process diagram Separate Web services for each community Internet standards BPM standard Corporate data standards Business process modeling standards Appendix 4 presents the EIP Index Model developed by the IBSA Team of the information, business systems and organization viewpoints in terms of the inventory, principles, models and standards for the new EIP. Appendix 5. Summary of Detailed Business Facts/Rules – All User Types (Adapted from Perks & Beveridge) Business Facts/Rules Business Information Needs User Type E_____S_____C_____P Generate production forecast Product demand X X X Maintain production capacity & inventory Component part demand X X X Maintain DNA of each component part used Component birth certificate – original supplier X X X Maintain supplier database Supplier information X X Maintain customer database Customer information X X Maintain partner database Partner information X X Maintain employee data and history Employee information X Generate & maintain corporate financial reporting Financial reporting X X X X Generate market trends, share & competitive forecasts Competitive market analysis X Produce quality products Product specifications X X X Produce & improve products to specifications Engineering designs X X X Maintain balance of product cost to profit Product cost information X X X Delight the customer with superior products & service Customer satisfaction ratings X X X Produce & supply high quality products Supplier quality & performance ratings X Manage debt and payment transactions Outstanding payments & receivables X X X Ensure products are delivered on time Lead time/ order to delivery X X X Maintain overall profitability Cost of product by supplier X Maintain customer satisfaction & contain costs Number of complaints and recalls X X X X Develop & manage product reliability Product failures/defects X X X Manage fixed assets Fixed assets X Maintain profitability Labor cost X Maintain profitability Production shrinkage X X X X Supply product & maintain inventory Production capacity X X X X Meet production schedules Equipment downtime X X X X Deliver product to schedule Transportation & product tracking information X X X X Maintain updated product information Products & parts catalog X X X Ensure corporate profitability & collections Pricing policy X X X Communicate payment policies Payment policy X X X Effective management of product orders Order processing & status X X X Manage receivables Payment processing & status X X X X Maintain accurate accounts Account information X X X X Maintain customer data Customer information X X X X Provide excellent customer service Customer service X X X X Design effective marketing strategies Marketing campaigns X X X X Enhance product awareness & knowledge Product training & documentation X X X X Manage procurement Procurement processing X X X X Effective management of corporate auction process Product auction information X X X X Enhance employee information sharing, knowledge & morale Announcements, news & information X Share project development planning for products Project management information X X X X Include partners & suppliers in sales planning process Sales planning information X X X X Provide employees with capability to manage personal data HR self service / employee data X Empower employees for career development Employee training X Facilitate employee teams’ productivity Team collaboration information X Communicate business metrics internally Business intelligence information X Improve sharing of corporate applications & intellectual property Internal applications information X Empower employees for career development Internal job postings X Promote improved internal communications Internal communications X As part of the overall analysis of the enterprise’s current operations its primary business facts (rules) with respect to the enterprise informational needs were identified. These business facts play an important role in the development of the information and business system architectures. Appendix 5 combines all enterprise user type viewpoints and illustrates the business facts that apply across the four user type domains. The represented user type domains are defined as E (employee), S (supplier), C (customer) and P (partner).