DOCSLIB.ORG

PF2, POET, PEAF and the Author

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Certification Training 2 - Foundation 2 November 2020 POETWhat does POET help you cope with? Keypoint The only constant is the ACCELERATION of change. POET helps you cope with the punishing G- Force, by driving the Transformation of Transformation™. Adoption Management: Instigate a project to ensure everyone related to Transformation is trained in POET/XOET. 09:02 Adoption Adoption What does the Adoption section of POET contain? Keypoint The Adoption section of POET defines Adoption 'HOW' it should be adopted and used. v2020 May 09:04 Adoption Step 4 What is the fourth step in Adopting POET? Elaborating Keypoint Designing Changes Step 4 allows you to decide what to change from Logical Design Physical POET to your Changes own XOET. v2020 May 09:07 Adoption Step 4 > Actions When Adopting POET, what are the fundamental Actions in Step 4? Step 4 Keypoint Design Changes Measures Framework Training Measures Enterprise Use POET to Measures’Level 3 Measures’Dependant Assessment Mitigate Risks Assessment design your Enterprise Design Your Framework Enterprise Dependant Dependant Assessment’ Target Assessment’ Target State own XOET. 4 MTargetA G StateS I C Motivation Current CONSTRAINT Target Motivation Enterprise EnterpriseINPUT Phase OUTPUT Enterprise Adoption Dependant DependantCurrent State Target State Dependant Motivation’ CurrentM A G StateI C MTargetA G StateI C Motivation’ IMPACT EA Project Team: ASSESSMENT Current State Actions Actions Follow the 4th step in Do I Care? Adoption Adoption POET for maturing your Transformation Guidance capability. v2020 May 09:09 Adoption Step 5 What is the fifth step in Adopting POET? Constructing Keypoint Developing Step 5 Changes allows you to create Physical Develop Operational your own Changes XOET. v2020 May 09:12 Adoption Step 5 > Actions When Adopting POET, what are the fundamental Actions in Step 5? Step 5 Keypoint Develop Changes Measures Measures Enterprise Mitigate Risks Enterprise Use P3 to Measures’Dependant Measures’Dependant Assessment Build Your Framework Assessment develop your Enterprise Target Enterprise Assessment’Dependant Target State Assessment’Dependant 4 MTargetA G StateS I C own XOET. Current CONSTRAINT Target EnterpriseINPUT Phase OUTPUT Motivation DependantCurrent State Target State Motivation Current State Target State Enterprise M A G I C M A G I C Enterprise Adoption Dependant IMPACT Dependant Motivation’ ASSESSMENT Motivation’ Current State EA Project Team: Actions Actions Follow the 5th step in Do I Care? Adoption Adoption POET for maturing your Transformation Guidance capability. v2020 May 09:14 Adoption Step 6 What is the sixth step in Adopting POET? Transitioning Keypoint Rollout Changes Step 6 allows you to rollout your Rollout own XOET Operational Physical World for people to Changes use. v2020 May 09:17 Adoption Step 6 > Actions When Adopting POET, what are the fundamental Actions in Step 6? Step 6 Rollout Changes Keypoint Measures Enterprise Mitigate Risks Use P3 to train Measures’Dependant Your Framework Training your staff in Target Assessment Target State Enterprise 4 Assessment’Dependant MTargetA G StateS I C your own XOET Current CONSTRAINT Target EnterpriseINPUT Phase OUTPUTEnterprise DependantCurrent State DependantTarget State Motivation CurrentM A G StateI C CurrentM A G StateI C IMPACT Enterprise ASSESSMENT Adoption Current State Motivation’Dependant EA Project Team: Install and Setup Tools Actions Follow the 6th step in Re-assess Adoption POET for maturing your Transformation Guidance capability. v2020 May 09:19 Methods Methods What does the Methods section of POET contain? Keypoint The Methods section of POET defines 'WHAT' should be done, 'HOW' and 'WHEN'. Methods Adoption C-Suite: Instigate a review of the Methods used in the Enterprise's Transformation Capability, to determine if their maturity is appropriate. v2020 May 09:22 Methods Phases What are the seven phases of Transformation? Keypoint The seven phases of EnterpriseStrategising transformation (Strategising, Context Contextual Roadmapping, Solutioning, Elaborating, Constructing, Using Roadmapping Transitioning, Using) are connected with the Physical Governance & Lobbying Stuff Conceptual Governance discipline. Lobbying Adoption Transitioning Solutioning Management: Adopt the seven phases of Transformation - Operational Logical Strategising, Roadmapping, Solutioning, Elaborating, Constructing Elaborating Constructing, Transitioning, Physical Using and the Governance & Lobbying discipline that connects them. v2020 May 09:24 Methods Phases > Basics Which Phase constitutes Business Architecture? Keypoint Enterprise Context Governance Business Architecture Direction Lobbying Business Architecture Strategising Governance (verb) Direction feeds Enterprise Contextual Lobbying Enterprise Architecture feeds Architecture Roadmapping Governance (verb) Conceptual Solution Architecture Lobbying Solution Architecture feeds Enterprise Solutioning Governance (verb) Logical Engineering. Lobbying Elaborating Governance Physical Enterprise Adoption Lobbying Engineering Transformation Transformation Constructing (verb) Management: Ensure Governance Operational everyone in the Lobbying Transitioning Governance Enterprise understands Physical World which phases are part Lobbying Using Operation Governance of BA, EA, SA and Operation Enterprise Engineering. v2020 May 09:27 Methods Phases > Resource Utilisation What is the general split of resource required to perform Architecture vs Engineering? 0.5% Architecture Keypoint BA Strategising 1% 99.9% of Enterprises are happy to spend money on 5% EA Roadmapping improving Engineering, but are very reticent to 12% spend money on SA Solutioning improving Architecture. Engineering Elaborating Adoption 76% Management: Constructing Assign more Engineering resources to Transitioning improving 5% Architecture. v2020 May 09:29 Methods Phases > Strategising What kind of work goes on in the Strategising phase? Enterprise Context Strategising Keypoint Strategising (aka Business Architecture) Contextual Strategising Roadmapping Conceptual Sometimes called Business is what the C- Solutioning or Enterprise Strategy Suite does. Logical Elaborating e.g. Value Propositions, Cost Adoption Physical Management: Ensure Constructing Structure, Revenue Streams, everyone in the Operational Partners, Channels, etc, Enterprise Transitioning Mission, Vision, Strategies, understands what the Physical Stuff term Strategising Tactics, Goals and Objectives refers to. v2020 May 09:32 Methods Phases > Roadmapping What kind of work goes on in the Roadmapping phase? Enterprise Context Roadmapping Keypoint Strategising (aka Enterprise Architecture) Roadmapping is Contextual Roadmapping “doing” Sometimes called Annual Conceptual Enterprise Solutioning Business Planning or Architecture. Logical Transition Planning Elaborating Adoption Physical Management: Ensure Constructing Creates a portfolio of projects everyone in the Operational and roadmaps to be initiated Enterprise understands what the Transitioning over the coming year(s) Physical Stuff term Roadmapping refers to. v2020 May 09:34 Methods Phases > Solutioning What kind of work goes on in the Solutioning phase? Enterprise Context Solutioning Strategising (aka Solution Architecture) Keypoint Contextual Solutioning is Roadmapping Conceptual Sometimes called “doing” Solution Solutioning Initiating Architecture. Logical Elaborating e.g. Logical Designs for Adoption Physical Management: Ensure Constructing particular parts of the everyone in the Operational Enterprise focussed on Enterprise understands what the Transitioning particular Business Physical Stuff term Solutioning refers Objectives to. v2020 May 09:37 Methods Phases > Solutioning > A Pragmatic Approach Why should Solution Architecture work be moved out of projects? Traditional Pragmatic Strategising (Business Architecture) Strategising (Business Architecture) Keypoint Current Target Current Target Business Model Business Model Business Model Business Model Do not constrain Current Enterprise Business Motivation Target Enterprise Current Enterprise Business Motivation Target Enterprise Capability Model Model Capability Model Capability Model Model Capability Model Solution Roadmapping (Enterprise Architecture) Roadmapping (Enterprise Architecture) Architecture in Current Intermediate Target Operating Current Intermediate Target Operating Operating Model Operating Models Model Operating Model Operating Models Model executing projects. Transformational Roadmap / Project Portfolio Transformational Roadmap / Project Portfolio 1 2 3 4 1 2 3 4 Project 1 Project 2 Project 3 Project 4 Solutioning (Solution Architecture) Adoption 1 2 3 4 1 2 3 4 Solution Solution Solution Solution Solution Solution Solution Solution Management: Move Architecture Architecture Architecture Architecture Architecture Architecture Architecture Architecture 1.1 1.2 2.1 3.1 4.1 4.2 1.1 1.2 1.2 2.1 3.1 4.1 4.1 4.2 Solution Architecure Conflict Conflict Conflict Conflict Design, Design, Design, Design, Project 1 Project 2 Project 3 work out of individual Build, Build, Build, Build, 1 2 3 Test Test Test Test Design, Build, Design, Build, Design, Build, Test Test Test projects and execute 1.1 1.2 2.1 3.1 4.1 4.2 1.1 1.2 2.1 3.1 4.1 SA as a program. v2020 May 09:39 Methods Phases > Project Execution What kind of work goes on in the Elaborating phase? Enterprise Context Project Execution Keypoint Strategising (aka Design, Build/Test, Deploy) Elaborating, Contextual Roadmapping Constructing and Sometimes called Engineering
Recommended publications
  • Applying the Cynefin Sense-Awareness Framework to Develop a Systems Engineering Method Diagnostic Assessment Model (SEMDAM)

    Applying the Cynefin Sense-Awareness Framework to Develop a Systems Engineering Method Diagnostic Assessment Model (SEMDAM)

    Applying the Cynefin Sense-Awareness Framework to Develop a Systems Engineering Method Diagnostic Assessment Model (SEMDAM) by Russell L. Gilbertson Bachelor of Electrical Engineering, June 1983, University of Minnesota Master of Business Administration, December 1985, Rensselaer Polytechnic Institute A Dissertation submitted to The Faculty of The School of Engineering and Applied Science of the George Washington University in partial fulfilment of the requirements for the degree of Doctor of Philosophy January 19, 2018 Dissertation directed by Bereket Tanju Professorial Lecturer in Engineering Management and Systems Engineering and Timothy Eveleigh Professorial Lecturer in Engineering Management and Systems Engineering The School of Engineering and Applied Science of The George Washington University certifies that Russell L. Gilbertson has passed the Final Examination for the degree of Doctor of Philosophy as of October 24, 2017. This is the final and approved form of the dissertation. Applying the Cynefin Sense-Awareness Framework to Develop a Systems Engineering Method Diagnostic Assessment Model (SEMDAM) Dissertation Research Committee Bereket Tanju, Professorial Lecturer in Engineering Management and Systems Engineering, Dissertation Co-Director Timothy Eveleigh, Professorial Lecturer in Engineering Management and Systems Engineering, Dissertation Co-Director Shahram Sarkani, Professor of Engineering Management and Systems Engineering, Committee Member Thomas Mazzuchi, Professor of Engineering Management and Systems Engineering & of Decision Sciences, Committee Member Amir Etemadi, Assistant Professor of Engineering and Applied Science, Committee Member ii Dedication I wish to dedicate this work to my wife, Ms. Debra Daniels who supported me throughout this endeavor and my mother, Ms. Sandra J. Gilbertson, who passed away before I completed this work, but inspired me to always keep learning.
  • Business Architecture: Setting the Record Straight

    Business Architecture: Setting the Record Straight

    BUSINESS ARCHITECTURE: SETTING THE RECORD STRAIGHT By William Ulrich and Whynde Kuehn This is a Reprint of Chapter 2, Part 1, of Business and Dynamic Change: The Arrival of Business Architecture, Published by Future Strategies, Inc. © 2015, but revised January 2019 http://BusinessandDynamicChange.com COPYRIGHT © 2019 BUSINESS ARCHITECTURE ASSOCIATES 1 BUSINESS ARCHITECTURE: SETTING THE RECORD STRAIGHT BUSINESS ARCHITECTURE: SETTING THE RECORD STRAIGHT William Ulrich, TSG, Inc. and BAA, Inc., USA Whynde Kuehn, S2E Transformation Inc. and BAA, Inc., USA An Introduction to Business Architecture Business architecture is drawing significant interest from a wide variety of organizations worldwide. Yet business architecture is often misperceived as to its uses, origins, and value proposition. These misperceptions are the biggest barrier to adoption, because it prevents businesses in many cases from getting a business architecture effort off the ground, and undercuts sponsorship and business engagement. Business architecture is not a buzzword or a quick fix solution for a broken process, a computer system, or a single project or business unit. It is a holistic discipline that is most effective when applied across business units, practices, disciplines, and stakeholders. The discussion that follows lays out a number of fundamental business archi- tecture concepts. This includes an overview, beneficiaries, common myths, core and extended perspectives, interdisciplinary alignment, governance, get- ting started, and a vision for the future. Business Architecture: What Is It? Formally defined, business architecture represents holistic, multidimensional business views of: capabilities, end-to-end value delivery, information, and or- ganizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders.2.(1) It is an ab- stract set of standardized perspectives that represent a given business ecosys- tem.
  • General Guide

    General Guide

    Praxeme Institute Guide PxM-02en “Modus: the methodology Praxeme” General Guide Objective This document lays down the foundations of Praxeme, an enterprise methodology. It addresses those who are interested in, who appraise and develop enterprises and their IT assets. It presents the basic principles and concepts that structure this open method. Contents . The foundation: “The structuring principles”, “The notion of “service”” . The products . The processes . Modeling guidelines Author Dominique VAUQUIER Translators Carolin CHAI, Nigel STRANG, Dominique VAUQUIER, Joanne TOWARD Version 1.99.1, 27 November 2010 Reference : PxM02en-gGen.docx Version : 1.99.1 Date : 27 November 2010 [email protected] Praxeme Institute 21, chemin des Sapins – 93160 NOISY-LE-GRAND – France +33 (0)6 77 62 31 75 Modus: the methodology Praxeme Configuration Elements The position of this module in the methodology The methodology Praxeme is based on and structured by the “aspects” and the Situation in the Enterprise System Topology. The general guide (PxM-02) explains this approach. documentation PxM-41 is an addition to the guide for the logical aspect (PxM-40). Figure PxM-02en_1. Structure of the Praxeme corpus in the “Product” dimension Owner The Praxeme methodology results from the initiative for an open method. The main participants are the enterprises SAGEM and SMABTP, and the French army1. They combined their forces to found a public „open‟ method. The Praxeme Institute maintains and develops this joint asset. Any suggestions or change requests are welcome (please address them to the author). Availability This document is available on the Praxeme website and can be used if the conditions defined on the next page are respected.
  • Enterprise Architecture Techniques for SAP Customers

    Enterprise Architecture Techniques for SAP Customers

    October 2007 Enterprise Architecture Techniques for SAP Customers by Derek Prior Enterprise architecture has rapidly matured in recent years as a business-driven technique to provide companies with the big picture needed to optimize long-term IT investments. Some of the leading SAP customers have been quietly deploying enterprise architecture techniques to transform their business and prepare for SOA. Why haven’t you? Enterprise Strategies Report Acronyms and Initialisms ADM Architecture development method ERP Enterprise resource planning BPM Business process management ISV Independent software vendor CMDB Configuration management database ITIL IT infrastructure library CRM Customer relationship management PPM Project portfolio management DMTF Distributed Management Task Force SOA Service-oriented architecture EA Enterprise architecture TOGAF The Open Group Architecture Framework EAF Enterprise architecture framework © Copyright 2007 by AMR Research, Inc. AMR Research® is a registered trademark of AMR Research, Inc. No portion of this report may be reproduced in whole or in part without the prior written permission of AMR Research. Any written materials are protected by United States copyright laws and international treaty provisions. AMR Research offers no specific guarantee regarding the accuracy or completeness of the information presented, but the professional staff of AMR Research makes every reasonable effort to present the most reliable information available to it and to meet or exceed any applicable industry standards. AMR Research is not a registered investment advisor, and it is not the intent of this document to recommend specific companies for investment, acquisition, or other financial considerations. This is printed on 100% post-consumer recycled fiber. It is manufactured entirely with wind-generated electricity and in accordance with a Forest Stewardship Council (FSC) pilot program that certifies products made with high percentages of post-consumer reclaimed materials.
  • CMMN Modeling of the Risk Management Process Extended Abstract

    CMMN Modeling of the Risk Management Process Extended Abstract

    CMMN modeling of the risk management process Extended abstract Tiago Barros Ferreira Instituto Superior Técnico [email protected] ABSTRACT Enterprise Risk Management (ERM) is thus a very important activity to support the Risk management is a development activity and achievement of the organizations' goals. increasingly plays a crucial role in Risk management is defined as “coordinated organization´s management. Being very activities to direct and control an organization valuable for organizations, they develop and with regard to risk” [1]. ERM, as a risk implement enterprise risk management management activity, comprises the strategies that improve their business model identification of the potential events in the whole and bring them better results. Enterprise risk organization that can affect the objectives, the management strategies are based on the respective risk appetite, and thus, with implementation of a risk management process reasonable assurance, the fulfillment of the and supporting structure. Together, this process organization's goals [2]. and structure form a framework. ISO 31000 Many organizations nowadays have their standard is currently the main global reference risk management framework, including framework for risk management, proposing the activities to identify their risks, and their general principles and guidelines for risk prevention measures, documented. To this end, management, regardless of context. The most [1] is at this moment the main reference for risk recent revision of the standard ISO 31000:2018 management frameworks, proposing the [1] depicts the process of risk management as general principles and guidelines for risk a case rather than a sequential process. To that management, regardless of their context.
  • Linking Business Models with Business Architecture to Drive Innovation

    Linking Business Models with Business Architecture to Drive Innovation

    Linking Business Models with Business Architecture to Drive Innovation Linking Business Models with Business Architecture to Drive Innovation A Business Architecture Guild Whitepaper Principal Co-Authors: Steve DuPont, Karen Erwin, Bryan Lail, Stephen Marshall Reviewers: Remco Blom, Frank Fons, William Ulrich, Wilton Wratten, Carl Zuhl August 2015 1 Copyright ©2015 Business Architecture Guild Linking Business Models with Business Architecture to Drive Innovation Executive Summary A business model describes the rationale of how an organization creates, delivers, and captures value.1 Organizations are expanding their innovation focus from products and processes to business models in order to remain competitive in the face of shrinking product lifecycles and growing market uncertainties. They are increasingly embracing the business model concept in strategic planning, accompanied by a greater focus on customers and corresponding value propositions. In a parallel development, organizations are using business architecture to provide increased business transparency and maximize the likelihood of an effective and successful deployment of strategy. Business architecture is defined as “a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands.”2 Despite the natural progression from business models (as an expression of business strategy) to business architecture (as the actionable blueprint for that strategy), these two concepts have evolved separately. To date, limited consideration has been given as to how they relate to each other. This white paper aims to address that gap, by demonstrating that the two approaches not only relate to each other but also work well together to effect change. We further expand on this synergy with a practical case study.
  • Cynefin, Statistics and Decision Analysis

    Cynefin, Statistics and Decision Analysis

    Cynefin, Statistics and Decision Analysis Simon French Manchester Business School University of Manchester Manchester, M15 6PB [email protected] April 2011 Abstract David Snowden‟s Cynefin framework, introduced to articulate discussions of sense-making, knowledge management and organisational learning, also has much to offer discussion of statistical inference and decision analysis. In this paper, I explore its value particularly in its ability to help recognise which analytic and modelling methodologies are most likely to offer appropriate support in a given context. I also use the framework to offer a further perspective on the relationship between scenario thinking and decision analysis in supporting decision makers. Keywords: Cynefin; Bayesian statistics; decision analysis; decision support systems; knowledge management; scenarios; scientific induction; sense-making; statistical inference. 1 Introduction Several years back David Snowden visited Manchester Business School and gave a seminar on knowledge management. At this he described his conceptual framework, Cynefin, which, among other things, offers a categorisation of decision contexts (Snowden 2002). At first I thought this said little if anything more than many other ways of categorising decisions, such as the strategy pyramid stemming from Simon (1960) and beyond Simon back to the prehistory of military theory: viz. strategic, tactical and operational (see Figure 2 below). However, a colleague, Carmen Niculae, had more insight and working with her and others, I have since come to realise Cynefin‟s power to articulate discussions of inference and decision making. In the following, I want to explore the ideas underlying Cynefin and their import for thinking about statistics and decision analysis. There is nothing dramatic in anything I shall say.
  • Deliverable D7.5: Standards and Methodologies Big Data Guidance

    Deliverable D7.5: Standards and Methodologies Big Data Guidance

    Project acronym: BYTE Project title: Big data roadmap and cross-disciplinarY community for addressing socieTal Externalities Grant number: 619551 Programme: Seventh Framework Programme for ICT Objective: ICT-2013.4.2 Scalable data analytics Contract type: Co-ordination and Support Action Start date of project: 01 March 2014 Duration: 36 months Website: www.byte-project.eu Deliverable D7.5: Standards and methodologies big data guidance Author(s): Jarl Magnusson, DNV GL AS Erik Stensrud, DNV GL AS Tore Hartvigsen, DNV GL AS Lorenzo Bigagli, National Research Council of Italy Dissemination level: Public Deliverable type: Final Version: 1.1 Submission date: 26 July 2017 Table of Contents Preface ......................................................................................................................................... 3 Task 7.5 Description ............................................................................................................... 3 Executive summary ..................................................................................................................... 4 1 Introduction ......................................................................................................................... 5 2 Big Data Standards Organizations ...................................................................................... 6 3 Big Data Standards ............................................................................................................. 8 4 Big Data Quality Standards .............................................................................................
  • A Quick Guide to Responsive Web Development Using Bootstrap 3

    A Quick Guide to Responsive Web Development Using Bootstrap 3

    STEP BY STEP BOOTSTRAP 3: A QUICK GUIDE TO RESPONSIVE WEB DEVELOPMENT USING BOOTSTRAP 3 Author: Riwanto Megosinarso Number of Pages: 236 pages Published Date: 22 May 2014 Publisher: Createspace Independent Publishing Platform Publication Country: United States Language: English ISBN: 9781499655629 DOWNLOAD: STEP BY STEP BOOTSTRAP 3: A QUICK GUIDE TO RESPONSIVE WEB DEVELOPMENT USING BOOTSTRAP 3 Step by Step Bootstrap 3: A Quick Guide to Responsive Web Development Using Bootstrap 3 PDF Book Written by a team of noted teaching experts led by award-winning Texas-based author Dr. Today we knowthat many other factors in?uence the well- functioning of a computer system. Rossi, M. Answers to selected exercises and a list of commonly used words are provided at the back of the book. He demonstrates how the most dynamic and effective people - from CEOs to film-makers to software entrepreneurs - deploy them. The chapters in this volume illustrate how learning scientists, assessment experts, learning technologists, and domain experts can work together in an integrated effort to develop learning environments centered on challenge-based instruction, with major support from technology. This continues to be the only book that brings together all of the steps involved in communicating findings based on multivariate analysis - finding data, creating variables, estimating statistical models, calculating overall effects, organizing ideas, designing tables and charts, and writing prose - in a single volume. Step by Step Bootstrap 3: A Quick Guide to Responsive Web Development Using Bootstrap 3 Writer The Dreams Our Stuff is Made Of: How Science Fiction conquered the WorldAdvance Praise ""What a treasure house is this book.
  • The Process Architect: the Smart Role in Business Process Management

    The Process Architect: the Smart Role in Business Process Management

    Redpaper Roland Peisl The Process Architect: The Smart Role in Business Process Management This IBM® Redpaper™ publication describes the concept of business process management (BPM) and specifically focuses on the role of the process architect within BPM. This paper covers in detail how to design business processes and how to enhance those processes for automated business process execution on a BPM platform. It addresses the requirements to successfully drive BPM programs in terms of what process knowledge, methodology, and technology needs to exist or be developed within an organization. Within the context of this paper, the process architect is defined as having the responsibility to model, analyze, deploy, monitor, and continuously improve business processes. This paper defines the role of the process architect as the driver of creating and improving processes and as a key bridge between business and process focused technology. This paper is intended for anyone who is involved in creating and improving BPM within an organization. © Copyright IBM Corp. 2009, 2012. All rights reserved. ibm.com/redbooks 1 Introduction Today, organizations that are facing aggressive market challenges share focus. To be more agile and to react faster to market changes, they must understand business processes better and in more detail. Business processes represent the organization’s key assets. The way a company invents, provides, and controls its core products and services depends on its core business processes. How well these processes can be managed and adapted to market changes is critical and more important than ever. Knowing business processes in detail requires further investigation. People from lines of businesses and from IT must understand the details of their business or IT capabilities.
  • Business Architecture a Balance of Approaches to Implementation

    Business Architecture a Balance of Approaches to Implementation

    Business Architecture A Balance of Approaches to Implementation Business Architecture Innovation Summit – June 2013 Presenter: Andrew Sommers Implementing Business Architecture at Capital Group Positioning Communicating Measuring Integrating 2 Measuring – What is the value of Business Architecture? Useful information, but starting a discussion of Business Architecture from here was challenging 3 Measuring – What is the Value of Business Architecture? If we have a successful Business Architecture practice, what are we able to do in 5 years that we cannot do now? Some ideas: • Provide a consistent method to directly link business objectives and drivers to the features that are required in our operating model, business processes, and technology solutions. • Provide a consistent enterprise view of the organization to quickly understand the entire impact of a business proposal. • Provide a consistent enterprise view of the organization to teams for analysis, planning, risk management, and support. • Improve our ability to leverage people, process, technology and information solutions for the same capability across the organization. • … But, what is it worth? 4 Positioning –Business Architecture in Our Organizational Model Placement is traditionally discussed in terms of our organizational chart Business Lead Management Services Investment Operations Technology Services Enterprise Architecture, Strategy, and Planning Equity Order Application Processing Services Solution Fixed Income Architecture Infrastructure Order Processing Business Architecture
  • Holistic Layer of the Enterprise Architecture on the Basis of Process-Driven Organization

    Holistic Layer of the Enterprise Architecture on the Basis of Process-Driven Organization

    Complex Systems Informatics and Modeling Quarterly CSIMQ, Article 65, Issue 11, June/July 2017, Pages 69–84 Published online by RTU Press, https://csimq-journals.rtu.lv https://doi.org/10.7250/csimq.2017-11.04 ISSN: 2255-9922 online Holistic Layer of the Enterprise Architecture on the Basis of Process-Driven Organization Stepan Alexa1* and Vaclav Repa1 1 Department of Information Technologies (FIS), University of Economics in Prague W. Churchill Sq. 1938/4, 130 67 Prague 3 - Žižkov, Czech Republic [email protected], [email protected] Abstract. Growing complexity of the enterprise ecosystem along with the existence of legacy approaches in the organization can result in a number of challenges when maintaining the solid baseline of its information assets. The digital industry has, over past two decades, passed through rapid evolution triggered both by availability of new technologies, and business as well as operating and funding models. These enablers have direct impact on the way that organizations design and execute their business processes in order to maintain the alignment between their capabilities and targets. This trend implies that enterprises and organizations need to remain flexible by maintaining the alignment of their business and their infrastructure in a dynamically changing and integrated ecosystem. It has been widely recognized that the enterprise architecture as well as the process driven approaches provide tools used by organizations to explain how business, resources and other elements within the organization are related to each other. This article discusses the role, and associated value, that the enterprise architecture and process driven approach have when describing what constitutes the enterprise.