A Case Study: Developing an Architectural Design Description for the Technology–Communications Engineering Viewpoint Annette L. Steenkamp steenkamp@ltu.edu College of Management Lawrence Technological University Jehad S. Alomari Jehad_Alomari@ADP.com Automatic Data Processing, Inc. Abdelraheem M. Basal ayman@centralacademy.net Global Educational Excellence Kamal Kakish kamal@cobaminc.com COBAM, Inc. Abstract This paper presents a case study of the experience of a technical architecture team, the TA-CE Team, when developing an architectural design description (ADD) for an IT system focused on the communications engineering views of the technology viewpoint. The project charter and requirements for the assignments of the TA-CE Team project are based on a real-world initiative to improve electronic collaboration within a global tier-one automotive enterprise and with its global partners. The improved infrastructure had to support thousands of employees in engineering and manufacturing scattered around North America and Japan. The team assignments performed by the TA-CE Team formed part of the requirements of a course on IT Systems Architecture in a Doctorate of Management in Information Technology. The TA-CE Team project conducted the architectural project concurrently with four other team projects focused on the application, information and business systems, quality of service, and enterprise security viewpoints, respectively. The case study outlines the approach followed to develop the ADD, and includes the principles that guided the project architectural, architecture framework, process model and methodology. The paper concludes with a discussion of the project findings and the value of an industry-sponsored learning experience. Keywords: architecture design description, architecture framework, architecture process model 1. INTRODUCTION The field of enterprise architecture is receiving much attention in today’s global market place where companies collaborate on joint ventures, and the enterprise system extends beyond the company. Collaborating partners, suppliers and customers form part of the greater enterprise system. The enterprise system consists of diverse assets that may be represented in terms of a set of architectural viewpoints and views (IEEE1471, 2000). For example, the business systems architecture viewpoint contains views of interest to business managers, planners and users, whereas the technology architecture viewpoints concern system architects, operators, administrators and acquirers (The Open Group, 2006). Business today is comprehensively supported by information technology (IT) systems and it is imperative that the information needs of all stakeholders are met (Schekkerman, 2005). Due to the complexity of such systems, several architectural taxonomies are typically adopted when designing architectures. Such taxonomies structure the problem space and allow stakeholders to focus on specific concerns and principles (Boar, 1999a; The Open Group, 2006; Phifer et al., 2003; Steen, 2004; Andrade et al, 2004). It is important for the enterprise to model its existing architecture and use it as a blueprint to respond to drivers and trends in today’s competitive environment. A range of frameworks, process models and methodologies has been proposed, but most are not integrated and there is no universally accepted standard at this time. However, several standards bodies such as IEEE and ISO have developed standards that address aspects of the architectural domain, and The Open Group has made a large contribution towards architectural integration through TOGAF (The Open Group, 2006). The paper describes a case study on the application of an architectural approach by a student team, the TA-CE Team, to develop an architecture design description (ADD) for an IT system. The focus is on the TOGAF Communications-Engineering sub-viewpoint and related views of the Technology Architecture Viewpoint (The Open Group, 2006) of the IT system, with goal to improve communications between two automotive partners. The IEEE 1471 definition of viewpoint is used in the paper, meaning that the case study presents views and corresponding models of the Communications-Engineering (C-E) sub-viewpoint. The C-E sub-viewpoint is concerned with structuring communications and networking elements to simplify network planning and design. The TA-CE Team project formed part of the requirements of a doctoral course in IT Systems Architecture. The goal of this course is to provide students with an enterprise perspective of the value of a well documented IT architecture as an enabler of competitive advantage. An enterprise architecture is defined as one consisting of a hierarchy of architectures, as determined by the business processes and information requirements, that are deployed within an enterprise in alignment with its strategic goals. Within this broader context the focus of the course was on the technical IT architecture, i.e. the software, hardware and infrastructure components of IT systems. Course objectives included defined theoretical outcomes in terms of concepts and principles of enterprise and technical IT architectures. Additionally, informational outcomes were based on leading edge approaches, and explored in both the individual assignments and teamwork (The Open Group, 2006; Varga, 2003, Steen, 2004) and technologies (Proforma Corporation, 2006; Popkin Software, 2004). A real-world initiative to improve electronic collaboration within a global tier-one automotive enterprise and with its global partners provided the basis for the project charter and requirements for the assignments of the TA-CE Team project. This team project provided the TA-CE Team with an opportunity to apply the theoretical concepts studied in the course to an architectural problem situated in practice, where the complexities of the global business collaboration are a reality. Section 2 provides the background to the team project and Section 3 summarizes the project charter. The project requirements are included in Appendix 1. Section 4 outlines the architecture approach followed by the student team, and Section 5 presents the deliverables produced in the project. The paper concludes with a summary of the team experience and some lessons learned. 2. BACKGROUND TO TA-CE TEAM PROJECT The real-world initiative was concerned with a review of the existing Lotus Notes environment in order to formulate action plans for improving the communication capabilities of employees within a division of the automotive enterprise as well as with its global partners. The resulting upgrades were to improve the communication capabilities for a division of the automotive enterprise, in this paper called the Heavy Vehicle Division, and its global partners while also easing the high maintenance load of the existing architecture. The intent was also to reduce the cost by leveraging the significant investment already made in the system. Problems existing at the time included space limitations of e-mail boxes; high maintenance requirements of the current servers; unsupported formats for e-mail attachments; no web-access of e-mail; and no calendar feature. 3. PROJECT CHARTER FOR TA-CE TEAM The project charter challenged the TA-CE Team to improve the global, regional, and local communication infrastructure thereby serving the core business, employee, supplier, customer, and business partners better. In particular, the team was tasked to design the C-E views for a technology infrastructure capable of supporting thousands of employees in engineering and manufacturing scattered around North America and Japan. The views should reflect the consolidation of servers from 300 locations into a few centralized locations known as regional hubs where they could be optimally used and centrally managed. The design also called for migration to the latest version of Lotus Notes running on centralized servers. The TA-CE Team committed to provide justification for time and resources to stakeholders of the project. The rest of the project charter outlines the purpose of the project, the problems to be addressed, and specific project requirements. Purpose of the project Develop an ADD document containing C-E views of the Technology Architecture Viewpoint that will meet the project requirements and address project issues and stakeholder concerns as described in the team assignments. The ADD should accommodate newly developed and/or purchased components/services; employ suitable technologies supported by reliable tools; improve data collaboration and accessibility; facilitate Web access; and employ a client-server paradigm. The ADD should also increase access to this enhanced technology for all users and stakeholders. The outcome must be a sound communications system that provides high-speed and secure access to shared resources from all locations. The new infrastructure should provide high bandwidth, global broadband, and improved wireless technologies. Figure 1 shows the elements of the Lotus Notes Business Communication Improvement Model. Problem statement The proposed design needed to consider the following problems as they relate to the C-E Views of the Technology Architecture Viewpoint: * The Local Area Networks (LANs) were below par – 10 megabits per second from the desktop to the server, and 100 megabits per second to the backbone routers/switches. * The Wide Are Networks (WANs) were slow at best due to the variety of bandwidth across a large number of subnets and segments. In most cases, WAN redundancy did not exist. * The infrastructure philosophy was based on the thin-client/fat-server approach. * There was no policy to restrict the transfer of very large files until much later in the infrastructure stabilization effort and no Service Level Agreements (SLA’s). * No Wireless technology available. Project requirements The requirements for the TA-CE Team project are given in Appendix 1. Figure 1. Lotus Notes Business Communication Improvement Model 4. ARCHITECTURE APPROACH The development of IT architectures should always take place within the context of the enterprise, its business processes, information requirements and existing IT systems, as explained in the Introduction of this paper. The architecture approach was informed by the IEEE1471 Conceptual Model of Architectural Description (IEEE, 2000) as shown in Figure 2. The architecture approach adopted by the TA-CE team was proposed by Steenkamp and Kakish (2004), and the key elements are summarized in this section. This approach has been used in a number of educational settings with a considerable learning curve and time constraints with success, attributed to the fact that it allows consideration of the myriad issues of architecture design in a structured way. Figure 2 gives a the meta model (IEEE1471, 2000) in terms of: the principles guiding architectural decisions; an analytical framework of the attributes of concern to the viewpoint to be modeled; the architecture process model structuring the architectural work into stages; the supporting architecture methodology; and the team approach. Each of these elements is explained below as used by the TA-CE Team. The TA-CE Team approach is summarized by the diagram in Figure 3 starting with the project charter, and resulting in the project outcome (the CE ADD), produced by following the steps of the architecture methodology supporting of the architecture stage of the architecture process model (refer Figure 4). Principles Architectural principles are those concerns that guide the architectural decisions of an architecture group, here the TA-CE Team. Overarching principles of the Heavy Vehicle Division, such as secure access, global accessibility, and enhanced synchronous and asynchronous communication, apply globally to all architectural projects. Principles specific to the C-E sub-viewpoint that guide decisions for the TA-CE project include heuristics derived from experience. These principles are given in the architecture framework in Appendix 1. Figure 2. IEEE1471 Meta Model of Architectural Description instantiated for the TA-CE Team Project Architecture Framework The need for an architectural framework, providing the organizational context when developing technology architectures, has been advanced by several authors (Orlikowski and Gash, 1994; Cook, 1996; The Open Group, 2006; Frankel, 2003; OMG, 2006). This is because the complexity within the enterprise demands that technology architecture viewpoints cannot be viewed in isolation, and all relevant factors need to be taken into consideration, such as principles, stakeholders, contents, layers, aspects, standards and tools ( Boar, 1999b; Feurer et al., 2002; Steen et al, 2004; Steenkamp and Kakish, 2004). This is achieved by means of a comprehensive analytical model as have been promoted in architectural frameworks by authors in the field (Zachman and Sowa, 1992; Orlikowski and Gash, 1994; Cook, 1996; Boar, 1999; The Open Group, 2006; Frankel, 2003; OMG, 2006; Stewart, 2004). An architecture framework provides a conceptual frame of reference when thinking about enterprise architectures. It is useful to identify viewpoints that represent perspectives taken of the architectural domain relevant to particular stakeholders. Viewpoints are modeled in terms of views that provide patterns or templates from which to develop specific models of concern to stakeholders. Therefore, viewpoints are used to manage the inherent complexities of enterprise architectures. The portfolio of models of each viewpoint, and related views is defined in terms of attributes that clarify the context of each view in terms of purpose, concerns, stakeholders, content, layer, aspect, viewpoint language used, standards referenced, and tools used. The TA-CE Team adopted the architecture framework given in Appendix 2 (adapted by Steenkamp (2006) from Steen et al (2004)). The attributes have the following semantics: * The purpose of a view is whether it is for purposes of informing, deciding, or designing. * The content attribute of a view is characterized by the three abstraction levels: Details, Coherence, and Overview. * A layer refers to the applicable business, application, and technology layers. * An aspect refers to structure, behavior, and information. * Viewpoint language is the modeling notation or representation scheme used. * Standards are the best practices adopted when modeling a view. * A tool refers to the automated capability used to model a view. Figure 3. TA-CE Team Approach Architecture Process Model The C-E views of the Technology Viewpoint are concerned with structuring communications and networking elements to simplify network planning and design. The instantiated architecture framework for Communications Engineering is given in Appendix 2. Similar to system and software process models IT architecture process models structure architectural processes into interrelated life cycle stages facilitating the managerial and technical tasks of architects and developers who plan, manage, evaluate, develop and maintain the IT architecture. The architecture process model followed in the TA-CE Team project is shown in Figure 3. The team received input from the Information/ Business System Architecture Stage and the IT Strategy Stage and focused on the Architecture stage as shaded in Figure 4. Architecture Methodology Complementary to the architecture process model is the supporting methodology, which provides steps to be followed in the life cycle stages, the representation schemes, modeling notations, and the deliverables to be produced. Various methodologies, techniques and notations are promoted to develop architectural models representing the architectural viewpoints (Monheit, M. and Tsafrir, A., 1990; Rechtin, 1997; Boar, 1999; Perks and Beveridge, 2003; Steenkamp and Kakish, 2004, Stewart, 2004), and a range of tools are used in practice (Microsoft, 2004; Proforma, 2004; Popkin’s System Architect™ , 2004; IBM’s Rational Rose™, 2004). The TA-CE team adopted the methodology summarized in Appendix 4 and used MSWord and the Visio modeling tool to model the C-E views. The steps of each phase are shown along with intended artifacts or models to be produced. Teamwork Approach The TA-CE Team consisted of two architects, who had complementary business and technical skills, a faculty sponsor and an industry sponsor. Team members were challenged with many architectural concepts that were applied to the real-world problem derived from the Heavy Vehicle Project initiative, thereby meeting the course requirement of applying theory to practice. Team members delivered their shared responsibilities according to the architecture project plan under direction of the project sponsors. The project charter, project requirements, and team assignments guided the team in creating the viewpoint models and ultimately the ADD. The team held weekly progress meetings and collaborated virtually throughout the project using the group feature within the Blackboard Learning System. Figure 4. Architectural Process Model (APM) 5. PROJECT DELIVERABLES This section shows a selection of the artifacts and deliverables produced during the architecture stage of the project. To conserve space the Architectural Project Plan is not included in the case study. System Block Diagram The system block diagram in Figure 5 shows a high-level representation of the key elements of the Lotus Notes Server Consolidation and other related platforms. It describes the different methods of access to the system and routing to the appropriate server. This is done through load balancing by spreading the work between many servers and other resources in order to get optimal resource utilization and decrease computing time. After the access request passes the external routing and load balancing technology, it passes through a firewall as shown in Figure 5. Figure 5. System Block Diagram Figure 6. Conceptual Architecture Conceptual Architecture Model The purpose of the conceptual architecture model, shown in Figure 6, is to give a high-level view of the architecture and is useful for communicating the infrastructure to non-technical audiences, such as management and end users. Figure 7. Specification Model Specification model The model in Figure 7 provides the hardware and software specification of the Lotus Notes server consolidation, and the interaction between the tiers relating to load balancing, Linux web server, Linux application server, Linux DMS servers, and Linux DBMS. Physical Architecture The communications infrastructure shown in Figure 8 has three levels: local, regional/metropolitan, and global. These levels are based on their particular geographic level. The local components relates to assets that are located relatively close together geographically. This level contains fixed communications equipment as well as small units of mobile communications equipment. Local area networks (LANs), to which the majority of end-devices will be connected, are included in this level. The regional and metropolitan area networks are geographically dispersed over a large area. In the corporation, regional and metropolitan networks are used to connect local networks. The global WANs are located throughout the world, providing connectivity for the corporate regional and metropolitan networks in the fixed and deployed environment. In addition, mobile units, shared databases, and central processing centers can connect directly to the global network as required. Standard interfaces will be provided to connect corporate regional and metropolitan networks and end devices. Figure 8. Communication Infrastructure In this project the C-E sub-viewpoint is mainly focused on facilitating the interoperability issues. Therefore, understanding the Open Systems Interconnection (OSI) Reference Model, TOGAF Model, and Transmission Control Protocol (TCP) and Internet Protocol (IP) is essential to absorb communication theories and be able to implement them. The TOGAF, OSI and TCP/IP reference models (shown in Appendix 3) were considered for modeling data communication. The TCP/IP and OSI models detailing the equivalent TOGAF platform infrastructure are hierarchical structures that have been widely adopted as standards in the computing and network communication industry because they define the necessary requirements for communication between computing devices. Each layer in the TCP/IP and OSI models represents single service(s) or protocol(s) and provides services for the layer above. Security model Historically, computing devices were secured by being behind physical walls of corporate offices. Using new technologies such as the Internet and VPN access, telecommuters could unsuspectingly infect their own devices and others by connecting to the corporate network. The widespread use of wireless networks made the security problem even more pressing. Therefore, the TA-CE Team did not distinguish between external and internal threats for the infrastructure architecture of the Heavy Vehicle Division. Recommendations for internal and external security access are: * Firewall Protection: Many techniques can be implemented to control access to the internal systems, such as for example, intruder detection, and URL blocking. * Router protection: The recommendations are applied if a hardware firewall is not installed such as an Intruder Detection service (IDS) module, which is an interface card that can be installed on a router. This module provides functionality of possible attacks at the router level; Internetwork Operating System (IOS) Firewall which provides intrusion detection functionality. Access Control Lists (ACL) to enforce privilege separation on routed packets. * Computing devices protection: The recommendation for this level is to maintain back up files, redundant servers, personal firewalls, update windows security patches, and application filtering. Figure 9. Security View Model The security model in Figure 9 shows the different levels of security for the Heavy Vehicle Division infrastructure: • Authentication: It is the mechanism to verify the identity of a user by the Application Program Interfaces (APIs). • Network Security: It is controlling the risk related to network use. • Server Security: Protecting servers and data are vital to protecting the organization’s business-critical files. The team focused on the security features of implementing Lotus Notes Servers. Table 1 Shows the security features of Lotus Notes servers. Table 1. Security Feature/Benefits of Lotus Notes Servers Feature Benefit Secure Multipurpose Internet Mail Extinctions (S/MIME ) • Ability to read, signs, encrypts, and verify signature. • Support X.509 certificate process; • Support and enhance other Web Access encryption messages. Password synchronization with Lotus Notes ID User can change their Lotus Notes password that Lotus Domino uses and have the option to change the internet password at the same time. Block access to attachment Administrators can control access to malicious attachments Force user logout Provide greater security for shared computers that access the organization’s infrastructure Control Lotus Sometime Web Conference Provide control over web conferencing There are three types of data security, as shown in Figure 9: * Element Security: It is any unit of data defended for processing, for example, Product ID, Product name, and Product description. * Document Security: The organization must enforce security policy mechanisms on sensitive documents. In addition, the mechanisms should not be restricted to any platform. * Data Security: is the way to protect data and keep it safe from corruption and unauthorized access. Figure 10 illustrates the security view of the network infrastructure. Network Infrastructure View The competitive global market place and the growth in outsourcing are increasingly forcing business environment to be collaborative in decision-making. Corporate workers, engineers, consultants, and contractors are globally dispersed. However, the demand for information exchange with 24x7 network accesses is crucial for business success. The IT department is responsible to support seamless robust communication deliver services to these users and enable technology to help in decision making across the organization. The network infrastructure is the backbone for business services, connectivity of users to acquire IT recourses and share information. This issue has been addressed in the new network infrastructure in Figure 10, where domestic and global suppliers, regional offices, remote office, and mobile users will be able to communicate, collaborate, and share information in a secure environment. Figure 10. Network Infrastructure Model The new network infrastructure posed a number of challenges to the TA-CE Team, such as: * Provide network connectivity among all computing devices and servers to support business services. * Support core business applications, database access, file transfers, remote terminals access, web browsing, remote dialup, and others. * Provide global access to services via internet, extranet and intranet. * Provide and maintain reliable, scaleable, secure, and cost effective network infrastructure by using suitable and compatible mainstream technologies based on standards. * Provide mechanism for future growth that does not interfere with critical legacy applications. * Achieve centralized infrastructure with distributed responsibilities for effective and efficient services. The network structure accommodates the internal and external commutation to support all nursery function of daily business. Disaster Recovery Model The organization’s data networks are strategic assets essential to its competitiveness and survival. The planning for the disruption of data into two separate locations is vital to the success of protecting the assets of organizations. The Disaster recovery system must consider the growing use of Internet-base application in a wide-area network (WAN) environment and redundant storage of data. To reduce the risk on information assets, data can be replicated in multiple locations. The robust WAN design integrated redundancy to reduce single points of failure. Figure 11 illustrates the approach to link two data centers via Synchronous Optical Network (SONET). Figure 11. Disaster Recovery Model 6. DISCUSSION This educational case study describes the architectural project of the TA-CE Team, based on a real- world project, concerned with developing an ADD for the Communications Engineering Views of the Technology Architecture Viewpoint. The systematic architecture approach followed by the team helped to consider the concerns and principles relevant to the problem, and instantiate the architecture framework with all the information relevant to the stakeholders when developing the models. The architecture process model and methodology guided the team to structure the work involved to produce the deliverables for the team assignments. The team approach helped team members to coordinate their work and meet assignment deadlines. The models of the ADD were developed by observing newly developed and/or purchased components/services and standards. The main concern of the TA-CE Team was to present the Communications Views to the stakeholders who are primarily network engineers and network architects. The TA-CE project deliverables were reviewed by professional architects and network engineers who provided feedback to the student team as they progressed with the project. 7. ACKNOWLEDGEMENTS The authors wish to express their appreciation to the sponsors of the TA-CE Team project for providing an opportunity to apply IT architectural theory to practice and collaborating on this educational project. 8. REFERENCES 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. Boar, B. H. (1999a) Attitudes, Personality, and Behavior. The Dorsey Press, Chicago. Boar, B.H. (1999b) Constructing Blueprints for Enterprise IT Architectures, Wiley. Cisco Systems. Retrieved April 2006 from http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/secur_c/scprt3/scacls.htm#14220. Cook, M. (1996) Building Enterprise Information Architecture. Prentice-Hall. Feurer, R. Chaharbaghi, K. Weber, M. and Wargin, (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. IBM (2004). Rational Rose. Retrieved April 2006 from www.IBM.com. IEEE Std 830 (1998) IEEE Recommended Practice for Software Requirements Specifications. IEEE Std 1058 (1998) IEEE Standard for Software Project Management Plans. 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/IEC (1996) ISO/IEC10746-3 Information Technology - Open Distributed Processing- Reference Model: Architecture. ISO/IEC12207 (2002) Information Technology – Software Life Cycle Processes. ISO/IEC15288 (2002) Systems Engineering – System Life Cycle Processes. ISO/IEC 17799 (2000) Information Technology – Code of Practice for Information Security Management. Kakish, K., Steenkamp, A. L., Basal, A., Dawwas, M., Konda, and D. Shulaiba, R. (2004) “A Team Project on Information Technology Infrastructure Architecture,” in Proc. of ICIER2004, International Conference of Informatics Education Research, Washington DC. 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. OMG (2006) Model-Driven Architecture Standards. Retrieved April 2006 from www.omg.org. Orlikowski and Gash (1994) “Making sense of information technology in organi-zations,” ACM Transactions on Information Systems, 12, 2. Perks, C. and Beveridge, T. (2003) Guide to Enterprise IT Architecture, Springer, New York. Popkin Software (2004) Retrieved April 2006 from www.popkin.com/products/system_architect.htm. Proforma Corporation (2006) ProVision Workbench Whitepaper. Retrieved April 2006 from http://www.proformacorp.com/. Rechtin, E. (1997) “Teaching systems architecting: Science and Art,” IEEE Spectrum, 29, 10. Schekkerman, J. (2005) 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, Third Edition. Schekkerman, J. (2005) The Economic Benefits of Enterprise Architecture. Trafford Publishing. Steen, M. W. A., Akehurst, D.H., ter Doest, H.W.L. and Lankhorst, M.M. (2004) "Supporting Viewpoint-Oriented Enterprise Architecture," in Proc. of the 8th IEEE Intl Enterprise Distributed Object Computing Conf. Steenkamp, A. L. and Kakish, K. (2004) "An Approach to Developing Information Technology Architecture," in Proc. of the Intl Conference on Informatics Education Research (ICIER2004), Washington, DC. The Open Group (2006) TOGAF -The Open Group Architecture Framework Version 8.1 Enterprise Edition. Varga, M. (2003) “Zachman Framework in teaching information systems," In Proc. of the 25th Int. Conf. on Information Technology Interfaces. Zachman, J. A. (1987) “A Framework for Information Systems Architecture,” IBM Systems Journal, 3. Zachman, J. A. and Sowa (1992) “Extending and Formalizing the Framework for Information Systems Architecture,” IBM Systems Journal, 31, 3. APPENDIX 1. PROJECT REQUIREMENTS FOR TECHNOLOGY VIEWPOINT – COMMUNICATIONS ENGINEERING VIEWS Develop an ADD which addresses the issues of the assigned project and accommodate the business requirements namely: • Technology Architecture Baseline Description • Target Technology Architecture • Gap analysis between the Baseline and the Target Technology Architectures • Justification of how the ADD models will meet the stakeholders’ concerns • List of the relevant tools and techniques In order to achieve the project charter the TA-CE Team will develop an ADD which addresses the issues of the assigned project and accommodate the business requirements. It should include: 1. Technology Architecture Baseline Description * Review existing baseline architectures (business, applications, etc.) to the degree necessary to make informed decisions and subsequent work. * Develop a baseline description of the existing technology architecture to the extent necessary to support the target technology architecture. For each major hardware or software platform type define the following: - Name – short and long - Who maintains the hardware/software - Physical location - Owner(s) - Other users - Plain language description of what the hardware/software platform is and what it is used for - Business functions supported - Organizational units supported - Networks accessed - Applications and data supported - System interdependencies (ex: fallback configurations) * Identify and document candidate technology architecture building blocks (potential reusable assets). * Draft the technology architecture baseline report: Summarize key findings and conclusions, developing suitable graphics and schematics to illustrate the baseline configurations. * Review the technology architecture baseline report with relevant stakeholders and incorporate feedback. Refine as necessary. 2. Development of the Target Technology Architecture * Inputs include - Technical Principles - Request for Architecture Work - Statement of Architecture Work - Architecture Vision(business scenario/architecture vision) - Relevant technical requirements from previous phases - Gap Analysis from other architectures - Baselines from other architectures - Target architectures from other architectures * Outputs include - Statement of Architecture Work - Technology Architecture Baseline - Validated Technology Principles - Technology Architecture Report summarizing what was done and the key findings. - Target Technology Architecture - Technology Architecture Gap Report - Viewpoint attributes which address key stakeholder’s concerns. Include the following Views in the Technology Architecture Model * Activities include - Collect data on the current systems - Document all the constraints - Review and validate the set the technology architecture principles - List the distinct functionality - Produce affinity groupings of functionality using the TOGAF technical reference model service groupings. - Analyze relationships between groupings - Identify interfaces - Produce technology architecture model - Verify technology architecture model - Document key questions to test merits of technology architecture - Document criteria for selection of service portfolio architecture. - Identify appropriate tools and techniques to be used for capturing, modeling, and analysis, in association with the assigned view point. - Perform tradeoff analysis to resolve conflicts among the different viewpoints as mentioned above in the CMU/SEI’S ATA - Develop the following views: network computing/hardware view, communications view, processing view, security view, standards view. 3. A gap analysis between the Baseline and the Target Technology Architectures. This can be best accomplished by building a Gap Analysis Matrix where you draw up a matrix with all the business architecture building blocks of the current architecture on the vertical axis, and all the business architecture building blocks of the target architecture on the horizontal axis. The most critical source of gaps that should be considered is stakeholder concerns that have not been addressed in the current architecture. Also consider other potential sources of gaps. A brief justification of how the Technology - C.E. Viewpoint will meet the stakeholders’ concerns. 4. A list of the relevant tools and techniques that you intend to use in the project. APPENDIX 2. ARCHITECTURE FRAMEWORK INSTANTIATED FOR THE TECHNOLOGY- C.E. VIEWPOINT TECHNOLOGY – COMMUNICATIONS ENGINEERING VIEWPOINT Model Portfolio Modeling language Purpose Concern/ Principle Stakeholder Content Layer Aspect Standard Tools System block diagram Block Diagram Informing Effective communications CIO Overview Technical Systems Structure Heavy Truck Division Visio Gap analysis Table Informing Deciding Consolidation Optimization CIO Detail Heavy Truck Division MSWord Conceptual model Graphic Informing Designing Effective communications CIO CTO Architect Overview Technical Systems Structure IEEE 1471 Visio Specification model Graphic Informing Designing Effective communications CTO Architect Network Engineer Coherence Technical Systems Structure ISO/IEC 10746-3 Visio Communications infrastructure Graphic Designing Effective communications Architect Network Engineer Coherence Technical Systems Structure ISO/IEC 10746-3 Visio Security Features Table Deciding Benefit CIO CTO Detail Technical Structure Heavy Truck Division MSWord Security model Graphic Informing Secure comms. Architect Overview Technical Systems Structure ISO/IEC17799 802.1x Visio Network infrastructure Graphic Designing Effective communications Architect Engineer CTO Network Engineer Coherence Technical Systems Structure ISO/IEC 10746-3 Visio Disaster Recovery Model Graphic Informing Deciding Secure recovery Architect Engineer CTO Network Engineer Overview Technical Systems Structure ISO/IEC17799 Visio APPENDIX 3. TOGAF, OSI, AND TCP/IP REFERENCE MODELS APPENDIX 4. METHODOLOGY FOR TECHNOLOGY ARCHITECTURE -COMMUNICATIONS ENGINEERING VIEWPOINT Architecture Stage/Phase Steps Artifact /Model IT Architecture Stage Planning Phase 1. Review project charter 2. Review viewpoint guidelines 3. Adopt architectural framework 4. Prepare Architectural Project Plan 5. Determine Framework/review principles within context of chosen architectural framework for communications engineering viewpoint. Architectural Project Plan - TA1 Framework and Process Model Overarching and viewpoint principles Architecture Stage IT Analysis Phase 6. Perform functional analysis; analyze project requirements, interpret project charter, and develop C.E. viewpoint definitions C-E sub-viewpoint definitions: Function tables 7. Gather information requirements from project sponsors relevant to C-E viewpoint Viewpoint requirements: Use-cases and scenarios 8. Choose representation schemes, modeling notations and CASE tool. Views Representation schemes 9. Adopt documentation method and template. EAB( Boar, 1999) documentation method and project folder format 10. Adopt method for alignment with enterprise and IT strategies. Not applicable 11. Model conceptual, logical views and document using CASE tool. System block diagram Conceptual architecture 12. Develop Draft Architectural Design Description Draft Architectural Design Description TA2 Target Architecture Stage Build IT Architecture Phase 13. Determine draft architectural design/scope; model physical views and document using CASE tool. Specification model Communication infrastructure Security mode Network infrastructure 14. Develop Service Level Agreement Service Level Agreement 15. Develop Disaster Recovery Plan Disaster Recovery Plan 16. Write technical paper : Architectural Case Study Draft ADD Case Study based on TA-CE Team project - TA3