University of Science and Technology Enterprise Architecture Lecture PDF

**University of Science and Technology** **Faculty of Computer Science and Information Technology** Department of Information Systems **Semester 8: Enterprise Architecture** **Lecture (1): Introduction to Enterprise Architecture** **Instructor: Prof. Noureldien A. Noureldien** **1- What is Ent...

**University of Science and Technology** **Faculty of Computer Science and Information Technology** Department of Information Systems **Semester 8: Enterprise Architecture** **Lecture (1): Introduction to Enterprise Architecture** **Instructor: Prof. Noureldien A. Noureldien** **1- What is Enterprise Architecture?** **[Definition (1): Enterprise: An Enterprise is any collection of organizations that has a common set of goals.]** **Definition (2):Architecture: An Architecture** is the fundamental organization of a system represented in its components, their relationships to each other, [the environment, and the principle guiding its design and evolution.] **That is: How you organize the components of a system and their relations with each other considering the environment and the guiding principles are architecture.** **Definition (3): Enterprise architecture**: An Enterprise Architecture is a systematic, strong set of principles, methods, and models that are used in the design and realization of an enterprise's organizational structure, business processes, information systems, and infrastructure. **[Enterprise architecture captures the essentials of the business, IT, and its evolution.]** The idea is that the essentials are much more stable than the specific solutions that are found for the problems currently at hand. **[Architecture is therefore helpful in guarding the essentials of the business, while still allowing for maximal flexibility and adaptiveness]**. Without good architecture, it is difficult to achieve business success. **The most important characteristic of enterprise architecture is that it provides a holistic view of the enterprise**. [A good enterprise architecture provides the insight needed to balance between different requirements and facilitates the translation from strategy to daily operations.] What is part of the enterprise architecture, and what only an implementation within that architecture is, is a matter of [what the business defines to be the architecture, and whatnot.] **[The quality of architecture means that the architecture helps in achieving essential business objectives]**. Therefore, to develop a quality architecture, choices should be related to the business objectives. **i.e What we should consider being part of the architecture must be required to achieve the business objectives.** Any architecture will need to allow and facilitate change. [Architectures change because the environment changes and new technological opportunities arise], and **[because of new insights as to what is essential]** to the business. Therefore, a[**n integrated set of methods and techniques for the specification, analysis, and communication of enterprise architecture that fulfills sure the needs of the different types of stakeholders in the enterprise is required**.] [Definition (4):] **Stakeholder**: A stakeholder is an individual, team, or organization with interests in, or concerns relative to, a system. **2- The Architecture Process** Architecture is a process as well as a product. [The product **serves to guide managers**] in [designing business processes] and **[system developers]** in [building applications in] a way that is in line with business objectives and policies. [Also, once the architecture is created, it needs to be maintained. Businesses and IT are continually changing. This constant evolution is, ideally, a rational process.] The architecture process consists of the usual steps that take an **initial idea** through **design and implementation** phases to an **operational** system, and finally maintaining the system, closing the loop. In all of the phases of the architecture process, clear communication with and between stakeholders is necessary. The [different architecture products in this life cycle are discussed with stakeholders, approved, revised], etc., and play a central role in establishing a common frame of reference for all those involved. **3- Drivers for Enterprise Architecture** Here, we briefly outline the most important and commonly recognized drivers for establishing an enterprise architecture. Business-IT association is commonly recognized as an important instrument to realize organizational effectiveness. The well-known strategic alignment model of **[Henderson and Venkatraman (1993]**) distinguishes between the aspects of: \- Business strategy and organizational infrastructure, and \- IT strategy and IT infrastructure The model provides four dominant perspectives that are used to tackle the alignment between these aspects (Fig. 1.3). [One can take the business strategy of an enterprise as the starting point, and derive its IT infrastructure either via an IT strategy or through the organizational infrastructure]; conversely, one can focus on IT as an enabler and start from the IT strategy, deriving the organizational infrastructure via a business strategy or based on the IT infrastructure. In any of these perspectives, enterprise architecture can be a valuable help in executing the business or IT strategy. In Fig. 1.4, enterprise architecture is positioned within the context of managing the enterprise. At the top of this pyramid, we see **[the mission]** of the enterprise [which states its 'image of the futu and the values the enterprise holds]. Next, there is **[its strategy]**, [which states the route the enterprise will take in achieving this mission and vision]. This is translated into concrete goals that give direction and provide the milestones in executing the strategy. **Translating those goals into concrete changes to the daily operations of the company is where enterprise architecture comes into play**. It offers a holistic perspective of the current and future operations and the actions that should be taken to achieve the company's goals. Next to architecture, which could be viewed as the 'hard' part of the company, **[the 'soft' part, its culture]**, which is formed by its people and leadership, and is of equal if not higher importance in achieving these goals. Finally, of course, we see the enterprise's daily operations, which are governed by the pyramid of Fig. 1.4. A well-defined architecture is an important asset in positioning new developments within the context of the existing processes, IT systems, and other assets of an organization, and it helps in identifying necessary changes. **University of Science and Technology** **Faculty of Computer Science and Information Technology** Department of Information Systems **Semester 8: Enterprise Architecture** **Lecture (2): Enterprise Architecture Methods and Frameworks** **Instructor: Prof. Noureldien A. Noureldien** **What is Enterprise Architecture Method?** An architecture method is a **[structured collection of techniques and process steps for creating and maintaining enterprise architecture]**. Methods typically specify the various phases of an architecture's life cycle, what deliverables should be produced at each stage, and how they are verified or tested. **What is Enterprise Architecture Framework?** **Enterprise [Architecture](https://cio-wiki.org/wiki/Architecture) [Framework](https://cio-wiki.org/wiki/Framework) (EA Framework)** is a **[formal definition of the essential elements or components of [Enterprise Architecture](https://cio-wiki.org/wiki/Enterprise_Architecture), and their inter-relationship.]** - - - An Enterprise Architecture fram**[ework (EA framework) defines how to create and use an [Enterprise Architecture](https://cio-wiki.org/wiki/Enterprise_Architecture)]**. An Architecture Framework provides principles and practices for creating and using the architecture description of a [system](https://cio-wiki.org/wiki/System). It divide the architecture description into domains, layers or views, and offers models - typically matrices and diagrams - for documenting each view. Enterprise architecture frameworks **[are valuable for planning and visualization]**. They are especially helpful at the early stages **[of architectural change to lead the conversation with stakeholders and visualize the outcomes of [business](https://cio-wiki.org/wiki/Business) and IT alignment.]** However, they are still just toolkits for people responsible for preparing the [roadmap](https://cio-wiki.org/wiki/Roadmap) to change **The Zachman Framework** In 1987, John Zachman introduced the first and best-known enterprise architecture framework (Zachman 1987), although back then it was called 'Framework for Information Systems Architecture'. The framework as it applies to enterprises is simply [**a logical structure for classifying** and **organizing the descriptive representations of an enterprise** that are significant to the management of the enterprise as well as to the development of the enterprise's systems]. **What is Zachman Framework?** Enterprise Architecture (EA) **[is a discipline that has evolved to structure the business and its alignment with the IT systems]**. **[The [Zachman Framework](https://www.visual-paradigm.com/features/zachman-framework-tools/) is a fundamental structure for Enterprise Architecture which provides a way of viewing an enterprise and its information systems from different perspectives,]** **and showing how the components of the enterprise are related**. **Why Zachman Framework?** **What is the problem today?** In today\'s complex business environments, many large organizations **have great difficulty responding to changes**. **Why Organizations have difficulties to respond to changes?** **[Part of this difficulty is due to a lack of internal understanding of the complex structure and components in different areas of the organizatio]**n. **[How Zachman Framwork solve this problem?]** **[By provides a means of classifying an organization\'s architecture].** **What is the relationship between Zachman Framework and Traditional Software Process?** Many **[software development methodologies]** are organized around the phases of the [**[system development life cycle]**](https://en.wikipedia.org/wiki/Software_development_process) and the steps within each of these phases required to develop systems. System development consists of **Strategy, Analysis, Design, Construction, Transition, and Testing.** In 1987, [**[John Zachman]**](https://en.wikipedia.org/wiki/John_Zachman) published a different approach to the **elements of system developmen**t. Instead of **[representing the process as a series of steps, he organized it around the points of view taken by the various players]**, **What this new organized provide?** This new organization provides an effective way of assessing the completeness of software development process models, in terms of an organization\'s information needs. **Structure of Zachman Framework** **[Zachman Framework is a two dimensional classification scheme for descriptive representations of an Enterprise that is structured as a matrix containing 36 cells]**, each cell is focusing on one dimension of the enterprise. Rows presented different viewpoints involved in the systems development process, while columns represent different perspectives of the stakeholders involved in the organization. The rows of Zachman Framework focus on describing the enterprise from six viewpoint perspectives of the stakeholders. **[These six perspectives are based on English language interrogatives \'what\', \'where\', \'who\', \'when\', \'why\', and \'how\' (known as W5H).]** The columns of the framework **[consist of a set of artifacts which are description of the enterprise from specific viewpoint of a group of stakeholders.]** The stakeholders are generally grouped as planners, owners, designers (architects), implementers, sub-constructors, and users. https://upload.wikimedia.org/wikipedia/commons/d/da/Zachman\_Framework\_Detailed.jpg **Columns of Zachman Framework** The columns represent the questions that are asked of the enterprise. These are: - **What** (data) - what is the business data, information or objects? - **How** (function) - how does the business work, i.e., what are the business\' processes? - **Where** (network) - where are the business's operations? - **Who** (people) - who are the people that run the business, what are the business units and their hierarchy? - **When** (time) - when are the business processes performed, i.e., what are the business schedules and workflows? - **Why** (motivation) - why is the solution the one chosen? How was that derived from? What motivates the performance of certain activities? **Rows of Zachman Framework** Each row represents **[a distinct view of the organization, from the perspective of different stakeholders]**. - **Planner\'s View** (Scope Contexts) - **This view describes the business purpose and strategy, i[t serves as the context within which the other views will be derived and managed]**. - **Owner\'s View** (Business Concepts) - This is a description of the organization within which the information system must function. **[Analyzing this view reveals which parts of the enterprise can be automated.]** - **Designer\'s View** (System Logic) - This **[view outlines how the system will satisfy the organization\'s information needs]**. The representation is free from solution-specific aspects or production-specific constraints. - **Implementer\'s View** (Technology Physics) - This **[is a representation of how the system will be implemented]**. It makes specific solutions and technologies and addresses production constraints. - **Sub-Constructor\'s View** (Component Assembles) - These representations **[illustrate the implementation-specific details of certain system elements]** - **User\'s View** (Operations Classes) - This is a view of the functioning system in its operational environment. **Rules of Zachman Framework** The framework offers a set of descriptive representations or models relevant for describing an enterprise. - Each cell in the Zachman Framework must be aligned with the cells immediately above and below it. - All the cells in each row also must be aligned with each other. - Each cell is unique. - Combining the cells in one row forms a complete description of the enterprise from that view. ### ### What is the Strength of Zachman Framework? One of the strengths of the Zachman **[Framework is that it explicitly shows a comprehensive set of [views](https://en.wikipedia.org/wiki/View_model) that can be addressed by enterprise architecture]**.  **University of Science and Technology** **Faculty of Computer Science and Information Technology** Department of Information Systems **Semester 8: Enterprise Architecture** **Lecture (3): How to Use Zachman Framework** In the Zachman framework, the content of enterprise architecture is **abstracted into the description of six different aspects of IT**. When all six perspectives are completed, so believed Zachman, **enterprise architecture would be fully described.** In addition to the six aspects of IT, the framework has six additional questions to answer. **[The result is a 6×6 matrix with 36 cells. Each cell stands for an individual perspective or viewpoint]**:  **[The aspects of IT Systems are the following]**: Executive perspective, business management perspective, architect perspective, engineer perspective, technician perspective, and enterprise perspective. [The six questions are: What? How? Where? Who? When? Why?] **Zachman Framework Example** Imagine that you are a **[business partner of an international manufacturer of coffee cups. Part of your]** business model is not only the production, but also involves the required ecosystem, including suppliers, logistic networks, and marketing partnerships. Your company has decided to enter a new market in another country. Your CEO (Chief Executive Manager) has asked your CIO (Chief Information Officer), who has asked you to provide a comprehensive positioning document for the Enterprise Architecture from your perspective. **What would you do and how could the Zachman framework help you with that**? First of all, you would understand that your expertise as a business partner is required, as much as **your skills to prepare the documentation for [the executive level] in a way that they easily understand** it. As you know that the audience (Actor) is the important factor in choosing the right row in the Zachman framework, you decide to look at the roles/audiences / EA perspectives of an executive (**first row**). Second, you would **decide which questions are relevant for you to be answered**. As the decision to enter the new market has already been taken, you assume that **you do not need to answer "Why" you want** to enter the new market. You would also **assume that "Where" is irrelevant, as everyone knows which market is in focus**. However, after thinking about it, you would decide that all the other questions are quite relevant. Therefore, you would start to prepare material around the following questions: 1. **What needs to be done** so that we can **enter the new market**? What would be the big, major steps? 2. **How would we do that**? Will we use **central or de-central IT systems**? 3. **Who would do that**? Would we find local outsourcing partners or bring in our experts? 4. **When could we do that**? What timeline do requirements and lead times of our IT landscape suggest? For all those questions, you would make sure that the answers can be easily understood by your target audience, the executive level. **Example:** **An enterprise want to use a CRM System, how can we use Zachman Framework in the development and deployment of this system?** **[Answer:]** **The W5H (Purposes / Classification) for the CRM system can be:** **What do we do**? We provide a CRM system. **How do we do it?** New leads are registered as soon as they register through a campaign and are followed up. **Where do we do it?** We use the system in all our subsidiaries w Who does it? Our marketing experts from the Marketing Department. **When do we do it?** Whenever a potential lead registers through one of our active campaigns. **Why do we do it?** We want to maximize the sales potential of leads and customers that are somehow interested in our products and services. **The roles (Audiences) can be:** The **executive** wants to identify what the CRM system is about. **Business** management wants to define how businesses can use the CRM system and benefit from it. The **architect** wants to describe the structure and the blueprint of the system and understand how it fits into the overall IT landscape. The **engineer** wants to determine the specifications that are needed to run the CRM system. The **technician** manages the configurations and ensures that they represent the specifications of the engineer. The **enterprise perspective** ensures that the CRM system **fits into the overall organization´s IT landscape**, that releases are managed, and that the instances work. Of course, the **classification and the audience can be combined in such a way that a total of 36 different viewpoints are created**. **For instance**, the purpose, **[the "why" for a CRM system would be different for an executive (maximize revenue per lead / customer) than for an enterprise architect (]**ensure that the CRM system fits into the overall landscape as it is a large system that is critical to our business continuity). However, the **[creation of 36 different viewpoints for every architecture work is certainly not necessary]**. Zachman rather promotes that one considers the different views and **[possibilities that there are]**. In the end, the consideration of the classification or the audience would often be sufficient -- without [defining the viewpoints that result when you combine the two in a matrix.] **University of Science and Technology** **Faculty of Computer Science and Information Technology** Department of Information Systems **Semester 8: Enterprise Architecture** **Lecture (4): How to Develop Enterprise Architecture** **Instructor: Prof. Noureldien A. Noureldien** **[Companies have long recognized the need for an approach to development an] EA.** Nevertheless, they still experience a lack of support in the design, communication, realization, and management of architectures. **[The following requirements are needed in different phases of any EA develoment life cycle]:** 1\. **Design**: When designing architectures, architects should: 1- **[Use a common, well-defined vocabulary to avoid misunderstandings] and create clear designs.** Such a vocabulary must not just focus on a single architecture domain (the business type), but should allow for the integration of different types domains. 2- **[Provide methodical support, general and specific guidelines]**, best practices, drawing standards, and other means that increase the quality of the architectures. 2\. **Communication**: Architectures are shared with various stakeholders within and outside the organization, e.g., management, system designers, or outsourcing partners. To facilitate the communication about architectures, it should [be possible discuss the relevant aspects for a particular group of stakeholders]. 3\. **Realization**: To facilitate the realization or deployment of architectures and to provide feedback from this realization, it should be possible to understand the architecture design activities such as; business process design, information modeling, or software development. 4\. **Change**: Architecture often covers a large part of an organization and may be related to several other architectures. [Therefore, changes to architecture may have a profound impact. Assessing the consequences of such changes beforehand and carefully planning the evolution] of **[architectures are therefore very important]**. **How to Deal with the Complexity of Architecture?** **[The standard approach to deal with the complexity of systems is to use a compositional approach, which differentiates between parts of a system, and the relations between these parts].** To understand how a car functions we first describe the parts of the car such as the engine, the wheels, the air conditioning system, and then we describe the relationship among these parts. **[Likewise we understand the information system of a company as a set of systems and their relations, and we understand a company as a set of business processes and their relations.]** [The decomposing approach will result in many sub-architectures that may need to be integrated]. In general, some **[integration problems can be easily solved]**: for example, by using an existing standard; others are **[built-in to the architectural approach and cannot be 'solved' in the usual sense]**. For example, the integration of the architectures in Fig. 3.1 is problematic because these five architectures are developed by distinct stakeholders with their own concerns. **[Relating architectures (i.e. find relationship) means relating the ideas of these stakeholders, which is something difficult]**. In *complex integration* cases that involve multiple stakeholders, it is clear that **[integration is a bottom-up process]**, in the sense that at [first the concepts and languages of individual architectural domains are defined, and then the] integration of the domains is addressed. **[To deal with the complexity of enterprise architecture, the representation of the architecture in the form of a model can be of great value]**. [A model is an abstract and explicit conception of something (in the real world) that focuses on specific aspects, based on the purpose for which the model is created]. **What are Views?** Different stakeholders have a different view of the world. Stakeholders therefore **[require specific *views* of an architecture that focus on their concerns]**. Since we can describe architectures as models, this implies that **[we have to provide different views of these models to accommodate the stakeholders' needs]**. **University of Science and Technology** **Faculty of Computer Science and Information Technology** Department of Information Systems **Semester 8: Enterprise Architecture** **Lecture (5): Values and Risks of Enterprise Architecture and Maryland State Enterprise Architecture (MSEA) Approach** **\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_** Instructor: Prof. Noureldien A. Noureldien **5.1 The Value & Risk of Doing Enterprise Architecture** Developing an EA has value to enterprises and at the same time it has risks. The following are some specific areas of value and risk when doing EA: **5.1.1 Values** **1- Goal Alignment.** Strategic goals are the priority objectives that enable an Enterprise to accomplish its mission. Goals do not accomplish themselves, so initiatives (activities) are required in the form of ongoing programs and specific projects. EA promotes the use of Key Performance Indicator (KPI) metrics for cost, schedule, and performance to track an initiative's status. **2- Resource Efficiency.** EA helps to ensure that an Enterprise\'s resources are best positioned to support the achievement of strategic goals. These resources include people, skills, funding, workflows, data, systems, networks, and facilities. **3- Cost Reduction.** EA can provide analyses to guide system and service outsourcing/insourcing decisions, as well as enterprise-level software licensing that often provides a lower per-seat and per-instance cost **4- Decrease Overlaps and Increase Coordination.** EA promotes enterprise standards, methods, and solutions. This decreases gaps and overlaps in capabilities and increases the amount of coordination within and between enterprise operating units. **5.1.2 Risks** **1- Loss of Local Control**. EA brings organization wide standards and methods to an enterprise. Accordingly, program managers and staff are likely to resist the loss of control over standards and methods. **2- Exposure of Inefficiencies.** EA promotes inventories of business and technology processes, resources, and capabilities. This includes programs, systems, personnel, and spending. Analysis of inventories often reveals gaps and overlaps in resources and capabilities, such as multiple instances of records management systems, procurement and contracting groups, data warehouses, and office automation software. The identification (exposure) of these gaps and overlaps -- and the prospect that the agency will act on these inefficiencies -- is often not welcome by affected program offices who can expect that changes will occur in responsibilities and resources. **3- Cultural Change** EA promotes a culture of cooperative achievement that is focused on attaining the enterprise's most important goals through a combination of enterprise- and program-level solutions and resources. The change from a group-centered culture to an enterprise-centered culture may be resisted by groups and individuals who feel that they are being marginalized and/or long-held beliefs and hard-won authorities are being done away with. **4- Resource Constraints.** Enterprises have limited resources (financial, people, skills, equipment, time, facilities, etc.). An EA program will need to compete for these resources and to do this successfully, EA must show that the value being produced exceeds the direct, indirect, and opportunity costs. EA should be able to do this as capability gaps/overlaps are closed. The both cases (values and risks), the best way to ensure that the enterprise EA program will be successful is to have an engaged **[Senior Executive]** who is the policy and results champion. The senior executive has to hire an experienced **[Chief Enterprise Architect]** to lead the EA program, and to involve stakeholders from the outset, and promote frequent communication between all of them regarding the EA approach, and specify the role of each stakeholder. **5.2 Maryland State Enterprise Architecture (MSEA) Approach** Many approaches to develop and maintain an EA are exits**. [We will study one of these approaches known as the Maryland State Enterprise Architecture (MSEA).]** This approach has six core elements: governance, framework, methodology, artifacts, an online repository, and associated best practices. The following are summary descriptions of each element, followed by more detailed information. **5.2.1 Governance.** The term "governance" refers to a process that provides oversight and decision-making capabilities over some area of enterprise activity. The EA Program Office can be located in the Strategy and Policy Services department, with oversight being provided by the Office of the Secretary and the Executive Steering Committee. **5.2.2 Framework.** The EA framework is a model that graphically shows the parts (sub-architecture domains) of the holistic architecture. By defining what parts of the enterprise are included in the EA, the framework defines the scope of the architecture. +-----------------------------------------------------------------------+ | **[The diagram of the framework] shown below have 8 | | domains:** | | | | - Strategy (legal mandates and Policy objectives), | | | | - Business (Mission Goal and Workflow), | | | | - Data (Data flows and Repositories), | | | | - Systems (Systems and Applications), and | | | | - Infrastructure (Network and Infrastructure) | | | | | | | | - Security, | | | | - Skills, and | | | | - Standards. | +-----------------------------------------------------------------------+ The frame work have many of stakeholders (Governor\'s Office, Executive Departments,........, Industry providers) that have touch points to each hierarchical domain.  **5.2.3 Methodology.** The EA methodology (method) is a 4-phase, 20-step process to establish the EA Program, development of current/future views in each domain, a transition plan, and utilization activities with EA projects and enterprise governance bodies. The methodology contains the following four phases. Phase 1: Establish the EA Program Phase 2: Documentation Preparation Phase 3: Establish Current/Future Views Phase 4: Maintain and Use EA Product **5.2.4 Artifacts.** Artifacts are various types of documentation that support EA analysis and design activities. Each area of the framework has recommended artifacts that are widely accepted, use standard notation sets and methods, and can be developed/updated by readily available modelers who are trained in that artifact. **Artifact ID Codes** - Strategic Domain (S) - Nets/Infra Domain (NI) - Business Domain (B) - Security/Privacy Thread (SP) - Data Domain (D) - Standards Thread (ST) - System /App Domain (SA) - Workforce Skills Thread (W) **5.2.5 Online Repository.** An online EA repository is an artifact storage and retrieval site located on the enterprise's internal network. To ease navigation, the repository uses a web browser interface and presentation matrix that is consistent with the parts of the framework and allows users to select the area they are interested in. Artifacts that have a logical relationship are linked and can be accessed together. **5.2.6. Associated Best Practices.** A best practice is an established method in the public and/or private sector which helps organizations improves their performance. EA does not compete with best practices, instead, EA provides context and standards for locating where and when a best practice is to be used within and between enterprise operating units. **3.3 Enterprise Architecture Context** Enterprise Architecture not only incorporates established best practices, but it also provides the context and relationships for the sub-architecture domains as is illustrated below. **University of Science and Technology** **Faculty of Computer Science and Information Technology** Department of Information Systems **Semester 8: Enterprise Architecture** **Lecture (6): EA Implementation** **\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_** Instructor: Prof. Noureldien A. Noureldien **6.1 Implementation Phases** Implementing an Enterprise Architecture centers on two things: \(1) Establishing an ongoing capability; and \(2) Creating/maintaining a coordinated set of domain views using various artifact types. **[The ongoing capability]** is best done through a dedicated EA Program Management Office (EA-PMO) and **[the artifacts]** should be made available through an internal online repository. The following is a summary of the EA implementation phases and steps. **Phase 1: Establish the EA Program** Step 1: Establish the EA Management Program and identify a Chief Architect. Step 2: Establish an EA implementation methodology. Step 3: Establish EA governance and links to other management processes. Step 4: Develop an EA Communication Plan to gain stakeholder participation. **Phase 2: Prepare to Document** Step 5: Select an EA documentation framework. Step 6: Identify EA Lines of Business/Crosscuts and the order of their documentation. Step 7: Identify the EA components to be documented framework wide. Step 8: Select documentation methods appropriate for the framework. Step 9: Select software applications/tools to support automated EA documentation. Step 10: Select and establish an on-line EA repository for documentation and analysis. **Phase 3: Establish Current and Future Views** Step 11: Evaluate existing business and technology documentation for use in the EA. Step 12: Document current views of existing EA components in all framework areas. Step 13: Develop several future business/technology operating scenarios. Step 14: Identify future planning assumptions for each future scenario. Step 15: Use the scenarios and inputs to drive documentation of future EA components. Step 16: Develop an EA Management Plan to sequence planned changes in the EA. **Phase 4: Maintain and Use EA Products** Step 17: Use EA information to support planning and decision-making. Step 18: Regularly update current and future views of EA components. Step 19: Maintain an EA Repository for modeling and analysis products. Step 20: Release annual updates to the EA Management Plan. These are generalized phases and steps, therefore it's expected that enterprises will adjust implementation activities to address situations that are particular to that enterprise. This could include more definition on roles, responsibilities, domain ownership; additional change management actions, specifics on vendor alignment, coordination with external enterprise partners, or enterprise history/cultural considerations. **6.2 Program Management Office** The purpose of the EA Program Management Office (EA-PMO) is to provide a focal point for establishing and maintaining an agency-wide EA capability and documentation set. The EA-PMO should be led by an experienced Chief Enterprise Architect who reports to the primary executive sponsor of the EA program. Enterprises should consider making the EA-PMO to be able to do the following: \- Coordination and advisement, \- Maintain the enterprise architecture baseline, and the online EA repository, \- Support the Configuration Control Board which is responsible for configuration of systems and technology throughout the enterprise. As with any ongoing enterprise program, the EA-PMO will require the resources, strong executive support, and the understanding and cooperation of stakeholders during the program process. The following is a graphic depiction of the functions of the EA-PMO:  **6.3 Reference Baseline** One of the agency EA program primary roles should be to develop and maintain an authoritative and accurate inventory and configuration model of current business and technology processes and systems, as well as to collaboratively identify legal requirements and industry standards that must be followed. Collectively, these inventories, models, and lists form a "**[Reference Baseline]**" that should be used by planning and decision-making functions throughout the enterprise. This EA Reference Baseline should be viewed as a dynamic artifact that is maintained by the EA-PMO with stakeholder input as part of a regularized schedule of major EA updates (bi-annual or a major change). **6.4. Analysis Projects** The two EA activities are analysis and design. **[The analysis projects]** usually focus on the development of new **[categorization methods]**, **[conducting inventories]** using existing methods, or **[assessing data, information]**, to identify patterns, confirm status, or validate options. Categorization methods include the use of taxonomy artifacts, **[also called "Reference Models]**". These Reference Models can be changed as part of the normal EA artifact update process and input from stakeholders in various agencies is encouraged. The enterprise EA-PMO should be trained in EA analysis project methods. **6.5 Design Projects** The other general category of EA activities **is design projects**, which usually focus on gathering stakeholder requirements for a new capability and identifying viable business and technology solutions. Design activities can include modeling workflows, data flows, applications, systems, networks, and facilities. The **[EA Reference Baseline provides]** context and standards that solutions need to consider. **6.6 Solution Architecture** The term "Solution Architecture" is normally used to refer to ***EA design projects that are focused on solving a business problem with IT enablement*** (also called "digitization"). The use of agile methods and maintaining a focus on enterprise/user requirements will hopefully produce more useful solution in a shorter time span, perhaps even with lower costs. **6.7 Best Practice Incorporation** One of the unique aspects of modern EA methods is that established best practices from government and industry are not only recognized but are recommended for use in the appropriate domain area(s). The following are examples of best practices that enterprises commonly use: Strategic Planning, Balanced Scorecard, SWOT Analysis Business Process Re-engineering, Capital Planning/Business Cases Robotic Process Automation, Workflow Modeling, Agile Projects Object-Oriented Data and Systems Design, Reusable Object Library Process Quality Control, Continuous 3rd Party Auditing **University of Science and Technology** **Faculty of Computer Science and Information Technology** Department of Information Systems **Semester 8: Enterprise Architecture** **Lecture (7): EA Utilization** **\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_** Instructor: Prof. Noureldien A. Noureldien **7.1 Organizational Transformation** [Organizational transformation means that the organization introduced and applies a significantly different and new concepts and methods to achieve the organization mission goals]. Enterprise transformation requires an enterprise-level view of mission activities, programs, and supporting resources. Enterprise Architecture, when practiced holistically can provide the context for moving operating units forward in a coordinated manner while incorporating new methods and technologies. Normally, transformation is applied in selected business units and may not affect the entire enterprise, but the enterprise should still utilize its EA baseline as the authoritative reference for making changes. **7.2 Strategic Planning** [Enterprise strategic planning activities include the update of goals, resource allocations, master IT plans, ongoing program plans, and time-specific project plans]. The alignment (arrangement) of these plans to achieve the enterprise and administration goals is one of the most important aspects of strategic planning. **The figure below shows how enterprise strategic goals are achieved through departments goals.** **7.3 Digital Enablement / Transformation** [Digital enablement is a term used for the use of IT to move a paper-based process to an online electronic process, as well as the further improvement of electronic] ([automated) processes]. Many of the mission and support activities in any enterprise may already have some level of digital enablement, which usually results in more flexibility, lower costs, and higher production output. Digital transformation is the IT component of Organizational Transformation (see lecture 6). This is a higher-level transformative activity which looks beyond individual processes to entire enterprise business units with a goal of making significant changes in functions and IT-based methods. The results of digital transformation efforts [can include the incorporation of new lines of business, new technologies, new strategic partners, new customer groups, and new mission areas]. Enterprises that are experienced in digital enablement and transformation initiatives are able to make these changes more rapidly and with better results. **[Enterprises should be mindful of new costs associated with needed IT resources and services that underpin (support) the digital enablement or transformation]** effort. **7.4 Enterprise Resource Planning** As enterprises use EA to view the organization holistically, the requirement for enterprise-wide IT solutions is likely to grow. **[These solutions are often referred to as Enterprise Resource Planning (ERP) systems and they include both mission and support solutions for case management, supply chain management, finance and accounting, human resources, and general administration]**. ERP solutions usually address a broad range of related activities and therefore must meet dozens of enterprise requirements that arise from legal and policy mandates, customer needs, and industry best practices. **Enterprises can achieve higher levels of productivity at lower levels of cost per transaction if they use mature large-scale ERP systems from experienced vendors.** It is rare that public sector organizations are able to create and maintain ERP systems with the reliability, functionality, and cost efficiency of mature commercial products that have been produced by vendors who specialize in common ERP areas. **[Accordingly, enterprises should use EA as a way to maintain control of their IT baseline as ERP products with large footprints come and go, which they will do.]** A good planning and contracting target for an ERP product or service lifespan is 5-7 years. **7.5 Portfolio Management** Enterprises deliver services through programs that depend on a number of resources such as trained personnel, IT systems, funding, and facilities**[. When similar types of resources are managed as a group it is called Portfolio Management. ]** In particular, IT systems are most effectively managed when hardware and software products are selected and implemented with overall enterprise needs in mind so there can be shared utilization among programs. Examples include records management, data storage and analysis, web content management, project management, and online collaboration. EA promotes this type of enterprise-level planning, management, and utilization. **7.6 Systems Integration** **[An important aspect of managing the enterprise IT systems portfolio is to promote hardware, software, and data interoperability]**. This is accomplished by selecting products that utilize open standards for equipment connectivity, application interfaces, and data formats. Acceptable open standards are those which are non-proprietary, mature, endorsed by government and industry groups, and related skills are widely available. **[If products do not use open standards, middleware may be available that allow IT systems to connect, share workflows, and exchange data.]** **7.7 Data Sharing** Most enterprises are "data centric" in that data and information are a core element of the products and services they provide to customers. These data and information products need to be available, accurate, properly protected, and useable. **[Accordingly, it is important for Enterprise to develop and maintain an effective Enterprise Data Management (EDM) program that uses open standards, a comprehensive set of security and privacy controls]**, and takes a total lifecycle approach to managing data entities and information collections at various levels of scale and complexity. The goal of the EDM program is to maximize the usefulness of data/information assets and balancing sharing vs safeguarding. **7.8 Vendor Alignment** **[Each Enterprise is responsible for the operation and protection of the IT systems and data assets that they own and operate]**. The exception to this are the systems and services that the Enterprise contracts to use from external public and private sector providers. Given that it is normal for external providers to want to maximize their market share and revenue, it is important for Enterprises to utilize EA and an enterprise IT baseline/reference architecture to ensure that contractor products and services are selected and consumed in as an integrated part of the baseline and in conformance with law, policy, and standards. **[This means that the Enterprise's architecture provides the context and standards for selecting and using vendor products and services]**. Proprietary products and service methods may occasionally be contracted for if there is a compelling mission need, but absent that, Enterprises must follow standards and vendors must align with these standards and ensure fit with the Enterprise EA. **7.9 Security & Privacy** **[The Enterprise\'s Risk Management and EA programs should provide the context and standards for the cybersecurity and data privacy program methods]**. **[Effective cybersecurity and data privacy capabilities center on the implementation and use of a comprehensive set of security controls that achieve the right level of protection and a balance between the sharing and safeguarding of data/information]**. **University of Science and Technology** **Faculty of Computer Science and Information Technology** Department of Information Systems **Semester 8: Enterprise Architecture** **Lecture (8): Details of EA Implementation Methodology (1)** **\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_** Instructor: Prof. Noureldien A. Noureldien **8.1 Introduction** **[An EA implementation methodology is a detailed, step-by-step description of how the EA program is to be established and run, and how the documentation of the EA is to be developed, maintained, and used.]** In this lecture and lecture (9) we will give an example of a generalized example of details of implementation of EA methodology. This example can be customized by the enterprise. **[There are four phases and twenty steps in this example and it is worth noting that the first two phases are]** designed to create a new EA Program Management Office (EA-PMO) or strengthen an existing EA-PMO.  **8.2 What to be considered** It is important to develop an EA methodology as one of the first steps in establishing or strengthening an Enterprise's EA program, because it forces the organization to 'think through' the following considerations: Which areas of the enterprise the EA will cover (scope) The approach to EA governance (e.g., centralized or decentralized) The types of EA documentation (known as artifacts) that will be needed to support business and technology resource planning and decision-making The EA documentation framework that best supports the needs of the enterprise The methods and techniques for gathering or developing EA documentation The software modeling tools, web applications, and databases that will be needed to automate documentation techniques How EA users will access and share EA documentation (e.g. an online EA repository) How often EA documentation will be updated **8.3 Phases of the Example Implementation Methodology** The phases and steps of this example implementation methodology are as follows: **Phase I: Program Establishment** **[Phase I activities are designed to get the EA program initially started, identify key players, and communicate the EA Implementation Plan to the executive sponsor and other stakeholders in order to gain buy-in and support]**. **These pre-documentation activities are important** to ensuring that the EA program has clear goals, remains focused, and is accepted throughout the enterprise. **Step 1: Executive Ownership.** The critical first step is for the enterprise's most senior leadership to formally designate the executive who will be responsible for and champion the EA Program. The designation document should signal the importance of the program and require support and alignment from all business units. **Step 2: Establish Governance.** The second step is for the **[executive sponsor and Chief Architect to co-develop an approach to architecture oversight (governance) that enables effective policy, planning, and decision-making within the program.]** This approach to governance should include links to other key oversight processes (e.g., strategic planning, capital planning, project management, security, and workforce planning). **Step 3: Launch the EA Program.** The third step is for the executive sponsor to establish an EA program and hire **[a qualified Chief Enterprise Architect to lead the EA Program]**. The EA Program's establishment activity begins as a startup project that becomes an ongoing program when the team is hired and a schedule of forthcoming projects is established. **[The executive sponsor must provide the Chief Architect with enough resources (e.g., budget, personnel, hardware/software, and facilities) and have the authority to establish the EA program]**. The Chief Architect should be accountable for EA program resources and results. Another of the Chief Architect's first actions should be to determine with the executive sponsor what the operating model for the EA Program Office will be. **[The options are]**: \(1) For the office to only do audits and promulgate standards; \(2) Do limited design and analysis work in support of business unit projects; \(3) Conduct architecture projects themselves; or \(4) A mix of these options -- sometimes advising, sometimes doing it all themselves. **Step 4: Create the EA Team.** **In step four, the Chief Architect hires, or contracts for EA team members in key skill areas** (e.g., business process analysis, systems design, data architecture, web applications, network engineering, security controls). How many there are depends on the operating model. Some team members are enterprise employees, while others may come from outside the enterprise (e.g., consultancies) or be independent contractors. **Step 5: Architecture Program Implementation Plan.** The Architecture Program Implementation Plan (Plan) **[specifies the EA development method and a schedule for establishment and projects.]** The Plan should be written in plain language to be understood by all stakeholders. **[The Plan should include statements about the purpose and vision of the EA, examples of how the EA will bring value to the enterprise,]** where EA documentation will be available for access, a summary of the methodology used, and the general principles that will be used for EA development. **Phase II. Preparation to Conduct Projects** **[Phase II activities solidify the EA team's readiness to start providing architecture services (audits, standards, analysis, and design]**). This begins with team and stakeholder training, then moves to confirming the artifact documentation methods and tools appropriate for the framework and finishes with the establishment of an on-line repository for documentation and an update of the Architecture Implementation Plan to set the order of analysis and design projects throughout the agency. **Step 6: Conduct Training.** This step focuses on training to get the EA Program Office ready to offer services and inform customers and other enterprise stakeholders. **The training covers EA Program objectives, schedule, and approach, including the areas of the agency that the EA will focus on first.** For example, the training should summarize the scope and relationships of the framework areas by identifying the five sub-architecture domains and three 'thread' areas, what the lines of business are and how they relate to the business and technology components (e.g., data, systems, processes, equipment, facilities). **Step 7: Select Documentation Methods.** The next step is for the enterprise to select the methods that will be used to gather and develop EA documentation artifacts. **[For example, the following are methods for modeling in the eight sub-architecture domain areas of the framework (five levels and three threads). The following are examples of EA artifacts that are used in each area:]** +-----------------------------------+-----------------------------------+ | Strategic level: Business level: | Strategic Plan, Scenarios, | | Data Level: Systems Level: | Balanced Diagrams, | | Network Level: Vertical thread | | | | Flowcharts, Swim Lane Chart | | | | | | Data Models, Object Diagrams, | | | Data dictionary | | | | | | System Diagrams, Web Service | | | Models, APIs | | | | | | Voice/Data/Video Network | | | Diagrams/Documents | | | | | | Security Diagrams, Standards, | | | Workforce Skills | +-----------------------------------+-----------------------------------+ It is important to choose documentation techniques that will provide the information that is needed for resource planning and decision-making. Therefore, the enterprise's Chief Architect should consult with EA stakeholders and the EA team in selecting the methods for artifact development and what type of information will need to be gathered to be able to create artifacts. **Step 8: Tool Selection.** Select the software applications (tools) that enable EA analysis and design. Once the lines of business and components are known, EA documentation and artifact modeling requirements can be established. **For example, if object-oriented methods are being used to develop artifacts at the data level of the framework, then a modeling tool that uses the Unified Modeling Language (UML) is needed**. [Tools will also be needed to model processes, databases and flows, networks, and facilities. Office automation tools are also needed, including graphics, spreadsheets, and word processing]. Consideration should be given to obtaining a robust architecture documentation suite of tools to enable the automated "rippling" of changes among linked models and databases. **Step 9: Establish the Architecture Repository/Standards Catalog.** **[The EA Repository is the place on the enterprise's internal network (private cloud) where architecture models, analyses, standards, policies, and project information are stored and made available to those who need them]**. A significant element of the repository is a listing of business and IT policies and standards. Begin by selecting a document management and storage application/database. Then determine what the archiving taxonomy (categories) will be, including file tags and metadata. The agency is then ready to upload content and promote its use to support planning and decision-making. **Step 10: Identify the EA Components to be documented** **Identify the EA components that will have to be documented in each area of the framework (strategy, business, information, services, networks, and vertical threads). Each of these areas represents a distinct set of activities and resources across the enterprise, which is represented by EA components**. **[EA components are plug-and-play goals, processes, measures, projects, data, services, and IT resources in the various functional areas.]** An EA component therefore is unique in the capability and resources that it represents within the EA framework. Each EA component is documented using information gathering methods and modeling techniques that are appropriate for the type of things that are contained in the EA component. For example, at the strategic level the enterprise\'s strategic goals, activities, and outcome measures are the primary items to be documented. **At the business level, the line-of business services and associated measures are documented. At the information level, the flows of information, databases, knowledge warehouses, and data standards are documented.** At the services and applications level, the various web services, office automation services, and software applications are documented. At the technology infrastructure level the voice, data, and video networks, as well as associated cable plants and equipment facilities are documented. For the vertical threads, IT security information, IT standards, and IT workforce information are gathered for associated activities and resources in each of the five other functional areas. **University of Science and Technology** **Faculty of Computer Science and Information Technology** Department of Information Systems **Semester 8: Enterprise Architecture** **Lecture (9): Details of EA Implementation Methodology (2)** **\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_** Instructor: Prof. Noureldien A. Noureldien **Phase III. Documentation of the Agency Enterprise Architecture** Phase III activities are where the actual development of the EA occurs in the form of documentation artifacts. This involves analyzing and documenting the current strategy, business, information, services, and infrastructure of the enterprise. It also involves the development of artifacts that reflect changes in resources in the short-term and the development of a group of long-term future scenarios to identify possible courses of action and resource changes that would be needed in response to different internal and external influences. The activities in this phase of the EA documentation methodology conclude with the development of an Architecture Transition Plan that summarizes the current and future views of the architecture and provides a transition and sequencing plan for short- and long-term changes. **Step 11: Harvest and Assess Existing Documentation.** The first step of Phase III is the beginning of actual EA documentation activities. Preceding activities established what would be documented, how it would be documented, and who would do the documentation. **[The current view of EA components is what is now being documented through the identification of what the EA components are at each level of the framework and then using existing and new artifacts to document the EA components that currently exist.]** In many ways this activity is like taking an "inventory" of the components (strategic goals, business services, measures, data, services, and IT resources) that already exist in the enterprise and mapping them to existing documentation. **Step 12: Document Current views of Existing EA Components.** **[The second step of Phase III is the development of new artifacts to complete the documentation of all existing components. The documentation methods and tools identified in Step 8 are used to gather and]** standardize existing artifacts, as well as to develop new artifacts. These documentation artifacts are organized by levels of the framework and stored in the EA repository that was established in Step 10. **Step 13: Develop Future Business and Technology Operating Scenarios.** Prior to developing future views of EA components, it is helpful to gain a high-level understanding of the possible future directions that the enterprise could take, depending on how it responds to internal and external influences. **[Three or more future scenarios should optimally be developed with EA and line of business (program) stakeholders to reflect what may occur if (1) the status current state is not changed; (2) a better business and technology operating environment is encountered; and (3) a high threat situation is occur]**. There are several beneficial outcomes from the development of the scenarios. First, the enterprise is more prepared and organized to handle future situations and plan needed resources. Second, a number of planning assumptions are identified in each scenario that reveal what the priorities of the enterprise might be if that scenario is pursued. Third, the planning for future capabilities is more coordinated. **Step 14: Identify future planning assumptions for scenarios.** Each future scenario describes, in story form, a possible business/technology operating environment that the enterprise might follow or face. In this step, the key elements of each future scenario are analyzed to reveal what things are important to the enterprise and what changes have to occur for the scenario to become reality. For the purposes of the EA, these key elements become the planning assumptions that can then be grouped together to represent changes in each of the functional areas of the framework. **[One of the benefits of having the scenario and planning assumptions is that they were developed with stakeholder buy-in, which will help when future changes are implemented.]** **Step 15: Use Scenarios to Drive the Design of Future Components.** **[This step involves the documentation of changes to EA components in the near term (1-2 years) and the longer term (3-5 years).]** These changes should be derived from the input by the leadership team via the operating scenarios' planning assumptions, and from program and project managers who know what the future business requirements are, as well as planned system implementations, upgrades, and retirements. In this way, changes are more coordinated and aligned with the strategic direction of the enterprise. **Future views of EA components should be developed using the same techniques that were used to develop the current views**. **[This helps to identify what the changes are in each of the functional levels (domains) of the framework, which helps in planning and decision-making.]** **Phase IV: Use and Maintain the EA** **[This phase focuses on the implementation and use of the architecture as a whole by all stakeholders and establishes an annual cycle for updates.]** **[This is where the value of the enterprise EA Program is realized as planning and decision-making throughout the organization are supported.]** **[This value is maintained through the development and maintenance of an Architecture Transition Roadmap, the regular updates of the current and future views of the architecture.]** Value is also gained in the maintenance of the EA repository and the maintenance of all associated software licenses for modeling and archiving. **Step 16: Develop the Architecture Transition Roadmap.** **[The first step in this final phase is the development of the Architecture Transition Roadmap. The Roadmap serves to articulate how the EA was developed and provides a synopsis of the current and future views.]** The Roadmap also provides a transition and sequencing sub-plan for the near-term changes, which may already be in the project pre-implementation stage. Also, a long-range sequencing sub-plan is provided that covers the potential changes associated with the future scenarios. **Step 17: Use the EA to Support Planning and Decision-Making.** **[During Phase III activities, current and future views of the architecture were stored in the EA repository and are ready to be used by the enterprise to support planning and decision-making.]** These stored artifacts become a baseline of reference information that can be used in a wide variety of leadership and staff activities. **[When this is done, a greater level of understanding is developed of capabilities and performance gaps among a wider group within the enterprise.]** Further, by having the EA documentation in an on-line repository, this information can be called up and referred to in meetings, which reduces the time it takes to convey an idea, increases comprehension, and reduces interpretation errors among meeting participants. This, along with information on the associated business services, support applications, and networks can be referenced meaningfully. **[The time to convey the ideas is significantly reduced when diagrams and text are being shown to everyone at the meeting. This can stimulate more productive discussions and informed decisions.]** **Step 18: Update Current and Future Views of EA Components.** The information in the EA repository is valuable for planning and decision-making only as long as it is comprehensive and accurate. **Therefore, it is important to regularly update the current and future views of EA components in all areas of the framework**. Further, it is helpful to users of EA information if the updates are made on a regular schedule: once or twice a year. **[Also, it is important to maintain version control in between updates, so that all of the users of the EA information know that they are conducting planning and decision-making activities based on the Same information.]** Since what is planned in the future EA views will eventually become the current architecture (at least some of it), it should be recognized that EA updates are ongoing activities that do not cease. Future EA plans will continue as an organization grows and changes. Consider a time when the agency no longer needs changes in future capabilities and resources. If so, the EA program transitions from focusing on the establishment of the EA to maintaining the EA and seeing that it continually brings value to the enterprise. **Step 19: Maintain the EA Repository and Modeling Capabilities.** **[The Chief Architect and EA team need to ensure that the EA repository and support applications/tools are kept current in terms of licensing and functionality. The requirements for archiving and modeling should be reviewed annually, and new products should be regularly reviewed to ensure that the EA team has the right application support capability]**. The team should be on the lookout for new improvements in tool functionality so that these improvements can be applied to the advantage of the agency. The costs for software purchases and license renewals should be part of the EA program budget. **Step 20: Release Updates to the Transition Roadmap.** [The Chief Architect needs to regularly inform EA stakeholders about the status of the architecture. This is done through the annual release of an updated Architecture Transition Roadmap that discusses changes that were made to the current and future views of the EA during the past year.] The communication should provide a transition and sequencing plan for changes anticipated during the coming year. Also, the ongoing value of the EA needs to be communicated through the citation of examples of where EA documentation supported planning and decision-making, **University of Science and Technology** **Faculty of Computer Science and Information Technology** Department of Information Systems **Semester 8: Enterprise Architecture** **Lecture (10): Design Artifact - Examples (1)** **\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_** Instructor: Prof. Noureldien A. Noureldien An EA artifact is a type of design or analysis documentation. This can include models, spec sheets, spreadsheets, tables, narrative documents, charts, diagrams, pictures, videos, maps, and other depictions of a component in the agency's architecture. The EA approach includes the following group of artifacts for enterprises to use in their EA projects. There is at least one "core" artifact at each sub-architecture domain level and these are indicated with an asterisk in the table below. **[The core artifacts are essential to understanding needs, current capabilities, and future options. The other artifacts from this or other EA approaches may be useful in providing additional understanding of requirements and solutions.]** In the following pages we will **provide examples of what artifacts should contain** for some of the types of the artifacts shown in the above table. **Example (1): S-1: Strategic Plan Artifact**  +-----------------------------------------------------------------------+ | **S-1: Strategic Plan**: A Strategic Plan is a high-level policy and | | planning document that an enterprise uses to document its direction, | | competitive strategy, most important goals, and the enabling programs | | and projects (strategic initiatives). The Strategic Plan covers a | | future period, usually 3-5 years. | +=======================================================================+ | **Description** | +-----------------------------------------------------------------------+ | **[A Strategic Plan is a narrative and graphical artifact that should | | guide the enterprise's direction over a 3-5 year period in the future | | by providing the following items:]** | | | | **Mission Statement** and a Vision Statement that succinctly | | captures the purpose and direction of the enterprise. | | | | **Statement of Strategic Direction** that fits the enterprise's | | purpose, ensures survivability, allows for flexibility, and promotes | | competitive success. This statement is a detailed description of | | where the enterprise intends to go. | | | | **[Summarize the results of a SWOT Analysis]** that is | | based on the statement of strategic direction and which identifies | | the enterprise's strengths, weaknesses, opportunities, and threats. | | The full SWOT analysis is artifact S-2. | | | | **Summarize the situation and planning assumptions for several | | 'Concept of Operations' CONOPS** Scenarios that support the | | enterprise's strategic direction. | | | | This summary should include one current scenario that describes at a | | high-level the coordination of ongoing activities in each line of | | business, as well as several future scenarios that account for | | different combinations of internal and external drivers identified | | through the SWOT Analysis. The complete scenarios are artifact S-3. | | | | **CONOPS Diagram that in a single picture captures the essence of | | and participants in the current operating scenario**. This graphic is | | artifact S-4. | | | | **General Competitive Strategy** for the enterprise that | | incorporates the current and future CONOPS scenarios and moves the | | enterprise in the intended strategic direction in a way that and | | address internal/external drivers such as culture, line of business | | requirements, market conditions, competitor strategies, and risk. | | | | **Strategic Goals that will accomplish** the competitive strategy | | and specify the executive sponsors who are responsible for achieving | | each goal. | | | | **Strategic Initiatives and resource sponsors** for the | | initiatives, which are the ongoing programs or development projects | | that will accomplish each Strategic Goal. | | | | **Outcome Measures for each Strategic Goal** and Initiative, using | | the Balanced Scorecard™ or similar approach. The full scorecard is | | artifact S-5. | +-----------------------------------------------------------------------+ **Example (2) D-1: Enterprise Data Management Plan** D-1: The Enterprise Data Management (EDM) Plan provides a detailed description of how knowledge, information, and data are managed throughout the enterprise. The EDM Plan includes models, descriptions, standards, and reusable solutions for total lifecycle data/information ownership and management. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ +-----------------------------------------------------------------------+ | **Description** | +=======================================================================+ | Table of Contents Example for an Enterprise EDM Plan | | | | \-\-\-\-\-\-\-\-\-\-\-- | | | | Data Governance | | | | - Data Ownership -- | | | | - Roles and Responsibilities | | | | - Types of Enterprise Data | | | | - Types of Enterprise Information | | | | - Types of Enterprise Knowledge Data Formats and Metadata | | | | - Data Access and Sharing | | | | - Data and Information Privacy | | | | - Data and Information Re-use/Re-distribution | | | | - Data Storage and Preservation | | | | - Data Services and Costs Training Resources | | | | - References Terms and Abbreviations | | | | - Data & Information Inventory Data Dictionary | +-----------------------------------------------------------------------+ | | +-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+ | **Example (3) D-2: Information Exchange Matrix** | | | |  | | | | The Information Exchange Matrix describes relevant attributes of data | | exchanges between systems. These attributes include size, logical | | specification of the information i.e., media, timeliness required, | | and the security classification and properties of the information. | | | | Description | | | | +------------------------------------------------------------------+ | | | - Information exchanges express the relationships across four | | | | important aspects of the architecture (information, | | | | activities, locations, and times) with a focus on the | | | | specific aspects of the information flow. | | | | | | | | - Information exchanges identify which business nodes exchange | | | | what information during the performance of what activities | | | | and in response to which events. | | | | | | | | - Additional information on who is performing the activity can | | | | be added, if needed for security analysis[. The detailed | | | | information in the Information Exchange Matrix may be hard | | | | to collect but it is necessary to fully understand the | | | | information flow in the enterprise and its security | | | | aspects.] | | | | | | | | - This Information Exchange Matrix partitions each high-level | | | | need line into its component parts, i.e., into distinct | | | | information exchanges between business nodes. | | | +------------------------------------------------------------------+ | +=======================================================================+ | **Example (4): SA-1: Technology Environment Overview Diagram** | | | | This overview diagram shows the major types of systems and | | application that the enterprise uses as well as activity, type, and | | connectivity relationships. | +-----------------------------------------------------------------------+ ----------------- **Description** -----------------  +-----------------------------------------------------------------------+ | **Example (5) : SA-4: Systems Connectivity Diagram** | | | | The System Connectivity Diagram shows the logical and physical | | interfaces between the enterprise's systems as well as specifications | | on how data is communicated between systems throughout the | | enterprise. This includes specifics about links, paths, networks, and | | a matrix table showing systems that are linked. | +-----------------------------------------------------------------------+ ----------------- **Description** -----------------  +-----------------------------------------------------------------------+ | **Example (6): ENI-1: Network Connectivity Diagram** | | | | The Network Connectivity Diagram shows the physical connections | | between the enterprises's voice, data, video, and mobile networks | | that are owned or subscribed to (government or commercial cloud | | hosting and/or infrastructure services). | +-----------------------------------------------------------------------+ ----------------- **Description** -----------------  **University of Science and Technology** **Faculty of Computer Science and Information Technology** Department of Information Systems **Semester 8: Enterprise Architecture** **Lecture (11): Design Artifact - Examples (2)** Instructor: Prof. Noureldien A. Noureldien +-----------------------------------------------------------------------+ | **Example (7): NI-2: Network Inventory** | | | | The Network Inventory lists all of the hardware and software on the | | enterprise's voice, data, and video networks throughout the | | enterprise. The list may include bar code numbers or other unique | | identifiers. | +-----------------------------------------------------------------------+ ----------------- **Description** -----------------  +-----------------------------------------------------------------------+ | **Example (8): NI-6: Cable Plant Diagram** | | | | The Cable Plant Diagram shows physical connectivity between | | voice/data/video networks throughout the enterprise and to global | | suppliers. The diagram should show the types of cable (fiber, CAT-6, | | etc.) and the bandwidth (T-3, OC-12, etc.) of each cable run between | | network centers, server rooms, wiring closets, user locations, and | | external connections. | | | | ----------------- | | **Description** | | ----------------- | | | |  | | | | +------------------------------------------------------------------+ | | | **Example (9): SP-1: Security & Data Privacy Plan** | | | | | | | | The Security & Data Privacy Plan provides both high-level and | | | | detailed descriptions of the enterprise's integrated physical, | | | | cyber, and data security program. The Plan should include | | | | physical, data, personnel, and operational elements and | | | | procedures, and example of which is provided below. | | | +------------------------------------------------------------------+ | | | | ----------------- | | **Description** | | ----------------- | | | |  | | | | +------------------------------------------------------------------+ | | | **Example (10): SP-2: System Accreditation Documentation** | | | | | | | | The System Accreditation Document uses a standard format for | | | | evaluating the security status of information systems throughout | | | | the enterprise. There are a number of parts to a system security | | | | accreditation as are illustrated in the example below. | | | | Government and industry standards should be considered. | | | | | | | | ----------------- | | | | **Description** | | | | ----------------- | | | | | | | |  | | | | | | | | +-------------------------------------------------------------+ | | | | | **Example (11): ST-1: Technical Standards Profile** | | | | | | | | | | | | The Technology Standards Profile is a listing of enterprise | | | | | | services and associated technologies that are accepted by | | | | | | the enterprise as being a primary or secondary standard. | | | | | | Further detail can be added regarding particular types of | | | | | | standards (e.g. data, telecommunications) and vendor | | | | | | products. | | | | | +-------------------------------------------------------------+ | | | | | | | | Description | | | | | | | |  | | | | | | | | +-------------------------------------------------------------+ | | | | | **Example (12): ST-2: Technology Forecast** | | | | | | | | | | | | The Technology Forecast supports and relates to the ST-1 | | | | | | Technology Standards Profile. The Technology Forecast | | | | | | documents expected changes in any of the standards listed | | | | | | in the ST-1 artifact, where future changes appear to be | | | | | | happening or about to happen. | | | | | | | | | | | | **Description** | | | | | | | | | | | |  | | | | | | | | | | | | +--------------------------------------------------------+ | | | | | | | **Example (13): W-1: Workforce & Skills Plan** | | | | | | | | | | | | | | | | The Workforce Plan provides a high-level description | | | | | | | | of how human capital is managed throughout the agency. | | | | | | | | The Workforce Plan includes strategies for hiring, | | | | | | | | retention, and professional development at the | | | | | | | | executive, management, and staff levels of the agency. | | | | | | | | An example of contents is provided below. | | | | | | | +--------------------------------------------------------+ | | | | | | | | | | | | Description | | | | | | | | | | | |  | | | | | | | | | | | | +--------------------------------------------------------+ | | | | | | | **Example (4): W-2: Organization Chart** | | | | | | | | | | | | | | | | The Organization Chart shows how positions and | | | | | | | | personnel are organized in hierarchical diagrams or | | | | | | | | matrix formats. Organization Charts help to show lines | | | | | | | | of authority, working relationships, as well as | | | | | | | | ownership of resources, services, resources, and | | | | | | | | processes throughout the enterprise. | | | | | | | | | | | | | | | | **Description** | | | | | | | | | | | | | | | |  | | | | | | | +--------------------------------------------------------+ | | | | | +-------------------------------------------------------------+ | | | +------------------------------------------------------------------+ | +-----------------------------------------------------------------------+