INTE 30033 Systems Integration and Architecture 1 PDF

Systems Integration and Architecture 1 Compiled by: Engr. Ranil M. Montaril, MSECE 1  Table of Contents Table of Contents..............................................................................

Systems Integration and Architecture 1 Compiled by: Engr. Ranil M. Montaril, MSECE 1  Table of Contents Table of Contents.................................................................................................................. 2 Module 1: Introduction to Systems Integration and Enterprise Architecture........................... 5 Overview.......................................................................................................................................5 Lesson Outcomes...........................................................................................................................5 Lesson 1: Importance of IT in Organizations....................................................................................5 Lesson 2: Defining Systems Integration...........................................................................................6 Lesson 3: Defining Enterprise Architecture......................................................................................7 References................................................................................................................................... 10 Assessment.................................................................................................................................. 12 Module 2: Overview of Enterprise Architecture Frameworks................................................ 13 Overview..................................................................................................................................... 13 Lesson Outcomes......................................................................................................................... 13 Lesson 1: The Enterprise Architecture Framework......................................................................... 13 Lesson 2: The Zachman Framework for Enterprise Architecture..................................................... 15 Lesson 3: The Open TOGAF Framework......................................................................................... 18 References................................................................................................................................... 21 Assessment.................................................................................................................................. 22 Module 3: Components of Enterprise Architecture............................................................... 23 Overview..................................................................................................................................... 23 Lesson Outcomes......................................................................................................................... 23 Lesson 1: Components of Enterprise Architecture......................................................................... 23 References................................................................................................................................... 26 Assessment.................................................................................................................................. 27 Module 4: Enterprise Information Architecture Concepts...................................................... 28 Overview..................................................................................................................................... 28 Lesson Outcomes......................................................................................................................... 28 Lesson 1: EIA Data Domains, Information Governance, and Information Security.......................... 28 Lesson 2: Conceptual and Logical View of Enterprise Information Architecture.............................. 33 Lesson 3: Component Model and Operational Model of Enterprise Information Architecture......... 38 2  References................................................................................................................................... 48 Assessment.................................................................................................................................. 50 Module 5: Enterprise Architecture Methods......................................................................... 51 Overview..................................................................................................................................... 51 Lesson Outcomes......................................................................................................................... 51 Lesson1: Evolution of Systems Development Methodology........................................................... 51 Lesson 2: Strategies for Enterprise Architecture Implementation................................................... 52 Lesson 3: Enterprise Architecture Incremental Build Context......................................................... 53 References................................................................................................................................... 53 Assessment.................................................................................................................................. 54 Module 6: Enterprise Integration Technologies.................................................................... 55 Overview..................................................................................................................................... 55 Lesson Outcomes......................................................................................................................... 55 Lesson 1: Integrating Technologies................................................................................................ 55 Lesson 2: Enterprise Application Integration Concepts................................................................... 59 Lesson 3: Enterprise Portal Technologies for Integration................................................................ 61 Lesson 4: Web Services for Real-Time Integration......................................................................... 64 Lesson 5: Service-Oriented Architecture for Integration................................................................. 65 References................................................................................................................................... 68 Assessment.................................................................................................................................. 68 Module 7: Enterprise Resource Planning.............................................................................. 69 Overview..................................................................................................................................... 69 Lesson Outcomes......................................................................................................................... 69 Lesson1: Definition of Enterprise Resource Planning..................................................................... 69 Lesson 2: ERP and Systems Integration.......................................................................................... 70 Lesson 3: ERP’s Role in Logical Integration.................................................................................... 70 Lesson 3: ERP’s Role in Physical Integration................................................................................... 71 Lesson 4: ERP implications for Management................................................................................. 71 Lesson 5: Comparison of E-Commerce and ERP............................................................................. 71 Lesson 6: ERP- Architecture and Components................................................................................ 72 Lesson 6: ERP Implementations.................................................................................................... 75 3  References................................................................................................................................... 78 Assessment.................................................................................................................................. 79 Module 8: Other EA Enabling Technologies.......................................................................... 80 Overview..................................................................................................................................... 80 Lesson Outcomes......................................................................................................................... 80 Lesson 1: Cloud Computing.......................................................................................................... 80 Enterprise Computing.........................................................................................................................................80 Internet as a Platform.........................................................................................................................................83 Cloud computing.................................................................................................................................................87 Future of enterprise cloud computing................................................................................................................88 Lesson 2: Business Intelligence, Analytics and Search.................................................................... 89 Data Warehousing..............................................................................................................................................89 OLTP and OLAP...................................................................................................................................................90 TEXT AND DATA MINING....................................................................................................................................92 References................................................................................................................................... 93 Assessment.................................................................................................................................. 93 APPENDIX A. Course Syllabus........................................................................................................ 94 4  Module 1: Introduction to Systems Integration and Enterprise Architecture Overview The Role of IT in an organization is very important especially in enabling business processes. Business capabilities of a modern organization are often determined largely by the capabilities of IT systems. Although modern organization are facing misalignment within its different department and its external parties due to decentralized Information Systems, poor communication within groups, inadequate planning, incomplete requirements. This challenges creates a critical implications to meet the organization’s business goal. To achieve this alignment, the organization should act as a single “big brain” always making best globally and locally optimized business and IT decisions. Systems/Enterprise integration is a progressive process; furthermore, its objectives have changed with the increase of computerization in the society. Facing all these uncertainties and changes, business processes have to be loosely coupled and flexible enough to be easily reconfigurable and to support the collaboration of workers at distributed geographical locations. Enterprise architecture is the process by which organizations standardize and organize IT infrastructure to align with business goals. These strategies support digital transformation, IT growth and the modernization of IT as a department. Lesson Outcomes o To discuss the role of IT and its importance in an Organization o To define an Enterprise integration and explain its goals in an enterprise. o To distinguish Enterprise Integration to System Integration, o To elaborate the four stages of System Integration. o To articulate the Enterprise Architecture and explain its goals, and advantages. o To Enumerate the common Enterprise Architecture Frameworks Lesson 1: Importance of IT in Organizations Most organizations nowadays are critically dependent on the daily operations of Information Technology (IT). Large Companies/Organizations often to run and maintain thousands of various IT systems to enable their business processes. The influence of IT systems on business models is continuously increasing. The role of IT in an organizations has evolved from purely technical and supporting action to a more strategic or even business-enabling function. Information systems often become a backbone of major organizational changes and transformations. The capital investment in IT systems, IT budgets and infrastructure are steadily increasing over time. Through the decades, the Information systems become more powerful, ubiquitous, diverse and affordable. The computing power and storage capacity of IT systems are exponentially increasing. Today, Business Applications can be deployed on dedicated servers, can be hosted in the cloud, and can run web 5 browsers and even installed on hand held devices. The relative price of IT systems are getting affordable making it more accessible. The purpose of IT is not only limited on installing the appropriate software and hardware in an organization rather improving the quality of business processes that requires consistent and coordinated changes in the three broad organizational aspects:  People  Trainings and Education to system users.  Processes  Introducing new improved business processes enabled by system  Decision Making procedures and rules.  Technology  Setting up new IT systems and required infrastructure.  Providing Technical and helpdesk support to users. Information systems can help organization executes their business strategies and gain competitive advantages in terms:  Operational Excellence and Cost Leadership  Product differentiation and leadership  Customer Intimacy and focus. Lesson 2: Defining Systems Integration Each department added its own custom-built applications, built specifically for its own use, without coordination with other functions or departments. With the passage of time, organizations accumulated isolated computer silos, each with their specific hardware, software, access procedures, data formats, and processing tools. To bring some order into a chaotic situation, enterprise systems integration started as a vehicle and a methodology to bring disparate systems together through a common front-end and mask the underlying computer and communication infrastructure. It has evolved into a systematic redesign of the information architecture, within enterprises and across enterprises, to ensure the flexibility and extensibility of the Applications by design, in addition to their interoperability. Both aspects coexist in initiatives for systems integration, even when they are not explicitly stated. System integration is closely related to enterprise integration, which “is concerned with facilitating information, control, and material flows across organizational boundaries by connecting all the necessary functions and heterogeneous functional entities (information systems, devices applications, and people) in order to improve communication, cooperation and coordination within this enterprise so that the 6 enterprise behaves as an integrated whole, therefore enhancing its overall productivity, flexibility, and capacity for management of change (or reactivity)”. The important distinction is that the scope of system integration may extend outside the boundary of the enterprise to cover suppliers, customers, banks, and other parties involved in electronic commerce. Enterprise Application Integration (EAI) was one of the first architectural concepts to bring together the various heterogeneous applications and information systems of an enterprise. The goal was to integrate the various platforms, tools, and applications spread across various departments and areas separated by organizational boundaries, so that they could access the same data and communicate using a common protocol. Four Stages of System Integration System integration can be achieved at different levels, which are labeled as follows: o Interconnectivity o Functional Interoperability o Semantic Interoperability o Optimization and Innovation Drivers for Systems Integration A combination of several factors have stimulated and facilitated systems integration projects. These are: o Advances in computer networks and information processing. o Globalization. o Need for organizational agility to cope with competition and rapid development. o Market positioning through the customization of products and services. o Regulatory compliance. It should be noted that the various integration drivers interact with each other and their effects are usually combined. For example, both technological advances and deregulations have resulted in a worldwide competitive environment with new patterns of collaboration and partnerships that enterprise information systems have to contend with. Issues in Enterprise/System Integration Current enterprise (or system) integration plans pose significant challenges due to the following issues: o Nature of the networking technology. o The difficulties of standardization. o The security threat to institutions and individuals. Lesson 3: Defining Enterprise Architecture Enterprise architecture (EA) is the practice of analyzing, designing, planning and implementing enterprise analysis to successfully execute on business strategies. EA helps businesses structure IT projects and policies to achieve desired business results and to stay on top of industry trends and disruptions using architecture principles and practices, a process also known as enterprise architectural planning (EAP). 7 History EA began in the 1960s, born from “various architectural manuscripts on Business Systems Planning (BSP) by Professor Dewey Walker”. John Zachman, one of Walker’s students, helped formulate those documents into the more structured format of EA. Both men also worked for IBM during this time, and that’s when Zachman published the framework in the IBM Systems Journal in 1987. Figure 1.0 Dewey Walker The EA framework came as a response to the increase of business technology, especially in the 1980s when computer systems were just taking hold in the workplace. Companies soon realized they would need a plan and long-term strategy to support the rapid growth of technology and that remains true today. Modern EA strategies now extend this philosophy to the entire business, not just IT, to ensure the business is aligned with digital transformation strategies and Figure 2 John Zachman technological growth. EA is especially useful for large businesses going through digital transformation, because it focuses on bringing legacy processes and applications together to form a more seamless environment. Goals of enterprise architecture: EA is guided by the organization’s business requirements — it helps lay out how information, business and technology flow together. This has become a priority for businesses that are trying to keep up with new technologies such as the cloud, IoT, machine learning and other emerging trends that will prompt digital transformation. “The framework successfully combines people, data and technology to show a comprehensive view of the inter-relationships within an information technology organization,” The process is driven by a “comprehensive picture of an entire enterprise from the perspectives of owner, designer and builder.” Unlike other frameworks, it doesn’t include a formal documentation structure; instead, it’s intended to offer a more holistic view of the enterprise. A good EAP strategy considers the latest innovations in business processes, organizational structure, information systems and technologies. It will also include standard language and best practices for business processes, including analyzing where processes can be integrated or eliminated throughout the 8 organization. The ultimate goal of any EAP strategy is to improve the efficiency, timeliness and reliability of business information. Benefits of enterprise architecture: EA can offer support for re-designs and re-organization, especially during major organizational changes, mergers or acquisitions. It’s also useful for bringing more discipline into the organization by standardizing and consolidating processes for more consistency. EA is also used in system development, IT management and decision-making, and IT risk management to eliminate errors, system failures and security breaches. It can also help businesses navigate complex IT structures or to make IT more accessible to other business units. The biggest benefits of EAP include: o Allowing more open collaboration between IT and business units o Giving business the ability to prioritize investments o Making it easier to evaluate existing architecture against long-term goals o Establishing processes to evaluate and procure technology o Giving comprehensive view of IT architecture to all business units outside of IT o Providing a benchmarking framework to compare results against other organizations or standards Enterprise architecture methodologies Enterprise architecture as a framework can be vague since it’s meant to address the entire organization, instead of individual needs, problems or business units. Therefore, several frameworks exist to help companies effectively implement and track EAP. According to CompTIA, these are the four leading Enterprise Architect Planning (EAP) methodologies: The Open Group Architectural Framework (TOGAF): TOGAF provides principles for designing, planning, implementing and governing enterprise IT architecture. The TOGAF framework helps businesses create a standardized approach to EA with a common vocabulary, recommended standards, compliance methods, suggested tools and software and a method to define best practices. The TOGAF framework is widely popular as an enterprise architect framework, and according to The Open Group it’s been adopted by more than 80 percent of the world’s leading enterprises. 9 The Zachman Framework for Enterprise Architecture: The Zachman framework is named after one of the original founders of enterprise architecture and it’s another popular EA methodology. It’s better understood as a “taxonomy,” according to CompTIA, and it spans six architectural focal points and six primary stakeholders to help standardize and define the IT architecture components and outputs. Federal Enterprise Architecture Framework (FEAF): FEAF was introduced in 1996 as a response to the Clinger-Cohen act, which introduced mandates for IT effectiveness in federal agencies. It’s designed for the U.S. government, but it can also be applied to private companies that want to use the framework. Gartner: After acquiring The Meta Group in 2005, Gartner established best practices for EAP and adapted them into the company’s general consulting practices. While it’s not an individual framework, CompTIA recognizes it as a “practical” methodology that focuses on business outcomes with “few explicit steps or components.” These are just four of the most commonly referenced and recognized EA methodologies, but others exist. For example, there’s the European Space Agency Architectural Framework (ESAAF), the Ministry of Defense Architecture Framework (MODAF) and the SAP Enterprise Architecture Framework. These frameworks are specifically targeted to individual industries or products, targeting more of a niche market than the more generalized EA methodologies listed above. Enterprise architect role Enterprise architects typically report to the CIO or other IT managers. They’re responsible for analyzing business structures and processes to see that they align with business goals effectively and efficiently. As an enterprise architect, you’ll also be responsible for ensuring these structures and processes are agile and durable, so they can swiftly adapt and withstand major change. References DaumBerthold, MertenUdo System Architecture with XML．San Francisco, CA，Morgan Kaufmann Publishers，2003． DoanAnhai, HalevyAlon, IvesZachary Principles of Data Integration．Massachusetts，Morgan Kaufmann Publishers，2012． Enterprise Information Architecture (EIA)．[Online][Cited: 27 September 2020．]https://cio- wiki.org/wiki/Enterprise_Information_Architecture_(EIA)． FinkelsteinClive Enterprise Architecture for Integration: Rapid Delivery Methods and Technologies．USA ，British Library Cataloguing in Publication Data，2006． FoundationEnterpriseInformation Architecture: A Semantic and OrganizationalTom Reamy ． [Online][Cited: 27 September 2020．]https://boxesandarrows.com/enterprise-information- architecture-a-semantic-and-organizational-foundation/． 10 GautamShroff Enterprise Cloud Computing: Technology, Architecture, Applications．New York， Cambridge University Press，2010． GodinezMarioet al. The Art of Enterprise Information Architecture: A Systems-Based Approach for Unclocking Business Insight．New York，IBM Press-Pearson plc，2010． GormanMichaelM.Enterprise Architectures． [Online]https://cdn.ttgtmedia.com/searchDataManagement/downloads/Enterprise_Architectures_Chap ter%2004.pdf． IEEE 1471-2000 - IEEE Recommended Practice for Architectural Description for Software-Intensive Systems．[Online]https://standards.ieee.org/standard/1471-2000.html． MyersonJudithM. Enterprise Sysatem Integration．New York，AUERBACH PUBLICATIONS，2001． RoshenWaseem SOA- Based Enterprise Integration: A Step by Step Guide to Service-Based Application Integration．New York，McGraw-Hill，2009． SageAndrewP., RouseWilliamB Handbook of Systems Engineering and management．s.l.，John Wiley & Sons，1999． SherifMostafaHashem Handbook of Enterprise Integration．New York，Auerbach Publications，2010 ． The TOGAF Standard version 9.2． [Online]https://publications.opengroup.org/c182?_ga=2.228793374.389549404.1598886728- 2043625528.1598886728． TOGAF Online: Introduction．[Online]http://www.togaf.com/togaf9/chap01.html． What Is Service-Oriented Architecture?: A Look At the Nuts and Bolts of Service-Oriented Architecture． [Online][Cited: 27 September 2020．]https://medium.com/@SoftwareDevelopmentCommunity/what- is-service-oriented-architecture-fa894d11a7ec． WhiteSarahK.What is enterprise architecture? A framework for transformation．[Online]16 October 2018．https://www.cio.com/article/3313657/what-is-enterprise-architecture-a-framework-for- transformation.html． Wikipedia: Enterprise architecture framework． [Online]https://en.wikipedia.org/wiki/Enterprise_architecture_framework． 11 Assessment Answer the following questions: 1. What are the Role of IT in an Organization? 2. Explain, how IT systems are becoming more powerful? 3. Why organizations need to invest in IT? 4. Identify and elaborate the issues may encounter during enterprise integration. 12  Module 2: Overview of Enterprise Architecture Frameworks Overview A Framework can be defined as a real or concept structure intended to serve as a support or guide for the building of something that expands the structure into something useful. In computer systems, a framework is often a layered structure indicating the kind of programs can or should be built and how they would interrelate. The layered structure mentioned is described as a vertical layer where at the top you want to see the most abstract and at the bottom is more of real infrastructure hardware and components. This Model documents the architecture-centric concepts associated with enterprise development. Lesson Outcomes o To explain the need of Enterprise Framework for designing and implementing an Enterprise Information Systems. o To develop a knowledge on how the Zachman Framework depicts entire artifact of an enterprise architecture. o To enumerate the Advantages and the Drawbacks of using Zachman Framework. o To recognize another known EA framework such as TOGAF. o To discover its Composition, Use and Benefits. Lesson 1: The Enterprise Architecture Framework A framework is a formal structure of giving you a list of the key elements that key factors we use in enterprise architecture. Four Characteristics of Enterprise Architecture Framework o Skeleton/Structure  It is an outline when you practice Enterprise Architecture. o Classification of Schema or Ontology  Classification of Schema is the way of describing the object, components that makes up and EA and group it together based on its characteristics.  Ontology is a set of concepts and categories in a subject area or enterprise architecture that shows their properties and the relations between them. o Thinking Tool  It helps to think about the Enterprise Architecture, on how to develop it on the future. It provides you different options and ways to configure or implement your enterprise architecture. o Management Tool  The EA is a management tool, it helps us to evolve the Enterprise Architecture. It also helps you to move it from current state to a target state. It gives you the capabilities that the business requires 13 IEEE 14071:2000 The enterprise architecture was based from a construction or civil architecture. This has become a basis of most software intensive systems such as information system, embedded systems and composites. And also this is adopted by most framework of enterprise architecture. Figure 3 Conceptual model of architectural description Different Views (i.e. Business Services View) are collected by the System Architecture. An organization desiring to produce an architecture framework for a particular domain can do so by specifying a set of viewpoints and making the selection of those viewpoints normative for any Architectural Description claiming conformance to the domain-specific architectural framework. This standard provides a conceptual framework which meant to explain how the key terms relate to each other in a conceptual model for architectural descriptions. It also tackles the role of stakeholders in the creation of architectural description. It also provide a number of scenarios for the architectural activities during the life cycle. 14 Lesson 2: The Zachman Framework for Enterprise Architecture Enterprise architecture was developed by John Zachman while with IBM in the 1980 s after observing the building and airplane construction industries and the IT industry. He saw similarities between the construction of buildings, airplanes, and the information systems used by an enterprise. It depicts the design artifacts that constitutes the intersection between roles in the design process which is: o Owner o Designer o Builder And the abstractions which is: o What (material) is made of o How (process) it works o Where (geometry) Figure 4 Interest in different diagrams or representations from their views/perspectives These industries manage the design, construction, and maintenance of complex products by considering the needs of different people. The figure above illustrates the owner in the building industry, who uses architect’s drawings to decide that the building addresses specific requirements. For airplane manufacture, the owner uses the high-level work breakdown structure of the plane to determine requirements. For information systems, the owner uses a model of the business to determine the enterprise needs. The designer, however, needs a different set of diagrams: architect’s plans for the building, sets of engineering design diagrams for the plane, or information system models for the enterprise. The builder relies on still different types of diagrams: contractor’s plans for construction of the building, a manufacturing engineering design for plane construction, or technology models for information systems. 15 Considering the following Abstractions: Figure 5 Different questions (or abstractions) also need to be considered in the design and construction of buildings, airplanes, and enterprise systems. What is needed is important to know. This is represented in Figure above by material, such as bills of materials for buildings and planes, and data models for information systems. How these are used is indicated by functions, such as functional specifications for buildings and planes, and functional models for information systems. Where is also important, as indicated by location—in drawings for building and plane construction and in network models for information systems. To complete the Zachman Framework for enterprise architecture, additional interrogatives added (Who, When, and Why). Bringing these concepts together, the result is a matrix of five rows and six columns. These represent the perspectives of the planner, the owner, the designer, the builder, and the subcontractor, who are all interested in what, how, where, who, when, and why. The last row addresses the functioning enterprise. The sixth row is not normally counted in the five main rows of the Zachman framework. 16  Figure 6 The complete Zachman framework for enterprise architecture Advantages of the Zachman framework: o Easy to understand.  It provides a holistic perspective on the whole enterprise while at the same time allowing to focus on certain aspects of the object. Thus, informed decision making with regards to creating, operating, and transforming the enterprise is enabled. o It addresses the enterprise as a whole, it is defined independently of tools or methodologies, and any issues can be mapped against it to understand where they fit. Drawback of the Zachman framework: o The large number of cells, which is an obstacle for the practical applicability of the framework. o The relations between the different cells are not that well specified. o Does not give a step-by-step process for creating a new architecture. o Does not give much help in deciding if the future architecture we are creating is the best architecture possible. o Does not give an approach to show a need for a future architecture 17 Lesson 3: The Open TOGAF Framework The Open Group Architecture Framework (TOGAF) is a framework with a detailed method and a set of supporting tools - for developing an enterprise architecture. It may be used freely by any organization wishing to develop an enterprise architecture for use within that organization. TOGAF is developed and maintained by members of The Open Group, working within the Architecture Forum (www.opengroup.org/architecture). History: The original development of TOGAF Version 1 in 1995 was based on the Technical Architecture Framework for Information Management (TAFIM), developed by the US Department of Defense (DoD). The DoD gave The Open Group explicit permission and encouragement to create TOGAF by building on the TAFIM, which itself was the result of many years of development effort and many millions of dollars of US Government investment. Starting from this sound foundation, the members of The Open Group Architecture Forum have developed successive versions of TOGAF and published each one on The Open Group public web site Using TOGAF as the architecture framework will allow architectures to be developed that are consistent, reflect the needs of stakeholders, employ best practice, and give due consideration both to current requirements and to the likely future needs of the business. Architecture design is a technically complex process, and the design of heterogeneous, multi-vendor architectures is particularly complex. TOGAF plays an important role in helping to "de-mystify" and de- risk the architecture development process. TOGAF provides a platform for adding value, and enables users to build genuinely open systems-based solutions to address their business issues and needs. 18  Figure 7 TOGAF Structure TOGAF consists of: o Architecture Capability Framework  This part discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture practice within an enterprise. o Architecture Development Method  This is the core of the TOGAF framework. It describes the TOGAF Architecture Development Method (ADM) – a step-by-step approach to developing an Enterprise Architecture. o Architecture Content Framework  This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable architecture building blocks, and an overview of typical architecture deliverables. 19  o Enterprise Continuum & Tools:  This part discusses appropriate taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise. Figure 8 ADM Steps of TOGAF Benefits of TOGAF: Any organization undertaking, or planning to undertake, the design and implementation of an enterprise architecture for the support of mission-critical business applications will benefit from use of TOGAF. Organizations seeking Boundary-less Information Flow can use TOGAF to define and implement the structures and processes to enable access to integrated information within and between enterprises. Organizations that design and implement enterprise architectures using TOGAF are assured of a design and a procurement specification that can facilitate an open systems implementation, thus enabling the benefits of open systems with reduced risk. 20 References DaumBerthold, MertenUdo System Architecture with XML．San Francisco, CA，Morgan Kaufmann Publishers，2003． DoanAnhai, HalevyAlon, IvesZachary Principles of Data Integration．Massachusetts，Morgan Kaufmann Publishers，2012． Enterprise Information Architecture (EIA)．[Online][Cited: 27 September 2020．]https://cio- wiki.org/wiki/Enterprise_Information_Architecture_(EIA)． FinkelsteinClive Enterprise Architecture for Integration: Rapid Delivery Methods and Technologies．USA ，British Library Cataloguing in Publication Data，2006． FoundationEnterpriseInformation Architecture: A Semantic and OrganizationalTom Reamy ． [Online][Cited: 27 September 2020．]https://boxesandarrows.com/enterprise-information- architecture-a-semantic-and-organizational-foundation/． GautamShroff Enterprise Cloud Computing: Technology, Architecture, Applications．New York， Cambridge University Press，2010． GodinezMarioet al. The Art of Enterprise Information Architecture: A Systems-Based Approach for Unclocking Business Insight．New York，IBM Press-Pearson plc，2010． GormanMichaelM.Enterprise Architectures． [Online]https://cdn.ttgtmedia.com/searchDataManagement/downloads/Enterprise_Architectures_Chap ter%2004.pdf． IEEE 1471-2000 - IEEE Recommended Practice for Architectural Description for Software-Intensive Systems．[Online]https://standards.ieee.org/standard/1471-2000.html． MyersonJudithM. Enterprise Sysatem Integration．New York，AUERBACH PUBLICATIONS，2001． RoshenWaseem SOA- Based Enterprise Integration: A Step by Step Guide to Service-Based Application Integration．New York，McGraw-Hill，2009． SageAndrewP., RouseWilliamB Handbook of Systems Engineering and management．s.l.，John Wiley & Sons，1999． SherifMostafaHashem Handbook of Enterprise Integration．New York，Auerbach Publications，2010 ． The TOGAF Standard version 9.2． [Online]https://publications.opengroup.org/c182?_ga=2.228793374.389549404.1598886728- 2043625528.1598886728． TOGAF Online: Introduction．[Online]http://www.togaf.com/togaf9/chap01.html． 21 What Is Service-Oriented Architecture?: A Look At the Nuts and Bolts of Service-Oriented Architecture． [Online][Cited: 27 September 2020．]https://medium.com/@SoftwareDevelopmentCommunity/what- is-service-oriented-architecture-fa894d11a7ec． WhiteSarahK.What is enterprise architecture? A framework for transformation．[Online]16 October 2018．https://www.cio.com/article/3313657/what-is-enterprise-architecture-a-framework-for- transformation.html． Wikipedia: Enterprise architecture framework． [Online]https://en.wikipedia.org/wiki/Enterprise_architecture_framework． Assessment Part 1: Read and summarize the ZACHMAN Framework for Enterprise Architecture in your own words. Map this framework to any enterprise system and provide architecture. Part2: Answer the following Questions: 1. What is the distinct advantage of Zachman Framework over TOGAF? 2. Explain how can information systems used by organization is related to construction of buildings. 22  Module 3: Components of Enterprise Architecture Overview An enterprise’s architecture is the engineering and structure of the enterprise’s mission, organizations, functions and database domains so that they can be extended and/or integrated with other more technical architectures such as hardware, business information systems, and business events. It describes the contents of the enterprise’s architecture and its high level model that tells how it is created. The enterprise architecture model comprises architectural components that serves as a key for identification of the Resources and their Resource Life Cycles. Lesson Outcomes o To enumerate and explain each components of Enterprise Architecture o To differentiate the approach of IT on development and support of Enterprise Architecture Lesson 1: Components of Enterprise Architecture The Four Primary components of Enterprise Architecture are: o Enterprise Business Architecture o Enterprise Information Architecture o Enterprise Solution Architecture o Enterprise Technology Architecture 23  Business Architecture Development Drives Information Architecture Support Prescribes Solutions Architecture Supported by Technical Architecture Figure 9 Four Components of EA Enterprise Business Architecture The Enterprise Business Architecture (EBA) documents the business strategy, governance, organization and business functions. EBA also establishes a baseline that defines which organizations perform these functions. It also provides a holistic view of our state government from a business perspective. It answers questions like, Who we are?, What we do?, and Where we want to go? It is gives a common reference model of citizens, businesses, members of General Assembly, current and future administrations, and other interested parties that helps define the business of state of government. Enterprise Information Architecture EIA provides a framework, model, and method to enhance each agency’s to quickly discover access, and understand data, while creating information needed to support critical agency business function decisions. The EIA framework must have three components that contain information about the enterprise’s data assets: o Data Sharing (How do I exchange the data?) 24   Information Exchange and Query Points – Information generated/required by a Unit of work and is subsequently passed to another unit of work. o Data Description (What does the data mean?)  Structured- Organized description of data to convey semantic understanding usually through an entity relationship diagram.  Semi Structured- Data that has characteristics of both Structured and Unstructured such email.  Unstructured – data that is more free-form format such as unstructured text. o Data Context (How do I find the data and access it?)  Subject Area - Broad Categories of data that supports business processes.  Information Class - Groupings of lines of business or community of interest. Enterprise Solution Architecture ESA is the collection of information systems supporting or related to the business functions defined by EBA and the enterprise business model, including applications and components that are purchased or custom-developed. Also known as Enterprise Application Architecture. ESA includes: o Inventory Solutions, applications, and components currently used to support business functions in an enterprise. o Analysis of current/baseline solutions, and current technology tools supporting existing automated solutions. o Future-state recommendations of automated solutions and related tools. o ESA governance and implementation requirements. Enterprise Technical Architecture ETA is a consistent set of IT standards and models that: o Reflect and support EBA, EIA, and ESA components. o Guides the engineering of emerging IS and technology infrastructure. ETA domains: o Security o Enterprise system Management o Information o Database o Applications o Integration o Platform o Networking and Telecommunications. 25 References DaumBerthold, MertenUdo System Architecture with XML．San Francisco, CA，Morgan Kaufmann Publishers，2003． DoanAnhai, HalevyAlon, IvesZachary Principles of Data Integration．Massachusetts，Morgan Kaufmann Publishers，2012． Enterprise Information Architecture (EIA)．[Online][Cited: 27 September 2020．]https://cio- wiki.org/wiki/Enterprise_Information_Architecture_(EIA)． FinkelsteinClive Enterprise Architecture for Integration: Rapid Delivery Methods and Technologies．USA ，British Library Cataloguing in Publication Data，2006． FoundationEnterpriseInformation Architecture: A Semantic and OrganizationalTom Reamy ． [Online][Cited: 27 September 2020．]https://boxesandarrows.com/enterprise-information- architecture-a-semantic-and-organizational-foundation/． GautamShroff Enterprise Cloud Computing: Technology, Architecture, Applications．New York， Cambridge University Press，2010． GodinezMarioet al. The Art of Enterprise Information Architecture: A Systems-Based Approach for Unclocking Business Insight．New York，IBM Press-Pearson plc，2010． GormanMichaelM.Enterprise Architectures． [Online]https://cdn.ttgtmedia.com/searchDataManagement/downloads/Enterprise_Architectures_Chap ter%2004.pdf． IEEE 1471-2000 - IEEE Recommended Practice for Architectural Description for Software-Intensive Systems．[Online]https://standards.ieee.org/standard/1471-2000.html． MyersonJudithM. Enterprise Sysatem Integration．New York，AUERBACH PUBLICATIONS，2001． RoshenWaseem SOA- Based Enterprise Integration: A Step by Step Guide to Service-Based Application Integration．New York，McGraw-Hill，2009． SageAndrewP., RouseWilliamB Handbook of Systems Engineering and management．s.l.，John Wiley & Sons，1999． SherifMostafaHashem Handbook of Enterprise Integration．New York，Auerbach Publications，2010 ． The TOGAF Standard version 9.2． [Online]https://publications.opengroup.org/c182?_ga=2.228793374.389549404.1598886728- 2043625528.1598886728． TOGAF Online: Introduction．[Online]http://www.togaf.com/togaf9/chap01.html． 26 What Is Service-Oriented Architecture?: A Look At the Nuts and Bolts of Service-Oriented Architecture． [Online][Cited: 27 September 2020．]https://medium.com/@SoftwareDevelopmentCommunity/what- is-service-oriented-architecture-fa894d11a7ec． WhiteSarahK.What is enterprise architecture? A framework for transformation．[Online]16 October 2018．https://www.cio.com/article/3313657/what-is-enterprise-architecture-a-framework-for- transformation.html． Wikipedia: Enterprise architecture framework． [Online]https://en.wikipedia.org/wiki/Enterprise_architecture_framework． Assessment Answer the following: o Enumerate and Explain each components of Enterprise Architecture o What’s the effect of an enterprise’s architecture on your projects? o Is the enterprise’s architecture followed as a controlling guidance? o What have been the benefits and drawbacks if it is followed as a controlling guidance? 27  Module 4: Enterprise Information Architecture Concepts Overview The heart of IA is information and knowledge, and we need to build on that foundation. EIA’s should better understand their organization’s business strategy and integrate the strategic vision in order to contribute to the development of business strategy. This can be done with a good IT governance framework. Conceptual as well as on the Logical Layer, both represent well-defined layers describing the EIA Reference Architecture. The architecture decisions that we then use to drill-down from the conceptual view to the logical view. The component model of the EIA Reference Architecture is covering the relevant services with its descriptions and interfaces to describe the functional components in terms of their roles and responsibilities, their relationships and interactions to other components, and the required collaboration to allow the implementation of specified deployment and customer use case scenarios. The operational- modeling approach provides a view on how physical nodes can be derived from logical components of the component model and related deployment scenarios. This uses of operational patterns on how Information Services can be constructed to achieve functional and nonfunctional requirements. Lesson Outcomes o To examine the different data domains that is being used in the line of business of an enterprise. o To determine the different areas IT governance that tightly coupled in business strategies and objectives. o To identify the different aspects of IT security and Information Privacy services. o To acquire knowledge on Conceptual and Logical views of Enterprise Information Architecture. o To design the Component Model of an Enterprise Information Architecture and to assemble the corresponding Operational Model. Lesson 1: EIA Data Domains, Information Governance, and Information Security Data Domains Data domains classifies information assets used for specific purposes where the purpose identifies usage patterns with a dedicated set of capabilities. Certain types of data might be used enterprise-wide and others might be used only locally within a department or a Line of Business (LOB). The data might be structured (for example, an order) or unstructured (for example, a scanned contract document). The data might also differ from a retention perspective indicating how long the data must be stored. We see the following five data domains: o Metadata Domain  Defined as “data about the data.” Metadata is the information that describes the characteristics of each piece of corporate data asset and other entities. o Master Data Domain  Refers to instances of data describing the core business entities, such as customer or product data. o Operational Data Domain 28   Also referred to as transactional data capturing data, which is derived from business transactions. o Unstructured Data Domain  Also known as content, typically managed by an enterprise content management application. o Analytical Data Domain  Usually derived through transformation from operational systems to address specific requirements of decision support applications. Figure 10 The five pillars of Enterprise Information IT Governance and Information Governance IT Governance is the key to deriving architectural decisions. Rather than trying to define what good architectural decisions are (nearly impossible because it is problem and context specific), we describe a typical governance framework to help drive architectural principles, policies, and decisions that can be agreed and policed by all relevant parties Standard of IT Governance For IT Governance, many standards do exist but one common example is the COBIT standard (Control Objectives for Information and related Technology), which is owned by the IT Governance Institute. From the COBIT perspective, IT Governance is considered a framework to govern IT assets over their lifecycle. Good IT Governance ensures that the IT group supports and extends the company strategies and business objectives. The decision making process on how information systems are planned and organized, acquired and implemented, delivered and supported, as well as monitored and evaluated. It should therefore be just another strategic agenda item that the board addresses. IT Governance is tightly coupled with the following: o IT principles  High-level statements about how IT will be used to create business value and a generic information-centric set o IT architecture  The set of technical choices that guide the enterprise in satisfying business needs. o IT infrastructure strategies  Describes the approach to building shared and standard IT services across the enterprise o Functional business requirements  Refers to applications that need to be acquired or built 29  o Prioritization of IT investments  The whole process of IT investments, including where they should be focused and the procedures for progressing initiatives, their justification, approval, and accountability. Information Governance is defined as the orchestration of people, processes, and technology to enable an organization to leverage information as an enterprise asset. It specifically details the area associated with managing issues such as incomplete data, poor or untimely access to data, lack of or poor Metadata, and managing and resolving duplicate (or similar) data. The key objectives of an Information Governance program need to first establish a culture that recognizes the value of information as an enterprise asset. This requires real discipline and possibly the creation of new roles within the business that didn’t exist previously (for example, Information Stewards for information assets). The development of effective Information Governance drives value into companies in many ways, including: o Compliance and regulatory adherence satisfies auditors and regulators by developing data management environments leveraging technology and process to ensure adherence to specific requirements. o Enhanced BI capabilities using high-quality information drives new opportunities for organic growth (for example, by identifying opportunities for increased effectiveness in cross-selling and retaining existing customers) o Enhanced alignment of IT initiatives with business strategies drives more value and enables the business through data availability and enrichment, which enables insightful strategic planning and execution. o Improved platforms measure, monitor, and improve business performance by tying operational metrics to business performance measures and facilitating reporting and management of critical processes. o Reduced environmental complexity improves business flexibility and accelerates strategic initiatives by providing comprehensive and predictable information environments that support effective business decision making. 30  Figure 11 Information Governance Information Security and Information Privacy Information Security and Information Privacy is another aspect of managing and controlling the information assets which are exposed to a growing number of security threats today. This is focus for our business information, and then we look at the potential areas in which information could be seen to be under risk in a typical enterprise information scenario. Trends around the security aspects of business systems: o Across the globe there has been a growing number of attacks on major enterprises with (internal inspired) threats still high. o Business infrastructures, such as utility networks for water or electricity, are increasingly equipped with sensors to capture information. The information is used, for example, to predict peak consumptions. o The Cloud Computing delivery model requires new means to federate identities across internal and external systems to protect data from unauthorized access. o Regulatory compliance pressures around the world across all industries demand strict enforcement of data access and Information Privacy. o Access by partners to internal systems is ever increasing as the new trends to distributed solutions and cooperation across business boundaries take place. o As systems design leads to more consolidated data sets (around core enterprise-wide DW and MDM capabilities), the opportunity to hack one’s critical resource can actually increase. There are many areas in which we must address Information Security in our business. 31 The following are: o Business Security Services  Defined as security aspects of the business that must be specified, owned, and managed for successful and secure operations of an enterprise. These are driven by regulatory concerns, partnerships, competitive influences, and more. o IT Security Services  Form the core technical components that must be designed and deployed around our data domains to deliver the security functions as defined in the Business Security Services layer. This means that the IT Security Services layer is responsible for addressing how the business security services are physically deployed. o Security Policy Management  Defined as a set of policies and principles that ensure that the Business Security Services are managed in a consistent manner with IT. Therefore, the Security Policy Management links the business-related and IT-related security services together. Data masking is rapidly gaining prominence when dealing with data such as test databases and the requirement to enable structurally integral data sets without exposing live data to the developers or designers. As defined by IBM, data masking is the process of identifying sensitive data and overlaying values that masks the sensitive data, but does not compromise the functional integrity of an application. By enabling data masking in the business, it seeks to manage the following issues in today’s businesses: o Meet regulatory compliance needs. o Enhance data security. o Protect against internal or external attacks as the data has little or no external value. o Enable the use of production data within exposing private, sensitive or confidential data to any non-trusted party. Figure 12 Data Masking Techniques There are two techniques in Data masking: o Extract-Mask-Transform-Load (EMTL)  Uses an enhancement to the well-known Extract-Transform-Load (ETL) mechanism often used with Data Warehouse environments. This is the process of extracting data from 32  production into flat files while masking the data and finally loading the data into multiple different environments. o In-Place Data Masking  Data is first copied from production into multiple environments and then masked in place. Lesson 2: Conceptual and Logical View of Enterprise Information Architecture The conceptual and logical layers are the first elements for a solution design with the latter fleshing out the former. Both represent well-defined layers describing the EAI Reference Architecture. For the Conceptual Layer, the EIA Reference Architecture is necessary because of its capabilities for in the context of the architecture terms and the Enterprise Information Model. An Architecture Overview Diagram (AOD) shows the various required capabilities in a consistent, conceptual overview for the EIA Reference Architecture. By introducing architecture principles, we guide the further design of the EIA Reference Architecture. We apply them to drill-down in a first step from the Conceptual to the Logical Layer. We show the Logical View as a first graphical representation of the logical architecture and explain key Architecture Building Blocks (ABB). Conceptual Architecture Overview An EIA provides an information-centric view on the overall Enterprise Architecture. Thus, any instantiation of the EIA Reference Architecture enables an enterprise to create, maintain, use, and govern all information assets throughout their lifecycle from a bottom-up perspective. From a top-down perspective, business users and technical users articulate their information needs in the context of business processes shaping the business and application architecture based on the role they perform. We develop the EIA Reference Architecture from a top-down perspective. We look at information from an end user perspective working with or operating on it to achieve certain goals. Key functional and technical capabilities provide and enable the set of operations on information required by the user community of an enterprise. Thus, we approach the Conceptual View of the EIA Reference Architecture presented in an AOD by introducing from a business Perspective the required functional and technical capabilities. The EIA must cover all five data domains with appropriate capabilities as required by each individual domain. Furthermore, there are several capabilities required that span across either some or all data domains. Building an EIA Reference Architecture that satisfies the more advanced business requirements of today and the upcoming ones in the future, we see the need for the following additional capabilities: o Predictive Analytics and Real Time Analytics  Predictive Analytics are capabilities allowing the prediction of certain values and events in the future. For example, based on the electricity consumption patterns of the past, an energy provider would like to predict spikes in consumption in the future to optimize energy creation and to reduce loss in the infrastructure.  Real Time Analytics are capabilities to address the need to analyze large-scale volumes of data in real time. Real Time Analytics capabilities consist of the ability of real time trickle 33  feeds into the DW, the ability of complex reporting queries executing in real time within the DW, and the ability of real time delivery of analytical insight to front-line applications. o Business Performance Management BPM is a capability enabling business users to:  Define the Key Performance Indicators (KPI) for the business.  Monitor and measure against the defined KPIs on an ongoing basis.  Visualize the measurements in a smart way enabling rapid decision making.  Complement the visualization with trust indices about the quality of the underlying data putting the results in context regarding their trustworthiness.  Intelligently act if the measurement of the KPIs indicates a need to act.  Trigger events and notifications to business users if there are abnormalities in the data. This capability often depends on strong analytical application capabilities. o Enterprise Information Integration (EII)  Provides abilities to understand, cleanse, transform, and deliver data throughout its lifecycle.  Data harmonization from various Operational Data sources into an enterprise-wide DW.  For cost and flexibility reasons, hiding complexity in the various, heterogeneous data sources of new applications should not be implemented in such a way that they are tied to specific versions of these data sources. Thus federated access must be available.  Re-use of certain data cleansing functions such as standardization services in an SOA to achieve data consistency and improve data quality on data entry must be supported. This requires deploy capabilities of data quality functions as services. o Mashup  Mashup capabilities enable a business to quickly build web-based, situational applications at low cost for typically small user groups (for example, all members of a department). The Mashup capability must allow non-technical users to create new value and insight from the combined information by mashing together information from various sources. o Information Governance  o Information Security and Information Privacy  A crucial part for the design, deployment, and control processes of any instantiation of the EIA throughout its life cycle. The Information Governance capability enables a business to manage and govern its information as strategic assets. More specifically it:  Aligns people, processes, and technology for the implementation of an enterprise-wide strategy to implement policies governing the creation and use of information.  Assigns Information Stewards to govern information assets throughout their life cycle. The Information Stewards govern each information asset in the scope of defined policies, which might be automated regarding enforcement or might require a human being executing a task.  Assigns a balance sheet describing the value of the information and the impact of loss or improper management from a data quality perspective. o Cloud Computing  Cloud computing capability is necessary for many enterprises today and represents a new delivery model for IT. However, the Cloud Computing delivery model is more than just a 34  new way of billing for IT resources. A new set of IT capabilities has been developed and significant changes to existing IT components have been applied. Not surprisingly, the Cloud Computing delivery model also affects the Information Management domain and therefore the EIA within an enterprise. Thus, we briefly introduce functional and technical capabilities relevant for the Cloud Computing delivery model  Multi-Tenancy capabilities  Self-Service capabilities  Full Automation capabilities  Virtualization capabilities  Elastic Capacity capabilities  Metering capabilities  Pricing capabilities  Billing capabilities  Monitoring capabilities EIA Reference Architecture In the Architecture Overview Diagram (AOD), you can see various candidates for Architecture Building Block (ABB) representing the discussed capabilities. Note that Information Governance is not shown explicitly, because only parts of Information Governance are technology based. A framework characteristic of the EIA Reference Architecture represented by the AOD is its industry- agnostic nature. Therefore, for any deployment for a company in a specific industry adaptation to industry-specific requirements must be done. For example, if the EIA Reference Architecture is used by a government to define the EIA for a homeland security solution, integration with external supply chain participants might not be needed, whereas third-party data providers such as terrorist blacklists must be integrated. 35  Figure 13 Architecture Overview Diagram for the EIA Reference Architecture Architecture Principle of EIA Architecture principles are a set of logically consistent and easily understood guidelines that direct the design and engineering of IT solutions and services in the enterprise. These principles provide an outline of the tasks, resources, and potential costs to the business for their implementation, and they also provide valuable input that can be used to justify why certain decisions have to be made. Architecture principles should enable the EIA Reference Architecture as a tool that can help you map between the organization’s business goals, business architecture, IT landscape, and the solution delivery, and help the Enterprise Information Architecture to be the conduit to understand the implications of planned new business requirements. The following are the 22 Architecture Principles: o Deploy enterprise-wide Metadata strategies and techniques. o Exploit analytics to the finest levels of granularity. o Exploit Real Time and Predictive Analytics for business optimization. o Enable KPI-based Business Performance Management (BPM). 36  o De-couple data from applications enabling the creation of trusted information which can be shared across business processes in a timely manner. o Strive to deploy an enterprise-wide search capability. o Compliance with all Information Security requirements. o Compliance with all relevant regulations and Information Privacy legislation. o Deliver de-coupled, trusted information through Information as a Service (IaaS) so that information services in a SOA are reusable and shareable services for the business like other business services. o Deploy new levels of information lifecycle management creating actionable information. o Apply Cloud Computing delivery model to Information Services. o Improve cost efficiency of the IT infrastructure, possibly now also using Green IT techniques. o Deliver information with appropriate data quality. o End-to-end inter- and cross-enterprise information integration. o Develop an EII strategy with optimization of data transport, federation, and placement. o Virtualize information whenever possible. o Deliver operational reliability and serviceability to meet business SLA to ensure access to Structured and Unstructured Data at all times. o EIA should reduce complexity and redundancy and enable re-use. o EIA should be based on open standards. o Enterprise information assets must have a business owner and be part of end-to-end Information Governance. o Align IT solution with business. o Maximize agility and flexibility of IT assets. Logical View of EIA Reference Architecture This diagram and the AOD described previously can be used to start the discussion about how one actually deploys these information components out into an enterprise. We depict each of the major areas of the EIA Reference Architecture, including the general system and infrastructure components needed to operate and manage any IT landscape. In addition, a set of common requirements that straddle all the layers of the information architecture—Business Process Orchestration and Collaboration capabilities, comprehensive Connectivity and Interoperability capabilities, and security- related requirements—all needed to manage and run any solution developed. 37  Figure 14 Logical View of the EIA Reference Architecture Lesson 3: Component Model and Operational Model of Enterprise Information Architecture The Component Model specifically describes how these functional aspects can be assembled to add value in any solution stack, and the Operational Model details how these functional components can be deployed onto physical assets to deliver the requirements (functional and non-functional) of the design. We now introduce each layer with a brief description. The Component Model To delve deeper into the architecture description of the EIA, another term is needed: component. A component represents a logically grouped set of specific capabilities to deliver particular software functionality. The Component Model is the heart of the EIA. It describes the functional components in terms of their roles and responsibilities, their relationships and interactions to other components, and the required collaboration that enables the implementation of specified deployment and customer use case scenarios. Each component is a relatively independent part of the architecture, where its characteristics are described by its functions, responsibilities, usage aspects, and interfaces. Their usages depend on the required solution capabilities and deployment scenarios. A detailed description of each component, the main focus of the Component Model is the Component Relationship Diagram and the Component Interaction Diagrams. 38 Component Relationship Diagram This diagram is a depiction of the components, interfaces, and relationships that are a part of the Component Model. The interfaces and relationships can be described at different levels. They simply describe directional flows of data between two components. On a more ambitious level, they describe the information content and the usage of protocols to exchange the information content between components. We call this the static relationship between the components. For the Component Relationship Diagram presentation, we applied the following color codes: o The dark gray boxes represent the information services components for the metadata, data, content, master data, and analytical data domain. o The gray boxes represent information service-related components such as the EII Component, the Mashup Hub Component, and IT Service & Compliance Management Services Component. o The light gray boxes are components that are not part of the previous two categories and are typically found in a solution based on the EIA. Figure 15 The Component Relationship Diagram 39 Component Descriptions Aside from a high-level description, it include a detailed description of the main functionalities and the responsibilities of each component. Depending on the nature and functional scope of the component, it also includes the service description and implementation aspects. These implementation aspects might be characterized by various design and service patterns. The component interactions, interfacing capabilities, and functional and non-functional requirements complete the Component Descriptions. Those key functional components are described using the following structure (depending on concrete project needs, a more enriched structure might be needed): o ID  For easy identification o Name  Applying intuitive naming convention o High-level description  Short paragraph for quick understanding o Service description  Focus on service, including service patterns o Interfaces  Component interactions and interface standards (such as XML) Figure 16 Service Description Component Interaction Diagrams These diagrams depict how components dynamically collaborate to support various required business scenarios. These diagrams capture the most significant dynamic relationships between components. It focuses on the interactions between components and illustrate the derived flow of functionality in the context of a specific deployment scenario. Depending on the deployment scenario and required business 40 scope, an appropriate subset of the functionality of each component might be required. Any customer use case scenario can be easily mapped to the Component Model using the corresponding Component Interaction Diagram. Each step in a scenario is indicated with a number. We now begin with the first scenario. Here we assume the user (a customer) bought a consumer product (e.g. shoes, mobile phone, PDA, and so on) in a store. Figure 17 Walkthrough for the information-centric application deployment scenario The Operational Model The Operational model is the definition and distribution of an IT system’s components onto geographically distributed nodes. It predominately targeted at enterprise architects, information architects, and system architects; however, it can also be used as a reference for IT experts from different skill domains. The key concepts of operational modeling provide an understanding of how physical nodes can be derived from logical components of the Component Model. 41 According to the IBM Architecture Description Standard (ADS), the Enterprise Architecture can be presented at different levels. One of the principles that guides the development of an ADS is the recognition that infrastructure design is a specialized skill and that its exponents deal with concepts, entities, and methods that are different from those known in the area of application development. The EIA Reference Architecture is subdivided into three parts: a Conceptual Level, a Logical Level, and a Physical Level Forms of Operational Mode Levels Logical Operational Model (LOM) The LOM identifies the required technical services, develops the connections, and refines the technical specifications. It describes: o Placement of specified components onto specified nodes o Specified connections between those nodes necessary to support the interactions between specified components o Non-functional characteristics of those nodes and connections, acquired from the placed specified components and their interactions Physical Operational Model (POM) It is the hardware and software technologies needed to deliver the Operational Model’s characteristics and capabilities are identified and configured. It documents the overall configuration of the technologies and products necessary to deliver the functional requirements and NFRs of the IT system. In particular, it describes: o Hardware and software technology and product selection for computers and networks o Hardware specifications, such as processor speed and disk configuration, or network bandwidth and latency o Overall hardware configurations, such as “fail-over” or “scalable” arrangements o Software product specifications (such as version) and detailed configuration, such as the need for multiple instances of a software product (operating system, middleware, and communication element or application system) on a computer Operational Model Concepts and Notations o Node  The central concept of an Operational Model.  A platform on which software executes. During early stages of the design process, a node represents a potential platform, before decisions have been made about how to map it to actual platforms. Each node has a name and optionally the number of instances. o Connections  It represent physical data paths between nodes and show the shape of the network. 42  o Deployment units (DU)  Items placed on the nodes.  It is the smallest unit of software or data for which an architect makes a placement decision. Deployment units are shown as named items on each node. A deployment unit consists of one or more components. o Execution deployment units (EDU)  It represents the installation and execution of components. o Locations  Group of nodes.  It is a geographical entity (such as a zone or building type) and is shown by pictorial elements around one or more nodes. Key Design Concepts within Operational Modeling When implementing Information Services, various design and development tasks must meet the operational requirements of the IT system. The major conceptual work items are: o The placement and grouping of components into deployment units o The application of walkthroughs confirming operational aspects. o The consideration of constraints and quality requirements o The physical configuration for a set of technologies Context of Operational Model Design Techniques The Operational Model derives from the Component Model and it details functional component interactions and deployment scenarios. The process of operational modeling means the partitioning and aggregation of logical components to DUs. The placement of DUs on physical nodes, the related locations and zoning capabilities, specified the node-to-node connections, and analyze the supported range of NFRs, the selected delivery model, and the scope of integration needed to meet the business context and related use cases. Figure 18 Generalized Operational Models 43 However, the generalized Operational Model allows to select, customize, and integrate pre-developed architectural patterns for our needs. For this reason, a collection of predefined node types, connection types, location types, and DU placements is provided. Furthermore, relevant IT service management node types, specified technical components, and topology patterns are selected carefully. Inter-location border types and interrelationships of specified nodes for the most common distribution scenarios of logical components are also provided. With these operational design techniques, we can maximize the reuse of robust solution outlines by selectable architectural patterns in the context of the EIA Reference Architecture. For operational modeling purposes, it is important to understand that NFRs can be derived from affected data domains such as Operational or Analytical Data. Operational Model Relationship Diagram Operational Model design techniques and service qualities are needed to satisfy a certain business scenario. The Operational Model relationship diagram is a depiction of nodes, locations, and correlating connections separately documented as the design proceeds. The relationship of those elements is developed to verify the way in which the Operational Model supports crucial use case scenarios. We introduce the generalized level of the LOM and POM to convey the application of patterns and reuse. Generalization means we provide a collection of standard node types, pre-defined connection types, location types, and deployment unit placements for specific business scenarios. It is important to recognize that the standards provided are a representation of typical IT landscapes over which the system is distributed. They represent the “design building blocks” that will be used when deciding upon the detailed physical configuration for a set of technologies. Basic Location Types: o External Business Partners Location o Public Service Providers Location o Disaster Recovery Site Location o Branch Systems Location o Branch Systems Location Inter-Location Border Types: o Corporate WAN  Corporate wide area network o Branch LAN  Internal local area network (LAN within a branch) o Head Office LAN  Internal local area network (within head office) o Internet Link  Internet link and access to the external business partner’s organization 44 Access Mechanisms In order to describe how the component model is implemented across IT systems, the Operational Model documents the access mechanisms used by all users of the system. In operational terms, people (and systems) can use and access the system components in a variety of access mechanisms according to the defined use cases. Well-known standard access mechanisms include: o System Support and Management o File Download (from file producers) o File Upload (to file consumers) o Message Receipt (from message producers) o Message Sending (to message consumers) o Socket Request (from socket requestors) o Socket Response (from socket responders) Standards of Specified Nodes Specified nodes do not represent actual computing resources. Rather, they provide a formal mechanism for enabling the specification of the location for the solution’s application and underlying technical components across the geographic landscape. Using standard specified nodes for the EIA Reference Architecture, we examine the patterns of how Information Services can be constructed and instantiated. Node relationship provides node-to-node connections and fleshing out exemplary topology views to meet particular service-level characteristics. This leads to the categorization of common capabilities in layers. The classification is done in four layers: o Information Services o Application Platform Layer for Information Services o Technology Layer for Information Services. o IT Service & Compliance Management Services. 45  Figure 19 Standard node types and their categorization in layers Figure 20 Example of a populated Logical Operational Model Relationship Diagram 46 Framework of Operational Patterns The framework of operational patterns is a repository of recurring solution elements based from previous experiences. It is a good practice to capture and reuse the experience of past engagements. The lessons learned applying Information Services, you can consider the “scope of integration” which is determined by typical deployment scenarios of these services. The scope of integration impacts the requirements for availability, resiliency, security, and, to a certain extent, scalability. The scope of integration can be categorized in three ways: o Discrete solution scope  Predominately applies to the use of services in a single Line of Business (LOB) o Integrated solution scope  Typically signifies the use of services as shared services across the enterprise o Cross-domain solution scope  Applies to the use of services in a multi-enterprise context, typically through the interconnection with partners or third-party providers Different Derived Operational Patterns (Selections and Reuse) o Near-Real-Time Business Intelligence Pattern  Provides access to information about business actions as soon after the fact as is justifiable based on the requirements. The implementation of near-real-time BI involves the integration of a number of activities required in any DW or BI implementation. o Data Integration and Aggregation Runtime Pattern  Provides solutions for transparently managing both the volume and diversity of data that exists in enterprises across the LOBs. It builds a solid foundation of existing data management solutions. o Enterprise Service Bus (ESB) Runtime for Guaranteed Data Delivery Pattern  The integration of various technologies such as message-based communication mechanisms, guaranteed delivery of messages over the network, assurance of once-only delivery of messages, different communications protocols, dynamically distributed workloads across available resources, and recovery procedures after message system and connectivity problems. o Continuous Availability and Resiliency Pattern  High availability is a component of continuous availability. High availability focuses on reducing the downtime for unplanned outages, and continuous operations focus on reducing the downtime for planned outages. The sum of high availability and continuous operations equals continuous availability, and enables “never stop” of a set of information systems. o Multi-Tier High Availability for Critical Data Pattern 47   Redundancy is a critical and well understood means of achieving high availability. This includes redundant components, redundant systems, and redundant data. Hardware components can fail, and software quality varies from release to release, making other techniques for high availability equally important. o Content Resource Manager Service Availability Pattern  Contributes to availability by segregating functions and can enable increased redundancy, increased scalability, and simplified management among components o Federated Metadata Pattern  Communicates with and retrieve data from remote data sources through wrapper services o Mashup Runtime and Security Pattern o Compliance and Dependency Management for Operational Risk Pattern  It addresses formal and documented dependency and configuration management procedures, inter-relationships of information resources, and the impact of a single- configuration change on business applications and infrastructure services. o Retention Management Pattern  It is about retaining corporate records for the minimum appropriate retention period to meet business and regulatory requirements (laws, policies, and regulations on the business). o Encryption and Data Protection Pattern  Provides greater data security, integrity, retention, auditability, and privacy. o File System Virtualization Pattern  File virtualization approach is through the use of a Distributed File System Services Clustered Node such as IBM General Parallel File System (GPFS). o Storage Pool Virtualization Pattern  It addresses the increasing cost and complexity in data storage management by shifting storage management intelligence from individual SAN disk subsystem controllers into the network through a virtualization cluster of nodes. o Automated Capacity and Provisioning Management Pattern  It has the ability to control lifecycle, starting, stopping, and provisioning of services automatically. References DaumBerthold, MertenUdo System Architecture with XML．San Francisco, CA，Morgan Kaufmann Publishers，2003． DoanAnhai, HalevyAlon, IvesZachary Principles of Data Integration．Massachusetts，Morgan Kaufmann Publishers，2012． Enterprise Information Architecture (EIA)．[Online][Cited: 27 September 2020．]https://cio- wiki.org/wiki/Enterprise_Information_Architecture_(EIA)． 48 FinkelsteinClive Enterprise Architecture for Integration: Rapid Delivery Methods and Technologies．USA ，British Library Cataloguing in Publication Data，2006． FoundationEnterpriseInformation Architecture: A Semantic and OrganizationalTom Reamy ． [Online][Cited: 27 September 2020．]https://boxesandarrows.com/enterprise-information- architecture-a-semantic-and-organizational-foundation/． GautamShroff Enterprise Cloud Computing: Technology, Architecture, Applications．New York， Cambridge University Press，2010． GodinezMarioet al. The Art of Enterprise Information Architecture: A Systems-Based Approach for Unclocking Business Insight．New York，IBM Press-Pearson plc，2010． GormanMichaelM.Enterprise Architectures． [Online]https://cdn.ttgtmedia.com/searchDataManagement/downloads/Enterprise_Architectures_Chap ter%2004.pdf． IEEE 1471-2000 - IEEE Recommended Practice for Architectural Description for Software-Intensive Systems．[Online]https://standards.ieee.org/standard/1471-2000.html． MyersonJudithM. Enterprise Sysatem Integration．New York，AUERBACH PUBLICATIONS，2001． RoshenWaseem SOA- Based Enterprise Integration: A Step by Step Guide to Service-Based Application Integration．New York，McGraw-Hill，2009． SageAndrewP., RouseWilliamB Handbook of Systems Engineering and management．s.l.，John Wiley & Sons，1999． SherifMostafaHashem Handbook of Enterprise Integration．New York，Auerbach Publications，2010 ． The TOGAF Standard version 9.2． [Online]https://publications.opengroup.org/c182?_ga=2.228793374.389549404.1598886728- 2043625528.1598886728． TOGAF Online: Introduction．[Online]http://www.togaf.com/togaf9/chap01.html． What Is Service-Oriented Architecture?: A Look At the Nuts and Bolts of Service-Oriented Architecture． [Online][Cited: 27 September 2020．]https://medium.com/@SoftwareDevelopmentCommunity/what- is-service-oriented-architecture-fa894d11a7ec． WhiteSarahK.What is enterprise architecture? A framework for transformation．[Online]16 October 2018．https://www.cio.com/article/3313657/what-is-enterprise-architecture-a-framework-for- transformation.html． Wikipedia: Enterprise architecture framework． [Online]https://en.wikipedia.org/wiki/Enterprise_architecture_framework． 49 Assessment Answer the following questions: 1. How the different data domains can manage successful enterprise though a coherent Information Governance framework? 2. What is a Component Interaction Diagram? How does it demonstrated the viability of the component model? 3. What are the introduced operational patterns that enable the architect to improve the reuse of the implementation design of Information Services? 50  Module 5: Enterprise Architecture Methods Overview There are various methods for implementing enterprise architecture. The emphasis of these methods is to identify priority data, business activities, and business processes, and then deliver these priority areas in 3-month increments as production systems. Strategic modelling that identifies the reusable business activities and business processes from data models. This is a key method that is used to derive project plans manually or automatically from data models. This method enables high priority business subprojects to be identified for delivery in 3-month increments. It is also an important step in enterprise architecture is strategic alignment: so that data as well as processes, locations, people, events and business plans all support each other. Lesson Outcomes o To review the evolution of systems development methodologies. o To identify the different strategies for enterprise architecture implementations o To plan EA based on Incremental Build Context Lesson1: Evolution of Systems Development Methodology Methodologies that have evolved since the beginning of the Information Age have helped us to examine current manual processes so we could automate them. From rudimentary methodologies in the 1960s, by the 1970s these had evolved into the software engineering methods which are also called structured methods. Evolutions of Software Engineering The software engineering meth