MSYS 50 Review PDF
Document Details
Tags
Summary
This document provides a review of various enterprise architecture frameworks, such as Zachman, TOGAF, and MDA. It covers topics like levels of abstraction, service-oriented architecture, and the iterative nature of architecture development. The document also describes considerations for implementing and managing these frameworks through the use of different viewpoints for varying stakeholder needs.
Full Transcript
MODULE 4.1 - FRAMEWORKS PODBS SESTD Zachman Addresses enterprise as a whole No methodology/artifacts TOGAF Treats enterprise as a system MDA Open, vendor-neutral approach to interoperability Raises level of abstraction for specifying software solutions Levels of abstraction Comp...
MODULE 4.1 - FRAMEWORKS PODBS SESTD Zachman Addresses enterprise as a whole No methodology/artifacts TOGAF Treats enterprise as a system MDA Open, vendor-neutral approach to interoperability Raises level of abstraction for specifying software solutions Levels of abstraction Computation independent business/domain model, business reqs. Platform independent BPMN model independent of workflow engine, UML model independent of computing platform Platform specific UML model for Java, WS-BPEL process model Mapping is key Set of rules and techniques to translate one model to another Service Oriented Architecture Set of design principles that enable units of functionality to be provided and consumed as services Applies equally to business and software apps. ○ Units of business representing value propositions within value chain or business process Separates internal and external behavior of a system Consumers usually not interested in internal system behavior Significance of SOA Interoperability, service reuse, understood in different domains MODULE 4.2 - TOGAF TOGAF Content framework ○ Architecture repository Modular structure ○ Isolation of specific guidelines ○ Incremental adoption ALL OF THESE MUST BE IN LINE WITH BUSINESS VISION AND DRIVERS + BUSINESS CAPABILITIES: ACF (capability) Organizational processes, skills, roles, responsibilities needed for EA Enterprise Continuum Architectures are developed across a continuum; foundational → industry-specific → enterprise’s own If they’re doing something right on the systems level, maybe they can adopt that approach/architecture on the domain level, and so on for the org. and industry level ○ vice versa (industry → org. → domain → system) ACF (content) Closely interrelated architectures BDAT - business, data, application, technology (IT) ADM Iterative: breadth of enterprise coverage, level of detail, time horizon, architectural assets to be leveraged Might need customization Can be used with other frameworks (Zachman) Domains Business - strategy, governance, organization, key processes Data - logical/physical data assets and data management Application - blueprint for individual applications deployment, interactions, relationships to core business processes Technology - IT infrastructure, HW/SW capabilities Implementation Governance (Deployment), Architecture Change Management (Maintenance) !! ADM component does not necessarily have to be sequential !! BIGGEST difference between this and SDLC = SCOPE! !! Version 10 vs Version 9.2 = emphasis on non sequential progression MODULE 4.3 - CSVLOD Dimension 1: What? Rules Broad, global rules defining an organization or its divisions Often textual format Permanent artifacts, updated periodically Facilitate planning decisions; how do we work or want to work? Helps with consistency of planning decisions ○ Example: all servers must install and use Linux as an OS Structures High-level structures = abstract instances + relationships Often graphical format Relatively stable artifacts, continuously updated Facilitates decision-making; what do we have or want to have ○ Example: description of IT systems in business capabilities context Changes Proposed incremental changes to an organization Usually in mixed textual and graphical formats Describe concrete instances in detail Temporary artifacts for specific purpose,then discarded ○ Example: changes to business process bc of new IT system Dimension 2: How? Business-focused Usually technology-neutral Use plain business language Soft, largely informal descriptions Only essential info for executive-level IT-focused Purely technical, IT-specific language Cover technical EA domains (BDAT) Hard descriptions, formal language Essential > 50% Common 25% - 50% Uncommon 10% - 25% Review which artifacts belong to which Considerations Dual artifact Expressed in simple, intuitive formats Used as organizational context for IS planning Proper use leads to conceptual consistency business IT Standards IT artifact Reusable means for IT implementation Technical consistency, technological homogeneity, and regulatory compliance Proper use leads to faster delivery of new IT initiatives Visions High-level conceptual description, business perspective Dual artifact Long term (3-5 years) Planning decisions on what IT should deliver in long term Brief, informal format, one-page diagram Alignment between IT investments and long-term business outcomes Landscapes High-level technical description of IT landscape Not dual Often focuses on current state Typically use strict formats, often as one-page diagram Proper use → increased reuse, reduced duplication of IT assets, improved IT agility, decrease dependence on legacy systems Outlines High-level descriptions of IT initiatives understandable to business leaders Dual artifacts Mid-term (1-2 years) Estimate business value and impact of proposed initiatives Proper user → improved efficiency and ROI of IT investments Designs Detailed technical description of separate IT projects actionable for project teams Not dual Focus on short-term (up to 1 year) Text, tables, complex diagrams Help implement approved IT projects Proper use → improved quality of IT project delivery Final word 24 in total, 8 of ea essential, common; usually, pragmatic use of 10-15 subtypes Organizations may have (or create) artifacts which are useful to EA but difficult to categorize MODULE 5.1 - ARCHITECTURE ANALYSIS & MODELING When describing architecture, they must ensure Capture it with the right level of abstraction & integration Model-based analysis technique Value of architecture models Realized if used in decision-making Address change; make well-informed design decisions Main categories of analysis techniques Functional - if you change something in one entity, how will it affect the others? ○ Functional aspects of architecture ○ Assess impact of change ○ Validate correctness ○ Does not answer how quick or how cheap (those r for quantitative! Quantitative - useful in: optimization (quantify effect of alternative design) ○ Assess impact of change ○ Capacity planning ○ Performance, reliability, cost = PRC! Additional classification Simulation - before deploy, simulate first Analytical - goes beyond statistical data, higher analysis vs quantitative Level of analysis in EA falls somewhere in between functional, analytical, some quantitative Mostly functional + analytical The Modeling Process Model - unambiguous, abstract conception of some parts or aspects of the real world EA: Abstract representations of enterprise ○ Products ○ Business processes ○ Applications ○ IT infrastructure ○ Relations between them Goal-driven Architects determine which domains are relevant Do you always need an unambiguous abstract conception of that knowledge? Do you always need a model to represent an aspect of an organization? No! Models are created to communicate something; Goal = introduce, agree on, commit to some knowledge representation. Through modeling, architect gains more knowledge. Models may not exist yet before the process. Basic Modeling Activities Establishing scope, purpose, and focus ○ Important to limit the scope ○ And to know the purpose of an actual model; again, each model is goal-driven. ○ Focus — think of each model as a piece of a jigsaw puzzle Selecting one or more viewpoints ○ Why viewpoints? You associate a viewpoint with a stakeholder ○ In most cases, you need to select a specific viewpoint ○ Goes hand in hand with selecting the stakeholders Creating and structuring the model ○ Thinking about what’s going to be contained within the model itself based on your objectives Visualizing the model ○ Content itself is different from the visualization aspect of a model Using the model ○ When you try to verify the stakeholders if they are okay with that version of the model, if it’s sufficient already, if you have captured the scope within the purpose of the model itself Maintaining the model ○ Obviously, the model will change because the organization will change. Parang system lang yan Types of modeling actions Introduce something to a model; new information, not captured before Refine the elements of a model; looking for more detail within that aspect of a model and tweaking them Abandon - why? Outdated, obsolete, erroneously represented models; abandon or change Abstract – opposite of refining, going higher level to abstract some elements Translate models - if it’s coming from another domain, and then translate it to your own domain. Mapping ex. Document modeling actions - for every artifact, every model you have to do this; you need a version history, to know what happened with this new version Guidelines for Modeling A model has to provide answers to questions Make a clear distinction between a model and its visualizations Model iteratively Model for dynamics – trying to be flexible and anticipate future changes in the model itself Be economical in models Be economical in views ○ “Economical” - efficient; wag sobrahana and go under as well (dont include unnecessary elements) Make concepts recognizable Make structures recognizable ○ Stakeholders should be able to recognize their own part; instantly recognizable ○ In some cases, why is it not recognizable to stakeholders? Visualization aspect, panget ng pagka yk; poorly structured/visualized What do the ff two imply? Within a model, what does that mean? Make a model consistent Keep related models consistent Make models as correct and complete as needed Treat different concerns orthogonally - Dont try to force them into a model if you cannot put them in one model, then separate them. Maxim of quantity ○ Make your model as informative as necessary ○ Do not make your model more informative than necessary Maxim of quality ○ Do not model what you believe to believe to be false ○ Do not model that for which you lack adequate evidence ○ Erroneous elements could affect a specific model and how you might need to abandon elements, even a model Maxim of relevance ○ Scope ○ Be relevant (i.e. model things related to the modeling goal) Maxim of manner ○ Visualization aspect contributes to this ○ Avoid obscurity of expression ○ Avoid ambiguity ○ Be brief (avoid unnecessary concepts and relations) ○ Be orderly Select the design viewpoints that match your objectives Focus Neglect matters of secondary importance and exceptions ○ Important because anaylsts/programmers tend to overanalyze on a less important aspect (exceptions) Exceptions are important but not as important to what happens normally Do not be afraid to abandon model elements Discuss stable, intermediate versions with the stakeholders ○ Important to contributing to the iterative nature of modeling itself ○ Getting feedback from stakeholders Start modeling from a single element ○ Very simple guideline but very effective, does not apply to modeling but this applies to solving complex problems ○ Start with the most intuitive starting point and expand from there 1 - capture key concepts and key relations at a high level of abstraction 2 - use a limited number of predefined abstraction levels 3 - define abstraction levels based on modeling goals 4 - keep abstraction levels consistent Structural Dimensions - FTULDW Functionality - functional decomposition Time - temporal structure, data flow, control flow Usage - dependencies, call graphs Location - physical distribution Data structure - type/class hierarchies Work - units of implementation, module structure Structuring Principles Make a model as self-explanatory as possible (easier said than done) Separate internal and external behavior ○ Clients only care about the services they need to avail, they do not need to know the internal stuff ○ Of an element, an entity ○ At some point, you simply hide its behavior because you are not concerned with them ○ Many of the concepts that we are talking about are used in MSYS 50 (higher level/architecture level) Use layers ○ Abstraction layers (related to second point) Group by phase Group by product/service Group by information used Group by physical distribution Group by independent parts MODULE 5.2 - VIEWS AND VIEWPOINTS View - what a stakeholder sees Viewpoint - where a stakeholder is looking from Concepts, models, analysis techniques, visualization Basis of Viewpoints Business level - management Logical - architects Physical - developers and administrators Choosing viewpoints should be based on Purpose and Content Purpose of Architecture view Designing ○ For designers ○ Initial sketch to detailed design Deciding ○ For managers ○ Assists in decision-making Informing ○ For stakeholders ○ Helps understand, obtain commitments, convince adversaries Content of Architecture view Details ○ Software engineers (UML class diagram) ○ One layer, one aspect Coherence ○ Operational managers (business processes, group of IT services ○ Multiple layers OR multiple aspects ○ Integration of several domains, Zachman Overview ○ EA architects and decision makers (CEO) ○ Multiple layers AND multiple aspects ○ Breadth over depth Typical Purpose Examples Stakeholders Designing Architect, software Navigate, design, UML diagram, BPMN developer, business support design diagram, flowchart, process designer decisions, compare ERD alternatives Deciding Manager, CIO, CEO Decision making Cross-reference table, landscape map, list, report Informing Employee, Customer, Explain, convince, Animation, cartoon, Others obtain commitment process illustration, chart Typical Purpose Examples Stakeholders Details Software engineer, Design, manage UML class diagram, process owner testbed process diagram Coherence Operational Analyze Views like use, managers dependencies, realize, assign impact of change (express relations) Overview EA, CIO, CEO Change Landscape map management Basic design viewpoints Introductory, organization, application usage Motivation viewpoints Stakeholder, goal realization Strategy viewpoints Capability map, resource map Implementation and migration viewpoints Project, migration Combined viewpoints ArchiMate and TOGAF MODULE 5.3 - LANGUAGE FOR ENTERPRISE MODELING Characteristics of Enterprise Modeling Language Heterogeneous architecture modeling approaches in different domains EA language should ○ Focus on inter-domain relations Model global structures within a domain Model relevant relations between domains Provide understandable language even for non-experts ○ Be formal (avoid ambiguity) Service Orientation and Layering Service - unit of functionality that some entity makes available to its environment and which has some value for certain entities in the environment Concept has many diverse applications Granularity may be discerned Leads to layered view of EA models ○ Forms stack of layers Basic Architecture Layers - not to be confused with BDAT of ACF Business ○ Offers products/services to customers ○ Realized by business processes Application ○ Supports business layer by application services ○ Realized by software application components Technology ○ Infrastructural services needed by applications CSPSCSI Structure = passive/active Active structure = subject (actor) Behavior = verb Passive structure = object Review arrows Groups using TOGAF must go through these notations Language should be flexible to allow customization and modeling of specific scenarios Flexibility via Adding attributes to concepts and relations Specialization of concepts MODULE 6.1 - IMPACT OF EMERGING & DISRUPTIVE TECHNOLOGIES Importance of Emerging & Disruptive Technologies Competitive advantage External pressure More efficient operation Not without integration challenges Emerging & Disruptive Technologies to Consider New ways of computing ○ Neuromorphic ○ Quantum Artificial intelligence ○ Disruptive ○ Affects other areas Robotics, NLP, art, movies, photography, music, among others Neuromorphic computing/Engineering Aims to mimic the human brain Architecture based on neural and synaptic structures ○ Processes information in an event-driven manner, similar to how neurons in the brain communicate ○ Real-time processing Retains many of the aspects of current hardware technology ○ Uses electronic circuits to replicate neural networks Usually used for pattern recognition Quantum Computers Different hardware architecture compared to today’s machines Based on the quantum principles in Physics ○ Parallel processing – processing of multiple possibilities simultaneously ○ Superposition and entanglement Disruptive (and threatening) when fully realized Usually for calculating exponentially faster to solve complex problems AI: Emerging and Disruptive Concept not exactly new Build upon from machine learning, deep learning, NLP, computer vision Needs a lot of “compute” Hardware improvements enabled significant progress Arms race between major and new tech players ○ Google, Meta, OpenAI, Apple, Microsoft More of general use ○ Healthcare, finance, retail IBM: AI is technology that enables computers & machines to simulate human learning, comprehension, problem solving, decision making, creativity, and autonomy. AI focuses on creating intelligent systems that can learn and make decisions based on data. Quantum Computing aims to solve complex problems by leveraging quantum mechanics for unprecedented computational power. Neuromorphic Computing seeks to replicate the brain's structure and function for cognitive tasks, emphasizing energy efficiency and real-time processing. Neurons: The basic units of a neural network, similar to neurons in the human brain. Each neuron receives input, processes it, and passes it on to the next layer. Layers: Neural networks are composed of multiple layers: Input Layer: The first layer that receives the raw data. Hidden Layers: Intermediate layers that process the data through various transformations. There can be multiple hidden layers in a deep neural network. Output Layer: The final layer that produces the output or prediction. Neural Networks Neuromorphic Computing Simulate the way the brain processes Mimics the brain’s structure & function information Processes based on events Processes data in a continuous Real-time response to specific events manner Thus it’s more energy efficient Ongoing data analysis More on AI Types of AI Capabilities ○ Artificial Narrow AI (ANI) ○ Artificial General Intelligence (AGI) ○ Artificial Superintelligence (ASI) Functionalities ○ Reactive machine ○ Limited memory ○ Theory of mind ○ Self-aware AI Techniques Generative ○ Art and design, music composition, content creation, virtual worlds, etc. ○ Large language model (LLM) ○ Natural language processing (NLP) ○ Computer vision ○ Machine learning, deep learning Predictive ○ Financial forecasting, fraud detection, healthcare diagnosis, etc. Why Orgs Need to be Aware: AI has already made its way into many aspects of daily computing Significant changes to existing business processes Era of quantum computing: not a question of IF, but WHEN MODULE 6.2 - CURRENT ADVANCES IN AI AND THE NEED FOR ORGANIZATIONAL PREPAREDNESS AI Models Model ○ An AI model is a program that has been trained on a set of data to recognize certain patterns or make certain decisions without further human intervention. – IBM Parameters ○ AI parameters are the interval variables that machine learning models learn and adjust during training to make predictions or decisions. (perplexity) ○ Similar to dials and knobs for fine-tuning Relevant AI Technologies Language models (LLM/SLM, NLP) Computer vision Image generation Music and sound generation No code development Robotics and general automation Scientific applications Natural Language Processing Learning a new language ○ More natural interactions (Duolingo Max via ChatGPT) Digital Assistants ○ Personal assistants ○ Digital companions Small/Large Language Models Billions of parameters Small-on-device (edge) deployment May be multimodal Prominent players and products ○ ChatGPT (OpenAI) ○ Gemini (Google) ○ Llama (Meta) – open source ○ Copilot (Microsoft) ○ Apple Intelligence ○ NVIDIA Image Generation Impressive photo-realistic quality Text-to-image, image-to-image Prominent models ○ Flux ○ Stable diffusion ○ Dall-E ○ Midjourney Music and Sound Generation Music generation (based on genre, singer, mood, etc.) Sound effects Voice (including cloning) Quality is as impressive as AI-generated photos Popular cloud-based services ○ Suno ○ Udio ○ ElevenLabs Video Generation Short clips, limited resolution Much more computationally-expensive Popular cloud-based services ○ Kling AI ○ Minimax ○ Sora (OpenAI) ○ Adobe Firefly Robotic and General Automation Humanoid robots 4-legged robots Driverless vehicles Notable companies ○ Tesla ○ Boston Dynamics ○ Ubtech Robotics ○ Unitree Robotics Scientific Applications Let AI agents do research and publish ○ Exponential growth in publications Potential to develop cures for cancer, alzheimer’s, space travel Limitations of current systems Not infallible (“hallucinations” are common) Reasoning capabilities are questionable Limited awareness of the real world Massive amounts of compute needed ○ Both training and development ○ Leads to other concerns Are we approaching AGI? Goal: for benefit of humanity (“safe” AGI) Current model architecture might not be the way to move forward How do we definitely say we have achieved AGI? ○ “… an AGI system can solve problems in various domains, like a human being, without manual intervention. Instead of being limited to a specific scope, AGI can self-teach and solve problems it was never trained for. “ (Amazon AWS) ○ Google Deepmind’s proposed metric: https://deepmind.google/research/publications/66938/ Major Challenges in AI Inefficient hardware (mismatched architecture of GPUs) Cost Energy requirements and environmental impact Ethical considerations Areas of Ethical Concern Privacy and data confidentiality Job security Deepfakes Blurred lines between reality and digital realm Military applications Sentience and superintelligence Privacy and Security Interactions sent and stored in cloud servers Increasing popularity of locally-hosted (on-device) systems ○ Need for capable hardware ○ Mobile phones: Apple Intelligence, Gemini Nano Hacking Open-Source Models: Why Host Locally? Cost (a way to democratize AI) Privacy and confidentiality Research and experimentation Main challenge: might be too much for non-technical users Job Security Which jobs will AI eventually replace? Repetitive, boring, labor intensive tasks ○ Shift towards knowledge workers? Impacted jobs (short-term) ○ Artists Musicians, actors/actresses (including voice), announcers, animators, photographers ○ Drivers (mostly, public transport) ○ Programmers ○ Game developers Deepfakes Definite and immediate concern for public figures Blurred lines between Reality & digital realm Proliferation of AR glasses and VR headsets Other simulators (e.g. walking while remaining in place) Impact on natural/real-world interactions Military Applications AI-assisted identification of criminals, terrorists, and other persons of interest ○ Concerns for accuracy, invasiveness Military offensive without human intervention Robot infantry Impact on EA Tweaks and changes to current EA approaches ○ Timeline: sense of urgency? ○ Need to focus and review the technology layer Potentially, vastly different workforce profile Quantum era in the horizon AI: current trend or long-term impact?