IAB401 - Introduction to Enterprise Architecture PDF

Introduction to Enterprise Architecture School of Information Systems Faculty of Science CRICOS No.00213J CR...

Introduction to Enterprise Architecture School of Information Systems Faculty of Science CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved 2 About this unit The unit covers critical knowledge and skills for producing systems architecture using different modelling techniques, at two levels - Enterprise architecture (cross-systems) - Solution architecture (individual system) It will cover representations of architecture for - Business functionality, i.e., business capability modelling - Archimate - Linking business to IT - Archimate - Software applications, using UML - Technology platforms and infrastructure - insights only, not detailed modelling The workshops and assessments are drawn from real-world projects aligned to enterprise and other systems utilized in business CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved Lecture 1 objectives To provide an overview of why enterprise architecture is important To provide an overview of where enterprise architecture fits into business and IT planning To describe key parts of enterprise architecture To provide an overview of enterprise architecture frame works and the Open Group Architecture Framework (TOGAF) CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved Agenda Business and IT gap What is enterprise architecture? Managing architecture work in practice – EA frameworks and TOGAF CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved Insights into IT systems complexity Defence Queensland Health Thousands of information systems and business One of the largest health IT landscapes in largest in processes Australia At least 200 in inventory management, warehouse and distribution alone! 100s information systems and thousands of business processes across hospitals, health agencies and corporate Several Enterprise Systems! organisations - Oracle Peoplesoft - SAP - SAP R/3 - AURION - Microsoft Dynamics - Hospital systems Different hosting and cloud infrastructure and systems platforms, each with its own technical Infrastructure technologies support and application support staff - 400 networked sites - 700 servers Multiple network types including multiple wide area networks different - 22,000 desktops - Operational - 28 sizable “data centres” - 250 PABXs - Administration - Public - 290 videoconferencing sites - 150 satellite television sites Thousands of device types (desktops, laptops, handhelds, sensors, robots CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved 6 Key factors of IT systems complexity The IT and process landscape of organizations change and increase in complexity and uncertainty under business mergers, acquisitions and globalization Different IT systems are acquired, at different times, with different degrees of capability, to support many processes concerning product, services and management needs - without a full understanding of the support and where the gaps and overlaps are Different types of data captured by different systems and processes are associated similar or the same types of things in a business (e.g., different ways in which activities are recorded, different levels of understanding a product or physical part) CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved 7 Factors of IT systems complexity (cont’d) Changes in systems released by providers may result in different versions of systems with major differences in the way they are hosted, operated and interacted with, e.g.: - Different versions of processes, on-premise, private cloud and public cloud versions, integration of systems with the Internet-of-Things and AI technology) The integration of systems is challenging, variable and improves over a considerable time through different technical interoperability mechanisms and different standards Systems may be subject to market volatility given changes volatility of providers and investment availability to them Partners of companies may also be subject to market volatility CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved 8 Factors of IT systems complexity (cont’d) The degree to which organisations manage IT systems is dependent on the skills and services available through the market, resulting in change Strategic changes in businesses and companies make adjustments due to changing market and competitors CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved Reported insights into change frequency CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved Navigating change through a clash of professional culture IT professionals Business professionals Rigorous, concrete, focussed, feasible Diligence on business thinking but less rigour in representing in how business works Specialised expertise and experience in specific areas of IT Expertise through business management practice, patterns of business operation, business-as-usual vs. opportunity/innovation focus Communicate with business through technology and software applications (e.g. ERP) capabilities and design models (e.g. BPM models) Limited involvement in IT for decisions that will impact business Joint collaborations with business based through specific activities guiding software development or Leads to ineffective and reactive utilisation of IT, procurements – system architecture, business planning and decision-making entailing IT process modelling and business requirements Value of IT for high-level business strategy hard to demonstrate CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved Understanding systems at different layers Systems are planned, designed and Business implemented at different model layers in an organization Processes Operating model Data This also applies to start- ups Operational systems Policies Different layers of activity People & rules require different skillsets (e.g., strategic, Software applications operational, technological) Hyperscale Platforms and infrastructure BPM Activities required at Cloud different layers require artifacts for communication, buy-in, further development etc. IoT & Edge Blockchain Computing Enterprise Cognitive systems Business Computing Intelligence CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved 12 Systems at different layers (cont’d) Business model - Organisational plan supporting the business strategy of an organization for the medium to long term (usually 3-5 years) - Scope: Strategic aspects of how an organization creates, delivers, and “Satellite captures value for to meet its mission and strategic goals and objectives view” in economic, social, cultural or other contexts. - Key ingredients: High-level capabilities (activities), resources, partnerships, offerings (products and services), customer segments, channels, relationship types to build customers and financial aspects. - Methods: Business Model Canvas (visual and textual description) CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved 13 Systems at different layers (cont’d) Operating model - Tactical plan for translating the business model into business operations - Scope: Detailing of the key elements of a business model, how they structured and interact to deliver operations, and what the key skills and culture needs are (e.g., resource training) “Town planning - Key ingredients: view” o How the elements are distributed across the different parts of a planned organization o How products/services are delivered o What partnerships are utilised o What the financial support and expectations are o Includes charts, graphics, tables and maps to show how the organization operates and the value it brings to customers and stakeholders. CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved 14 Systems at different layers (cont’d - Key ingredients (cont’d) o High-level design principles are captured for operations which utilise capabilities, partnerships, resources etc. o Design principles effectively represent high-level systems requirements for digital solutions and business processes - Methods: Bespoke depiction (visual and textual description), business architecture and design principles, enterprise architecture Business processes - A set activities which utilise resources (human, material, digital) to achieve operational goal. - Provide the coordination at the operational layer of an organization “Street - Implemented using digital technologies view” - Methods: Business process modelling techniques, e.g., BPMN and related modelling techniques like UML CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved 15 Systems at different layers (cont’d) Software applications - Technology directly used by users (desktop, mobile, Web and enterprise applications) - Implemented by software components and storage repositories such as “Building databases view” - Methods: Solution Map and software architecture techniques, e.g., BPMN and UML Platforms and infrastructure - Underlying systems software and tools used to support and run software applications - Servers, storage and networking resources used to host and operate systems “Foundation - Methods: Detailed technical architecture modelling techniques and utilities view ” CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved  IT Career Roles IT Systems Layers Chief Information Officer Chief Technology Officer Chief Digital Officer Business Chief Innovation Officer Data Processes Digital Product Manager Business Digital Solutions Manager model Digital Entrepreneur Assets Operating model Business and Enterprise Policies Architecture & rules Business Architect Enterprise Architect Operations Business process models and business data analytics and predictive Information Architect models Business Analyst Software applications Solution maps, data models, software architecture and unit/systems test plans, software Systems Analyst design patterns and architecture, systems architecture, reusable code repository Process Analyst Platform and infrastructure Data Analyst Cloud and edge computing strategy and architecture, data migration plans, integration architecture Solution Architect Process Architect Business Hyperscale Intelligence Data Architect Cloud IT BPM Software Engineer IoT & Edge Computing Application Developer Cognitive Blockchain Cloud Developer Computing Enterprise © 2024 QUT All Rights Reserved systems Different methods for managing systems at different layers Business Operating Model Business architecture Enterprise architecture Roles and actors Client Insurant ArchiSurance Insurer External business services Claim registration service Customer information service Claims payment service Business Damage claiming process layer Registration Acceptance Valuation Payment External application services Software Customer Claims Payment administration administration service service service Application Application components and services Customer Claim information information service service CRM system Policy administration Financial application layer Technology External infrastructure services Claim Customer files files service service Infrastructure Infrastructure Business capability map layer zSeries mainframe Sun Blade Financial DB2 iPlanet application database app server EJBs Business Processes Platform and infra. Software applications Process architecture systems Solution architecture CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved Agenda ü Business and IT gap What is enterprise architecture? Managing architecture work in practice – EA frameworks and TOGAF CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved 19 What is enterprise architecture (EA)? Whole-of-organization “Google Maps” Operating Model of digital systems, their connections Enterprise architecture and how they support business Roles and actors Client Insurant ArchiSurance Insurer Comprises multiple models, External business services Claim Customer Claims Business registration information payment service service service Damage claiming process specifications and documents of Registration External application services Acceptance Valuation Payment Software Customer Claims framing concepts for understanding Payment administration administration service service service Applications Application components and services Customer Claim of systems across organization information information service service CRM Policy Financial system administration application External infrastructure services Claim Customer Technology files files Viewed in different layers providing service service Infrastructure zSeries mainframe Sun Blade Infrastructure Business capability map different areas of focus Financial DB2 iPlanet application database app server EJBs Linked to and guides architectures of individual systems (process, Business Processes Software applications Platform and infra. solution and cloud architecture) systems Process architecture Solution architecture Provides transparency, planning, Cloud architecture decision making and risk identification of systems Steers transformation roadmaps CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved Where EA fits into digital systems planning? Business Establish architecture of Continuously improve digital systems and their architecture Business support of business model Data Processes Operating model Business and Enterprise Architecture Business processes Policies People & rules Business process models, resource models and business intelligence Support business Track transformation Software applications case for change Solution maps, data models, software architecture and unit/systems activities and refactor test plans systems Platform and infrastructure systems BPM Hyperscale Cloud strategy and architecture, data migration plans, integration Cloud Develop target architecture - Blockchain business processes, Define transformation IoT & Edge software Computing Enterprise Business Cognitive roadmap systems Computing applications, and Intelligence technology systems IT Oversight of digital transformation using Enterprise Architecture Framework (e.g., TOGAF) and IT governance How EA and detailed architectures are co developed? 1 Profile business functionality of selected area Business capabilities, value streams and capability realization roadmap (current and future state) 2 Digitally enable business functionality at a high-level Map business business capabilities and value streams into EA models 3 Analyse gaps, overlaps and limitations of digital systems support of business functionality Apply heat map analysis on business capabilities based on EA models and link to transformation roadmap process 4 (Digitally) enable business functionality through process architecture Align EA models with process architecture 5 Digitally enable business functionality through solution processes Align EA models with solution architecture Industry insight: Use of Lean IX EA models to support SAP ERP to SAP S4/Hana migration © 2024 QUT All Rights Reserved How EA and detailed architectures are co-developed? ENTERPRISE ARCHITECTURE BUSINESS ARCHITECTURE Roles and actors 2 3 1 Client Insurant ArchiSurance Insurer Fulfilments Pre-sales Sales order Delivery Billing Payments negotiations processing processing External business services Claim Customer Claims registration information payment service service service BUSINESS PROCESS ARCHITECTURE Damage claiming process Registration Acceptance Valuation Payment Inquire-to-pay 4 Custome Sales Sales Ship Bill Customer External application services r Quotation Order Order inquiry Update Order customer payments Customer Claims Payment Creation administration administration service service service Application components and services Value streams Customer Claim information information Engineer-to- service service Sell-from-stock Make-to-order order CRM Policy Financial system administration application Business processes External infrastructure services Claim Customer files files service service Infrastructure zSeries mainframe Sun Blade SOLUTION ARCHITECTURE Financial application DB2 iPlanet Software Component database app server EJBs 5 Software Component Software Component What is EA? (cont’d) “Enterprise Architecture” coined by 1987 by John Zachman in IBM systems journal, “A Framework for Information System Architecture Video summary: EA insight in a few minutes CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved What is an Architecture? Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principle guiding its design and evolution. (IEEE Standard 1471-2000) Architecture captures - Structure (objects) - Behaviour (interaction between objects) - Constraints (rules in structure and behaviour) and design principles for a specific domain – e.g., business, information, process and service architecture CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved What is an Architecture? Architecture is supported by specific modelling techniques and document conventions, e.g. - Fundamental Modelling Concepts or FMC (block systems architecture, data and process) - Unified Modelling Language or UML (data, process, use cases and others) - Business Process Modelling Notation or BPMN (different process viewpoints) Architecture frameworks integrate - Integrates a number of modelling techniques - Provides coherent appreciation of alternative modelling techniques used by different sets of professionals designing, implementing and maintaining systems Ultimately, architecture frameworks draw together alternative modelling techniques used by different sets of professionals designing, implementing and maintaining business planning & operations, business applications and IT infrastructure CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved 26 Enterprise Architecture Frameworks Zachman Framework Department of Defence Architecture Framework (DODAF) Federal Enterprise Architecture Framework (FEAF) Treasury Enterprise Architecture Framework (TEAF) The Open Group Architecture Framework (TOGAF) CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved The genesis of EA - the Zachman Framework abstractions DATA FUNCTION NETWORK PEOPLE TIME MOTIVATION perspectives Business analysis focus What How Where Who When Why List of Things - List of Processes - List of Locations - List of Organizations - List of Events - List of Business Important to the Business the Business Performs Important to the in which the Business Operates Significant to the Business Goals and Strategies Business SCOPE Planner Entity = Class of Function = Class of Node = Major Business People = Class of People and Ends/Means=Major Business contextual Business Thing Business Process Location Major Organizations Time = Major Business Event Goal/Critical Success Factor e.g., Semantic Model e.g., Business Process Modele.g., Logistics Network e.g., Work Flow Model e.g., Master Schedule e.g., Business Plan ENTERPRISE MODEL Owner Process = Business Process Entity = Business Entity I/O = Business Resources Node = Business Location People = Organization Unit Time = Business Event End = Business Objective conceptual Rel. = Business Relationship Link = Business Linkage Work = Work Product Cycle = Business Cycle Means = Business Strategy e.g., Logical Data Model e.g., Application Architecture e.g., Distributed System e.g., Human Interface e.g., Processing Structure e.g., Business Rule Model Architecture Architecture SYSTEM MODEL Designer Entity = Data Entity Process.= Application Function Node = IS Function People = Role Time = System Event End = Structural Assertion logical Rel. = Data Relationship I/O = User Views Link = Line Characteristics Work = Deliverable Cycle = Processing Cycle Means =Action Assertion e.g., Physical Data Model e.g., System Design e.g., Technical Architecture e.g., Presentation Architecture e.g., Control Structure e.g., Rule Design IT design focus TECHNOLOGY CONSTRAINED MODEL Node = Hardware/System Builder physical Entity = Tables/Segments/etc.Process= Computer Function Software People = User Time = Execute End = Condition Rel. = Key/Pointer/etc. I/O =Data Elements/Sets Link = Line Specifications Work = Screen/Device FormatCycle = Component Cycle Means = Action e.g. Data Definition e.g. Program e.g. Network Architecture e.g. Security Architecture e.g. Timing Definition e.g. Rule Specification DETAILED REPRESEN- TATIONS Subcontractor out-of-context Entity = Field Rel. = Address Node = Addresses Process= Language Statement I/O = Control Block Link = Protocols People = Identity Work = Job Time = Interrupt Cycle = Machine Cycle End = Sub-condition Means = Step EA insight in a few minutes FUNCTIONI DATA FUNCTION NETWORK ORGANIZATION SCHEDULE STRATEGY NG Implementation Implementation Implementation Implementation Implementation Implementation ENTERPRIS E CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved Agenda ü Business and IT gap ü What is enterprise architecture? Managing architecture work in practice – EA frameworks and TOGAF CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved 29 Enterprise architecture frameworks Provides comprehensive process for development of Enterprise Architecture across all aspects Supports the planning, capture, approvals and release of architecture building blocks (e.g., business capabilities, value streams, business processes) Provide documents and templates for Enterprise architecture development work, across planning, approvals and governance CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved 30 Enterprise architecture frameworks Utilised across full systems lifecycle – operating models, solution design, tendering for solutions in market Utilised by software providers like SAP, Oracle, Microsoft, Amazon for allowing their solutions to be developed and adapted by customers across different layers of systems CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved Introduction to TOGAF TOGAF is a framework – a detailed method and a set of supporting tools for developing an enterprise architecture Provides an architecture development process, and identifies architecture development capabilities and stakeholders Fosters for reuse and refactoring of architecture models (building blocks) Supports architecture transition Supports implementation transition, so the project to implement it and the associated time and cost can be defined more exactly Framework can be customised to suit the requirements of the organisation CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved TOGAF Architecture Development Method (ADM) Cycle Preliminary Iterative over the whole process and between phases – for each iteration, decide: A. Architecture Vision - The breadth of the coverage of H. Architecture Change B. Business the organisation to be defined Management Architecture - The level of detail to be defined - The extent of the time period aimed at, including the number G. Requirements C. Information and extent of any inter mediate Implementation Systems Management Governance Architecture time periods Can be used to populate the Foundation Architecture of an F. Migration D. Technology organisation Planning E. Architecture Opportunities and Solutions CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved 32 33 Systems development process Contextual Share (Visioning) The Board Business Model holders Planning Business & Enterprise Architecture Cross org Conceptual Business and Enterprise Ent./Bus. Architecture (Planning) Architecture models Architects development & governance Solution Architecture Logical Future State (Designing) Business Solution Future State System Business Processes Architects Architects Architecture Strategy (Level 0) Change Projects Architecture Physical Business FS Business Processes Logical and physical Technical components (Detailing) Analysts (Level 1-2) System Design Architects Logical Systems Physical Systems Architecture Architecture Component Procedures & Solution Developers Applications (Building) config Architects Operations Operational Value: Products (Using) Users Services CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved  Insight: EA products and modelling tools See product insight through: http://www.sparxsystems.com.au/resources/tutorial/uml_models.html CRICOS No.00213J CRICOS No.00213J 35 Insight: Industry EA framework of SAP In December 2023, SAP acquired the EA tool, Lean IX for approx. $1.2b USD (following from its acquisition of Signavio, for approx. $900b USD, which supports BPMN modelling) Lean IX is being used to support the SAP EA Methodology using industry standards (incl. TOGAF, BPMN, UML, APQC) This supports architect work from the definition of target architectures to implementation and continuous transformation. “Over the course of time, we have seen as Enterprise Architects in SAP Business Transformation Services, both SAP internal as well in the interaction with customers and partners, that different methodologies, artifacts, and approaches are used in architecture engagements. With the creation of a reference architecture the need for a common Enterprise Architecture Framework at SAP was obvious as different departments within the SAP organization produce and consume the content of the reference architecture. Only one common “language” and approach would ensure that information can be leveraged in an efficient and effective way both inside and outside the organization”. https://community.sap.com/t5/enterprise-architecture-blog-posts/sap-enterprise-architecture-framework/ba-p/124037 CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved Key Elements/Subsets of Enterprise Architecture Business/Business Process Architecture: business strategy, governance, organisation, and key business processes Data and Information Architecture: structure of an organisation’s logical and physical data assets and data management resources Solutions Architecture (SA): blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organisation Technology and Infrastructure Architecture: platform and hardware capabilities needed to support the deployment of business, data, and application services – middleware, operating systems, servers storage, networks, standards, etc. CRICOS No.00213J CRICOS No.00213J © 2024 QUT All Rights Reserved The Architecture Journey of Unit Operational Business Analysts Business Strategy Architecture The Board Operating Business model model Business Architecture Enterprise Architecture Business Capability Map EA Business-to-IT Models: In Archimate in Archimate Solution Architectures Roles and actors Client Insurant ArchiSurance Insurer Solution design and implementation External business services Detailed Claim registration service Customer information service Claims payment service data analysis Damage claiming process Registration Acceptance Valuation Payment Software High-level External application services Design/ Process Customer Claims Payment Config Integrated administration administration service service service map scenarios Application components and services Data models Customer Claim in UML Technical BUSINESS PLANNING: information service information service Value Streams in Archimate analysis CRM Policy Financial system administration application Detailed External infrastructure services process Claim files Customer files analysis service service Infrastructure zSeries mainframe Sun Blade DB2 database iPlanet app server Financial application EJBs Process models in BPMN 2.0 CRICOS No.00213J CRICOS No.00213J Business Enterprise Business Solution Technical Architects Architects Analysts Architects Architects CRICOS No.00213J CRICOS No.00213J  Introduction to Enterprise Architecture School of Information Systems Faculty of Science CRICOS No.00213J CRICOS No.00213J Business architecture in a “nutshell” “How to model what a business does on one sheet of paper!” Model business as high-level functions - or business capabilities Use capabilities to link to business and IT for planning, design and delivery of systems CRICOS No.00213J CRICOS No.00213J © 2024-2027 QUT All Rights Reserved 2  sP PLAN sS SOURCE Business sP1 Plan sP2 Plan sP3 Plan Make sP4 Plan sP5 Plan Return sS1 Source sS2 Source sS3 Source Capability Map Supply Chain Source Deliver Stocked Product Make-to-Order Product Engineer-to- Order-Product used in global sP1.1: Identify, Prioritize, and Aggregate Supply sP2.1: Identify, Prioritize, and Aggregate Product sP3.1: Identify, Prioritize, and Aggregate Product sP4.1: Identify, Prioritize, and Aggregate Delivery sP5.1: Identify, Prioritize, and Aggregate Return sS1.1: Schedule Product Deliveries sS2.1: Schedule Product Deliveries sS3.1: Identify Sources of Supply supply chains: Chain Requirements Requirements ion Requirements Requirements Requirements sS1.2: Receive Product sS2.2: Receive Product sS3.2: Select Final Supplier(s) and SCOR sP2.2: Identify, sP3.2: Identify, sP4.2: Identify, sP5.2: Identify, Negotiate sP1.2: Identify, Assess, and Assess, and Assess, and Assess, and sS1.3: Verify sS2.3: Verify Prioritize, and Aggregate Product Aggregate Product Aggregate Delivery Aggregate Return Product Product sS3.3: Schedule Aggregate Supply Resources ion Resources Resources Resources Product Deliveries Chain Resources sS1.4: Transfer sS2.4: Transfer sP2.3: Balance sP3.3: Balance sP4.3: Balance sP5.3: Balance Product Product sS3.4: Receive sP1.3: Balance Product Resources Production Delivery Resources Return Resources Product Supply Chain with Product Resources with with Delivery with Return sS1.5: Authorize sS2.5: Authorize Resources with Requirements Production Requirements Requirements Supplier Payment Supplier Payment sS3.5: Verify Supply-Chain- Requirements Product Requirements sP2.4: Establish sP4.4: Establish sP5.4: Establish Sourcing Plans sP3.4: Establish Delivery Plans and Communicate sS3.6: Transfer sP1.4: Establish Production Plans Return Plans Product and Communicate Supply Chain Plans sS3.7: Authorize Supplier Payment sEP Enable Plan sES Enable Source sEP.1: Manage Business Rules for Plan Processes sEP.6: Manage Integrated Supply Chain Transportation sES.1: Manage Sourcing sES.6: Manage Incoming Business Rules Product sEP.2: Manage Performance of Supply Chains sEP.7: Manage Planning Configuration sES.2: Access Supplier sEs.7: Manage Supplier sEP.3: Manage Plan Data Collection sEP.8: Manage Plan Regulatory Requirements and Performance Network Compliance sEP.4: Manage Integrated Supply Chain Inventory sES.3: Maintain Source Data sES.8: Manage Import/Export Source: SCOR web site, sEP.9: Manage Supply Chain Risk Requirements http://supply-chain.org/SCOR- sEP.5: Manage Integrated Supply Chain Capital sES.4: Manage Product Assets sEP.10: Align Supply Chain Unit Plan with Financial Plan Inventory sES.9: Manage Supply Chain overview Source Risk sES.5: Manage Capital Assets SES.10: Manage Supplier Agreements CRICOS No.00213J CRICOS No.00213J © 2024-2027 QUT All Rights Reserved 3 Business Capability Map developed by Brisbane City Council CRICOS No.00213J CRICOS No.00213J © 2024-2027 QUT All Rights Reserved 4 Understanding systems at different layers What a business does at the strategic level for the medium to long term (3-5+ years): Business model What is the business and IT plan is for supporting the business strategy and model in the terms: Business & Processes Operating model Data Enterprise Architecture Operations What the business does: Process & Information Policies Architecture People & rules Software applications What the digital solutions are for operations and BPM users? Solution Architecture & Software Hyperscale Platforms and infrastructure Architecture (wireframes, workflows, Cloud data model) What the digital support mechanisms are: IoT & Edge Blockchain Cloud Architecture Computing Enterprise Cognitive systems Business Computing Intelligence CRICOS No.00213J CRICOS No.00213J © 2024-2027 QUT All Rights Reserved 5 IFN663 architecture journey Tactical Strategy Business Analysts Business Strategy Operating The Board model Business case / model Business Architecture Enterprise Architecture Business Capability Map EA Business-to-IT Models: Archimate Solution Architectures Roles and actors Client Insurant ArchiSurance Insurer Solution design and implementation External business services Detailed Claim registration service Customer information service Claims payment service data analysis Damage claiming process Registration Acceptance Valuation Payment Software High-level External application services Design/ Process Customer Claims Payment config Integrated administration administration service service service map scenarios Application components and services Data models Technical