Enterprise Study PDF
Document Details
Uploaded by Deleted User
Tags
Summary
This document provides an overview of enterprise study, including Moller's conceptual framework and the TOGAF ADM approach to architecture development. It discusses various architectural styles and characteristics, such as layered architecture, microservices, and pipeline architecture. The text also touches upon distributed computing, big data, and software design principles within enterprise contexts.
Full Transcript
[]{#_Toc184910037.anchor}Enterprise study Contents {#contents.TOCHeading} ======== [Enterprise study 1](#_Toc184910037) [Describe Moller's conceptual framework for enterprise systems. 2](#_Toc184910038) [Foundation Layer 2](#foundation-layer) [**Process Layer** 3](#process-layer) [**Analytical...
[]{#_Toc184910037.anchor}Enterprise study Contents {#contents.TOCHeading} ======== [Enterprise study 1](#_Toc184910037) [Describe Moller's conceptual framework for enterprise systems. 2](#_Toc184910038) [Foundation Layer 2](#foundation-layer) [**Process Layer** 3](#process-layer) [**Analytical Layer** 3](#analytical-layer) [**Portal Layer** 3](#portal-layer) [Pipeline Architectural Style 4](#pipeline-architectural-style) [Describe five fallacies related to distributed computing 4](#describe-five-fallacies-related-to-distributed-computing) [event-driven architecture ( Broker Typology ) 5](#event-driven-architecture-broker-typology) [Define the terms coupling and cohesion in relation to software design and identify the various types of cohesion 5](#define-the-terms-coupling-and-cohesion-in-relation-to-software-design-and-identify-the-various-types-of-cohesion) [Types of Cohesion (from least to most desirable): 6](#types-of-cohesion-from-least-to-most-desirable) [Describe the layered architecture style 7](#describe-the-layered-architecture-style) [Identify and describe five operational architecture characteristics 8](#identify-and-describe-five-operational-architecture-characteristics) [Microservices 8](#microservices) [GPT 9](#gpt) TOGAF proposes a cycle approach to architecture development which includes a number of phases. TOGAF advocates a dynamic view of requirements. Explain how requirements management relates to the ADM cycle ------------------------------------------------------------------------------------------------------------ A diagram of a diagram of a company Description automatically generated The **ADM** in TOGAF is a structured, cyclical approach to enterprise architecture development, comprising various phases that help define, design, and implement the enterprise\'s architecture. Each phase in the ADM builds upon the previous one, ensuring a consistent development process. **ADM Phases**: 1. **Preliminary Phase**: Prepares the organization for architecture development, establishing governance structures, tools, and principles. 2. **Architecture Vision**: Defines the overall goals, scope, and high-level architecture. 3. **Business Architecture**: Focuses on the business structure, processes, and functions. 4. **Information Systems Architecture**: Defines the data and application architectures, bridging the business and technology views. 5. **Technology Architecture**: Establishes the technology infrastructure required to support the application and data layers. 6. **Opportunities and Solutions**: Identifies solutions to gaps, risks, and opportunities found during previous phases. 7. **Migration Planning**: Creates a roadmap for transitioning from the baseline to the target architecture. 8. **Implementation Governance**: Ensures the implementation follows the architectural vision and meets the desired standards. 9. **Architecture Change Management**: Manages the ongoing evolution of the architecture to adapt to changes in the business environment. **Role of Requirements Management**: - **Requirements Management** is a key, continuous process within the ADM cycle, ensuring that business and technical needs are captured and refined as the architecture develops. - Requirements are not static; they evolve during the cycle as new information, constraints, and opportunities emerge. This dynamic nature requires that the **Requirements Management** activity interacts with each phase of the ADM, feeding requirements into each step, revising them as needed, and ensuring that the architecture aligns with business goals and operational needs. - In each phase of the ADM, requirements are reviewed, modified, and tracked to ensure they align with the architecture's goals, such as defining business needs in Phase B, refining data and application requirements in Phase C, and defining technology infrastructure in Phase D. ***Describe the purpose and scope of phases B, C and D in the cycle***. Phases B, C, and D in the ADM cycle focus on elaborating the architecture from a business, information systems, and technology perspective. These phases provide the detailed design needed for the implementation of the enterprise architecture. 1. **Phase B: Business Architecture** **Purpose**: Focuses on aligning the enterprise\'s architecture with its business processes and strategies. It defines the organizational structure, business goals, objectives, roles, and processes. **Scope**: Describes business motivation elements (drivers, goals), business functions, and services, as well as the business entities and processes that shape the business environment. **Activities**: - **Baseline Architecture**: Captures the current state of business processes and structures. - **Target Architecture**: Envisions the desired future state of the business architecture. - **Gap Analysis**: Measures the differences between the baseline and target architectures and identifies areas for improvement. 2. **Phase C: Information Systems Architecture** **Purpose**: Bridges the business and technology perspectives by defining the data and application architectures. **Scope**: Specifies the applications, data structures, and systems needed to support the business processes defined in Phase B. **Activities**: - **Baseline Architecture**: Describes the current state of the information systems, including applications and data. - **Target Architecture**: Defines the desired future state of data management and application systems. - **Gap Analysis**: Identifies the gaps between current and future states, evaluating their impact on business processes and technology. 3. **Phase D: Technology Architecture** **Purpose**: Defines the technology infrastructure and platforms required to support the application and data systems. **Scope**: Specifies the hardware, networks, and platforms that enable the applications and data systems to function. **Activities**: - **Baseline Architecture**: Describes the existing technology infrastructure. - **Target Architecture**: Outlines the desired technology architecture that will support the applications and data defined in Phase C. - **Gap Analysis**: Identifies the technological gaps and how they will be addressed in the transition. **Common Activities**: - **Baseline Architecture**: Defining the current state of the organization's business, information systems, and technology. - **Target Architecture**: Defining the future desired state based on business goals and requirements. - **Gap Analysis**: Identifying the differences between the baseline and target architectures and understanding their impacts. - **Roadmap Creation**: Developing a transition plan for moving from the baseline to the target architecture. ***Explain the role of iteration in the TOGAF cycle***. TOGAF emphasizes iteration as a key feature of the ADM cycle, enabling the architecture to adapt as new information emerges or requirements change. The ADM cycle is not strictly linear, and iterations occur at various levels: 1. Iteration Across Phases: - Complete Cycles: The entire ADM cycle can be repeated to refine and adjust the architecture over time. After completing one cycle, the architecture may need to be revisited to adapt to changing business needs or technological advancements. 2. Iteration Within Phases: - Refinement: Each phase allows for iterative refinement. For example, in Phase B (Business Architecture), the business processes may need to be revisited and refined multiple times as business goals and requirements evolve. - Revisiting Previous Phases: If new constraints or opportunities arise, earlier phases (such as Phase A or B) may need to be revisited to revise the architecture. For example, the Architecture Vision in Phase A might change as new insights are gathered from later phases. 3. Iteration in Transition Planning (Phases E and F): - Ongoing Adjustments: In Phases E (Opportunities and Solutions) and F (Migration Planning), the transition path may evolve based on technical and organizational feasibility, leading to changes in the implementation roadmap. Key Benefits of Iteration: - Flexibility: Allows the architecture to remain aligned with business and technological shifts. - Continuous Improvement: Ensures that the architecture evolves to meet emerging needs and conditions. - Risk Mitigation: By iterating, potential risks or issues can be identified early, leading to timely corrective actions.. []{#_Toc184910038.anchor}Describe Moller's conceptual framework for enterprise systems. ![A diagram of a company\'s erp Description automatically generated](media/image2.png) Moller's framework organizes enterprise systems into distinct layers, each with specific roles and components, working together to achieve a unified system. The framework provides a comprehensive approach for integrating business processes, analytics, and user interaction. Foundation Layer ---------------- **Role**: The foundation of the framework, encompassing the core systems and infrastructure required for enterprise operations. **Components**: ERP I , ERP II = Integrates core business functions such as finance, human resources, and procurement. Extends integration to external entities, including suppliers, partners, and customers. Middleware: Ensures seamless communication between disparate systems. **Interaction**: Acts as the data source for the upper layers by providing real-time operational data. **Process Layer** ----------------- **Role:** Smooth workflows across departments by focusing on automation and execution **Components:** Workflow Engines: Automates and monitors business processes Supply chain systems: Optimizes logistics and supplier integration **Integration:** Relies on foundation layer for data and provides processed data to analytical layer **Analytical Layer** -------------------- **Role :** Handles data processing, analytics and decision support converting processed data into insights **Components** BI : Tools to create dashboards to display information Predictive Analytics: Uses statistical models to forecast trends **Integration:** Receive processed data from process layer and presents analytical data to portal layer **Portal Layer** ---------------- **Role:** Provides user-interface for accessing information and interacting with systems **Components** Web Portals : centralised access point for users Role-based dahboards : Different view for different people **Integration:** Fetches insights from analytical layer and process layer for end-user Pipeline Architectural Style ============================ A diagram of a pipe filter Description automatically generated - Pipes usually low volume - Filters Self Contained - Four types filter producer, transformer, tester and consumer (think data) Describe five fallacies related to distributed computing ======================================================== 1. the network is reliable 2. latency is zero 3. bandwidth is infinite 4. the network is secure 5. the typology never changes 6. there is only one administrator 7. transport cost is zero 8. the network is homogeneous. Answer like name misconception, reality then impact event-driven architecture ( Broker Typology ) ============================================= In event-driven architectures, the **broker topology** is a design pattern where a central **message broker** mediates communication between event producers and consumers ![A diagram of a event Description automatically generated](media/image4.png) \- chain-like broadcasting fashion through a lightweight message broker Initiating event, event channel, event processor and processing event Define the terms coupling and cohesion in relation to software design and identify the various types of cohesion ================================================================================================================ **Coupling**: - **Definition**: Coupling refers to the degree of dependency between different modules or components in a software system. Lower coupling is desirable as it allows changes in one module to have minimal impact on others. **Cohesion**: - **Definition**: Cohesion refers to the degree to which the elements within a single module or component work together as a single unit. Higher cohesion is preferable as it improves maintainability and readability. ### Types of Cohesion (from least to most desirable): 1. **Coincidental Cohesion**: - **Definition**: Elements are grouped random without any meaningful relationship. - **Example**: A module that handles unrelated tasks, such as logging and data validation. 2. **Logical Cohesion**: - **Definition**: Elements perform similar or related tasks but are invoked based on control logic. - **Example**: A module with functions for file read, write, and delete, selected by a control flag. 3. **Temporal Cohesion**: - **Definition**: Elements are grouped because they execute during the same time frame or phase. - **Example**: A module that initializes variables, opens files, and establishes connections. 4. **Procedural Cohesion**: - **Definition**: Elements are grouped to perform a sequence of operations that follow a specific order. - **Example**: A module that reads a record, processes it, and writes it to a database. 5. **Communicational Cohesion**: - **Definition**: Elements are grouped because they operate on the same input or output data. - **Example**: A module that computes statistics from a shared dataset. 6. **Sequential Cohesion**: - **Definition**: The output of one element serves as the input for the next element in the module. - **Example**: A pipeline that fetches data, filters it, and stores it. 7. **Functional Cohesion** (Highest Cohesion): - **Definition**: All elements of a module work together to achieve a single, well-defined purpose. - **Example**: A module solely responsible for calculating tax in an application. Describe the layered architecture style ======================================= A diagram of layers of a company Description automatically generated with medium confidence **Presentation Layer** - **Purpose:** Manages user interface and interaction. - **Examples:** Web pages - **Responsibilities:** Handles user input and displays results. - **Interaction:** Communicates with the business layer only. **Business Layer (Business Logic Layer)** - **Purpose:** Implements business rules and workflows. - **Responsibilities:** Processes requests and applies business logic. - **Example:** Order processing or payment validation. - **Interaction:** Interacts with both the presentation and persistence layers. **Persistence Layer** - **Purpose:** Manages data storage and retrieval. - **Responsibilities:** Handles interactions with databases and other storage systems. - **Example:** Database queries and updates. - **Interaction:** Communicates with the business layer for data storage. **Database Layer** - **Purpose:** Provides the actual data storage system. - **Responsibilities:** Stores data in structured formats. - **Example:** SQL or NoSQL databases. - **Interaction:** Directly stores and retrieves data from storage systems. Identify and describe five [operational] architecture characteristics ================================================================================= 1. **Availability:** The system's ability to remain operational and accessible whenever required. 2. **Continuity:** Ensures that the system can continue functioning in the face of disruptions or failures. 3. **Performance:** The efficiency with which a system performs its tasks and responds to user requests. 4. **Recoverability:** The system\'s capability to restore itself and resume operations after a failure or disaster. 5. **Reliability/Safety:** The system's ability to perform consistently without failure and to ensure user safety. 6. **Robustness:** The system\'s strength in maintaining performance under unexpected or adverse conditions. 7. **Scalability:** The system\'s ability to handle growth, either in data volume or user load, by adding resources. Microservices ============= ![A diagram of a software application Description automatically generated](media/image6.png) GPT === **1. TOGAF ADM and Enterprise Architecture Concepts** TOGAF advocates managing requirements dynamically throughout the ADM cycle: - **Dynamic Viewpoint:** Requirements evolve and are identified, validated, and prioritized in real-time. - **ADM Phases:** New requirements are iteratively reviewed in each phase (e.g., Phase B: Business Architecture) to ensure they align with the overall architecture. - **Integration:** The requirements repository supports traceability and continuous improvement. **Scope and Purpose of TOGAF ADM Phases B, C, and D** - **Phase B (Business Architecture):** Defines business strategy, governance, and processes to support enterprise goals. - **Phase C (Information Systems Architecture):** Develops data and application architectures that align with business architecture. - **Phase D (Technology Architecture):** Outlines the technological infrastructure needed to implement information system solutions. **Role of Iteration in ADM** - Iteration allows revisiting and refining work from previous phases. - Encourages flexibility to adapt to changing requirements. - Reduces risk by validating assumptions in early phases. **Enterprise Architecture Solving IT Alignment** - **Problem:** Business and IT misalignment arises from differing goals, communication gaps, and siloed systems. - **Solution:** Enterprise architecture provides a holistic framework ensuring IT systems and processes directly support business objectives. **Duality of Enterprise Architecture Artifacts** - **Conceptual Artifacts:** High-level views (e.g., strategies, goals). - **Operational Artifacts:** Detailed, actionable models (e.g., system blueprints). **2. Architectural Styles** **Layered Architecture** - **Definition:** Organizes a system into layers with distinct responsibilities (e.g., presentation, business logic, data). - **Strengths:** High modularity, easy to understand, promotes separation of concerns. - **Weaknesses:** Can introduce performance overhead, tightly coupled layers. - **Supported Characteristics:** Scalability, maintainability. - **Poorly Supported Characteristics:** Performance. **Microservices Architecture** - **Topology:** System composed of independent, small, deployable services. - **Granularity:** Defines how small or large a service should be. Smaller services increase flexibility but add complexity. - **Bounded Context:** Each service operates within its domain and is loosely coupled. - **Operational Concerns:** Duplication is preferred to tight coupling. Shared operational features (e.g., logging) are handled via tools like centralized log servers or service mesh. **Space-Based Architecture** - **Typology:** Decentralized architecture using in-memory data grids for scalability. - **Data Pumps:** Continuously transfer data between systems to improve performance. - **Caching:** - **Replicated Caching:** Same data copied across nodes. Best for read-heavy operations. - **Distributed Caching:** Data partitioned across nodes. Ideal for balanced read/write operations. **Pipeline Architecture** - **Definition:** Breaks processes into sequential stages (or filters) connected by data streams (pipes). - **Use Case:** Efficiently loading data into a data warehouse from diverse sources (e.g., IoT systems). **3. Moller's Conceptual Framework** **Explanation of Moller's Framework** - **Core Elements:** - **ERP I:** Internal integration (e.g., finance, HR). - **ERP II:** External integration (e.g., supply chain partners). - **Focus:** Seamless integration of business processes across the organization and beyond. **Enterprise Systems Integration** - **Enterprise Systems (ES):** Overarching systems integrating business functions. - **Manufacturing Execution Systems (MES):** Manage shop-floor operations. - **Production Control Systems:** Handle equipment-level controls. - **Integration:** Use middleware to ensure smooth communication and real-time data flow. **Supply Chain and Information Systems** - Streamlines logistics by providing real-time tracking and communication. - Enhances demand forecasting using analytics. - Facilitates just-in-time manufacturing. **4. Event-Driven Architecture (EDA)** **Broker Topology** - **Definition:** Messages are routed between producers and consumers via a broker. - **Advantages:** Scalability, decoupled communication. - **Example:** A central message broker (e.g., RabbitMQ) manages subscriptions and dispatches events. **Preventing Data Loss in EDA** - Use persistent queues to store messages until processed. - Implement acknowledgment mechanisms to confirm message receipt. - Use replicated brokers for fault tolerance. **EDA in Manufacturing** - **Event Capture:** Sensors generate data (e.g., machine temperature). - **Analytics:** Real-time dashboards display production metrics. - **Lean Manufacturing:** Identifies inefficiencies and optimizes workflows. **5. Distributed Computing** **Fallacies of Distributed Computing** 1. The network is reliable. 2. Latency is zero. 3. Bandwidth is infinite. 4. The network is secure. 5. Topology doesn't change. 6. There's one administrator. 7. Transport cost is zero. 8. The network is homogeneous. **6. Big Data and Data Architectures** **Maier's Big Data Reference Architecture** - **Components:** - **Data Ingestion:** Collects raw data from sources. - **Data Storage:** Scalable repositories (e.g., HDFS). - **Data Processing:** Batch or stream processing for analytics. - **Data Visualization:** Dashboards and reports for end-users. **Data Mesh Architecture** - **Definition:** Decentralized approach using domain-driven design. - **Data Products:** Each domain team owns its data as a product. - **Advantages:** Scalability, autonomy, and improved data sharing. **7. Software Design Principles** **Coupling and Cohesion** - **Coupling:** Degree of dependency between modules. - Low coupling is preferred for flexibility. - **Cohesion:** Degree of relatedness within a module. - Types: Logical, functional, sequential, communicational, etc. **Operational Architecture Characteristics** 1. Performance. 2. Scalability. 3. Security. 4. Availability. 5. Maintainability.