Book extracts: An Enterprise Architecture Development Framework

An Enterprise Architecture Development Framework The Enterprise Reference Maps, Single Page Architecture, Metamodel SOA Design, Business Case and Strategic Planning for your Enterprise 3rd Edition Office Factory/ Warehouse Desktop Router Router Desktop Notebook LAN Services Notebook LAN Services Printer Email Print Server File Email Print Customers File Server Printer Server Server ServerServer /Agents ISDN IP/MPLS Call Service Data Center Phone PBX Center Provider Intranet IVR CTI Server Voice Router Servers 3 C Call Centre workstation Recording Floor Switch Core Router Content Switch Border Mng Email Print Border Manager Mainframe Wallboard Server Server Server Server Shifttrack Server File Server CITRIX Farm Servers AA Remote Access Shop WS xDSL VPN RouterLoadB Firewall Workstation Internet FW RouterLoadB Web Printer Firewall ServerFW Adrian Grigoriu practicing architecture for a very long time

© Copyright 2005-2009 by Adrian Grigoriu The copyright for any material created by the author is reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic, mechanical, including photocopying, recording, or by any information storage and retrieval system, except in case of reviews, without the express written permission of the author. 3rd Edition, November 2008 Note for Librarians: A cataloguing record for this book is available from Library and Archives Canada at www.collectionscanada.ca/amicus/index-e.html. ISBN 1-4120-8665-5 Printed in Victoria, BC, Canada 10 9 8 7 6 5 4 3 2 1 ii

“I enjoyed reading this book. It was as if Grigoriu had laid out all the business and IT elements that make up an enterprise on a table and then played around until he could fit them all together into a single cube – an ingenious effort at puzzle solving… I would happily recommend this book to anyone who is already an experienced enterprise architect. This book is an excellent “graduate review” that will force you to think through lots of issues and consider how you might address them in your own architecture. I would also recommend this book to someone who was interested in the issues involved in building a business case for an Enterprise Architecture effort – the sections on benefits and costs are excellent and comprehensive – and I’d also recommend this book to someone who wanted to learn more about how to classify stakeholders. The section on strategy and stakeholders is outstanding”. For the previous edition, Paul Harmon, the Executive Editor of Business Process Trends (www.bptrends.com), a recognized BPM analyst and consultant and the author of Business Process Change.

TABLE OF CONTENTS 1.ABOUT THE BOOK ............................................................................................................................................................ WHY THIS BOOK ........................................................................................................................................................................... 15 OUTLINE ............................................................................................................................................................................................. 17 AUDIENCE ......................................................................................................................................................................................... 25 REVIEW CHECKLIST .................................................................................................................................................................... 26 2.EA PROVIDES A COMPETITIVE EDGE TO THE ENTERPRISE ............................................................................ REVIEW CHECKLIST .................................................................................................................................................................... 29 3.THE PROBLEM AND DRIVERS FOR CHANGE ........................................................................................................ THE PROBLEM ................................................................................................................................................................................ 31 BUSINESS TRENDS...................................................................................................................................................................... 33 BUSINESS NEEDS ......................................................................................................................................................................... 35 WHAT BUSINESS CONSTANTLY REQUIRES FROM IT ............................................................................................. 35 WHAT THE GOVERNMENT SECTOR EXPECTS FROM IT ......................................................................................... 36 REVIEW CHECKLIST .................................................................................................................................................................... 37 4.ENTERPRISE ARCHITECTURE, THE SOLUTION ..................................................................................................... EA, THE SOLUTION TO THE ENTERPRISE PROBLEM................................................................................................. 39 WHAT IS ENTERPRISE ARCHITECTURE (EA) ................................................................................................................. 40 EA definitions Own EA definition REVIEW CHECKLIST .................................................................................................................................................................... 44 5.ENTERPRISE ARCHITECTURE BENEFITS................................................................................................................. GOVERNANCE BENEFITS (G) .................................................................................................................................................. 45 Enables Business Modelling Improves Decision Making Aligns Technology to Business Processes and Goals Enables Agility, Faster Business Change Enhances Project Planning and Prioritisation Accuracy OPERATIONAL BENEFITS (O) .................................................................................................................................................. 46 Maximises Reuse of Existing Assets Simplifies the Enterprise operation Aligns Organization to Enterprise operation Improves Operating Procedures Enhances Enterprise Processes Enables Activity Based Costing (ABC) Permits Faster New Product introduction Exploits Synergies between similar operations of the Enterprise STRATEGIC BENEFITS (S) ......................................................................................................................................................... 48 Maps Roadmaps to Architecture Facilitates Vendor Products Roadmaps alignment to EA Provides Agility to business change

Enables Outsourcing and Mergers & Acquisitions Improves Risk Management COMMUNICATION, COLLABORATION AND COMPLIANCE BENEFITS (C) ...................................................... 48 Improves Stakeholders’ Understanding and Communication Enhances Working with Suppliers and Partners Makes Regulatory Compliance possible REVIEW CHECKLIST ..................................................................................................................................................................... 49 6.THE BUSINESS CASE AND RETURN ON EA (ROEA) ........................................................................................... HOW DO YOU ‘COST-JUSTIFY’ ARCHITECTURE ........................................................................................................... 51 RETURN ON ENTERPRISE ARCHITECTURE (ROEA) .................................................................................................... 52 KEY BENEFITS INDICATORS TABLE ..................................................................................................................................... 53 QUANTIFYING THE COSTS AND REVENUE RELATIVE TO THE NON EA CASE ............................................. 56 THE EA DEVELOPMENT REVENUE AND COST CURVES .......................................................................................... 58 EA PAYBACK AND NPV ............................................................................................................................................................. 59 REVIEW CHECKLIST ..................................................................................................................................................................... 61 7.TECHNOLOGIES REFERRED TO, SUPPORTING THE EA ..................................................................................... 63 WEB SERVICES (WS) AND XML ........................................................................................................................................... 63 ENTERPRISE INTEGRATION EAI/ESB ................................................................................................................................. 63 ENTERPRISE RESOURCE PLANNING (ERP) .................................................................................................................... 64 IT INFORMATION LIBRARY (ITIL) ........................................................................................................................................... 64 CONTROL OBJECTIVES FOR INFORMATION (COBIT) AND VAL IT ...................................................................... 65 BUSINESS PROCESS MANAGEMENT (BPM) ................................................................................................................. 66 SIX/LEAN SIGMA .......................................................................................................................................................................... 67 CAPABILITY MATURITY MODEL (CMM) ........................................................................................................................... 68 BUSINESS PROCESS REPRESENTATION ......................................................................................................................... 68 PORTER'S VALUE CHAINS ........................................................................................................................................................ 70 BALANCED SCORECARD .......................................................................................................................................................... 71 COMPLIANCE (SOX, BASEL II. HIPAA…) ............................................................................................................................. 71 AGILE PROCESSES AND SMART DELIVERIES ................................................................................................................ 71 REVIEW CHECKLIST ..................................................................................................................................................................... 72 8.EA FRAMEWORKS AND CLASSIFICATION ............................................................................................................. EA FRAMEWORKS OVERVIEW .............................................................................................................................................. 73 Zachman's EAP, Spewak's FEA Reference Model DODAF TOGAF Other: NGOSS/eTOM, PERA, E2AF, BPTrends EA Pyramid… AN EA FRAMEWORKS CLASSIFICATION .......................................................................................................................... 82 REVIEW CHECKLIST ..................................................................................................................................................................... 83 4

9.THE FUNCTION-FLOW-LAYER-VIEW (FFLV) FRAMEWORK DESIGN ............................................................. 85 AN EA FRAMEWORK DEFINITION ....................................................................................................................................... 85 EA FRAMEWORK IN ANALOGY TO THE HUMAN BODY ......................................................................................... 86 EA FRAMEWORK ENTITIES ..................................................................................................................................................... 87 THIS FRAMEWORK DESCRIPTION AND COMPONENTS ........................................................................................ 89 THE EA DESIGN APPROACH, IN SHORT ........................................................................................................................... 90 ENTERPRISE CONTEXT, STAKEHOLDERS' INTERACTIONS/USE CASES ....................................................... 91 THE BUSINESS FUNCTIONS.................................................................................................................................................... 92 THE BUSINESS FLOWS ............................................................................................................................................................. 93 Customer’s View of the Enterprise Owner's View of the Enterprise THE FUNCTIONAL ARCHITECTURE: FLOWS OVER FUNCTIONS......................................................................... 94 THE EA RESOURCE LAYERS: TECHNOLOGY AND PEOPLE .................................................................................... 95 A Function Stack consists of Business, Technology and People A Flow is executed by a sequence of Function Stacks EA LAYER SPECIFIC VIEWS ..................................................................................................................................................... 98 Business Layer Views: processes & orchestration, strategy & objectives Technology Layer Views People Layer Views: organization, culture, communications… ENTERPRISE WIDE VIEWS: INFORMATION, SECURITY, PERFORMANCE, FINANCE… ......................... 101 The Information Architecture The Security View The Location (Where) View The Performance View The Planning and Evolution View The Financial View ARCHITECTURE PRINCIPLES ............................................................................................................................................... 105 Decoupling/Modularisation Encapsulation Layering Hierarchical design Distribution agnostic Standardisation Duplication minimization TECHNOLOGY DESIGN STANDARDS .............................................................................................................................. 106 Design on SOA services with ESB and Web Services Employ Container/Application hosting technology (JAVA, .NET, Portal) Virtualise technology Converge data, voice and video networks Deploy Web interactive access for stakeholders Reuse, Buy or Build REVIEW CHECKLIST ................................................................................................................................................................. 107 10.ENTERPRISE REFERENCE MAPS AND ORGANIZATION DESIGN ............................................................... 109 ORGANIZATION DESIGN......................................................................................................................................................... 109 5

BUSINESS AND OPERATING MODEL, VALUE CHAIN ............................................................................................ 110 Business Models Operating Models Value Chains THE ENTERPRISE GODS MAP............................................................................................................................................. 113 THE IT EA TEMPLATE ............................................................................................................................................................. 114 THE BUSINESS (FUNCTIONS) REFERENCE MAP ..................................................................................................... 116 THE BUSINESS FLOWS REFERENCE MAP .................................................................................................................. 117 THE ENTERPRISE GROUP LINE OF BUSINESSES ..................................................................................................... 119 TERMINOLOGY OF BUSINESS ARCHITECTURE ........................................................................................................ 120 THE APPLICATIONS REFERENCE MAP .......................................................................................................................... 120 THE INFORMATION REFERENCE MAP ........................................................................................................................... 120 THE INFRASTRUCTURE REFERENCE MAP ................................................................................................................. 121 MAPPING REFERENCE MODELS TO ORGANIZATION ........................................................................................... 125 REVIEW CHECKLIST ................................................................................................................................................................. 127 11.EA PATTERNS AND SINGLE PAGE ARCHITECTURE................................................................................ 129 ENTERPRISE ARCHITECTURE PATTERNS ................................................................................................................... 129 Business Layer Application Layer Infrastructure Layer THE SINGLE PAGE ENTERPRISE ARCHITECTURE (SPEA).................................................................................... 132 REVIEW CHECKLIST ................................................................................................................................................................. 135 12.THE FFLV FRAMEWORK AND NAVIGATION ....................................................................................................... THE EA FUNCTION-FLOW-LAYER-VIEW, FFLV FRAMEWORK ........................................................................... 137 THE THREE DIMENSIONS OF THE FFLV FRAMEWORK ........................................................................................ 139 THE FFLV FRAMEWORK TREE .......................................................................................................................................... 139 THE KEY FFLV VIEWS .............................................................................................................................................................. 140 THE FFLV FRAMEWORK METAMODEL ......................................................................................................................... 141 THE FFLV FRAMEWORK NAVIGATION ......................................................................................................................... 144 A CUSTOMER'S REQUEST NAVIGATION SCENARIO .............................................................................................. 145 THE FFLV MAPPING TO OTHER FRAMEWORKS ..................................................................................................... 147 Mapping to Zachman Mapping to the four "standard" EA layers Mapping to DODAF REVIEW CHECKLIST ................................................................................................................................................................. 150 13.THE ENTERPRISE WIDE IT ARCHITECTURE ............................................................................................... 151 THE ROLE OF IT ........................................................................................................................................................................... 151 BUSINESS DRIVERS FOR IT.................................................................................................................................................. 152 KEY IT PROJECTS ..................................................................................................................................................................... 153 SOLUTION ARCHITECTURE ALIGNMENT TO EA ....................................................................................................... 155 6

APPLICATIONS INVENTORY ................................................................................................................................................. 159 INTEGRATION ARCHITECTURE ........................................................................................................................................... 161 IT OBSOLESCENCE AND EA ROADMAP ........................................................................................................................ 161 THE EA VERSUS ITIL, BPM, SIX SIGMA, ERP, ITIL… .................................................................................................. 162 REVIEW CHECKLIST ................................................................................................................................................................. 164 14.SERVICE ORIENTED ARCHITECTURE - SOA ......................................................................................................... WHAT IS SOA OR WOA FOR THAT MATTER.............................................................................................................. 165 SOA BENEFITS ............................................................................................................................................................................. 167 SOA AND BPM ............................................................................................................................................................................ 169 SOA AND EA ................................................................................................................................................................................. 170 SOA + EA = SOEA....................................................................................................................................................................... 170 SOA, TO DO OR TO BUY .......................................................................................................................................................... 171 SOA DESIGN BEST PRACTICES .......................................................................................................................................... 172 EVOLUTION TO SOA .................................................................................................................................................................. 174 SOA, LESSONS LEARNT ......................................................................................................................................................... 175 REVIEW CHECKLIST ................................................................................................................................................................. 176 15.STRATEGIC PLANNING AND ENTERPRISE TRANSFORMATION ................................................................ 177 DO ENVIRONMENT ANALYSIS: PESTEL, PORTER'S 5 FORCES ........................................................................ 179 PESTEL Porter's Five Forces DO COMPANY ANALYSIS ...................................................................................................................................................... 181 DO STAKEHOLDERS' ANALYSIS ........................................................................................................................................ 181 OUTLINE ENTERPRISE VISION, GOALS AND TARGETS ......................................................................................... 182 SPECIFY STRATEGIES .............................................................................................................................................................. 182 BALANCE BENEFITS BETWEEN STAKEHOLDERS ................................................................................................... 183 CHECK STRATEGIES FOR FEASIBILITY, ACCEPTABILITY, SUITABILITY......................................................... 184 CASCADE STRATEGY PLANNING TO THE EA TREE ................................................................................................ 185 SPECIFY THE STRATEGIC EXECUTION ROADMAP & MAPPING ...................................................................... 185 REVIEW CHECKLIST ................................................................................................................................................................. 189 16.THE EA DEVELOPMENT PROCESS AND BEST PRACTICES .......................................................................... WHAT IS THE VALUE OF BEST PRACTICES ................................................................................................................ 191 DEFINE EA MISSION AND DELIVERIES ........................................................................................................................... 192 CAPTURE STAKEHOLDERS’ REQUIREMENTS, DETERMINE SCOPE .............................................................. 192 BUILD THE BUSINESS CASE FOR ENTERPRISE ARCHITECTURE .................................................................... 192 GET SUPPORT FROM TOP LEVEL MANAGEMENT & BUSINESS ..................................................................... 193 BUILD THE EA GOVERNANCE TEAM ............................................................................................................................... 193 NOMINATE THE EA CORE AND VIRTUAL TEAM ....................................................................................................... 193 SPECIFY AN ENTERPRISE ARCHITECTURE FRAMEWORK ................................................................................. 194 7

SELECT AN EA TOOL SET TO SUPPORT THE FRAMEWORK ............................................................................. 194 OUTLINE A DESIGN STRATEGY .......................................................................................................................................... 195 Bottom-Up discovery of existing technology and model ERP processes Design SOA in the middle to wrap Applications as Business Services Apply Architecture and Design Principles SPECIFY AN EA EXECUTION STRATEGY ....................................................................................................................... 196 Prioritize to deliver the urgent fixes for the Enterprise Leverage existing applications and infrastructure Work with Suppliers to package applications as SOA services Design, Plan and Implement iteratively Use an Agile Processes (AP) approach Establish SMART Deliveries, CSFs, KPIs Agree Best Practices DESIGN THE BUSINESS FUNCTIONS AND FLOWS ARCHITECTURE ............................................................ 198 DISCOVER AS-IS USING THE BUSINESS REFERENCE MAP AND FRAMEWORK LAYERS ................ 199 CASCADE STRATEGY OBJECTIVES AND INITIATIVES TO EA TREE ................................................................ 199 SKETCH THE TARGET ENTERPRISE STATE ................................................................................................................. 199 ASSESS GAP BETWEEN CURRENT AND TARGET STATES, ESTABLISH ROADMAP ........................... 200 ESTABLISH PROJECT PORTFOLIO AND PROGRAM PLAN ................................................................................. 200 ESTABLISH EA OPERATIONAL GOVERNANCE ........................................................................................................... 200 EXECUTE ENTERPRISE TRANSFORMATION ITERATION AND EVALUATE EA MATURITY ................. 200 REVIEW CHECKLIST ................................................................................................................................................................. 200 17.AN EA DESIGN EXERCISE ........................................................................................................................................... THE DESIGN PROCESS STEPS............................................................................................................................................ 201 AN EA DEVELOPMENT EXERCISE OR VIRTUAL CASE STUDY .......................................................................... 202 Specify Enterprise Mission & Products, Vision, Strategy and Objectives Document Stakeholders' Interactions and internal requirements Design the Business Functions Map Design stakeholders' scenarios as Flows over Functions Draft the Single Page Architecture Specify the Applications executing processes in Functions Draw the Infrastructure aligned to Applications Map Information entities to Functions Map Organization units to Functions Link all Views in the EA framework Specify Target Objectives and Vision for the Enterprise Design the target EA, employ SOA paradigm Assess gaps and devise the Transformation roadmap and program INSTEAD OF CASE STUDIES ................................................................................................................................................ 214 REVIEW CHECKLIST ................................................................................................................................................................. 215 18.FRAMEWORK USE CASES FOR M&A, OUTSOURCING. ITIL.......................................................................... 217 EA FRAMEWORK USE FOR INVESTMENT ................................................................................................................... 217 EA FRAMEWORK FOR IT SERVICES MANAGEMENT (ITIL) ARCHITECTURE ............................................. 218 8

EA FRAMEWORK FOR SECURITY ARCHITECTURE ................................................................................................. 219 HOW TO DESIGN YOUR ENTERPRISE AROUND THE CUSTOMER ................................................................. 220 EA FRAMEWORK USE FOR MERGERS AND ACQUISITIONS ............................................................................. 221 EA FRAMEWORK USE FOR OUTSOURCING................................................................................................................ 222 EA FRAMEWORK USE FOR A START-UP BUSINESS .............................................................................................. 223 REVIEW CHECKLIST ................................................................................................................................................................. 224 19.THE EA GOVERNANCE, PROGRAM AND THE ARCHITECT ROLE ................................................................ 225 EA GOVERNANCE....................................................................................................................................................................... 225 THE EA PROJECT ORGANIZATION AND FUNDING ................................................................................................. 227 AN EA SITE TAXONOMY ......................................................................................................................................................... 228 THE ROLE OF THE ENTERPRISE ARCHITECT .............................................................................................................. 229 Enterprise Architect kinds How does one select an Enterprise Architect The job description for an Enterprise Architect The Tasks and authority of the Enterprise Architect Enterprise Architect as a leader The growth of EA jobs REVIEW CHECKLIST ................................................................................................................................................................. 239 20.EA MATURITY, VALUE AND SELL ............................................................................................................................ MEASURE YOUR ENTERPRISE ARCHITECTURE MATURITY .............................................................................. 241 EA development maturity EA exploitation maturity MEASURE THE VALUE OF EA .............................................................................................................................................. 243 SELL THE EA ................................................................................................................................................................................. 245 REVIEW CHECKLIST ................................................................................................................................................................. 246 21.EA ROADBLOCKS, CULTURE AND POLITICS....................................................................................................... EA DEVELOPMENT TRIGGERS ............................................................................................................................................ 247 EA ROADBLOCKS ....................................................................................................................................................................... 248 The Enterprise Inertia, silo organization and the Business - IT divide The lack of reference Business Architectures The diversity and non-coordinated approaches to fix the Enterprise evils EA vague definition, is it a blueprint, process, program, strategic planning…? EA scope, no non-IT technology, no people or other stakeholders' views The EA program developed solely by IT Lack of an agreed EA framework Overly simplified EA framework Lack of Business Case at initiation EA deliverables not fit for purpose EA governance and implementation failures Enterprise Architect not invested with authority Politics slowing EA development Independent SOA programs competing for resources ERP development competing with EA 9

Not using EA tools The vast knowledge required and paucity of Enterprise Architects Roadblocks recap and recommendations ENTERPRISE CULTURE AND EA ........................................................................................................................................ 258 EA POLITICS .................................................................................................................................................................................. 261 EA RISKS AND CHANGE MANAGEMENT ..................................................................................................................... 263 REVIEW CHECKLIST ................................................................................................................................................................. 264 22.EA STATE, FUTURE OUTLOOK AND THE VIRTUAL ENTERPRISE ....................................................... 265 EA CURRENT STATE ................................................................................................................................................................ 265 THE VIRTUAL ENTERPRISE .................................................................................................................................................. 267 The Virtualization of the Enterprise IT The Virtualization of the Enterprise Architecture (EA) Layers The Enterprise Value Chain modelling and Virtualisation THE FUTURE OUTLOOK FOR EA ........................................................................................................................................ 275 REVIEW CHECKLIST ................................................................................................................................................................. 276 23.ENTERPRISE ARCHITECTURE RECAP .................................................................................................................... THE EA FRAMEWORK RECAP ............................................................................................................................................ 277 THE KEY STEPS OF AN EA DEVELOPMENT ............................................................................................................... 278 THE EA DELIVERIES CHECKLIST ........................................................................................................................................ 280 WHY USE THE FFLV FRAMEWORK ................................................................................................................................ 282 EA STAKEHOLDERS' BENEFITS REVIEW ....................................................................................................................... 283 THE ENTERPRISE TRANSFORMATION STRATEGIC PROCESS ......................................................................... 284 FINAL SAY...................................................................................................................................................................................... 286 REVIEW CHECKLIST ................................................................................................................................................................. 286 24.REFERENCES ................................................................................................................................................................... ACRONYMS ............................................................................................................................................................................ INDEX ........................................................................................................................................................................................ ABOUT THE AUTHOR ........................................................................................................................................................... 10

Chapter 2 1. EA provides a competitive edge to the Enterprise Due to the growing complexity of technology, the daily increase in the amount of information and the ever fastening pace of change and competition, the very existence of many Enterprises will be challenged in the next few years. Ray Kurzweil states that every ten years the rate of change doubles; in the next hundred years we may experience the same amount of change as in the past 20,000 yearsi. Historically, companies built products, deployed services and structured the organization rapidly in response to market demand and new regulations. This was achieved through point solutions, patching and silo organizations, all at the expense of an increasing complexity of a “spaghetti” like architecture, fostering duplication in functions, data, platforms, processes and projects. The unnecessary complexity slows down business change, the decision making process and fosters longer time to market which ultimately increases the costs of operations. At today’s pace of change, to conquer the soaring complexity, to deliver faster and better and be sustainable the Enterprise has to be: A. Streamlined: simplified to minimize unjustified variety, reduce unnecessary complexity, remove silos and improve focus B. Aligned: technology (IT) and people (organization) resources aligned to business processes and strategy to achieve the firm objectives C. Agile: modular, layered, standardized, technology independent, built out of services, quickly to adapt to change D. Built to last: strategically planned according to business and technology trends and vision E. Documented: a blueprint to document the current and target architecture to enhance comprehension and management of its performance.

To repair a car, the mechanic has to know its blueprint and, based on it, its operation. To design a car or improve it the firm needs to understand where technologies and markets go. The mechanic has to become a planner, a marketing man, a business man. Same with the Enterprise Architect. An EA will integrate in a single effort many fragmented or loose coupled Enterprise developments such as SOA, IT Architecture, Application Integration (EAI), ITIL efforts and many independently performed activities such as Enterprise alignment to Business Strategy and Objectives, Enterprise Simplification, Compliance to Regulation Frameworks, Business Process Improvement, Six/Lean Sigma, Business Performance Management, Mergers and Acquisitions, Integration and outsourcing (such as BPO, SaaS…). What will be the role of the Enterprise Architecture (EA) in the Enterprise evolution in the decade to come? How can an Enterprise operate in a predictable manner, change fast enough to lead or at least swiftly follow the market and offer high quality products at the same time, without the modular structure and blueprint of an Enterprise Architecture? For the next decade, there is little chance for a legacy Enterprise to survive the accelerating change, the ever reducing time to market, increasing customer expectations, the industry consolidation and outsourcing trends without a clean, streamlined, optimized and documented operation. The EA is an asset which, once in place and properly maintained, will return value for many years (RoEA) since the investment in EA can be leveraged over and over again to pay back dividends. EA is the knowledge database of your Enterprise. The EA asset promises you a Competitive Advantage by streamlining your Enterprise, enabling faster product delivery at lower costs, handling the exploding amount of information and providing greater Enterprise agility to cope with change. Conservative quotes from different industries vary between 10-30% reduction in cost and time to market due to EA. The hypothesis and conclusion of the book is that the EA will offer the Enterprise the edge needed in the survival race through blueprinting, streamlining, roadmapping and agility. The US now requires government departments to provide their Enterprise Architecture to justify investments. Your shareholders will demand the EA soon in order to increase the guarantees of their return of investment. 12

Chapter 2: EA provides a competitive edge to the Enterprise Review checklist 1. What is the hypothesis of the book? What do we want to prove? 2. What are key benefits of the EA? 3. What developments does EA integrate in a single effort? 4. Why is the EA indispensable to the Enterprise for the decade to come? 13

Chapter 3 2. The Problem and Drivers for Change The Problem Remember how many times you have spoken to a large organization providing you a service, only to discover that they still have your previous address, where some of their correspondence is still sent, as well as having your current address. This is because for each service there is a platform which retains your personal data. A change in address often has to be operated in many platforms, at the same time, and sometimes manually, which is slow and error prone. In fact, duplicated data is created for each platform. On occasion, as a customer, you need to identify yourself several times to get a service from a company. This is because each service owns its data and requires its own authorization since there is no cross platform authentication and authorization service. The current state of the Enterprise as seen by Zachman: “Enterprises have a large inventory of current systems built out-of-context, not integrated, not supporting the Enterprise, that are consuming enormous amounts of resources for maintenance and are far too costly to replace; as a matter of fact, the inventory of existing systems has come to be referred to as ‘the legacy’”ii. Enterprises met many challenges in arriving at their current structure. Many have been through a rapid customer growth and technology changes which fuelled an organic growth, based often on one-off, point solutions. Shortening timelines for new products, and immediate priorities to minimize CAPEX and OPEX, resulted in a silo culture where, quite often, each part of an organization cares only for its own products, budgets, applications and technology. The Enterprise, as a result, is made of patched legacy with multiple and various solutions for same or similar capabilities. The current state of the Enterprise requires simplification since it has grown

complex, after many mergers and acquisitions. The complexity makes applications patching impossible. Adding new point solutions, re-using little from the existing capabilities, can only make things worse. Can we call this Enterprise manageable, predictably delivering quality to customers and value to shareholders? And the cost of running this Enterprise is growing higher and higher with the level of complexity increased by mergers, point solutions and patching. The divide between business and IT departments is frequently deep since there is no common vocabulary, skills to facilitate communication and shared objectives to align efforts. Business understands processes, rules, markets and products. IT people specialize in IT support, maintenance, helpdesk and software development. Usually, business inflexibility is associated either with the IT or with the organization which is changed ever so often. It does not matter how much emphasis is set on the Customers' needs, if the products themselves and the operational processes deliver at low quality. This, ultimately, hinders the efforts made by the customer facing units. And the faulty products are the result of faulty processes which require business process improvement using Six/Lean Sigma and BPMS etc. Currently, in an Enterprise, there are so many plans, designs and architectures. Everybody has a drawing: the Supply Chain, the Customer Services department or IT. They do not look alike, they have different vocabularies, entities, conventions and levels of detail, they are drawn with various tools as Word, Visio, Power Point… and they sit everywhere and nowhere when you need them. What do we do? We call a meeting with all domain experts to make a decision. And we just pick their minds during a brainstorm. It's like the architecture is floating in the air, above the expert audience where nobody can see it. And we are not even sure that we are talking about the same thing. By the way, where is the Business Architecture blueprint to be used by IT to align Technology Architecture to business processes? Unfortunately, no Enterprise has been built according to a blueprint, at best it was re-engineered. But we solely let IT provide the Enterprise Architecture. To our relief, the ERP application suites are saving the Enterprise by providing both the business processes and application layers of the Enterprise. More often than not, this comes at the price of inflexibility, poor integration, high cost, dependency on one vendor and poor comprehension of the underlying functionality. EA is more than an ERP. Every Enterprise has a structure, an architecture, and it works, more or less. The 16

Chapter 3: The Problem and Drivers for Change structure is often the result of an organic growth and not the outcome of a deliberate process. Without the synoptic view of an EA, the Enterprise is marred by duplication in platforms, projects, roles, data, applications and even products. Quite often, units of the same company compete with each other and do not share good practices, processes, applications and strategies. From a business perspective, the Enterprise problem is the inflexibility, slow change and high costs of IT. From an IT perspective, it is the lack of business process and requirements clarity, inherited obsolete technologies and the tangled IT spaghetti architecture. The Problem: the silo organization, the point solutions duplicating functionality, the unnecessary complexity and the poor understanding of the Enterprise operation, causing a lengthening of the decision making; not able to implement, quickly enough, the change required by business. The problem lies with the today's unresponding and undocumented Enterprise in a world of growing complexity and change. . Business Trends The next decade is characterized by an ever increasing trend in speed of change, complexity, amount of information and customer expectations, reducing product life cycles and industry consolidation. Often, an Enterprise needs to enter a new line of business or to enhance its product portfolio by acquiring or merging with another company rather than taking the time and absorbing the cost to produce the product in house. Mergers and acquisitions happen so often now because, before an Enterprise can acquire the skill and deliver the product, the window of market opportunity is lost. The new company has to be aligned to the Enterprise. But because companies have overlaps in products and functions, and exceedingly different applications to implement similar processes, a merger may simply fail to bring benefits since there is no common blueprint of operation to deliver a single service proposition to customers and cost reduction, from economies of scale, to owners. On the other hand, the opposite result could occur; customers are confused by offers of similar but slightly different products and technologies, employee’s motivation may suffer from internal competition and potential redundancies and the share price may drop until the confidence is restored, that is, when the new products are integrated and the Enterprise is streamlined again. But there are numerous issues with acquisitions, for instance alignment of organizations, IT infrastructure, applications 17

and in general Customer Relationship, Supply Chain and all the Enterprise Support functions. Not to mention different strategies, cultures and values. It is hard to understand how it is done without a common blueprint, provided by the EA. The current best practice is to align the organizations' charts. Outsourcing and managed services are also one of the strongest trends in any industry now. They are essentially about work division. Nowadays we can do very few things well, at the level of quality expected by customers. Companies outsource functions which do not align to the perceived core business activities. Interestingly although companies pretend, more and more, to be customer oriented, they outsource Customer Care functions such as Call Centers. But what functions in the Enterprise should we outsource? Should we outsource operations? It happens, often off-shored. Before making the decision you need to determine in detail the services to be provided to your Enterprise and their present Total Cost of Ownership (TCO). Is there a context, a blueprint to help us make our outsourcing decisions? Can the Enterprise be certified against quality frameworks (CMM, Six Sigma)? This may be a trigger for initiating an EA program, besides acquisitions and outsourcing as these maturity and quality frameworks require business process optimization. Six Sigma, Capability Maturity Model (CMM) and recent regulations and auditing procedures as Sarbanes-Oxley, Basel II … demand a structured, well understood, managed business process architecture, data architecture, security and privacy controls, accompanied by proper document and financial management systems, all in the scope of an Enterprise Architecture. The business process and information flows modeling offer a framework for auditing and compliance to regulatory requirements like Sarbanes-Oxley. There are numerous external and internal forces that lead towards the development of an Enterprise Architecture: 1. Business management need for direct control of change of the Enterprise, IT and investment process; for a long time now, business users have struggled to obtain the IT support they need to deliver process change for flexibility 2. The need for Enterprise simplification and integration of point solutions and silo organizations due to the current state of organic growth and patching 3. Increasing customer demand and expectations for quality, growing raw material and energy prices forcing companies to deliver new levels of scalability, quality, cost efficiency and performance 18

Chapter 3: The Problem and Drivers for Change 4. Rising worldwide business competition manifesting in o Rapidly reducing lifecycles/Time to Market o Increasing consolidation trend through mergers and acquisitions as the cost of developing new products in house is growing o Rising trend for outsourcing of Business Process (BPO) , applications (SaaS), data centers and managed services o increasing request for modular, service based business architecture (SOA) and growing popularity for web services to increase business agility 5. Drive for quality frameworks (Six Sigma, CMM) and new regulatory compliance (SOX, Basel II, HIPAA…) demanding documented and auditable structures and processes 6. EA, becoming a regulatory requirement in the US: the Clinger-Cohen Act of 1996 for Federal Agencies mandates the EA. Business needs Of course, a business has to return value to all its stakeholders: owners, employees, community... But what are the main categories of issues a business always has to have in perspective, what are the business needs in this day and age? 1. Differentiate products for customers' benefit, and establish business models to create a continuous competitive advantage to increase profit for your shareholders/owners (Financial view). 2. Increase agility to be able to respond quickly enough to market changes (Operational view) 3. Streamline and architect current Operations to enhance effectiveness and reduce costs (Operational view) 4. Automate as much as possible, reduce redundancies in functions, processes, platforms and projects, reduce the tangled architecture, document current business functionality and implementation to get in control of your business. 5. Build the Enterprise to last (Strategic view) 6. Analyze trends (industry, economical, social, political and regulatory, technological) and plan your strategy and business models accordingly (market segments, products, costs, new technology capabilities). 7. Improve Corporate Social Responsibility (Community and Regulatory view) 19

What business constantly requires from IT 1. Technology alignment to business and strategy intentions 2. Customer self service 3. Customer/Employee/Partner Reduced/Single (Reduced) Sign On 4. “Single Customer View:” a real time operational response to customer data request to return all personal data, subscription, interaction history… , 5. “Single Version of Truth”: only one source of data for reporting, Business Intelligence and ultimately decision making 6. Straight Through Processing: process automation, document imaging and character recognition to reduce human error and processing time 7. Agility to change, access security, data privacy… 8. Reduce IT costs and investment What the Government sector expects from IT In short, a collection of issues the government agencies are confronted with at this stage in time: 1. Joined-up government, inter-working & information sharing between departments 2. Common services and infrastructure across government 3. Government portal and intranet, authentication/authorization/Id Mng service … 4. Information systems to respond faster to business change 5. Efficiency & customer focus through business process re-engineering 6. Electronic delivery of services, E-business to business 7. Usage of communication and cooperation technologies such as Web2 (2 way Web) As such, the Government demands a streamlined operation with reduced duplication and improved processes, common inter-departmental shared resources, cross boundary services and electronic services delivered over the Internet, using the latest Web2.0 communication technologies. Ultimately, the book intends to prove that the Enterprise problems and trends can all be acted upon in coordination in an Enterprise Architecture to defeat the 20

Chapter 3: The Problem and Drivers for Change increasingly threatening enemies of the Enterprise: growing competition, rate of change, complexity and ultimately the increasing entropy of the Enterprise. Review checklist 1. Which are the key issues with the Enterprise today? What is the "problem"? 2. State a few important business trends. 3. Describe the main business drivers and the business requirements from IT. 4. What are the Government drivers? 21

Chapter 11 3. EA Patterns and Single Page Architecture EA layers are built on few simple patterns: Nodes, Lines, Rules and Plans. The metamodel describes the relationships between EA entities observing patterns. The Single Page Architecture is an overall single page view of the Enterprise. Enterprise Architecture patterns EA layers are built on few simple patterns: Nodes, Lines, Rules and Plans. Business Layer The Nodes are implemented by Processes in Business Functions; the Lines by Flows of control (events), information (documents) or parts. Application Layer The Nodes are implemented by Applications. Lines by information exchanges over middleware such as EAI. A Service sub-layer is introduced by a SOA/EA development. Nodes are implemented by Services while Lines by Requests in SOAP/XML, REST Web Services and ESB messaging. Infrastructure Layer Is composed of two sub-layers: Servers & Storage and Networks. Server and Storage sub-layer Nodes are implemented by Servers and Storage units. Lines by TCP/IP transport protocols and respectively SCSI and Fiber Channel links.. Servers: ♦ SW side:

o Application Servers (Java EE, .Net) o DB Servers (Relational, XML, Object, Hierarchical… DBMSs) o Web Servers (+ Server Pages) o Network File Servers, Printer Servers o Audio/Video Servers o Email, Chat, FTP, telnet… ♦ SW servers interconnection protocols o JMS, RMI, SMTP, SNMP, FTP, Telnet… ♦ HW side o Windows, UNIX. LINUX…, Hypervisor (virtualization) o on Blades, rack drawers, mainframes, AS/400… ♦ HW servers interconnections: o Sockets, TCP/IP Storage sub-layer nodes o DAS: Direct Attached Storage o NAS: Network Attached Storage o SAN: Storage Area Network (RAIDx) ♦ Storage interconnections o iSCSI o Fiber Channel (FC) o Networks ♦ LAN (Local Area Network) implemented mainly by Ethernet Hub switches ♦ WAN nodes implemented by Switches, Routers, Gateways, DNSs…over fiber (Dark Wave, SONET…) and copper ( Tx/Ex, xDSL) transmission networks 26

Nodes & Lines patterns and Technologies at each EA layer Nodes Lines Nodes Layers Process Process Business Flow Service Service Req/Resp (ESB, WS SOAP/XML, REST) Applications Application (ERP, CRM…) Application Information Exchange/EAI, CORBA Infrastructure DAS, NAS, SAN DAS, NAS, SAN Storage (i)SCSI, Fibre Channel (FC) & SW side: Application, DB, Web…) Figure 11-1 – EA patterns: Nodes and Lines at each layer Chapter 11: EA Patterns and Single Page Architecture Servers JMS, MQ… HW side HW Serv Sockets, UDP,TCP/IP protocols Networks Switch, Routers Gateways, DNS… WAN MPLS ,ATM, FR, Copper Hubs, Bridges Hubs, Bridges LAN Ethernet 27

The Single Page Enterprise Architecture (SPEA) The Single Page Enterprise Architecture is a diagram (see diagrams at end of chapter) providing a synoptic view of an Enterprise operation, describing the key business functions and the interconnections channeling key flows; it shows a reduced view of a functional Architecture (all Flows over Functions) depicting solely key business functions and flows. It looks like an application integration architecture with applications exchanging information over pipes. The applications (systems), the Functions they map to, the flows and stakeholders are represented in subsequent EA views. SPEA is structured on the Business Functions Map. As the Business Flows Map is discovered and designed, entities are added to the Single Page EA. SPEA is the most popular EA artifact. It is used by everybody to understand the Enterprise operation and communicate in the same language. It remains, in some cases, the only Enterprise Architecture artifact. It addresses the whole Enterprise audience and should be designed with a largely available drawing tool since most people must have access to it. It is similar to the Operational View 2 (OV-2) in DODAF that shows nodes (Functions here) and needlines (Flows). Since SPEA represents the logic operation of the Enterprise, the level of detail has to stop to a couple of levels below a Line of Business (LoB). Frequently, an Enterprise consists of a few Lines of Business, each delivering a product. Further detail going beyond level 2, can be provided by a specific business Function architecture and be referenced from the parent Function in the SPEA. A couple of samples of Single Page EAs are shown in the following. Support functions are typically not shown, for simplification. In the Single Page EA diagram: a box is a Business Function which is a subdivision of a Line of Business. ♦ A Line of Business is an area of the enterprise delivering a specific service or product ♦ A line is an information/material/control flow; an arrow ending a line shows the destination of the flow. 28

29 Direct Mail House Insurance System Banks Campaign Figure 11-2 - A Health Insurance Single Page Architecture- IT template Managmnt Membrship Product Claims Bank Gway Payment Face 2 Face EFTPOS Claims/ Bank 1 3rd Parties Contact Mng Benefits Provider Rate Config Cheque Service Refunds/ Customer Premium Providers Payments Member Service Billing Member Claims Chapter 11: EA Patterns and Single Page Architecture Centre Center Gway HIC B2B Gway Prospects ContactMg Eligibility Authorise Claims Hospital Phone Call Customers IVR Centre (Batch) Gway Access Premium Medical DB Bus Corporate Call Center Retail Access B2B Gway Corporate Autoclaims Access ID Claims Mng (Real Time) Tranfer Web www.xxx.com. Pre supplier admission Payment Provider Premium Access Payment Payment Banks Content Intranet Manag Payment Post Office Paymaster Revenue Management Cheque Cash Group Real Time Replica Finance Apps Balance Register Balancing Balancing Reports ETL Score- ReInsurance GL AP/AR AM Card Batch Reports Government DW Claims Community BI

Review checklist 1. What are the EA main patterns? 2. How do they map on each EA layer entities? 3. What is a metamodel? 4. What are the key artifacts of the metamodel? 5. Explain the key relationships between entities of the metamodel artifacts? 6. What is the Single Page Enterprise Architecture (SPEA)? 7. What are the main SPEA components? 30

Chapter 12 4. The FFLV Framework and navigation The EA reference maps/templates supply a generic structure for an Enterprise. It should be used to jump start the EA development efforts. A framework is the backbone, the frame of a system to which most parts are fitted. An EA framework looks like a contents page, a mindmap or a document tree with all components of the EA having to hook onto the framework. It does not define the architecture of the components, but solely the frame joining them, exhibiting component placeholders. It enforces reuse of components, an interface philosophy, design constraints and notations and architectural principles to provide consistency in design so that artifacts fit back into the framework. The EA Function-Flow-Layer-View, FFLV Framework The EA framework consists of business Functions, Flows and Layers (Business, Functions, B Technology and People) described by Views Views. The FFLV framework proposes an EA meta-architecture consisting of a Flows over Functions functional architecture - shaped by a Business Reference Map - executed by the Technology and/or People resource Layers with Views describing various layer specific or Enterprise wide stakeholders' concerns.

Functions Flows Development D Layers Governance G Views Support S O Operations Products/Lines Business Technology People The FFLV Enterprise Architecture Framework Figure 12-3 - The Function-Flow-Layer-View (FFLV) EA Framework An extended business Function can be seen as a stack traversing the EA layers. The business processes. the technology and people resource layers, belong to the Function stack. To that, one might add strategy, objectives, performance criteria etc, all cascaded to the Function stack entities. In a Flow diagram, any line between Functions or to stakeholders can be described in terms of an output of a process (Product) which can be a part, information (bill, order, message) or event and a connection (Line) which is its transport, implemented by a network, a mechanical transport band or courier. The framework could initially be implemented with a minimum of flows describing the customer’s services, two or three levels of Functions in a hierarchical decomposition and a minimum number of Views. As the framework is open, Functions, Flows and Views can be added at later times. There are also the 4th dimension, “Time” and the 5th, the detail or level of granularity. 32

Chapter 12: The FFLV Framework and navigation The three dimensions of the FFLV Framework The FFLV Framework specifies three dimensions: Functions, Flows and Layers/Views. A swimlane functional architecture diagram shows business Flows consisting of processes executed by Functions/participants in lanes. The Layers/Views dimension exhibits the executing resources view. Flows Layers /Views Functions Layers, Views Functions A B w w F lo Flo Business Technology People Flows Another dimension is the hierarchical functional decomposition granularity level Figure 12-4 - The 3 EA framework dimensions: Function. Flow, Layer/View The FFLV Framework Tree The EA design and analysis is hierarchical; a specific level of detail could be chosen for analysis, depending on stakeholder's interest. An Enterprise can be seen as a hierarchy of Functions structured in an Enterprise tree i.e. the Business Functions Map; it can be also seen as an Enterprise hierarchy of Flows (Business Flows Map); and also categorized in a number of Layers: Business, Technology and 33

People or Organization, each and every one of them further described by Views filtering only the aspects of interest to you. Hence, the entry points into the EA navigation framework and tree are the Functions, Flows, Layers and Views. This tree can and should be devised for the Enterprise Architecture. It also guides the sitemap of the EA web site which may also contain other information business, technology or people related such as strategy… Enterprise Functions Flows Layers & Views Levels Process Technology People 1 G O D S Views 2 Plan Strt SCM CRM HR Pay Click on an Line Click on a View… Connection Output/ Product Process S Technology Flow People Figure 12-5 - The Enterprise Framework Tree The Key FFLV Views The Business Reference Map (BRM) provides the initial structure for all EA views, including the Single Page EA. The Business Functions Map may be shaped by the BRM Enterprise reference map. The key Views were selected to minimize the effort to design the first iteration of 34

Chapter 12: The FFLV Framework and navigation an EA. They are the Context (Stakeholders' interactions), the Business Functions Map, the Business Flows, The Organization chart and the Technology (IT Applications, Servers and Storage and Networks) architectures. People Organization Technology Networks Unit 1 L1 Org Servers and Storage L1 Org Unit 2 Business Applications OU1.1 L2 Information Node2 L2 OU2.1 Node5 Business Flows Server2 Server5 Qantas Airline Associated Node1 L2 OU1.2 2 Node4 App5 Services Business Functions Map Subject Area Cluster Subject Area 1 App2 Server1 Server Market Sales Sell Customer Service Customer Deliver/Operate Holidays Context View Context ViewApp1 Entity 1.1 Entity 2.1 Entity 2.2 Marketing Management Qantas Airl ine Service Management Relationship Management Ground Operations In-flight Service Associated Context View Market Sell Service Virtual L1 Org Unit 3 App4 Services & Maintenance Deliver/Operate Catering Develop Enterprise Holidays Node3 Marketing /Plan Sales Customer Service Functions Customer Ground Srver1 Deliv er/Operate In-flight Single Page Architecture Management Management Relationship Management Operations L2 OU3.1 Service Engineering Product Yield Reservations Operations Environment Analysis Entity 1.2 Server3 Business Reference Map App3 Develop Campaign Management Development Customers Acquisition Management QF Int ranet Customer Cent res Ticketing Enterprise Contact Centre Customer Service Entity 2.3 Check-in Entity 2.4 Node6 Boarding Gates Fli ght s Di spl ay Logistics Pax S ervices I -Fli ght S ervice Catering Freight /Plan Delivery Channels Schedule Functions Virtual Freight Management /Front Tier L2 OU3.2 Airline Product Reservations Srver2 Operations Brand Market Segmentat ion Mngment Yield Bags S ervices App6 Sales CRM Development Management Ticketing Logistics Engineering/ Crew Management Subject Area 3 Node7 Freight Maintenance Operations Utility Functions Schedule Management Server7 Manage Lounge Fleet Planning Product Development Planning & Payment Content Mngement ... Business Flows User I dentification Entity 3.1 Crew Comms/ Loyalty Negotiation Management Crew Management App7 Performance Engineering/ Maintenance Pax Yield Reservat ions Ticketi ng Depart ure Comms Opti misat ion Management Mngment Management Corporate Group Services Market & Planning & Negotiation Payment Make & Entity & Sell 3.2 Crew Comms/ Performance Loyalty Management CEO Office Group Services Risk & Assurance Inventory Mngment Security Safety OpS ched & Di srupti on BI & Fl ight Planni ng Finance Property Forecast Deliver Service Reporting Control:IOC Legal Schedule Schedule/GDI Development Dist ribution Corporate Report ing Warehouse Group Services Enterprise IT Fuel Procurement Payroll People ... Make/ Revenue Payment Load Accounti ng Mngment Control Communi Management cations Crew Bi ddi ng CEO Office Legal Corporate Business Logic Risk & Assurance Security Safety BI & Reporting Finance Meal Orderi ng Property Crew # Work Planning CrewPlanning Crew Source/B2B Long Range Pl Patt ern/Pairing Rostering Tracki ng Enterprise IT Fuel Procurement Payroll People ... Communi Management cations Developmnt Governance Fuel Planning Support Crew Perform Mngment Services Agreements Negotiat ion Corporate Services Crew Comms Airlines Comms Figure 12-6 - Key FFLV Views, Business Reference Map & Single Page EA The FFLV Framework Metamodel Largely, a metamodel describes the structure of a system. The EA metamodel illustrates the types of EA artifacts, their components and relationships. It is imperative to be implemented in an EA tool since the metamodel is the DB schema of the repository of the EA framework in the tool database. The Enterprise can be depicted as a Black Box with surrounding stakeholders’ interactions described by business Flows. The Black Box is decomposed as either a hierarchy of Business Functions or Organizational units. A map linking the 35

Functions to organizational units should exist, and it is important for the organization alignment to business and technology. Business Flows contain entities such as processes, interconnections, information exchanged, events and participants (in swimlanes). A sequence flow between two processes can represent an information item, event or a physical part transported over a connection. A swimlane in a Flow diagram represents a Function in the Business Functions Map diagram. As such, processes become part of Business Functions. Resources such as People, Applications and Infrastructure, show a relationship to the process they execute. A Function, as the basic unit of the Enterprise, is related to the Applications and People groups or roles it is executed by. Hence resources executing the processes - such as organization roles and applications – may appear in a lane. At the business level, an Information Architecture Model exists, in fact a taxonomy of Enterprise key Information Items. At the resource level, the physical or electronic documents with data schemas, described in the Data Model are implementing the Business Information Model. Process sequence flows are implemented by applications interconnections. All objects in the diagrams are stored in the tool repository with relationships as in the metamodel for enabling navigation between EA artifacts. More relationships and components could be added to the basic metamodel from new EA architecture artifacts. 36

Chapter 12: The FFLV Framework and navigation The FFLV Framework Navigation One may choose to see the whole picture of the Enterprise or a department, a Function, a View, a Line (connection). One may navigate horizontally along a Flow or vertically over a Function to inspect the process and resources involved, such as people, applications and supporting technology. EA Selection EA entities As-Is As- Functions Governance To-Be To- Flows (from…to) Operations (from… Roadmap Layers&Views Development Support HR Finance … D s ion at S Op er O G Business Technology People Click on a Function, Flow, View/Layer, Line Figure 12-7 - The FFLV Framework Navigation Cube from menu bar The FFLV framework representation constitutes the Graphical User Interface (GUI) to the EA artifacts with direct entries to the EA tree elements: Functions, Flows, Layers and Views, for selection. The navigation is initiated by clicking on the graphical image components (Function, Flow, Layer or View. For horizontal navigation you need to click on a product/line. Navigation can also be performed with Up/Down, Back and Home buttons. 37

EA Selection EA Entities As-Is As- To-Be To- Roadmap D Layers&Views Business Security Technology S O Planning People Organization G Location Security Culture Information Planning Comms Business Technology Finance Location Values… People Information Finance For navigation, select the Function, Flow, Layer/Views from the Drop-Down Menu Drop- or click directly on a Function, Flow or Layer/View on the FFLV framework. Click on a Function, Flow, View/Layer, Line Figure 12-8 - The FFLV Framework Navigation Cube with side menus From a tool perspective, a View, is the graphical representation of all objects in a repository that have been selected to have a specific attribute value, chosen from the EA GUI. A mouse click on a menu or cube GUI generates an SQL statement selecting a combination of objects and interconnections from the repository, assembled as a diagram by the tool. Ideally, once a View or a group of Views is selected for display and visually edited, the tool should be able to retain the visual configuration and re-create the diagram on subsequent selections; a first time editing will allow diagram shaping and configuration. A Customer's request navigation scenario The following figure illustrates how to trace a customer's interaction flow and navigate to the layers of applications and infrastructure implementing it. 38

39 EA Selection EA Entities As-Is To-Be Roadmap Organisation Servers and Storage Servers and Storage L1 Networks Org Unit 1 L1 Org Unit 2 Server2 Server5 Server Cluster Applications OU1.1 L2 4a 2b Server1 Server5 Information Server22a 3 4 5 Applications 2 L2 OU2.1 Virtual Business Server1Node2 Server Cluster Node5 Q antas Airline Associated Services Srver1 Chapter 12: The FFLV Framework and navigation App5 Business Functions Map L2 OU1.2 Server3 Market Sell Service Flows App5 Deliver/Operat e Subject Area View 1 ContextNode1 App2 Subject Area 2 & Maintenance Holidays Sales App2 Custom er Custom er 4a Management Service Ground In-flight Context Marketing Virtual Managem ent Relationship Operations Ser vice Virtual Entity 2.1 Node4 2.2 Unit 3 Q ant as Airline Management Associated ContextApp1 1.1 1 View Entity Entity App1 App4 L1 Org Srver1 Services Srver2 Engineering Market Sell Service Deliver/Operate Catering App4 Figure 12-9 – The basic EA navigation screen Develop Enterprise /Plan Functions Holidays Marketing Sales Management Customer Server3 Service Management Customer Relationship Management Ground Operations In-flight Service 2a Server7 Entity 2.3 EntityOU3.1 Virtual L2 Product Yield Reser vations Operations Management Node3 Entity 1.2 2.4 App3 Developm ent Ticketing Logistics Freight Freight Develop App3 Enterprise Catering Airline /Plan Schedule Functions Srver2 Node6 Managem ent Product Development Yield Management Reservations Ticketing Cr ew Managem ent Business Flows OU3.2 App6 Operations Logistics L2 Server7 Freight Engineering/ Maintenance App6 Schedule Management Subject Area 3 ... Q antas Airline Planning & Negotiation Pay m ent Management ... Crew Management Entity 3.1 2 App7 3 1 Node7 Crew Com ms/ Per form ance Engineering/ Loyalty App7 Maintenance Corporate G roup Services Planning & Payment Crew Comms/ Loyalty 4 Group Services 3.2 Entity Negotiation Performance Management CEO Office Risk & Security Safety BI & Finance Property Assurance Reporting Legal Corporate Enterpr ise IT Fuel Group Services Procurem ent Pay roll People ... Management Com m uni cations CEO Office Legal Risk & Assurance Security Corporate Safety BI & Reporting 5 Finance Property Enterprise IT Fuel Procurement Payroll People Communi ... Management cations A Customer’s Request Navigation Scenario

The FFLV mapping to other frameworks The FFLV framework covers: ♦ Zachman's designer and implementer perspectives: as Business and Technology layers respectively ♦ the What and the How perspectives of Zachman: the Functions and Flows in FFLV ♦ EAP and TOGAF like layers: Business, Information, Applications and Infrastructure ♦ People and Organization layer (the Who) (TEAF, PERA …) ♦ Views, aspects of interest to Stakeholders as in TOGAF, IFEAD's E2AF ♦ As-Is, To-Be and the Transformation process and Best Practices as in TOGAF, EAP & others ♦ Architecture principles and technology guidelines, as in TOGAF, FEA ♦ Enterprise Strategic Planning as in EAP, TOGAF Both TOGAF and FFLV refer to an EA development process, layers, views, principles. TOGAF does not really put forward a framework structure synthesized as a single graphical representation. TOGAF ADM is similar in approach to the proposed EA development but a comparison is difficult since TOGAF is so plentiful. And, like in OO methods, the FFLV employs UML and Use Cases to describe the interaction with stakeholders. Some other frameworks as MIMOSA, Gartner's … are outside the scope of this book since they are not widely in use or I was not able to collect relevant information. Mapping to Zachman Zachman’s framework from an FFLV point of view: ♦ the What: FFLV business Functions - rather than information What: ♦ the How FFLV Flows, describing the operation of the Enterprise How: ♦ the Where the location View applied at the Enterprise or Function level Where: returning the location of resources ♦ the When EA roadmaps and planned developments When: The FFLV functional architecture maps on Zachman's designer’s logical perspective. 40

Chapter 12: The FFLV Framework and navigation The How: Flows Development The What: Functions s ion at Support er Designer/Engineer’s Views: Op Governance the Technology layer Business Technology People The Who: People layer The Why: Strategy mapping The When: Roadmapping/Planning Views The Where: the Location Views Figure 12-10 - FFLV Framework mapping to Zachman Mapping to the four "standard" EA layers The mapping to Zachman, the early guideline and mapping model for most frameworks, is described in the figure. The Business, Information, Applications and Infrastructure architectures appear in most EA frameworks, as the de facto "standard" four layer architecture. In the FFLV, Business, Applications and Infrastructure are each described by different views relevant to stakeholders rather than by a single architecture diagram. The Information Architecture is a composite Enterprise View as information exists in conceptual form in the business layer, in electronic data versions in the Technology layer or in physical paper copy on your desk.. In addition, FFLV has a People and Organization layer, essential in describing the Enterprise organization and performance in alignment to business processes and technology. 41

Mapping to DODAF DODAF Operational DODAF System Function-Flow-Layer-View Viewpoint Viewpoint (FFLV) OV-2 Operational Nodes Business Functions Map Interconnectivity Model diagram OV-5 Operational Activity SV-4 System Business Flows Models; SV-4 Model Functions is the implementation flow, in Interconnectivity fact, an OV-5 at the ultimate Model level of detail OV-4 Roles and Org Units People/Organization Chart OV-7 Information Model SV-11 Data Model Information Architecture OV-6a,b,c Business Rules, SV-10a,b,c Business Only applied when behavior State Transitions, Rules, State is required Sequence Transitions, Sequence OV-3 Info Exchanges Matrix SV-6 System Data Result data exchange matrix Exchanges Matrix from Lines summary SV-1 Systems Nodes Applications & Technology Interconnectivity Architecture Figure 12-11 - A comparison between DODAF and FFLV Leaving out, for clarity, the concept (OV-1), the summary (AV-1/2), and standards (TV-1) the remaining artifacts compare well to FFLV. The summary of a potential mapping a minimum DODAF to the FFLV: OV-2 Business Functions Diagrams OV-5 Business Flows Diagrams OV-3 Information exchange generated from Function/Flow models SV-1 Applications Architecture The FFLV Flow diagrams are similar to DoDAF OV-5 or SV-4 views while the FFLV Applications architecture diagrams to DoDAF systems SV-1. The FFLV frameworks enables navigation between Functions, Flows, Layers and 42

Chapter 12: The FFLV Framework and navigation Views at different levels of detail; it unifies most EA frameworks approaches and provides answers to all Zachman's questions. It is structured and synthesized in a graphical framework easy to understand and navigate. The FFLV framework can be utilized to integrate the work you have already done using another framework; it also adds Views for all stakeholders and enables, at the same time, the mapping of processes and applications to the organizational units and people roles. Review checklist 1. What are the dimensions of the FFLV EA framework? 2. Why is the navigation of EA framework important? 3. What is the Enterprise tree? 4. How can the EA framework be navigated? 5. Describe FFLV mapping to Zachman. 6. Write down the mapping to DODAF. 7. What is the mapping to business process maps like SCOR, VRM, eTOM? 43

Chapter 13 5. The Enterprise wide IT Architecture The role of IT It is hard to conceive a business without IT of some sort these days. Overall, IT supports the customer sales, service, access and call center technology, business automation, B2B, data storage, document management, archiving, office automation, complex calculations, communications, collaboration and security. Here is only a draft list of some of the today's Enterprise IT functions: ♦ implement core business and support activities: business logic, ERP, CRM, SCM… ♦ business automation engines replacing repetitive human activities through business process and rules ♦ storage of structured information (customer, product, supplier...) ♦ content management supporting the information lifecycle: creation, transformation, storage, archiving, search, publishing and presentation of documents, media, records... ♦ authentication and authorization of customers, partners and employees ♦ customer presentation and distribution channels: web, email, chat… ♦ automated B2B interaction to suppliers and partners ♦ data and applications integration middleware ♦ powerful calculation tools for complex scientific, forecasting or simulation algorithms ♦ DW/BI/Risk Management tools ♦ office automation, desktop and printing network services

♦ Software development tools ♦ Computer Aided Design (CAD) tools for drawing and design ♦ management of all other IT infrastructure ♦ collaboration, communications, remote access and mobility ♦ security (encryption, digital signatures, firewalling...), load balancing ♦ the infrastructure to support all above: processing servers, disks, RAID..., archiving tapes ... The list is open. Often SW/HW systems are not categorized as IT as for instance: PBXs, SCADA, manufacturing equipment, robots, mobile technology… Since IT has such a high innovation rate, IT is also a major source of innovation. IT is ultimately a key source of competitive advantage in the enterprise or, alternatively, when poorly managed, a source of pain and costs. IT has become a prime object for simplification, alignment to business processes and goals i.e. for Enterprise Architecture. Business drivers for IT Business imperatives like resolving the legacy patched spaghetti Enterprise, coping with customer churn, the increased amount of complexity, information, change and the need to care for the world around have all solutions in IT. The customer data and identity integration demands of a "Single Customer View" may be solved by a data architecture and implementation of Master Data Management (MDM)/Customer Data Integration (CDI) solution. The "Straight Through Processing" may be the target of a business process improvement effort. SOA will provide modularity based on services, thus agility. A Data Warehouse, Business Intelligence and reporting efforts will manage the "Single Version of Truth". They are all, in fact, part of an integrated Enterprise Architecture effort. The table summarizes the five big Business requirements along with their stakeholders and the IT solutions that contribute to their satisfaction. 46

Chapter 13: The Enterprise wide IT Architecture Business Customer Operations Financial Strategic Corp. Social Drivers Satisfaction Streamlining Fitness Strength Responsibility Rationale Increased Point Revenue Increasing Increasing Competition Solutions Growth amount of care for the Cust. Churn Patching Cost Reduct. info, rate of world around Org. Growth change, complexity Business Customer Company Owner Employee, All Community/ Stkehold Environment Business Improve Simplify Prioritize Establish Manage Actions Response Legacy investm. & Competitive Community/ Usability Enterprise reduce Advantage Environment Develop New waste Manage Manage Products & Business Change Compliance Markets Process Manage to Regulatory Improvemen Innovation t Align organization Resulting Single Cust. Fix Spaghetti IT strategy Manage Save the IT View (MDM) Architecture alignment Agility/SOA environment Priorities Cust Portal Straight Thru Single Risk (recycling…) CRM Processing Version of Management Community BPR, CMM, Truth-DW/BI Emerging Involvement Self Service 6/Lean Real Time BI Technologies Sigma Knowledge Virtualization Management Document Management Figure 13-12 - Business Drivers and IT priorities in summary Key IT projects IT technology currently stands many transformations. The mainframe is still there occasionally. Its replacement requires a multi-million, multi-year effort. In some cases, the life time should be extended with SOA services. The legacy of merged companies with multiple products left Enterprises with inconsistent organizations, many portals, different information architectures and various platforms for the same purpose. Business requires a Single (Reduced) Sign On for customers and a Single Front End i.e. the same "Look and Feel" and process for all products and services. Management needs to understand the reality of the business; so reporting based on a Single Version of Truth is key. Data warehousing and Business Intelligence well implemented, become competitive advantages since they help understanding the market and the costs and profits of your own operation. 47

Applications Reference Map Web Web Mobile Delivery Channels Mobile PBX IVR Access /Front Tier Server Server 2.0 Single Cust. Content Sales as a Campaign Mg Front End Product Ctg Content Mng Portal Distribution Sales Service CRM Utility Functions Data Straight Reduced Forecasting MDM BPM-Rules SSL AAA BPM- Messg Document Integration Thru Sign On Imaging Processing Market Make & Sell & & Plan Business App New Business App Deliver Service products Make/ Business Logic Application Integration Middleware Integration Partner B2B SCM Integration Source/B2B SW IDE CAD Decision Enterprise Recruitment Portfolio ERP Travel Making Portfolio Mng Mng Deployment ERP Payroll Training Knowledge Finance GL Knowledge Mng Assets Mg Expenses Procurement DB Single BI DW & Version ITIL IT Operations Helpdesk Development G overnance of Truth CMDB S upport Figure 13-13 – Developments at IT Application layer Document imaging to translate the customer paper application to electronic XML documents are unavoidable. Business Process Automation (Straight Through processing) through BPM orchestration and choreography with partners are a condition for survival in this competitive landscape, since they enable an agile Value Chain. Application and Data integration efforts are a must today. since there are too many applications, each with its design philosophy. Outsourced converged networks (data, voice, video) services become the norm. Virtualized data centers are the latest in fashion: servers, networks and storage are all virtualized. The Data Center is eventually outsourced. Loss of Business Continuity is unacceptable nowadays. Disaster recovery is required by shareholders. 48

Chapter 13: The Enterprise wide IT Architecture Review checklist 1. Explain why IT is indispensable to the Enterprise. 2. What are the business imperatives? 3. What are the typical key IT projects? 4. How are Solutions Architectures aligned to EA? 5. Describe Solution Architectures integration to EA. 6. What are the attributes of the Application Integration table? 7. How do you deal with IT obsolescence? 8. Describe in a few words the relationship of EA to BPM. 9. Describe in a few words the relationship of EA to ITIL. 10. Describe in a few words the relationship of EA to Six Sigma. 49

Chapter 14 6. Service Oriented Architecture - SOA For most business people, SOA looks like yet another over hyped information technology. SOA, which has its roots in a long history of distributed components architecture, is usually associated to Web Services technologies and is typically promoted by IT. But what is SOA? Is it a technology, an architecture, a program or a product? Is it a business or an IT development? What is the rapport to BPM? And what is the relationship to Enterprise Architecture (EA)? After all, both SOA and EA are about the Enterprise and its architecture, with the EA supposed to remedy similar malfunctions of the Enterprise. It is just that SOA appears to attract an even more IT oriented audience than EA. The question is, should we implement SOA and EA, SOA only, EA only? What is SOA or WOA for that matter SOA is primarily about business design and only afterwards about the technology for service integration and discovery. In a wider view, any function of an Enterprise, not necessarily IT, can be defined as a service. The service paradigm has been long applied in our day to day life and even in IT. Not long ago we were attempting to fix the car ourselves or mow the loan. These days, we just employ one of the many services on offer, at a cost we can afford and at a quality we cannot supply any longer. In real life, the technology for service discovery is the Yellow Pages. From a business angle, SOA is a style of business architecture design and, ultimately, a way of re-structuring your business. It enables a Business Oriented Architecture by allowing the business define Enterprise workflows around reusable business services. The granularity of the service is targeted at the business cognizant, rather than at the software application developer.

♦ What is SOA? ♦ SOA is a business oriented style of architecture enabling best of breed, technology agnostic business services, delivered by applications, with a granularity determined by business needs rather than IT ♦ A SOA Service is an interchangeable building block, providing a business service that exposes an interface, hiding the internal implementation technology and published in a service registry for dynamic discovery ♦ SOA is also an integration technology (based on WS: SOAP, UDDI, WSDL and ESB) evolving from distributed component architecture technologies ♦ SOA, W3C definition: "a set of components which can be invoked and whose interface definitions can be published and discovered” ♦ Web Services (WS) are implementing a SOA paradigm over Web protocols. A business service would require definition and enforcement of SLAs to control the quality of the service delivered and the service consumption within defined usage limits. An accounting mechanism should measure the service usage at an SLA for payment purposes. Security is another important aspect of SOA as it regulates access and enforces privacy and integrity of the information exchange in a distributed environment. From an IT point of view, a SOA service is a component providing a service which exposes an interface hiding the internal implementation technology, published in a registry, and eventually, dynamically discovered. Like Object Oriented (OO), SOA provides data and behavior encapsulated in a service, accessible solely through published interfaces. But, as opposed to OO, which addresses the SW development community, SOA aims at services business can understand, and orchestrate to implement end-to-end Enterprise processes. Objects and components like Java Beans and ActiveX are still technology dependent i.e. in the context of the language and platforms, Java EE and .NET, while SOA services are technology transparent executables, in that any technology would do as long as it complies to the messaging and interfacing protocols. A SOA service returns an outcome in response to a request. The service may use other services, transparently, in a layered manner. What is the definition of a layered service? By having a look at networks and their protocols, it is apparent that the concept is not new. In the OSI (Open System Interconnect) networking standard, a layer uses services provided by the layer immediately below, that in turn, employs services in the lower layer, and so on. Similarly, SOA business 52

Chapter 14: Service Oriented Architecture - SOA services use distribution and security services provided by the supporting middleware, which in turn employs services provided by the platform (JavaEE, .Net) and OS infrastructure. As a style of architecture, SOA applies to any system design. At the Enterprise level, the workflows, delivering value to stakeholders, may be built out of services which are technology, supplier, location or owner independent. The Enterprise would ideally consist of a loosely coupled set of business services. Web Services have been implementing the SOA paradigm over Web protocols, for a while now. As a result, SOA is often associated to Web Services and its technologies (SOAP, XML, UDDI, WSDL...). But SOA is more than IT although its origins are in software. SOA + WS gives WOA used for integration of external services, called in some instances, global SOA. WS is a technology only, SOA is a style of architecture while WOA joins the two. WOA is an IT development rather than a business one as SOA: already existing services, accessible on the Web, are integrated to Enterprise processes. WOA brings SOA in the IT realm again. SOA benefits Service Oriented Architecture (SOA) reduces costs through service reuse and, by promoting modularity at service level, it enables the flexibility and agility required to respond to the ever greater pace of change. More often than not, agility and technology reuse are the major benefits associated to SOA. The reality is that SOA, frequently approached outside an Enterprise Architecture context, is developed incrementally, without the benefit of the big picture the Enterprise Architecture delivers. As a consequence, the promised agility and reuse are not achieved or are achieved late, towards the end of the SOAization of your Enterprise when technology reuse may require costly redesign. Nonetheless, there are a few other major SOA benefits, which should be more easily achieved, understood, and accepted. Invoking these advantages would make SOA a joyous sell rather than the often reported stressful experience. SOA benefits: ♦ Agility is the ability to compose your business processes our of independent services in response to market demands; the services themselves can be outsourced to different services providers when necessary and the orchestration can be easily changed by the business expert. 53

♦ Integration: after all SOA enables easy integration of business systems over standard messaging, standard technology (WS, ESB), standard discoverable interfaces. ♦ Documents based communication between various services; an important distinction to OO is the communication with information rich XML documents rather than simple information structures; this increases manifold the communication efficiency and aligns systems integration better to the business style of transactions. ♦ Reuse: SOA is about modularity and reuse; a good service will be called from many applications rather than redesigned or re-implemented in various versions. A "re-entrant" platform capable to sustain many threads is in order. It is worth mentioning though that the Business process reuse is the advantage rather than the IT reuse, since SOA identifies similar business activities and groups them in a service. SOA reduces process replication and, only afterwards, for the same type of process, the application duplication. ♦ Business service accountability, improving business governance Application are usually a bundle of many functions; in practice, a large group of business and IT people will share the responsibilities for the data and behavior of application functions. But can you hold accountable a group of individuals with many other responsibilities, for a specific function? In such an environment, neither accountability nor authority can be assumed for specific functions in an application. On the other hand, for an SOA business service, a single role is being assigned the responsibility: it does not matter if it is an IT or business issue, there is one single point of contact for the service and a service SLA to deliver against. ♦ IT technology virtualization conveyed by SOA services hide the implementation technology and offer a clear, contractual-like interaction between business and IT. IT becomes a service provider, offering business services at a QoS secured by an SLA, well comprehended, quantified, and eventually remunerated by the business through a payback mechanism. This is a major achievement since your applications and technology are hidden behind IT services supplied to the business. From a business perspective, this is what really counts. There is no longer a division between business and IT, but well cut interfaces, SLAs, and contracts. No more blame culture. The separation of concerns pacifies the 54

Chapter 14: Service Oriented Architecture - SOA parties. ♦ Untangling the applications to provide a clean architecture, reducing the side effects of change. There is no more random access through the back door to applications or databases, which makes any change a burden and any modification a major risk because of unforeseeable effects. ♦ Extended lifetime for legacy applications, reducing the pressure to replace them. This is achieved through the encapsulation of legacy behind SOA interfaces. Although there are other increasing costs related to legacy technology, there is no more pressure to replace it; you can do it at own convenience when a viable alternative exists. This is an extension of the technology virtualization benefit. ♦ Enables outsourcing: Software as a Service (SaaS) which is making inroads in the software market, is effectively an outsourced SOA service. SOA and BPM The relationship between SOA and BPM has been the subject of debate. No wonder, since there are different professional groups, magazines or activities to address them. BPM was in vogue in the 90s as BPR, Business Process Reengineering. As a concept, it is the practice of discovering your processes, improving and automating them to reduce human error, Business processes are also a part of the Business layer of the Enterprise Architecture (EA). The Enterprise processes would be described by current and target process architecture parts of As-Is and To-Be EA. Processes are still abstract in that they still have to be performed by humans and/or machines. There are notations and languages to describe business processes. There are models that help in evaluating the maturity of processes and frameworks, such as CMM and Six Sigma, for process improvement. SOA is a style of business process design for the target architecture with processes implemented as an orchestration of loosely coupled SOA services. SOA is an evolution of BPM aiming to hide and encapsulate complexity of processes in independent business services. In SOA, the business workflows will consist of orchestrated SOA services that encapsulate both the process and the technology implementing it. From a technology viewpoint, BPM is offered at the EA business layer, as Business Process and rules design, execution and monitoring engines. Now these are 55

offered as part of an overall SOA proposition, since they provide an orchestration service. On the other hand, SOA is an integration technology based on products as Enterprise Service Buses (ESB), Service Registries, and management tools. But the definition of SOA services is still in the realm of business; services should be specified by business people, since they are not an IT concern or in the IT domain of expertise. This being said, ERPs, embedding and integrating various Enterprise processes, are the products of IT companies. Is an ESB part of SOA? It is not, even if inside an Enterprise, it is definitely helpful, in that it provides a series of services like transparent distribution, reliable messaging. security, transactions, data transformations… that otherwise will fall into the attribution of each and every application. Is orchestration included in SOA? That is orchestration performed in a business process execution language in a business engine. Not really, but it is a good practice, adding to the business agility since it is performed by the business expert graphically and not by IT. SOA and EA Many EA programs are partially happening under the cover of SOA developments. In truth, SOA can be seen solely as the Target EA implementation solution whereby, business functions are specified as services and workflows as orchestration or choreography of services. The SOA only effort ignores though, the initial As-Is discovery phase of an EA development, the requirement to align IT to business goals and the Enterprise strategic planning effort. SOA does cover architecture, but it does not specifically address business process automation, IT alignment to strategy, even if it helps; it does not document the As- Is state like EA does; and it does not provide guidance for the development program as EA methodologies do. SOA requires a large Enterprise process re- engineering and re-design effort, with significant consequences, at process, applications, infrastructure, and people Enterprise Architecture layers. Services will be reused, access will be enforced by SLA contracts, and a new SOA services governance will be in use affecting the existing organization and applications suites. SOA harbors under its umbrella developments that are in the scope of EA and as such, it hides the recognition and complexity of an EA program. SOA, given its scope and ambition, should be a joint business and IT effort, a key part of a full EA development, and not considered in isolation as a light IT Enterprise Integration 56

Chapter 14: Service Oriented Architecture - SOA effort. SOA alone is misleading if not taken in the context or scope of the EA development. After all, it can be applied to any architecture (an application architecture, for instance) and not necessarily to an Enterprise Architecture (EA). A note of caution: the Enterprise Wide IT Architecture (EWITA) is often called Enterprise Architecture. SOA, in the Enterprise context, is a Service Oriented target EA design and implementation. It requires re-engineering of the business, data, technology and people layers around business services and, as such, a new business governance. SOA + EA = SOEA A “Service Oriented Enterprise Architecture,” SOEA, defined as an EA with an SO style of target architecture, would better describe the positioning of SOA with regard to EA. EA may be implemented without SOA while a stand-alone SOA development, mainly driven by a Service Orientation Architectural requirement, will tend to ignore business objectives and strategy. The EA sets in place a process to achieve technology and organization alignment to business processes, strategy, and objectives. SOA, as a style of business architecture, is adding value to the EA by enabling modularity at the business service level, and, as such, agility, reuse, Quality of Service, facilitating payback mechanisms and service contracts. This means a more decoupled business where services are provided and consumed based on contracts. And this offers enhanced manageability. Moreover, there are benefits from enabling services provided over the Web using Web Services technologies, and from making possible service outsourcing on an on-demand basis, such as Software as a Service (SaaS). SOEA, the development of an EA with an SOA flavor, must have support from top management and involve business since it requires process re-engineering, technology alignment, and firm re-organization, in other words, SOEA transforms the whole Enterprise, more than EA or SOA taken separately. As both SOA and EA are usually initiated by IT, the lack of business stakeholders' engagement and firm's management support or funding may foil the success of SOEA. The SOA should be initially implemented as an additional EA service layer – on top of the EA applications layer – which would exist during the Enterprise Transformation stages. Some time into the future, the Applications will be, hopefully, implemented as Business Services, and the SOA services layer will 57

cease to exist. This requires the applications suppliers to adopt SOA, which would be an advantage for everybody except, maybe, for them. Once implemented, SOEA (EA + SOA), becomes a powerful competitive asset since it is the blueprint of a service-based Enterprise, with best of breed components easily outsourced, no matter what technology or geography. SOA, To Do or To Buy The definition of architecture states that it is the structure of a system and the description of its components and interconnections. As a structure, the architecture exists in any system, no matter how convoluted; and it can be described by an architecture diagram. For the target state of a system, a blueprint is drawn to describe the desired logical architecture of the system, that is its components and interconnections. This architecture blueprint enters then a design phase where technologies and products are selected for each component and interconnection. The end result, the design blueprint, consists of detailed drawings of the interconnected components of the systems. The design is ready now for implementation and as such, at last, the architecture is implemented in a physical system out of the interconnected products. A style of architecture consists of recognizable and reproducible architecture patterns. SOA is a style of architecture applied to a target system. SOA, as a style, can be equally used in an application or in the target architecture of an Enterprise. SOA architecture, after the design phase, is implemented by the systems delivering the SOA business services. SOA is at the same time an integration technology for services rather than applications. This is what vendors try to sell you: ESB, registries... based on SOAP/XML, UDDI, WSDL etc. SOA technology integrates and interconnects rather than implements the services of a system. Vendors also offer, in addition, business process (and rules) engines, B2B systems, application servers, service management and other products in their SOA offer. The SOA business services design and orchestration is what people say you must do, not buy. You do have to specify your business services first and then interconnect them with a SOA technology. Can you say implement SOA services once you specified them? You can. But you can equally say that you buy SOA technology to integrate the systems delivering the business services. 58

Chapter 14: Service Oriented Architecture - SOA SOA Design Best Practices SOA is often treated as a separate development from EA, BPM…. It is not. SOA provides modularization, standardization, integration and re-use. In hardware design you always need a schematics diagram to describe the components and their interconnections. Catalogues describe the components functionality, interfaces and protocols. By analogy, in a SOA architecture, services described by WSDL and discovered by UDDI are interconnected through orchestration. The SOA development, part of the EA effort, should be directed by business and should have support from top management since it is really a business re- engineering exercise. Exceptions are cases where SOA scope is limited to Portal developments and Web Services where IT is in charge and already skilled for the development. Here are the few steps for designing the target EA, SOA style: 1. Discover your current architecture: 1.1. Specify for each Line of Business the As-Is EA Business Functions Map Use Business Reference Map provided. 1.2. Document the external stakeholders’ flows process steps, events, data, control and material flows, key business rules and associated roles. 1.3. Specify internal flows; use the business process template suggested in the book or alternative sources. 1.4. Specify GUI and process interaction to customers and other stakeholders. 1.5. Document current technology architecture 1.6. Identify bottom-up systems, applications, information topics and organization units and roles, implementing business functions and processes. 1.7. Document supporting organization roles and responsibilities 2. Specify target business architecture 2.1. Assess impacts of strategy, planning and objectives on functions, applications and technology 2.2. Evaluate technology specific issues and solutions impacts on architecture 2.3. Employ loose coupling, high internal coherence architecture principles to specify independent elementary services 59

2.4. Build complex services out of elementary ones using SOA composition 2.5. Identify functions in applications that can be deployed as services 2.6. Propose a list of services 2.7. Design target Functions as business services: encapsulated functions with interfaces describing service requests and responses, technology independent; not all services being implemented by IT. In software development, function calls or subroutines are reusable segments of code. SOA orchestration calls services in a similar manner to the main program calling a function. 2.8. Re-design processes as an orchestration/choreography of services; 2.9. To confer responsiveness, Event Driven Architectures (EDA) are often a choice in SOA design. This enables asynchronous operation and parallelism. Since the OO time a debate existed between the sequential like Central control of the objects of an application and the distributed event and message based communication between objects with no central supervision. The reality is as always somewhere in the middle, where the central orchestration and events at service and orchestration level co-exist. An event distribution scheme like publish/subscribe could be implemented. This would be in the realm of the SOA products technology capabilities. 2.10. Describe services UI to users and customers 2.11. Provide management and maintenance interfaces to services 2.12. Align information architecture to services; provide an MDM service to hide existing legacy databases 2.13. Identify applications changes required to fit SOA services and request change projects 2.14. Select technology for SOA integration (ESB, UDDI/WSDL repository… BPM) 3. Begin implementation program 3.1. Sketch technical transformation roadmap with dependencies, taking into account the technology and applications lifecycle and upgrades to minimize change for the sake of change and exploit new technology opportunities 3.2. Decide, roadmap and initiate negotiation for outsourcing of services as BPO/SaaS/Managed Services/Data Center 60

Chapter 14: Service Oriented Architecture - SOA 3.3. Assign governance and accountabilities for each business service 3.4. Do planning, establish budget, assign resources 3.5. Plan with suppliers the SOA style changes/design of applications 3.6. Iterate and design and deliver services in steps A SOA Design Case In this section, a SOA design is illustrated in pictures, specifically the As-Is and the To-Be EA. To simplify the matter, the transformation excludes the strategy impacts on the architecture. The target picture is derived from the Service Orientation demand of the Enterprise and good architecture principles such as reduction of duplication, applications integration and technology standardization. Hence, the current duplication in business systems is eliminated, the many internal connections dissapear replaced by an ESB, and the platforms are identical (Java EE, Open Source JBOSS or BEA/Oracle). Circled are the systems that become Enterprise Services, grouped in a customer front-end layer (Portal and presentation), utility functions (Authentication, Content…), B2B access (to suppliers, banks…), Business Logic specific services and Support (financial, reporting…). Before the SOA technology is deployed, the major effort is to define reusable services provided by systems and decouple, encapsulate and standardize their interfaces over SOA ESB and Web Services interfaces. An ESB technology internally interconnects all the major services of the Enterprise. A business orchestration engine is implemented and if the architecture is opened to accept Web Services an UDDI/WSDL discovery platform must be added. SLA contracts must be established to formalize the service payback, according to usage, monitored over the ESB. The architecture should be events based. 61

On line Receipting Health Insurance Fujitsu Mainframe Member Center Corporate Med/Dent Call center Hospital HBA Mail House Banks Direct Health Insurance System To EFTSRV Cam paign ANZ Genesys DW IBM mainframe Bank Gway ASCII/FTP/ISDN 3rd Parties ASCII file Claims/Cheque EFTPOS Payment Bank3 Grp TCP/IP Contacts GW Face 2 Face Providers Printer Web Premium Pay/HTTP Prospects SQL Health IT Sun Cluster HIC MC Gway Custom ers MBFG MC DNT New Technology Oracle Database .Net CITRIX .NET Farm JBOSS/JETTY / BEMIS EJB SchedTibco JMS Messaging MDB Hospital JMS SOAP/ HTTP Struts / Classic BusLogic B2B Gway EDI Batch Claims IVR Phone DNT Bus Logic CC Gway Diamond Data Services ECXpert/SUN Medical CFS RV Tibco Proprietary SQL Scripts GT-X / Claims HTTPS Corporate Tibco BW CC SQL Retail/ W ebLogic XML file HICAPS/IP B2B Gway Corporates Autoclaims NAB W ebLogic JMS ID GW Switch eDir IBA/IP iChain W eb PreAdm WL Telecom TCP/IP JMS Provider W L Web JMS HTTPS SOAP Prem ium Pay Banks Diam SDK HTTPS JMS WebLogic Insite Content Mng Vignette FTP Post Office W ebLogic Paymaster Channel Support Crystal Netw Bid Finance Oracle BalSC Oracle Cobol,SQL RT Analysis Shell,Pearl GL AP/AR AM Oracle RMS Crystal Java EJB Extra MfReports DB Benefits Cold TM1/Price Sched Informix W eblogic SAS ClaimInd Claims BI/ ISIS Im promptu XRAY FUTRIX BusObj Web InfoView ePortofolio (ZABO) Figure 14-14 – The As-Is Single Page EA of an Enterprise Banks Mail House Corporate Direct Campaign To EFTSRV DW/SVOT Banks Genesys Bank Gway ASCII/FTP/ISDN Claims/Cheque 3rd Parties EFTPOS Payments Grp Contacts GW Providers Face 2 Face Printer Web Premium Pay/HTTP Prospects SQL Health IT HIC Customers MC Gway Member Center CITRIX DNT New Technology Oracle Database .Net B2B Gway Farm JBOSS/JETTY / BEMIS EDI Tibco BW EJB Claims SQL Hospital JMS Messaging MDB JMS Classic BusLogic XML file ECXpert/SUN Proprietary SOAP/ HTTP Struts / Under Review IVR DNT Bus Logic Batch CC Gway Workflow Phone CFS Diamond Data Services Medical SQL Scripts HTTPS GT-X / Claims .NET OCR Scan Corporate ESB Call Center SQL Retail/ EclipseOPVClaim ESB JBOSS HICAPS/IP S FS B2B Gway Corporates C Autoclaims NAB JBOSS ID V GW Switch eDir IBA/IP iChain Web PreadmisJB TCP/IP Telecom ProviderJB JMS HTTPS Web Premium Pay Banks ) SOAP Diam SDK HTTPS JMS Content Mng JBOSS Insite Vignette FTP JBOSS Post Office Paymaster To Branch Printer Support Finance Oracle Crystal ETL RT GL AP/AR AM RMS Single Version RMS Java EJB Extra Of Truth DB Benefits Sched SVOT JBOSS ETL Indemnity ISIS XRAY FUTRIXj Crystal BusObj Provider Claims Sales Revenue SAS InfoView () 1 Figure 14-15 – The SOA design solution for the target EA 62

Chapter 14: Service Oriented Architecture - SOA Evolution to SOA The MIT Sloan Centre for Information Systems Research (CISR) studies identified four distinct architectural stages that business units and IT must pass through before the benefits of SOA can be realized: (1) Silos, (2) standardized IT, (3) standardized business processes (Optimized Core) and (4) business modularity. There is the underlying assumption that SOA is a target EA architecture, achieved at the end of the Enterprise transformation process, from the As-Is Silo stage. Long term, the history truly shows, that the Enterprise maturity evolves from the silos of the ‘90s, through IT standardization, to arrive now at stage 3 of business process rationalization and pointing at stage 4, the SOA based Enterprise. CISR also states that moving upwards, from stage 1 to 4, is increasingly difficult, since to achieve stage 3, business participation is a must and to realize stage 4, an overhaul of your Enterprise operation and organizational change are necessary. . While I agree, I would like to observe that the transition from 1 to 2 would not remove silos until stage 3, since silos exist because of business rather than IT. SOA, lessons learnt 1. SOA is primarily a business development, a way to structure your Enterprise, a style of target business architecture, and only then an integration technology. 2. SOA must have support from top management and involve business since it requires process re-engineering, technology alignment, and firm re- organization. 3. Since both SOA and EA are usually initiated by IT, the lack of business stakeholders' engagement and a firm's management support or funding may foil success 4. Pick only the technology you need for integration and orchestration; vendors have piled all their products in the SOA basket – BPM and rules engines, user interaction (Portals), application servers, B2B gateways, messaging middleware, repositories/registries, data management, business intelligence products, development environment and management equipment. After all SOA is about best of breed, vendor independent services. 5. SOA does not succeed outside an Enterprise Architecture development since, in itself, does not cover the development process, the current situation discovery (process, apps, infra…), information architecture, the alignment to strategy… 63

6. The target business processes are specified top-down while, the current processes discovery, is performed bottom-up starting with the re-modeling of existing applications. Top-Down design and Bottom-Up discovery EA efforts, performed simultaneously, succeed if observing the same EA framework decomposition tree. SOA in the middle approach is recommended. Initially it may add an SOA services layer on top of the applications, until the vendors come up with SOA solutions. 7. SOA will not succeed without an Information Architecture and service in place because, after all, SOA services use the same information vocabulary. Review checklist 1. Define SOA and WOA 2. What are SOA benefits? 3. Depict the relationship to BPM. 4. What is SOEA? 5. Answer the question SOA "to do or to buy". 6. List SOA design best practice process in conjunction to EA design. 7. What is the SOA evolution path? 64

Chapter 16 7. The EA Development Process and Best Practices This chapter will Endeavour to identify and summarize Best Practices in an Enterprise Architecture development. Practices will be outlined at each phase of a proposed process, which in itself becomes a suggested good practice. The process, the result of a deliberate reflection act, was constructed from answers to common sense business questions. Why Enterprise Architecture, what are its economic drivers and benefits and what is the technology context? What are the requirements and what shall the Enterprise Architecture deliver to you? What do you need to set out even before you start? What are the critical success factors and development strategies capable to guarantee success? And how can Best Practices become Business As Usual (BAU) practice! Practices are shown in a rather imperative manner, illustrated by a few sample practices of my own. As a good practice, embed Best Practices in the EA delivery process and make it an integral part of the Enterprise Framework next to principles and technology evolution guidelines. Document the EA process and enforce it using an Enterprise Architecture tool. What is the value of Best practices Best methods to achieve an outcome and guidelines to achieve best results! ♦ Result of our collective experience, lessons learnt from pioneers ♦ Afterthoughts and result of a deliberate process of reflection, retrospective analysis! ♦ Good practices have to pass the test of time and trial to become ♦ Best Practices are a first step in building a rigorous process and methodology to deliver a desired output.

Define EA Mission and Deliveries The EA Mission Statement will capture unambiguously, for all audiences, the essence of deliveries and development goals. For example: “The program will deliver an integrated blueprint of all business domains showing the boundaries and scope of the Enterprise, functions, use case scenarios and flows delivering customer products and value to stakeholders. The EA blueprint should describe the Enterprise in a hierarchical manner, enabling ‘drill down' from logical to technology level architecture and offering each stakeholder its own views. It shall provide common architectural and design principles, standards, guidelines and policies”. Capture stakeholders’ requirements, determine scope To manage expectations, first determine the scope of your development. Is it an IT only architecture? Is it a SOA or a business process re-engineering? Do you include your people organization? Is it a full EA development? Identify stakeholders and gather requirements. Common stakeholder requirements (add your requirements to this sample lot): ♦ specific views for every stakeholder at each iteration ♦ link solution architecture to EA as Views at the next level of detail ♦ EA roadmap must be linked to the Enterprise Project Portfolio ♦ align technology strategy and roadmapping to Business Objectives ♦ provide traceability to Requirements and Business Objectives ♦ allow simulation of change impacts and Business Modeling ♦ show areas of bottlenecks, potential high cost or little yield Capture all relevant business information which serves specify and align the EA to the business model, strategy and objectives. Build the Business Case for Enterprise Architecture Organizations must be prepared to perform a thorough analysis to determine the benefit of the EA investment in the long term. Consider the EA an asset which, once in place and properly maintained, will return value for many years since the investment in EA can be leveraged over and over again to pay back dividends. The EA asset offers your company a competitive advantage by providing simplicity, alignment, strategic planning and as a result, 66

Chapter 16: The EA Development Process and Best Practices cost savings, increased revenue, agility to change and customer satisfaction. Conservative quotes from different industries vary between 10-30% reduction in cost and time to market. Nevertheless, consider the initial investment and migration expenses. The Business Case will need to talk the language the decisions are made in, the language of finance. Get Support from Top Level Management & Business Use the Business Case to get support from your top level management and stakeholders. Quite often, companies operate in silos. To reduce the decision tree, units are often empowered to make up their mind in isolation, with regard to business, strategy design and technology selection. To penetrate this silo culture, the support of top level management and business stakeholders is essential. There is also the divide between business and IT. EA will help attenuate this divide, in the long term, by aligning the organization to work towards common goals. Build the EA Governance team The Governing Function should include members of the management board, senior business and sponsor, e.g. its advocate, and the EA lead architect. The Governance should be able to make cornerstone decisions with regard to framework, principles, planning and prioritization and facilitate investment and funding in the Enterprise. The Enterprise Architect’s lack of empowerment is often the motive for EA failure, since the EA lives only on paper. Nominate the EA core and virtual team Assemble an Enterprise Architecture core team with a knowledge of Business Strategy, Business Processes, BPM, IT, Enterprise Architecture and Frameworks and not in the least SOA, BPMS and Web Services technologies. The EA architecture team shall define the EA Framework: layers, views..., principles and, after the first iteration, police further Enterprise developments for compliance to the EA. Nominate architects or domain experts, with a knowledge of your Business Processes and IT Applications for each main business function or department. They will constitute the virtual EA architecture team. Negotiate their availability for the initial design phase. 67

Specify an Enterprise Architecture Framework The EA Framework is a structure describing the Enterprise decomposition tree at all architectural levels and from all perspectives. Select layers you will be looking at and the architectural and technology principles guiding the specification of the target EA. The framework should not define the component architectures, but solely a frame joining them, showing component placeholders. The framework enforces the specific system views and principles that apply consistently to all component architectures. Request the function architects to provide the same system views, with same conventions and constraints, in order to interconnect them in overall Enterprise wide pictures observing common architectural principles. The EA framework is, as well, the backbone of the whole program as it defines the component Functions and the way they fit into the whole. Once you know the components and the work breakdown around them, a program plan can be devised as a portfolio of component projects. This will give you and everybody else the confidence that it can be done. Select an EA Tool set to support the framework An Enterprise Architecture tool should document the whole process and store all components and artifacts from the beginning. A repository, centralized or distributed, is essential for documenting and reuse of the EA entities. The EA tool should enable drawing business processes, data architecture, organization charts, applications and IT infrastructure diagrams, in various notations. It should provide navigation between artifacts, at various levels of detail, web rendering, change control, requirements tracing, collaboration, access control, regulatory compliance features, link to other existing tools and databases and be able to store artifacts as business objectives, strategies and organizational information. It should be able to store both current and target EA. Various specialized tools exist to support modeling, repository and collaboration to design organizational structures, business processes, information flows, applications and technology infrastructure and link them to business strategy. An aggregated set of tools will probably serve the goal best. To properly present and interact with such dissimilar information, the various types of data have to be recognized and the proper tool launched to act upon the data. This is similar with the file type extensions of your operating system associated to various applications. Or it is analogous with the microformats operation of the semantic web world. The EA tool should provide the GUI navigation and serve launching 68

Chapter 16: The EA Development Process and Best Practices other tools, depending on the artifact type. The EA team should embed the framework – graphical interface, object metamodel, principles…. - into the tool. Outline a Design Strategy The recommended practice is to establish a Design Strategy: Bottom-Up document As-Is, Top-Down design To-Be, and middle-out use SOA paradigm for integration of Bottom-Up and Top-Down. Top-Down MDA approach to model the Value Chain This approach supports the development of the Business Process Architecture from the Value Chain. Services, in the SOA sense, may be implemented from any business function, not necessarily IT. A service could be built by a 3rd party or outsourced from another company. By deploying SOA you arm your Enterprise with flexibility and prepare it for rapid change. Bottom-Up discovery of existing technology and model ERP processes May be executed in parallel with the Top-Down design and would consist of discovery and documentation of the Current architecture and technology. Design SOA in the middle to wrap Applications as Business Services Would support the Top-Down and Bottom-Up approach integration by orchestrating workflows out of business services obtained by wrapping existing applications. SOA may be built on an Enterprise Service Bus (ESB) wrapping legacy applications, deploying Business Rules and Process Engines for orchestration, and employing ESB horizontal services as reliable transport, security, transactions service life cycle management, and Service Level Agreements (SLAs). SOA offers the flexibility to build your Enterprise from Off-The-Shelf (OTS), best of breed applications. A service is a Function with a request (service solicitation) and response (service provision) behavior. You have to: ♦ Specify Functions as Services ♦ Design transparent, layered Services ♦ Adopt a location agnostic, distributed architecture of Services Apply Architecture and Design Principles ♦ Adopt a hierarchical, layered, modular, service based architecture ♦ Functions at level one are partitioned in sub-functions that are still composed 69

of Process, Technology and People Layers. ♦ Specify non-functional capabilities as Performance, Scalability & Availability ♦ Specify Security controls at design time ♦ Assess threats, their probability, estimate impacts and specify security policy; assess intrusion points and design security zones accordingly and specify for each zone security controls, access rules and roles and Access Control Lists (ACL). ♦ Design Services to support testing, lifecycle ♦ Design for deployment, upgrade, retiring and recycling. ♦ Specify design and drawing guidelines ♦ Use a tool or combination of them: a tool for Enterprise Architects and a standard one such as Visio for business analysts to design process and technical architects to document infrastructure ♦ Establish an intranet site for all other EA documents and EA web tool publishing ♦ Use same modeling methods/diagram types for all EA artifacts same symbols and naming conventions, colors, diagram size, diagram identification box, logo… ♦ Align levels of granularity (level 1, 2, 3…) between diagrams ♦ Map input/outputs between diagrams Specify an EA execution strategy Some good practices to have in the implementation phase: Prioritize to deliver the urgent fixes for the Enterprise This is a good policy to get acceptance, to make the business case for the Enterprise Architecture by firstly initializing those EA projects seen by the business as a priority. Leverage existing applications and infrastructure Any design that is worth considering, should strive to leverage the large investment that has already been made in existing applications. Ideally, these systems can be re-used without significant re-investment in development. The design should provide an approach for integration of these systems. EA and SOA should be implemented opportunistically, taking advantage of the 70

Chapter 16: The EA Development Process and Best Practices existing technology lifecycle to avoid artificial, architecture only generated expenses. Do ERP modeling to discover the embedded business processes. Work with Suppliers to package applications as SOA services A SOA approach will be more successful if your applications’ vendors cooperate to deliver their applications as services accessible through defined interfaces and standard protocols. Design, Plan and Implement iteratively Construct a plan taking into consideration the stakeholders’ short term priorities. What is characteristic to the EA is the continuous delivery process, in iterations to keep the team focused on incremental stages in order to deal with complexity. Use an Agile Processes (AP) approach As Enterprise Architecture development is a long term process. Use an agile methodology with frequent deliveries and stakeholders' consultation. Nonetheless, a minimal process and plan is necessary to measure, manage and guarantee progress, quality and timely deliveries. Establish SMART Deliveries, CSFs, KPIs Critical Success Factors (CSF) and Critical Achievements must be estimated upfront. Once delivered, the EA will be closer to realization. CSFs represent milestones in the delivery process. ♦ Define SMART, measurable deliveries ♦ Define KPIs for the EA Development Process The goals, defined for the To-Be architecture, in line with the organization’s strategy, must be quantifiable. Once the EA program has defined its goals, it needs a measure for progress toward these goals. Key Performance Indicators (KPIs) are quantifiable measurements, agreed beforehand, that reflect the progress towards targets. KPIs must be tracked against a plan and embedded into a dashboard to enable you to assess the state of the Enterprise Architecture development, at a glance. From a business point of view, it should be proved that the EA program creates value. The Balanced Scorecard Model aligns the Enterprise objectives with four Enterprise viewpoints: Customer, Process, Innovation and Learning (People), and Financial (Owners). The four views define, describe and capture the goals, KPIs 71

and initiatives for each area. The EA value delivery can be traced at a high level, with this tool. The key benefits indicators table, in the business case chapter, should be used to fill in the perceived benefit % column at each iteration to estimate returned value. The EA maturity model should support the KPI definition for the EA progress measurement. Agree Best Practices Here are a few: ♦ Establish the EA Scope at the whole Enterprise, not only IT! IT is just a part of the Enterprise. There are many other reasons the Enterprise does not perform, like people and work culture. Lack of recognition and empowerment can be more damaging than technology. The EA development includes the strategy specification and mapping effort, process improvement, company re-organization, roadmapping and planning towards the To-Be state, the blueprint design and documentation. ♦ Manage early Cultural and Organizational transformation Enterprise Architecture removes silos and duplication. For a merger, a main trigger for a converged Enterprise Architecture effort, there will be human redundancies and technology platforms to be scrapped even though they have not reached the end of their life cycle. People will feel threatened, new platforms will require training. As such, early in the process, propose changes necessary to align the organization to the business functions structure. Organizational change is one of the most difficult aspects of change since it involves people. The best way to avoid resistance is to ensure that people are prepared and motivated to support the change. Involve people from the beginning, clearly explaining the reasons for the change. Having a clear strategy, direction and vision will help. Involve Change Management expert teams, communicate goals, reasons, solutions, and provide a transition path for people. ♦ Sell, Not Tell Do not tell people what to do: find out what their issues are and demonstrate how the EA works for them. 72

Chapter 16: The EA Development Process and Best Practices Design the Business Functions and Flows Architecture Specify the business functions tree (Functions) and business process map (Flows) and ultimately the Single Page Architecture (logical architecture). This will enable stakeholders to understand the Enterprise structure and operation and how their own work fits into the whole. The functional Single Page architecture is also the frame for As-Is discovery and To-Be Enterprise design. Use standard industry process frameworks or the Business Reference Map and current organization chart to derive main business Functions. Discover As-Is Using the Business Reference Map and framework layers Any Enterprise has an existing architecture, whether documented or not. Before designing a new architecture, the current architecture must be documented. This will help you measure the gap between As-Is and To-Be. The Bottom-Up approach is based on documenting the systems already in place i.e. applications and the legacy technology systems to determine your existing Business, Processes and Technology layers. Do ERP modeling. As-Is EA evolves as you work, with all projects modifying your Enterprise. Cascade Strategy objectives and initiatives to EA tree Map Strategies and goals targets Top-Down, that is, cascade them to Functions, Flows, Technology and People. Do the reality check (are they realizable?) and re- iterate, if necessary, to soften and prioritize targets. Introduce strategies, Bottom-Up as well, to solve existing issues in processes, technology and organization. Harmonize with Top-Down vision strategies in a single view, ensuring that both business objectives and practical issues are resolved in the execution phase, without additional projects and resources. Sketch the target Enterprise state Specify the To-Be Functions, Flows and Layer Architectures taking into account the Business Strategy, Mergers & Acquisitions, Architectural principles, technology transformation guidelines and roadmaps. Enterprise Architecture is a continuous process of improvement, adaptation and managing of the gap between As-Is and To-Be. Business Objectives will be moving, perhaps, faster than your EA development. Prioritize deliveries and iterate, applying each time the 80/20 rule (80% 73

functionality with 20% effort). Think of a spiral, iterative process. An iteration starts from its own requirements and has its own deliveries. Subsequent iterations would build on prior progress to supply new functionality. Most iterations shall be planned in advance, although the farther in time, the lower the detail. Assess Gap between current and target states, establish roadmap For each Function, Flow, Layer and View assess differences, gaps, effort (resources, time, costs). For each serious gap do a business case to assess feasibility and priorities. Specify the transformation roadmap. Establish project portfolio and program plan For each iteration, do the whole cycle from requirements to implementation, always building on the previous iteration or cycle. Fully involve the EA program management team and office at this stage. Establish EA operational governance After the 1st iteration, nominate an EA operational governance team to supervise and sanction all new developments, modifications and additions to the Enterprise for compliance to EA. The team will insert EA checkpoints in all relevant business processes and will review all new applications and capability developments for compliance. Execute Enterprise transformation iteration and evaluate EA maturity Use agile processes, iterate, deliver often and frequently consult the stakeholders. The EA maturity has to be measured now for the EA development, exploitation and maintenance phases. Review checklist 1. Depict the process of EA design and implementation. 2. What are the main design strategies? 3. Enumerate key execution strategies. 74

Chapter 17 8. An EA Design Exercise This chapter describes a logical sequence of steps and deliveries for the development of an Enterprise Architecture. Students of EA and practitioners at any level, may use this exercise to build their own baseline EA, following the conceptual case study illustrated in this chapter. The Design process steps The EA design process for a minimal architecture can be roughly illustrated in the picture in a few numbered steps, around the metamodel artifacts, beginning with the documentation of the firm's mission and vision followed by the design of A. Enterprise context and key stakeholders' interactions or Use Cases B. Enterprise Lines of Business (LoB/Products) and Value Chains C. Business Functions Map D. stakeholders' interaction scenarios as Business Flows over Functions E. business information map with information items from Business Flows F. organization chart resources (roles/units) alignment to Business Functions G. the architecture of applications executing the Business Flows H. data architecture, implementing the business information architecture, showing data flowing in applications exchanges I. IT technology (desktops, platforms , servers, and storage/DBMSs/SANs) J. networks (LAN/WANs, data and voice) providing interconnectivity K. application inventory database (configuration database) L. preferred technology standards for applications, technology, networks

76

Chapter 18 9. Framework use cases for M&A, Outsourcing. ITIL... The Single Page logical Architecture describes the operation of the Enterprise in terms of business Functions and interconnections. It offers a logical view, useful for comprehension, value chain analysis, business model establishment, current EA discovery and target EA design. The Business Functions and Flows maps are aligned with the Single Page EA.. A user should be able to select a business Function part of a an organization department, at a specified level of detail, to investigate process issues. Then navigate to the affiliated applications and technology, to discover the activity they perform. Alternatively, a user can select only the narrow View, a Function to analyze for instance, how re-insurance works. By navigating along the Function stack, the user finds out who is responsible, what technology is employed and what is the roadmap for change for the next year. Since Views can be built in response to any stakeholder's concerns, the four layer architecture, designed in the first path, is rapidly augmented to cover all the aspects of an Enterprise. An EA tool is essential for complex selections, subsequent navigation and access control. EA Framework use for Investment Once elaborated, the Enterprise Transformation plan would establish the priorities and timetable of the investment to implement the business objectives and strategy. The transformation plan already takes into account the technology replacement budget, innovation program costs… Any new investment proposals should be evaluated in the context of this existing and approved Enterprise roadmap and transformation project portfolio so that all implications on other projects or final objectives can be assessed. The investment would be assessed at the people and technology layers delivering a capability or a new product.

EA Framework for IT services management (ITIL) architecture EA is sometimes associated to ITIL, that is, IT service management architecture. To start with, the IT architecture only describes the IT department structure and operation, and as such is not an Enterprise wide IT Architecture, but the illustration of the IT department organization and processes. First of all, the customers of the IT are the business units rather than the external Enterprise stakeholders. But the EA framework may be applied successfully to any department of an Enterprise. The GODS structuring method: ♦ GODS IT Operations (O) is Service Delivery in ITIL, consisting of o Infrastructure operation, maintenance, upgrades and optimization o Applications maintenance and upgrades, back-up, log cleaning; (note: business people operate applications not IT people) o Availability & Capacity Management o Service Level Management o IT Service Continuity Management o Release & Configuration Management o Change Management o IT Architecture documentation ♦ GODS IT Development (D), project activities, would be SDLC in ITIL o Applications: software design (SDLC), new solution integration and EAI deployment o Infrastructure: new capability Design and Planning, Deployment o Project management ♦ GODS IT Support (S) is ITIL Service Support o Incident, & Problem Management o Helpdesk ♦ IT Governance consists of boards as : o IT Management committee o IT Architecture, Strategy and Roadmap o IT Investment committee IT Flows over IT Functions constitute the IT business architecture. The Enterprise applications, while serving the business purpose, are not serving the IT key 78

Chapter 18: Framework use cases for M&A, Outsourcing, ITIL… functionality and thus they are not part of the ITIL department Application views, as opposed to Helpdesk, monitoring, upgrading applications etc. EA Framework for Security Architecture Enterprise security architecture is, in actual fact, about controlling and protecting access to the Enterprise assets. For that, a strong concept is the "perimeter". We surround an asset, or a group of assets, with a perimeter at which we install protective measures. The logical security architecture begins at the business level by discovering the information, processes, and other artifacts like business strategy and planning, to which access needs to be managed. The next step is to devise the type of access (Read, Write, Update…) for each role, and an Access Control List (ACL) for the asset. People and systems would be assigned roles. The access type: it can be physical or remote, over networks particularly with regard to IT. At the Business Layer, an Actor would be assigned a role and specific rights with regard to business artifacts and process execution. At the Applications Layer, these rights would materialize in Access rights to content, structured data and application (right to reverse an EFTPOS transaction, for instance). At the infrastructure layer, the rights to manage platforms, OSs, servers, storage and networks would also have to be controlled by similar mechanisms. Actors are assigned roles with standard rights to infrastructure assets. The Enterprise assets, become components of the Security Architecture; they should become objects in the EA repository, having a description of access rights for various roles. Assets belong to business Functions. At the technology layer, access rights to non-IT assets (paper documents, equipment…) must be established. Security must be also enforced for real estate and facilities with access controlled at the perimeter around workplaces, especially at gates, doors and cabinets inside buildings. Nevertheless, before costly security systems are put in place (such as video cameras, 128bit encryption etc.), a threat and risk analysis would be performed to learn how often and how damaging could a threat be. Once the potential loss analyzed, an estimate of the worth of the security method and system could be 79

produced. At the people layer, security access cards and remote access authentication tokens could be provided besides passwords. For remote access, VPNs or SSL with encryption for information integrity and confidentiality should be utilized. Measures should be put in place to detect Denial of Service attacks and Man in the Middles message modification. In summary, every component of every EA layer should be analyzed from a security standpoint and accordingly protected, given the level of threat and potential damage to the Enterprise. 80

Chapter 18: Framework use cases for M&A, Outsourcing, ITIL… How to design your Enterprise around the customer ♦ The Business (Functions) Reference Map allows a good modeling of the customer interaction. Customers Authorization Subscription Customer Discovers Campigns Research Service Service Update Market Service Market Service usage Customer Interaction Layer Operations Utility Functions Market & Sell & Make & Plan Service Deliver Make/ Business Logic Source/B2B Development Governance/ S upport Services Corporate Services Partners/Supliers Figure 18-16 - A sample customer's interaction navigation scenario Some of the following business activities have to be strengthened to transform your organization into a customer centric one. ♦ Market research (customer needs, trends, competitors' products) resulting in customer segmentation, new product concepts. ♦ Market campaigns based on research to attract prospects ♦ Customer interaction at the Portal, Shops, Call Centers… ♦ The Booking/Reservation/Subscription/Application for Product 81

♦ Customer Service and Relationship Management for customer interaction history, personalization, product changes, incentives, loyalty ♦ Service Authorization and Access ♦ Service usage (downloading, therapy, access to show, transport…) EA Framework use for Mergers and Acquisitions The starting point is the existence of two different As-Is Enterprise Architectures, even if not properly documented. The aim is the development and evolution towards a single Enterprise and EA. This is a long term process, finished after the formal merger. To control this process a formal common program has to be established, before the merger, with activities described in this section. By looking at the EA framework it becomes apparent that you have to align ♦ the Business layers of the two Enterprises: o establish the new common Governance of the merged Enterprise o evolve towards a single mission, set of products, market segments,, brands o design a single vision, strategy, objectives o establish high level logical architecture (business functions and flows); specify common Functions such as operations, shared support and development services; analyze outsourcing at this early stage o rationalize external stakeholders (banks, suppliers …) ♦ the Technology layer: after discovering the existing two EAs, rationalize and standardize the Applications and Infrastructure platforms to serve the functional architecture (Functions and Flows). Decide on, merge and rationalize: o ERP, CRM, SCM… o customer services and sales channels o main product applications o Data Warehouse, Business Intelligence, reporting o B2B platforms o Knowledge and Content management o Voice and IP networks, email and printing architectures o Office technology (PCs, mobiles, Helpdesk, IT support) o Non IT technology and facilities: rationalize real estate, parking… ♦ the People layer: 82

Chapter 18: Framework use cases for M&A, Outsourcing, ITIL… o manage change (expectations, redundancies…) o align organizations to the same EA business functions; o begin cultural transformation: choose common values, ethics… o design common communications channels and technology o align payroll levels, recruitment standards… ♦ design common EA Views, such as o Financial/Accounting functions, flows people and technology o data architecture (vocabulary) o security o planning EA Framework use for Outsourcing Outsourcing, a fast growing trend, offers the flexibility to choose the best of breed service and cost effective supplier. It could be justified by a few factors: ♦ reduced costs of service compared to the in house TCO ♦ enhanced reliability and quality of service as a result of clients' usage by and feedback ♦ improved response times and productivity through supplier's specialist expertise ♦ faster time to market due to the new service deployment time ♦ elimination of longer internal feature development cycles ♦ minimization of the HW/SW infrastructure maintenance costs ♦ reduction in real estate for people and machinery. Moreover, it allows you to focus on managing the key business functions only and deploy an "on demand" model of usage rather than build, operate and maintain, in-house, a service you seldom consume (recruitment for instance). Drawbacks: the formal, contractual way to address a new requirement, especially when you missed the opportunity to formulate the feature at acquisition. Not all functions can be easily outsourced. The more connections are necessary, at human and technology levels, the more difficult is to outsource. Another impediment is the fact that there is typically little understanding of the existent service boundaries, requirements, costs and profitability. As such decisions are the result of "intuition". 83

Outsourcing exists at business process level (BPO), IT application level (SaaS), infrastructure (data centre), function or department level (helpdesk, call centre), or combined under a managed services agreement. In general, it is employed when specialized skills are required and it is not your core function. You already outsource development to contractors, maintenance of the mainframe to suppliers, business strategy development to management consultancies, IT support to specialized IT firms, call centers to India, payroll to China, HR to specialized agencies and so on. Enterprise Architecture and SOA would prepare the ground for outsourcing by showing all parameters of a Function starting with the process, technology and people belonging to it, the costs and KPIs associated to it etc. The Lines would describe the interface to other business functions. The EA framework would support a rapid transition to outsourcing at all layers: Process, Application, Infrastructure and People. The Operations, Support and Development functions may all be outsourced depending on your business model. That is, the way you decided to make money would stress specific links of your Value Chain, leaving out others which can be outsourced. EA Framework use for a Start-Up Business How would a Small or Medium Business (SMB) adopt EA? A simplified framework can be used as a guideline for entrepreneurs to plan and build the new company. The EA framework already contains the main aspects an entrepreneur needs to consider: ♦ The business architecture layer is to be determined first: o the product, the business mission o the vision, business strategy and plan (how to get there), forecasts o Value Chain and business model (what markets, customer segments, pricing, costing, core capabilities etc) to serve the mission o typical stakeholders: partners, suppliers, financial institutions ♦ define Governance, type of ownership such as Sole Trader, Partnership … and decision making: the managing team roles and responsibilities ♦ Specify GODS functions in terms of activities and required resources such as people and technology and estimate costs for each and every function o Operations: sales and services, inbound/outbound logistics, customer 84

Chapter 18: Framework use cases for M&A, Outsourcing, ITIL… distribution channels, manufacturing o Development (R&D, product and capability development) functions o Support functions ; decide their business model (how do they produce value to the company) and outsource if necessary ♦ Select basic technology for each function, deploy an ERP, use managed services or a plan to do this ♦ Sketch key aspects: locations, data, security, planning, required performance (from benchmarking data) Produce the business plan including all the above. Review checklist 1. Describe Security Architecture. 2. Explain the process of application of EA framework to ITIL 3. Describe the interaction of the customer with the Enterprise. 4. How do we use the framework for M&A? 5. How could be FFLV used for outsourcing? 85

Chapter 19 10. The EA Governance, Program and the Architect role EA Governance The EA should be used across the entire company in various ways, to support learning, making decisions and investments, designing new products and capabilities and do strategic planning. EA compliance checkpoints and templates should be incorporated into all relevant business and IT processes: ♦ The Product/Capability development process will observe enforcement checks at each milestone ♦ Projects will have milestones checked against the architecture deliveries templates. ♦ Roadmapping process aligned to EA ♦ the Investment process to consider the Enterprise Project Portfolio and technology selection to EA technical standards An EA compliance team should observe and police all solution architecture development for compatibility with the EA . Departments shall: ♦ design their own architectures using the same tools and conventions ♦ provide architectural Views to the overall Enterprise Architecture ♦ interconnect their architectures at reference points agreed with the EA ♦ observe common architectural principles and technology standards in design Suppliers should be distributed a version of the EA architecture so that they may include the required functionality, interfaces, protocols, roadmap and EA technical standards in products. The Business improvement activity should be devised to take into consideration: process, technology and people performance at the same

time. EA Governance EA Governance Council: Business Sponsor, CIO, Chief Architect, Program Manager EA Chief Architect EA Program EA Tool/Site Lead Architects: EA workstreams Solution Manager & PMO Administrators Business EA Architect Lead Architects Architects Applications EA Architect Technology EA Architect Domain experts Compliance& Information Portal, Cnt Mng, Maturity Id Mng, BI/SW) Domain experts Virtual team members Figure 19-17 - EA governance EA should provide mixed business-IT governance, compliance, program management, administration teams and Enterprise Architects to lead the EA workstreams and supervise the key EA domains of activity. The business and IT governance should be adapted to the new SOA structure, to enable ownership and operation of the business Services by common business and IT teams. This deserves a discussion: the business Function as such contains business processes, information and the Technology and/or People executing the processes. But there are different teams and managers for business Functions and IT. An explanation is the existence of the separate IT organization delivering shared services. While technology is key in supporting business processes and in 88

Chapter 19: The EA Governance, Program and the Architect role delivering business objectives, the IT team supporting this specific technology may have other priorities coming from the IT line management. A straightforward remedy would be that the people operating the technology would report directly to the business Function and in dotted line to IT, to enable co-ordination with the rest of IT for technology standardization. A solution is to partition the IT department into units, reporting into broader LoBs, except for the few truly shared IT and EA central functions. The ultimate goal is to unify the business and IT teams and their objectives, inside the business Function. The EA project organization and funding Is EA a project or Business As Usual (BAU) activity? EA, ultimately delivers an asset, a capability. A project has to be initiated to create the capability in the first place. Afterwards, a BAU function and team must be established to manage and upgrade it. The EA is no different. A project will deliver the EA in an 80/20 manner (functionality/effort). The project should transit and deliver into a BAU team. The EA project should be organized in phases and staffed accordingly: 1. Planning phase: determine scope, iterations, resourcing and governance 2. Overall EA set-up phase – Architecture + program support group o Specify rather than choose the EA framework o Design the key EA layers and views o Specify the vision state of the Enterprise 3. Design and Implementation of iteration N – multiple teams/workstreams o Discover As-Is views o Design End and transition States o Plan, resource and Implement state for each workstream 4. GO TO 3 (after reviewing 1 and 2) 5. Form and handover to BAU team The BAU EA team should follow the same design process with Solution projects. The main tasks of the team would be to coordinate the work done by Solution Architecture teams to assure fitness for the EA purpose. 89

EA Program and BAU organization Program BAU transition Phase 1 Iteration 1 Iteration 2… Workstream 1.1 Discover As-Is Design To-Be Solution Workstream 2.1 Implement Gap Project 1 Discover As-Is Design To-Be Planning: Scope, EA set-up: Implement Gap Workstream 1.2 EA coordination Iterations, EA Framework, Discover As-Is Discover As-Is Governance Principles, Design To-Be Design To-Be Resourcing… Standards, Implement Gap Implement Gap Estimating costs Strategies Workstream 2.2 Discover As-Is Design To-Be Workstream 1. 3 Solution Implement Gap Project 2 Discover As-Is Design To-Be Implement Gap EA core team EA core team EA core + virtual team IT Architects Figure 19-18 - The EA program organization Initially, the development should be funded as a project with Operational Expenditure (OPEX) for development. Both OPEX and Capital investment (CAPEX) are necessary for implementation but the CAPEX should be synchronized opportunistically with the lifecycle of existing technologies. SOA requires that funding be distributed between the internal customers of a service. After the design phase, outsourcing of a service should be considered. An EA site taxonomy As the EA becomes the knowledge DB of the Enterprise, the content has to be organized early according to an EA taxonomy and exposed on the Intranet to enable content. management. The EA architect leads this effort. 90

Chapter 19: The EA Governance, Program and the Architect role EA site taxonomy Architect. Tool Business Layer Line of Business Line of Business Technical Roadmaps Documents Relevant Publishing Folder Standards EA Architect Relevant Documents Documents Applications EA Architect Technology EA Architect Information IT Solution & Domain Team Structure Program Governance Info Architecture Docs /Responsibilities Documents Business Cases (Cnt Mng, Id Mng, Portal, BI/DW, EAI, B2B, BPM…) Figure 19-19 - EA site organization The role of the Enterprise Architect The EA architect role requires putting together an EA business case to justify the EA development once and for all, then sell the EA to business and management to get sponsorship and resources. Afterwards, the job demands the EA framework selection, customization and creative design since most frameworks stop at general architectural patterns like matrices, layered structures, triangles, pyramids, cubes, circular processes etc. This is a critical success factor for the rest of the EA development! The architect establishes the design principles, the process, breaks down the EA work into workstreams, and organizes the teams to discover and document the current Enterprise state and blueprint. Then he validates other Enterprise developments from an EA point of view: all 91

solutions architecture designs have to comply to EA principles, standards and conventions, reuse the same components and link them to each other and the rest of EA artifacts. Also, the ERP, SCM, CRM, MDM, Portal and business specific applications, suites and activities have to be properly documented at the process and technology layers, to be integrated in the overall EA. Then the architect looks at the Business and IT Strategies - to align them to the Enterprise map and analyze their impacts - and determines the future state of the EA and its roadmap. The EA architects also establish the technology standards and guidelines, specify and verify the EA compliance criteria and process check points, evaluate the EA maturity and not least, coordinate the entire EA development work. Enterprise Architect kinds A good number of Enterprise Architects (EAs) appear to come through the IT professional promotion ladder process which ends up at the top of this value chain: the Enterprise Architect. They are veterans, they know people and people know them, they give advice and are knowledgeable about the company history, culture and motivation behind every technology in existence. They are often consulted by management and occupy a position of respect since some are legends for services rendered. Do they really do Enterprise Architecture? They mostly don't. They do check consistency of designs between projects and against their own experience, but they do not have a reference Enterprise Architecture to validate results against. Another type of Enterprise Architect is the Integration architect; it is an important role since most applications are hard to interconnect even today. They are chosen from the SOA ranks, as the middle name for SOA is integration for most adopters. They use middleware, mostly based on ESBs, JAVA/JMS, MQ Series… and Web Services. Do they do Enterprise Architecture? They do the EA integration bit. Then, the well known Enterprise JAVA Architects so called because of the “Enterprise” in the Java EE naming. The technology is said to be Enterprise wide, in that it may support all Enterprise applications. There are also Enterprise Solution Architects because they work in capability delivery projects. They do patching and interconnection work to keep the applications running. This is not really EA work., but Solution Architecture. The Enterprise IT strategist role, is the Enterprise Architect working on the IT 92

Chapter 19: The EA Governance, Program and the Architect role roadmap which is aligned to the Enterprise Architecture. If not based on EA, this role will deliver best effort silo-ed outcomes. leaving gaps which, later on, would demand resources competing with the strategy activities. The Enterprise Architects are often classified in Applications and Infrastructure architects to enable work division and specialization. Often they end up doing inventories of technologies and applications, working on these EA layers in isolation. Sometimes, the Enterprise Data Architect and Warehouse roles are also created when the Enterprise has trouble with managing its customer data or extracting reliable intelligence from available sources, which is quite often, simply because information is duplicated in many applications. It is significant to note that Business Architect roles are seldom if ever advertised even though Applications, Information and Infrastructure roles, one for each framework layer, are. Business Architects, when they exist, usually occupy business analyst roles, mostly belonging to the "business" community, not the IT; they have the task to look into requirements and model the business processes but typically out of the Enterprise Architecture context. Hence, while there are "Enterprise Architects" in place doing IT solutions, integration, inventories... more often than not, there is no one to do the business architecture (business functional decomposition, process , business services). More, EA architects do not really do EA framework design and customization, metamodel specification, EA compliance or maturity evaluation work. The EA positions are occupied nevertheless because the thrills of the EA job attract lots of candidates. Since the current "Enterprise Architects" are more likely to be senior and experienced people, there is no way one can substitute them. They do a great job. While existing EA architects are experienced IT people there is no guarantee that they understand the business methods and theory. One still needs to bring in "true" EA architects to develop and manage the EA. An EA architect must be able to develop the EA framework, understand the business theory and practice and manage the EA development. The problem with the EA is that Enterprise Architects do not cover business architecture and business analysts do not cover technology, information or even architecture as a discipline. The division between business and IT does the rest of the damage. In reality, one may not employ another team of Enterprise Architects. How would one avoid the conflict of naming and interests? Who is supposed to draw and drive 93

the Enterprise Architecture? Does one have to reassign roles and responsibilities or change titles? The risk is the loss of these valuable people. A solution would be to introduce the Business Architect role whose responsibilities are not covered by either current Enterprise Architects or business analysts. The business architect is not a mere business analyst. The role, once created and properly filled, could take charge of the EA development since the business architecture drives the technology, describes the operation and goals of the company and conveys understanding to everyone in business and technology alike. This role should be a senior one, unlike the Enterprise Architect today; it should have authority to suggest organization alignment, perform project and team management, resource, delegate... To inspire trust to the top management, the role should be knowledgeable in business operation, value chain analysis, supply chain, business models, Six/Lean Sigma, strategy and BPM and have an understanding of IT and architecture. The Business Architect would lead the design of the Business Functions Map, Single Page Architecture, Business Flow Map, Business and Operating model assessment, strategy alignment and so on. The existing EA IT architects would continue to do the IT work, play the same important role in IT, in alignment with the Business Architecture this time. They should have a dotted line reporting relationship to the Business Architect lead. All in all, there are just a few true Enterprise Architects; the few who have both the business and IT theoretical and practical background and have overcome, with passion and dedication, the limitations of existing EA frameworks. How does one select an Enterprise Architect Since there are few distinctive qualifications or selection criteria for an Enterprise Architect, how do you recognize an Enterprise Architect? Most EAs have studied TOGAF, Zachman, FEA and quickly gave up on DoDAF. These appear to be the universal requirements for an Enterprise Architect. Nothing earth shattering though, almost marketing like material. Zachman is quite straightforward to read and understand. It is common sense. All candidates have browsed TOGAF, hard to go through due to its richness. FEA is a bit of a read, in fact there are quite a number of documents, but what remains in one's mind is the simple framework (consisting of performance,... business, services, technology reference layers) which is not quite rocket science. But if you read specific agency frameworks you discover they differ in many ways. DODAF formalizes descriptions in diagrams types with relationships described by 94

Chapter 19: The EA Governance, Program and the Architect role a metamodel. It has its own vocabulary that departs a bit too much from the EA accepted modeling. Hence it is hardly usable, except in defense. As such, it is not too hard for a candidate to tick the methodology boxes for an Enterprise Architecture job: Zachman, TOGAF, FEA and other (IAF, EAP, E2AF...). But unfortunately this is not too distinctive, in fact it provides no differentiation since most IT architects can claim this. The EA (SOA too) certification courses will surely help, won't they? EA certification attempts to fill the gap to an experienced IT professional but, typically, it does rely on the existing frameworks to guide the development work. The IT layers (applications, information, technology) are more often than not, presented extensively in training and certification courses. You will see long chapters about network, DB, servers technologies, type of applications etc. But do they arm the Enterprise Architect with a practical framework to design or lead the implementation of an Enterprise Architecture? An Enterprise Architect needs to understand the framework connecting the layers and its navigation, rather than all layers in detail. Since it is not too hard to tick the boxes for an Enterprise Architecture ad, the Enterprise Architect's curriculum must be usually backed by a long IT experience, references and social skills. There are also technology requirements: such as experience with Java, DBs, ERP... And there is also the experience in the specific business domain such as "Insurance" industry. Counting these criteria, is it possible to narrow down the candidates to a short list? Not by much. How do you really make sure you get what you need? Since there are no clear qualifications or selection criteria for an Enterprise Architect, how is it done today? The professional history, Zachman and TOGAF tick boxes, soft skills, technology skills like Java decimate the number of candidates. Ultimately a reference and the experience in the domain of business do the trick for most jobs. You just selected an Enterprise Architect. But will you get an Enterprise Architecture? These criteria help but unfortunately they may eliminate the "real" Enterprise Architects. But what is that? Someone who had a structured mind and takes the time and the pain to understand how things fit together. Might also have done hardware design since this is a more structured domain based on functionality encapsulated in chips. Consultancies, do they have EA frameworks? They have variations of the existing 95

ones. Consultancies count on the collective consultant experience to resolve issues. For a consultancy, a typical framework - which changes quite often - is based on the known layers (business, information, applications, technology etc) conveniently surrounded by a few great Zachman style questions, such as Why, Who, When, Where.... Orthogonally one will always find a security slice. The job description for an Enterprise Architect A job description for an Enterprise Architect,: Architecture wise ♦ architecture know how: definition, principles ♦ IT architecture styles (centralized, layered, multi-tiered client server, web) ♦ IT architecture patterns and typical components: Content Management, Presentation, Business Orchestration, ID Mng, B2B… ♦ SW and HW development experience at flowchart level ♦ concepts as MDA (Model Driven Architecture), MVC (Model View Controller) ♦ OO concepts, design and Distributed Components history (RPC, CORBA, COM) ♦ UML modeling: context diagrams, Use Cases, activity, sequence, state diagrams, data modeling, ERD (Entity relationships Diagrams), Class diagrams, BPEL ♦ a disposition to draw diagrams and flowcharts before coding and soldering ♦ Integration experience Business wise: ♦ Business acumen: operation of an Enterprise, Porter's Value Chain, Business Models, Operating Models, Governance, Financial Management, Performance and Cost Management, SWOT analysis, SCOR and VRM reference models ♦ Business Strategy, Roadmapping ♦ Business Process modeling (BPM, IDEF representations, swimlanes), Business Process Management, Business Orchestration and Rules, Balanced Score Card, Six Sigma, CMM, Change Management ♦ A working knowledge of the specific business: products and stakeholders Technology wise: ♦ EA Frameworks: Zachman, TOGAF, DoDAF, FEAF, TEAF…, PERA, eTOM /NGOSS 96

Chapter 19: The EA Governance, Program and the Architect role ♦ EA and other modeling tools ♦ SOA, ITIL, COBIT IT process and governance frameworks ♦ Systems and Software Architecture and Principles ♦ Service Oriented Architecture concepts and Web Services protocols ♦ Mainframe, client server technologies, databases, Content Management, Data Warehouse, Business Intelligence, reporting, B2B, Portal, Internet and IP technology, virtualization technologies, trends ♦ Infrastructure: servers, storage, networks, telecommunications, OSI ♦ Agile Processes, project management ♦ ERP, CRM, SCM… applications suites ♦ SDLC: Software Development Life Cycle ♦ EAI/ESB distributed component architectures ♦ Web Services, Java and .Net aware Social wise: ♦ Able to communicate, influence, negotiate, motivate, facilitate and inspire, in other words, get the human interaction right. ♦ Able to guide the EA development process and get support from all levels. ♦ The Enterprise Architect should be politically savvy, able to present and argue at all levels of management. The Tasks and authority of the Enterprise Architect ♦ Prepares business case, exposes benefits and drivers ♦ Specifies framework, best practices and tools ♦ Establishes architecture, design and technology principles and guidelines ♦ Supervises EA design and development ♦ Coordinates works done by domain architects ♦ Controls artifacts consistency and compliancy ♦ Owns the EA repository and decides access rights ♦ Presents, justifies communicates to all stakeholders in business and IT ♦ Recommends transformation roadmap and works with PM ♦ Controls EA iterations and operation ♦ Establishes compliance checkpoints in major development processes 97

♦ Assesses EA maturity ♦ Measures returned value Authority: ♦ makes decisions with regard to artifacts design and implementation ♦ drives the virtual team of function architects ♦ resolves architecture disputes Enterprise Architect as a leader There is an argument that the Enterprise Architect is a leader in the transformation of the Enterprise and a participant in the business decision making process. Right now, this is not the case but the trend points in that direction. But what is a leader or leadership for that matter? And what is it compared to management? Management is about organization, control, planning and budgeting. Leadership is about motivation, mobilization, creating the vision and establishing the culture and relationships. To succeed, an Enterprise Architect has to act as a leader to motivate people, mobilize resources and create the EA vision while as a manager has to manage the complexity of the Enterprise Architecture development, documentation and day to day running. Latest thinking points out that leaders must have theatrical qualities. I would say that actors becoming leaders are not rare these days, especially in politics. But is it what leadership needs? What is called theater is in fact another term for excellent communication skills, the ability to hold an inspiring speech in front of people at a conference. But it is possible to have a leading position without having leadership capabilities or the other way around. A leader is an individual who leads a group's activity to a specific purpose. But these individuals could be selected, nominated, self- nominated or inherit a leading position, a position of authority. In this latter case, a group may not even respect or agree with these individuals since the authority of this leader comes from the power of the position. Discussed here is the case of leaders capable of leadership. What is leadership then? Leadership or charisma is the quality of an individual to attract followers for a specific purpose. For that, a leader must inspire trust and respect, coming from natural personal qualities, experience or education. Leadership requires self confidence and emotional control to reassure and inspire the followers. 98

Chapter 19: The EA Governance, Program and the Architect role What are the qualities of leadership? Inspiring trust and respect is vital, even if the leader has a position of power, but how is it done? In the first place, the individual has to be credible and lead by example. This requires top competence in that field of activity, a basic sine qua non condition for the leader. Self confidence has to be rooted in knowledge and experience rather than mandated by culture (you must be confident at all costs!), or two days training courses. The leader would find solutions where few can, strengthening the others' confidence. He is Not someone who is looking the part, confident, decided, sure of success but without with the depth to deliver. The problem is that without the underlying professional ability, the confidence is wrong footed and the results average. The surrogate leader fails without knowing why, since he is playing the role well and moreover believes unconditionally in himself. Acting the role alone, will not deliver professional results. Acting the role of a leader, can only benefit, in the long term, the actor, the "leader" and not the group. There is a difference between the role and the reality, the personage and the person. An actor is at his best when plays naturally since he is authentic i.e. a leader. Otherwise there is mismatch between substance and form, easily noticed unconsciously, decoded by primitive but efficient detectors within ourselves: the eyes which do not smile or avoid looking into your eyes, the gesture that does not confirm the words, the intonation gone the other way. The leader should have a vision, an ideal that inspires people and determines them to follow in the long term. He does the "right things", and does "things right" as a good manager/administrator does. He should be emotionally stable, having a degree of Emotional Intelligence (EQ as opposed to IQ), so that he could understand, interpret and control emotion in others. But the leader is in control of himself first. A leader, alternatively, could be passionate to inspire his followers with his energy and enthusiasm. Leadership needs authenticity to succeed, that is the image shown should fit the substance and competence. Authenticity means "you do what you say" and "you say what you think". There are archetypes, or worse, stereotypes of leadership. The hero leader in films is a typical example. People are molding themselves on heroes since early childhood. We struggle to imitate the best, their behavior, we learn from them. There is also the stereotype of the business manager played by many, unfortunately. In a culture driven by acting leaders, the real work would not be prized any longer; meritocracy would be applied in terms of acting skills. An acting leader can empower, delegate, but the immediate ranks feel the competence void. This 99

leadership will be maintained not by respect inspired by competence but through power, minute control and politics. The style of leadership depends on field: a warrior leader would be bold and ready to fight, a president would be a decision maker, and a conductor would orchestrate the individuals in the orchestra. This would require different qualities. Leadership also depends on situation such as a company in difficult times for instance. In normal times leadership is welcome but not in demand. It does not necessarily mean doing moral "good". There are evil leaders. Why people follow them? Because trust, belief and the lack of doubt is said to make people content, if not happy. It was discovered that following is easier than leading, that too many choices or decisions make people unhappy. Finally, leadership comes from will or desire to lead, since it is not solely a blessing but a very consuming activity, requiring sacrifice and dedication to the cause. EA is a difficult task. Many people in management, business and IT would have to trust the Enterprise Architect and take action. But without the right authority the task is made impossible for the Enterprise Architect. Review checklist 1. Describe governance for EA design. 2. Illustrate governance for EA execution. 3. How is the project organized? Specify phases. 4. Discuss project funding. 5. List a few components of the EA silo taxonomy. 6. Write the job description of an Enterprise Architect. 100

Chapter 20 11. EA Maturity, Value and Sell Measure your Enterprise Architecture Maturity A few attempts have been made to define EA maturity evaluation models. The Capability Maturity Model of Carnegie Mellon Software Engineering Institute (SEI) is a main source of inspiration. A simplified maturity model is shown here. The development maturity model assesses the phase of EA development. The exploitation model determines the degree of adoption. An important factor is overlooked deliberately at this stage. the quality of EA. This depends very much on EA definition, scope, framework (and artifacts) and practical purpose of development. EA development maturity The following phases are distinguished: 1. Phase 0: Pre-EA From value of EA not assessed or understood until the Business Case is approved. There is no commitment or capability to plan, design or execute. 2. Phase 1: EA Program Initiation From approved business case until o the EA organization is set up o planning and resources are committed o Chief EA architect, Steering Committee/governance are agreed. Capabilities for the EA design and execution are committed now. 3. Phase 2: EA Definition EA design and transformation planning phase, until

o the EA framework and tool are established o the As-Is Architecture is discovered o intermediate stages and To-Be EA are sketched, o transformation plan approved o KPIs, CSFs, quick win are determined. 4. Phase 3: Transformation Execution Enterprise transformation execution in iterations until 80/20% (functionality/ effort) is achieved and value delivered is confirmed. 5. Phase 4: EA exploitation EA enters the exploitation stage, while incremental design/plan/ implementation stages are still executed. The components assessed in the transformation implementation process would typically be business processes, technology architecture and organization. The degree of EA development progress inside a phase would be also evaluated as a percentage. To measure the earned value, the table of indicators in the Business Case chapter can be employed to fill in the % column. Alternatively, a subjective way to measure benefits, would be to estimate the ultimate benefits: the degree of simplification, alignment, agility, strategy alignment and blueprint documentation achieved. Once the EA is implemented to a significant degree (80/20) the CMM for the EA exploitation process should be employed. EA exploitation maturity This may overlap with the EA development capability assessment. It may be practical to keep them separate. 1. Level 0: EA ignored o Although EA artifacts exist, they are ignored or not easily available. o No EA central authority or clear distribution of ownership of iterations exists. 2. Level 1: Empirical EA exploitation by a few stakeholders: o the process is repeatable but depends on people; o There is some ownership but o The EA utilization process is not clearly documented. 102

Chapter 20: EA Maturity, Value and Sell 3. Level 2: Documented EA utilization process o The exploitation process is well defined o Design and ownership of artifacts is in place o The exploitation process embeds controls, checkpoints and audit points in all relevant Enterprise processes. 4. Level 3: Managed EA It is used by management, business and technology teams to design, deploy, control investment, make decisions and manage change. 5. Level 4: Optimizing EA There is on-going EA improvement and maintenance. EA is used in product design, organization evolution and strategic planning. Measure the Value of EA EA, like any architecture, represents the structure of an Enterprise and its documentation describing how the Enterprise operates. The better the architecture, the better the outcome, i.e. the returned value. A good architecture structure reduces duplications and overlays in processes, platforms, projects and sometimes people and it consolidates the many interconnections. A good EA framework describes the structure, standardizes best practices and technologies, maps strategies on architecture components and architecture layers such as processes to people and technology. It makes understanding the operation and training people easy. The Enterprise Architecture delivers value, as soon as it is designed and implemented. In fact, it does that, gradually, while it is implemented by increasing the effectiveness and efficiency of your Enterprise. EA soon becomes an asset in its own, returning value to your Enterprise. A project justification is done at Business Case time, before the start of the development, by enumerating and estimating a number of key benefits. Ideally, all these initial benefits should be tracked and measured at implementation time to prove the delivery of promises. Same applies to EA. The EA scope is key though, since more scope should return more value. EA iterations may add scope and as such, new value. 103

But EA definitions vary and their scope is wildly different for each development. What is EA? Is it an IT only architecture? Then you are looking only at the benefits of standardizing technology and integrating applications. With business and people architecture the picture changes significantly. The Business, Organization and IT alignment with ensuing benefits can only be achieved if you include in scope a Business Architecture. Once the scope and deliverables are established, the benefits and business case of the development can be estimated. The EA success should be measured against the listed benefits and deliverables in scope rather than against an abstract EA that does not have an agreed definition, but promises a lot, in vague terms. A table of key business improvement benefits, the way to measure them, and their stakeholders should be defined from the beginning and measured at the end of an EA iteration. The key benefit indicators may be grouped in a few categories: ♦ Operational (those enhancing the operation such as single customer view - master data management -, Development (improving your innovation and the new product development process, reflected in time to market) and Support (enabling single version of truth for reporting…) ♦ Governance (enabling understanding, communication and decision making in the organization) ♦ Strategic, enabling effective execution of strategy ♦ Communications and Collaboration The EA development success is measured at implementation time with project progress indicators. An EA maturity framework will help you measure progress in the development and compliance in exploitation phases; It will do that by measuring success from a process maturity and extent of business participation points of view rather than from a business value view. Value, sometimes comes down to how do I justify my job as an EA architect! Firstly, many "EA architects" are not really doing an EA design work. They are Enterprise level technology and applications integration experts and IT veterans. But if you are really doing EA work, one can evaluate your job performance by assessing, after each iteration, the benefits stated in the business case and measured by key improvement indicators in the benefits table. This could be correlated with a maturity framework evaluating the EA development progress, participation and compliance to EA. 104

Chapter 20: EA Maturity, Value and Sell A Balanced Scorecard approach for performance measurement and management of your Enterprise is supported by the FFLV framework in that it is addressing the four scorecard views: market (customers), processes (company), learning and growth (people) and financials (owners). Sell the EA This seems to be one of the issues continually confronting us in the EA arena. To sell it, start by identifying the interested and affected parties for each iteration, the stakeholders. Ask the old question "what's in it for them?" and "what is the impact on them" since they would be asked to support, pay or even contribute to it! The potential audience depends entirely on the scope of your EA development which can vary a lot. Is your EA an IT only architecture? If you define your architecture in terms of applications, information and technology architecture you address an audience in IT, for the most part. For IT, do you intend to include content management, knowledge management, BI, DW, integration architectures? That will considerably enlarge your IT audience. Top management, what is in it for them? The representation of the Enterprise governance, the roles and responsibilities, governance bodies and principles of decision making, the business models - how the business makes a profit -, strategy alignment to the Enterprise organization, regulatory compliance and not least a business blueprint. There is quite a lot to sell. For Enterprise shared services organization: support functions as HR, Payroll, have to be described in terms of services, processes, costs and effectiveness. For business people you should be providing information on IT or other technologies they use - like SCADA and GIS for utility companies - process automation and improvement, business rules and orchestration and not in the least reporting and Business Intelligence blueprints. If you provide this information the business organization would become your supporter. To satisfy the interests of most potential stakeholders, the concept of architectural view is crucial: a view satisfies the concerns or needs of a stakeholder group. There are as many views as stakeholder types. To sell the EA, put together, upfront, an EA drivers and benefits pack and a business case based on financial terms. Business management thinks in terms of Payback, ROI, NPV which are measures of profit vs costs, typically applied to projects. A table of benefits, such as time to market, agility, and the estimated EA contribution to them at each EA iteration will do a lot of good to the sales process 105

of EA. Calculate RoEA at each iteration. The EA has to be opportunistic, planned to deliver first what the business needs such as a Single Customer View or a Single Version of Truth architecture. A natural progression to EA with obsolete systems and technologies replaced when their time has come and not before would reinforce the EA sell effort. Business does not see technology in isolation as IT does, except as a source of problems. Review checklist 1. Describe the EA maturity exploitation model. 2. Explain the stages in measuring the EA maturity at design phases 3. How do you measure the value of EA? 4. How do you sell the EA? 106

Chapter 21 12. EA Roadblocks, Culture and Politics EA Development Triggers Enterprise Architecture, as shown, provides many benefits. Once a business case is built it is easier to argue for the EA investment. The typical issue is that tactical concerns are always winning in competition with long term, strategic programs as EA. A reason is that strategic issues are coming today, at tactical speeds. If not strategic thinking, then which factors may trigger the development of an EA? ♦ An imminent Merger and Acquisition requiring the amalgamation of two companies with different organizations, processes and technology ♦ A decision to outsource business functions where productivity and costs are becoming an issue ♦ Technology infrastructure needs urgent alignment to business Strategy ♦ Imminent regulatory issues demanding documented business processes and document management with compliance controls ♦ The company suffers from inefficient processes ♦ A re-organization to adopt a new business model and strategy is on the agenda ♦ Master Data Management or Customer Data Integration introduction ♦ There is an acute need to upgrade from an obsolete technology as Mainframe To be successful, the EA has to offer first relief for the trigger problem. EA Roadblocks Enterprise Architecture (EA) has promised a thorough transformation of the business world by streamlining enterprise operations, aligning IT to business, enabling strategic planning and documenting the company blueprint to improve understanding, measurement and management of its operation.

Although EA has been around for some time now its take off has been rather modest or inconsequential. The value it promised to offer has not quite materialized. But what are the factors inhibiting adoption or its success? What I found is that EA is seen as an IT architecture only. All technologies besides IT seem to be ignored. EA is overly simplified to four architectural layers with few other "views" to respond to non-IT stakeholders' concerns. The logical architecture, a good practice in systems design, is not really adopted and Use Cases, coming from the world of software design, are not really used. There is seldom a link to the enterprise Value Chain or business model. EA tools are not used, true EA architects are hard to find (as opposed to Java/.NET architects), and there are few successful EA cases to encourage adoption. ERPs are already covering the Application side of EA and are very costly to change, SOA is in fact a disguised EA development but incomplete. Presentations on large paper format (A0), covering a wall, scare off stakeholders. This being the case, no wonder that people are reluctant about an EA development then: it is costly, takes time and resources, its business case is not proved and the outcome may not live up to expectations. The Enterprise Inertia, silo organization and the Business - IT divide Your Enterprise may be in a state of cultural inertia. EA challenges the status quo of the Enterprise by altering its course. Most companies have a predominant tactical thinking. EA is about strategic planning. This collides with the short term thinking. Strategy demands good long term planning and execution that needs discipline. Tactical action demands ad hoc allocation of resources which works against long term planning. The Silo organization plagues many Enterprises where there is no big picture (EA). Silo management focuses on own business segment ignoring the big picture activities. Silos generate wasteful duplication in projects, platforms and resources. The divide between Business and IT, yet another silo, exists simply because they have different management, planning and goals. Besides, It is not easy to cross the boundaries between domains of such different skills and interests. The lack of reference Business Architectures Historically, there is no business architecture designed by the academia, a global 108

Chapter 21: EA Roadblocks, Culture and Politics forum or business people. You have to design the business architecture without a template, a reference map or even help from business. The diversity and non-coordinated approaches to fix the Enterprise evils In practice, there are a few categories of activities or approaches for mending the evils of today’s Enterprise: ♦ Business Process Management (BPM), improving processes - belonging to the business domain and specialized consultancies ♦ Six/Lean Sigma to eliminate defects in processes, mostly people related and typically in the manufacturing environment ♦ Enterprise Applications Integration (EAI), about IT architecture and integration; ♦ EA, that usually and unjustly belongs to IT only ♦ Human Performance and organization evolution, about people performance and organization design, factors frequently dealt with by HR and top management or external Human Performance agencies ♦ SOA, about transforming the Enterprise based on Services ♦ Strategy alignment, executed top down affecting mostly the organization and job descriptions Not surprisingly, each activity ♦ is performed in isolation, at different times, and by different groups, without a mutual exchange of knowledge ♦ engages a different set of skills ♦ develops artifacts with different conventions, tools and stores them in different places but they are all associated to a layer of the Enterprise Architecture. Management consultancies typically operate on the business side in business process improvement, organization design, business strategy and objectives cascade to people and roles. IT consultancies, more often than not, sit in the driver’s seat for the EA, SOA and Enterprise Applications Integration developments. The same divide between business and IT can be observed at external expert advice from consultancies. Six/Lean Sigma is typically an internal business development to improve processes requiring extensive resources and training. 109

EA vague definition, is it a blueprint, process, program, strategic planning…? In fact, EA is all that: a blueprint for As-Is and To-Be Enterprise, a plan and roadmap for transformation and a process of delivery, reinforced by best practices. The strategy and target Enterprise Architecture specification constitute the "strategic planning" of the Enterprise. The EA design and Enterprise transformation are part of an Enterprise wide program organized as an Enterprise project portfolio.. But no matter what the definition is, you have to clarify what the expectations are for your case, right from the beginning. EA scope, no non-IT technology, no people or other stakeholders' views A. EA is more than an Enterprise wide IT only architecture This is a noteworthy scope issue: Enterprise Architecture is composed of the Business, Technology and People Architecture, not only IT. The end result is that it prevents the business people and firm's management involvement, funding and support. The EA is not visible to the business side and what is more relevant is that it does not cover business aspects. Such an EA fails to raise interest or ultimately extend usage outside the IT. The assumption may come from Java Enterprise Edition (Java EE) or EAI, ESB where the term "Enterprise" is used liberally! There is nothing wrong with an IT architecture. The issue is that the expectations promised by the Enterprise Architecture advertisement will not be fulfilled. IT architecture is only a part of an EA architecture. To succeed, an EA architecture needs to address business concerns, to be sanctioned, supported and have visibility at the business and management board. EA needs the wider scope to include and provide motivation to business teams and enable adoption and usage. You need to design the EA top-down starting from business processes and strategy and not bottom-up from the supporting IT technology. B. Not many IT Views Often there are no email, printing, PBX, SOE, Helpdesk… architecture views; no Knowledge or Content Management, Data Warehouse, Business Intelligence…, typically approached in isolation. 110

Chapter 21: EA Roadblocks, Culture and Politics EA frequently covers only the key products architecture. It needs a wider scope to include other architecture views to provide motivation to all IT teams. Enterprise Architecture is more than two views of Applications & Infrastructure. C. Technology is more than IT! Often, no other kind of technology such as mechanical, optical etc is considered. What about manufacturing technologies? 50 years ago there was no IT. Banks and factories still existed though. It is hardly an Enterprise wide Architecture, a development which does not describe the manufacturing equipment when your products are cars or shoes. The IT only view is restricting the sphere of interest to just a few types of IT intensive enterprises and, inside a company, to a few stakeholders. It is again a matter of scope, not only in design but in business users' involvement, support and usage. As a result it's difficult to get traction from firm's management, business or manufacturing people or, for that matter, from other stakeholders outside IT. For wider adoption, EA has to cover all Technology, not only IT. Enterprise Architecture is more than IT Architecture and Technology is more than IT. D. Lack of stakeholders' views reduces the interest and usage of EA to just a few stakeholders, leaving out other aspects or "views" of the Enterprise such as real estate, accounting, parking or, in IT, email or printing, file server architectures although they probably exist, are documented elsewhere in some form and are of real interest to you and quite a few enterprise stakeholders. Due to this simplification, EA architect positions are sometimes advertised directly for Information, Infrastructure or Applications roles in the IT space, already confining the activities to this narrow scope before the development has even started. E. Often people/organization are left outside the scope of EA Typically business processes or parts of them are still performed by people rather than applications. These processes, in fact, more accurately workflows, are still relying on human interventions for data input, validation, phase approval... In other words they are not automated. Processes lag because 111

people taking decisions are away or technology fails at the hands of poorly trained personnel. More often than not, the human intervention is not described in business workflows for the simple reason that people are not part of the framework. If human performance is not accounted for, the overall workflow will perform as its weakest link, the people. But EA looks like an unfinished business without people manning processes and technology. Organization (people) design is often the object of an entirely separate and non-correlated initiative. In a company, the process and best practices optimization effort, the organization re-design and alignment to strategy and the Enterprise Architecture program activities are often performed by three different groups, in parallel. That is, the process, people and the EA activities, constrained to IT, are executed in isolation, without correlation. The organization chart should be aligned to your Enterprise Architecture so that people take ownership of business function's process and technology. Culture and people communication also affect your Enterprise performance, but this is quite a topic in itself. After all, "the Company is the People" who govern, plan and operate the Enterprise. The EA program developed solely by IT In terms of EA implementation, the EA program initiated by IT has little authority to drive the business architecture, influence corporate strategy or recommend the people architecture/organizational changes. Usually the EA team has little control of the business process documentation effort, for instance, even if it successfully initiates it. Lack of an agreed EA framework or the diversity of approach and limited scope of the existing frameworks inhibits EA adoption. Some of the existing EA frameworks are, by and large, cognitive aids, enabling discovery by asking key questions such as why, what and how. Some are merely reference models describing outcomes and implementation guidelines to serve as reference for other EA developments. Some are specialized on domains as government, defense, manufacturing or telecoms. Some have been applied for a while with less than convincing results, and some are obsolete or used no 112

Chapter 21: EA Roadblocks, Culture and Politics longer. Some other only touch aspects of the EA implementation program management. Some approaches talk about BPM, Enterprise Applications Integration or SOA only. Most leave out the people layer, and some are only process architectures ignoring the technology and people resources. Most are mapped on Zachman's for scope validation. Mapping matrixes are used, sometimes, to link elements in layers but they hardly support the navigation or consistency of artifacts. How do we choose a framework? None of them appears to cover all aspects. Are there any recommendations for the framework selection? Do we need to create our own framework where so many others have not quite succeeded? All legitimate questions. Overly simplified EA framework A. EA, overly simplified to the four layers architecture EA frameworks typically consist of four architectural layers: business, information, applications and technology. The EA development is often considered finished, soon after an inventory of technology is compiled, the application architecture is drawn, the process documentation is initiated by business analysts and data architecture class diagrams are sketched. An EA framework that covers business functions and flows architecture, people and organization and many views on top of the four layers framework, is necessary to deliver to the many stakeholders. B. Frequently there are neither business reference or logical architectures The lack of an industry reference architecture inhibits understanding of the Enterprise operation and of the EA itself. A logical Single Page architecture outlines key Flows operating over the Functions of the firm to deliver value to stakeholders. eTOM/NGOSS provide such a reference process architecture framework around which a Telecommunications company can be modeled . For a technical system design, the logical architecture specification is one of the first steps an architect has to perform to describe the system operation and its components. The organization has to be mapped to the logical architecture. A Single Page EA (key Functions + key interconnections), added to the business, information, application and technology layers, will dramatically 113

improve comprehension. It will also make possible SOA with services built around functions. A Single Page Applications Architecture, derived from SPEA, serves the IT audience. The logical architecture is one of Zachman's framework perspectives, the designer's. C. The EA design is not initiated by Stakeholders’ Use Cases By default the only stakeholder considered is the customer, leaving out owners, partners, employees and other views, thus limiting the EA scope yet again. This leaves out B2B and employees views. A good practice would be to listen to stakeholders and capture their interactions as part of the EA architectural layers. The Enterprise discovery should be initiated by Stakeholders' interaction Use Cases. Lack of Business Case at initiation Frequently, the EA development is rather the result of the hype that animates IT but annoys the business . A Business case would resolve once for all, the argument about To Do or not To Do Enterprise Architecture. Further more the business case establishes the indicators that have to be measured to prove that EA delivered value. The business case, drivers and benefits need be produced for each EA iteration. EA deliverables not fit for purpose Deliverables are not fit for implementation. Take the typical “tome” delivery, a stack of paper reflecting in fact the politics of “passing the buck” to the next team and phase. EA governance and implementation failures The EA, initiated solely by IT, has little chance to enroll business stakeholders or attract management support. At implementation time, an EA development that trails for too long, not solving the immediate business pains and displaying a lack of transparency revives the tactical project threat to resources and discussions about the utility of the EA. There is little tolerance for long programs with uncertain results. At exploitation time, the governance makes sure EA is not ignored, forgotten or 114

Chapter 21: EA Roadblocks, Culture and Politics considered a dead weight because you have not implemented architecture controls and check points in the relevant business processes. The governance team has to be properly chosen to reflect all interests and has to have enough authority to make it happen. Enterprise Architect not invested with authority The lack of authority, budget of the Enterprise Architect and in general of the Enterprise Architecture program proves that management and business people still see EA as an IT clean up exercise, at best. Until this perception is changed EA remains a futile exercise usually terminated after a few months when the applications diagram and inventory are produced. One of the common mistakes is to invest no authority in the Enterprise Architect. Even minor objectives cannot be achieved without the proper approvals, contributions and budget. Politics slowing EA development There are execution mistakes: ignoring important stakeholders, not communicating properly or enough, in simple clear definitions and messages, not consulting relevant people, not referencing and recognizing contributions, to name a few. Not consulting the relevant groups, breeds the “not invented here” syndrome, i.e. “you have not consulted us, where did this come from"? The Enterprise knowledge is locked in people's minds. The ability to extract information requires negotiation skills in the absence of authority. To release this collective wisdom you need negotiation skills, “selling not telling”. Otherwise, the information you may get for the EA may be of little value. Independent SOA programs competing for resources SOA is a partial EA development in disguise. While not an inhibitor as such, SOA harbors under its umbrella developments which should be covered by EA. SOA does cover architecture but not technology alignment to strategy or organization design for example. SOA is not IT specific; it tends to fail as much as EA because it is initiated by IT, without business stakeholders' and the board of directors' support. 115

SOA should be a business development first, part of a larger EA development. It is taking off as the Enterprise integration paradigm of preference as it provides agility and utilization of best of breed solutions from various vendors ERP development competing with EA but not offering an Enterprise blueprint, comprehension alignment to strategy... ERP (Enterprise Resource Planning) covers many Enterprise functions (payroll, procurement, accounting, finance, inventory, order fulfillment etc.). It provides, in a rather monolithic approach, the business process and application layer of an EA for support functions. Historically, they were introduced to integrate the Enterprise applications in software suites delivered by one single vendor. Nowadays, ERPs are probably too integrated, too vendor dependent to open the Enterprise to Best of Breed (BoB) applications and offer agility through easy integration. It's not in the ERP suppliers' interest to open up their products to SOA which promotes best of breed services and as such open the gate to other vendors. ERPs do not promote the understanding of the Enterprise an EA does, through its blueprint and there are main culprits in inhibiting the alignment of IT to business requirements for lack of agility and laborious integration to other applications. ERPs are notoriously hard to change as they are inflexible, expensive and hard to learn! ERP modeling is the solution for documenting the ERP processes and as such, reuse the existing suites in the EA development. Not using EA tools There are many repositories, inconsistent diagram input/outputs, various notations and a proliferation of PowerPoint and Visio drawings with the consequence of creating the issues which, in the first place, EA had to eliminate. As a consequence the EA artifacts are hard to reuse or evolve in harmony. A change has to be propagated to many diagrams in many stores. Each stakeholder would produce in isolation artifacts which represent own concerns. They are usually poorly linked, if at all, to diagrams of the Enterprise from other stakeholders. The consequence is the lack of navigation.. A tool or tool-set would enable a repository, a common vocabulary, consistency in representation and data integrity. Often the sheer size of the diagrams discourages EA consultation, take for instance, A0 paper formats. Not everyone has equipment to print them (in fact very few), space to display them or is patient enough to discover in the maze solely the 116

Chapter 21: EA Roadblocks, Culture and Politics aspect of concern. The diagrams are too big, they look and are too complex for everybody. In the end they are forgotten and forgiven. The vast knowledge required and paucity of Enterprise Architects Only a few EA architects are able to deliver. To develop an EA the knowledge stretches across the business and technology domains in fields such as Value Chains, Business Models, Strategy, Operations, Business Processes and BPM, Technology, EA frameworks, architecture design, IT, ITIL, IT Applications and Infrastructure, ERPs, CRMs, SOA, outsourcing, BPO, SaaS, Web Services, modeling and tools, performance and change management (Human Performance) organization design, and maturity models. These are some of the challenges Enterprise architects face. In the corporate transformation phase many other resources have to be involved. The EA governance and the quality of the Enterprise Architects are key to the process and a major risk as a result. Roadblocks recap and recommendations To succeed, an EA architecture needs to address business concerns, to be sanctioned, supported and have visibility at the business and management board. EA needs the wider scope to include and provide motivation to business to defeat the Enterprise inertia, cross the silos, the business-IT divide and commit resources. EA needs to be clearly defined and scoped to consider all stakeholders views such as owners, partners, employees, community, not only customer's products. Avoid returning discussions by providing a business case in financial terms. Employ an EA team having a vast knowledge of the Enterprise. Consider EA governance from start. The Enterprise discovery should be initiated from stakeholders' interaction, Value Chain and business model. EA should include people and organization, in alignment to business processes and technology and aim to cover the whole Enterprise operation rather than solely IT architecture and all technologies rather than only IT. It should cover many views besides the over simplified four layers, a logical architecture, content & knowledge management, MDM, DW/BI, Governance, decision making, Financial/Accounting, HR, fleet views… The EA effort should be jointly governed by business and IT, since IT alone has little authority to get traction from firm's management and business, drive the business architecture, influence corporate strategy, facilitate decision making, planning and 117

investment or recommend organizational changes. Be unambiguous with regard to other Enterprise related technologies : BPM is part of the business architecture, SOA is an architecture style and integration technology for the target EA, ITIL is only the EA of the IT department, and ERPs provide the applications and process layer of the EA support functions. Employ EA tools that support consistency in definitions, inputs/outputs and look and feel of all EA artifacts by employing a single vocabulary, metadata, repository and set of architectural patterns, principles and conventions; they also enable process simulation for business process improvement, dependency reports, navigation, "zoom in/out", configuration, change management, collaboration, access control and web presentation. Enterprise Culture and EA The Enterprise Architecture development has to be supported by the organization and its culture. People are the company; they can make or break the EA. To succeed one has to adapt the organization and subtly sniff and influence the culture. SOA for instance, requires a new governance based on services. People are accountable for the service they deliver, its roadmap, business, IT technology, usage, defects, service continuity and for acquiring internal or even external customers. Here are a few definitions for culture, from the web: - "The set of learned beliefs, attitudes, values and behavior that are characteristic of a particular social group or organization." - "A set of shared norms and values which establish a sense of identity for those who share them". - "The sum total of the ways of life of a people; includes norms, learned behavior patterns, attitudes, and artifacts; also involves traditions, habits or customs; how people behave, feel and interact; the means by which they order and interpret the world; ways of perceiving, relating ..." And an own attempt at definition: company culture is a set of principles and values that drive the behavior of a group and shape the way people respond to events and get things done beyond established procedures. It consists of, and is transmitted by rites (ceremonials), traditions (established ways of doing things), legends (heroes and deeds people treasure) and education (training). It is reflected in the way people solve issues, communicate, celebrate, approach management (direct call/email, kick the door open…). It is the unwritten code of behavior in a firm; it determines the attitude towards 118

Chapter 21: EA Roadblocks, Culture and Politics colleagues and work; it lives in people's minds and hearts; it is determined by the successes and history of the company; it makes people proud, ready to identify with the company and set its interests first. Culture becomes tradition. The culture is the collective soul of the organization. It is influenced by: type of governance, internal regulation, empowerment (liberty to act in some established limits) and recognition policies, height of the organization tree (bureaucracy), clarity of accountabilities and roles, freedom of communication, right of opinion… Recognition makes employees happy which in turn make the company successful. Company values are the principles or rules of behavior which determine culture; they have to be meaningful, realistic, even measurable - unlike the values of most companies, today -. It is important what happens if people ignore or even act against values. An Ethics code, based on values, represents the code of law preserving the culture; it has to be communicated and policed, because otherwise it becomes a "lip service" of, and for the powerful and the manipulator: insider trading, networking, nepotism begin to manifest until, like societies, the company begins to disintegrate. God had created people in his own image, it is said. In a similar manner, a top Executive determines the culture in the organization through personal example, choice of direct reports - in his own image - of governance, business strategy and ethics code. Empty words won't do! People, intuitively, have an 6th sense, the ability to feel the truth from gestures, expression, phrasing and intonation. A few known organization cultures: - "Meritocracy" is the culture of reward and recognition associated with rapid progress and pride in the organization. - The "can do" culture characterized by achievement, as opposed to the "can talk" culture. - "Innovative" culture where invention is rewarded and praised - "Agile" where formalism is replaced by people’s empowerment to immediately act - "Blame culture" where if anything goes wrong a scapegoat is found; the consequence is that people rarely assume accountability - "silo " where the departments don't care about the greater, collective good. Some of these types can co-exist. 119

The best culture is meritocracy that worked so well for societies. Everyone achieves the position deserved in an organization with optimum results for the individual and the company. It is the ideal win-win balance of benefits between the company and employees. There is mutual respect (we respect achievers), and everyone knows their own place (promoting the right individuals rather than self promotion). Collaboration is the norm and people care for each other. A good culture polarizes individual behaviors towards the company goals first (rather than personal gains) from which all other individual rewards come, proportionally. The secret of good culture, in short: ♦ a history of success, conserved and taught ♦ a code of ethics and values that are enforced ♦ freedom of speech ♦ transparency of decision making ♦ clear governance, thin organization ♦ fair participation and repartition of benefits (unlike the CEO/employee salary ratio today >> 50:1!) ♦ empowerment, recognition and fair promotions The wrong culture can ignore or make fruitless the EA efforts and for what it matters, can wreck the company. In a difficult culture the personal interest comes first against the Enterprise. The company sinks under the weight of the many individual benefits working against each other and the common company goals. Not only a firm, but a society falls apart under the weight of an incompetent or corrupt administration fighting solely for power and personal benefits. The disease spreads quickly downwards, by example rather than discourse. If formal mechanisms are not set in place, culture tends to deteriorate with people tending to take advantage of the honest, the trustful, the weak or the unaware. Action is necessary to enforce ethics, transparency, empowerment and recognition in support of a positive culture. How can you change culture? That is, change it in a positive sense since it may often happen otherwise. The cultural change starts at the top. It requires honesty (as opposed to political spin), justification, communication, openness (information available to anyone concerned) that is, all in all, transparency (information available to anyone) enforced by a Freedom of Information like act. Accountability (the ability to associate people’s performance to task accomplishment) and recognition of merit are essential to enforce a successful culture. 120

Chapter 21: EA Roadblocks, Culture and Politics Practices like "networking" are clearly working against meritocracy since the best available are not selected. Positions are not advertised, only a few are in the know, and only a few can occupy the position in an exchange of favors. These people team to maintain power and the phenomenon grows with a viral behavior until the company suffers the worst, the end. This works against the freedom of information principle and employs "spin" to project the appearance of " politically correctness". The spin culture uses media to distort messages, the truth and hide the sources of information. Management at all levels has to pay attention to atmosphere and open communication channels so truth can be told with immunity. Freedom of speech is key to evaluation of culture. Personal performance evaluations have to be performed by customers and colleagues rather than managers alone who can spin the outcome from fear for their positions. In times of hardship, un autocratic culture with a cult for a leader, may succeed though, like in time of war. So cultural changes may be beneficial depending on existing conditions and the place of the Enterprise in its lifecycle. Often governance issues generate an unhealthy culture. For instance, silos or the division between business and IT. It exists because there are two different organizations with different objectives, plans and roadmaps. So they do not concur to deliver together. They have different missions and products, it is that simple. The EA governance and organization have to be set up so that the concerned business and IT groups have same leadership and goals. EA Politics The culture can be a fertile ground for politics. Nothing is achieved without playing the game. Rumors abound about IT fearing the business reaction to the EA/SOA program, unfortunately, too often initiated without a business case. IT, avoiding confrontation is probably substituting the EA and SOA terms with a discourse on benefits. Politicians, as well, in avoiding sensitive topics, come back with convoluted answers to respond to simple, closed questions. Too many prophets have jumped in the EA/SOA bandwagon adding to the IT pressure on business. “Do EA/SOA or …!” Over-hype has already placed EA and SOA at the top of the hype curve where the credibility is not sustained yet by realizations. The IT history lessons would not concur to support the EA far-reaching claims; the result is that the business doubts it! 121

Although business is reacting to the technology push, they do not contest the benefits but they are painfully aware of the potential cost of disruption, which might break rather than make the company. Business requires solid justification and careful planning before moving from the “status quo” to such a revolutionary course, as SOA. Without critical business input, the resulting IT only Enterprise Architecture would mainly provide the Applications, Infrastructure and may be the Data architecture, which is frequently the case, but not sufficient for releasing the goods of the EA: process improvement, agility, strategic planning etc. The business people will have little reason to consult it, the word spreads, and, progressively, the EA loses its momentum. The loop is closed now. The business was right to doubt it, after all. Business, as well, got tired of the exotic IT acronyms like WS, SOAP, REST, UDDI, WSDL, mashups, AJAX, ESB, BPM, BPEL, XML, UML, TOGAF… some badged 2.0 now (and technology is changing at an exponential rate these days - Ray Kurzweil’s law-, i.e. the situation is getting worse). Furthermore, IT is not talking about Value Chain, business models, process improvement, Six Sigma, regulation, customer satisfaction, Balanced Scorecard, SWOT, KPIs, NPV, payback, the terms the business can understand. On the other hand, is the business providing the Business Architecture (process architecture, business information and vocabulary) necessary for IT to comprehend and align the technology? No. The net result of all this is the great Business and IT divide and an increasingly highly charged atmosphere progressing towards a blame culture. And the solution is the EA, which ought to mend all the evils of the Enterprise, to cure the silo culture and patch the divide between Business and IT. In a nutshell, EA becomes the ground of the already existing political battle but, at the same time, the tool to mediate the political divide. While the EA encompasses alignment of business, strategy, technology and people, the IT takes the driving role without business and top management support. How is this supposed to happen? After all, more than half of the EA is not IT, i.e. business processes (how), strategy (why), information (what), organization (who)… In fact, without a strong business leadership and participation, EA would lack political support and fail to deliver on its promise since IT alone cannot specify SOA services, improve processes, determine usefulness of information. In this phase, the best you can do is be convincing i.e. gain support for the EA 122

Chapter 21: EA Roadblocks, Culture and Politics business case which you should express in financial terms. Spend energy to rally critical stakeholders’ support in business and top management. Involve them by planning adequate EA artifacts, in response to specific requests, explaining what is in it for them. Thinking in many Enterprises is tactical, at best. Firefighting would better express the facts. The EA is strategic and accepted because of its strategy promise but it may become a lip service only, with its execution ever postponed in order to cope with tactical crisis. In truth, EA will compete for resources with many other activities which have not been included in the EA scope, in the first place. Supposing the EA development moves slowly; it will be generating lots of tactical- strategic conflicts: people need solutions yesterday, the market cannot wait and the EA will provide the feature who knows when! Tactical projects are approved then and co-exist and compete for resources with the EA program. There is no easy solution to this except delivery on time and fit for purpose. To reassure everybody have a clear, simple plan in place that you are confident you can deliver to. You probably have one single try. Deliver often, iteratively, emphasize value returned. Prioritize business needs, deal with the EA trigger causes first, and deliver what the stakeholders requested. This is a program, so business process discovery projects will probably have to be executed in parallel to Applications, Infrastructure, Data architectures and other streams. Then add views as DW/BI, Content Management, procurement processes, network architecture etc. With a delivery plan in front, people can wait, if they trust you. Otherwise, tactical projects win. There are execution mistakes: ignoring important stakeholders, not communicating properly or enough, not consulting relevant people, not referencing and recognizing contributions, to name a few, provoking the syndrome of "not invented here” i.e. you have not consulted us, where did this come from"? Enterprise knowledge is locked in people’s minds. To release this collective wisdom you need negotiation skills, “selling not telling”. Otherwise the information you may get for the EA may be of little value. Define an EA vocabulary and Frequently Asked Questions (FAQ) to avoid confusion and display the progress dashboard on the Web for transparency. From your side, lack of EA development experience and poor definition of scope, deliveries, not fit for purpose, i.e. (typically large documents with poor focus) can increasingly deteriorate credibility as the development process is stalled by unusable outputs and by disputes about how the artifacts are to be used. 123

Agile processes with frequent deliveries and wide consultations will help make the process transparent and accountable. EA roles and responsibilities have to be well designed to avoid overlaps generating confusion and conflicts and, in the end, politics. Work as a team is crucial as the domain and span of activities is much too large. Bottlenecks have to be quickly discovered and eliminated. Observe EA inhibitors since they could stop your EA development early, and find ways to conquer them from the beginning. Accountability and empowerment, recognition and award as company values will pave the way to progressive success in eliminating a culture of politics. After the first few deliveries, it is important to police all other development work, install EA compliance controls (checkpoints) in all relevant business processes, provide training and easy access. Otherwise your EA may be ignored, forgotten. EA Risks and Change Management EA is perceived as a threat as, in reducing duplication in process, platforms and projects, it creates people redundancies, it brings change. Change Management (CM) becomes essential in the Enterprise transformation execution process since people can and will resist, will do partisan fighting since, after all, their job is at stake for no grander purpose. CM has to work along to provide a path forward for all affected by the migration process to expose the greater good, to motivate. Early preparation is essential to avoid problems. The EA team must have a vast knowledge spanning business, IT and people issues and be socially and politically astute. Selection of the proper EA team constitutes the major risk in this development. This team will not only have to develop the EA properly, but will have to explain it in simple terms everybody can understand, and then gracefully deploy EA compliance controls in all major business processes defeating the inherent resistance. The Enterprise Architect has to be politically literate to justify EA/SOA, argue the business case, rally support from stakeholders, keep management informed and optimistic, do the work and survive the process! Review checklist 1. List EA triggers. 124

Chapter 21: EA Roadblocks, Culture and Politics 2. Enumerate and explain EA roadblocks and give recommendations. 3. Talk about culture and politics. 4. How do you select an Enterprise Architect? 5. What do you need to sell the EA? 6. What are the political factors which have to be considered in EA development? 7. Culture, what are the key elements? 125

Chapter 22 13. EA State, future Outlook and the Virtual Enterprise The Future Outlook for EA This looks like a legitimate question. Is Enterprise Architecture going anywhere? It is, albeit slowly in the absence of an agreed practical framework and clear proof of its business case. The reason is straightforward: EA is a necessary "evil". Any system needs a blueprint enabling proper operation, maintenance, planning... To fulfill the expectations, EA needs to satisfy its many stakeholders in top management, business, technology/IT and organization. Here are a few directions, I can see the Enterprise Architecture progressing, in no particular order: A. EA will finally be recognized as a business discipline, having incorporated Value Chains, Business Models, Strategic Planning... B. The EA evolves to increasingly cover business architecture rather than IT alone; the Enterprise Architecture will be the result of the fusion of IT, Business and Organization/People architectures; what is the value of an applications architecture, without the process it implements or the people operating it? C. The governance for EA will be more & more business and top management heavy; this is because it would be used in mapping the strategy to components, to derive the enterprise transformation portfolio, make investments and take strategic and tactical decisions. D. The EA development will be increasingly triggered by Mergers & Acquisitions and outsourcing activities; IT BPO, SaaS(ASP) are riding a strong current right now. E. The Enterprise Architect would be more and more called in the business decision making process; because the EA architect deals with the business logic, technology operation and strategy, is able to understand both worlds and use both business and IT vocabularies. 127

F. A combined EA framework emerges to take advantage of the strengths of various frameworks, such as Zachman, TOGAF, FEA and others. G. SOA is recognized as part of the EA program as the target EA style of architecture and technology, rather than executed in isolation as it often happens H. EA would be increasingly required by shareholders/owners/investors to provide the blueprint of the business operation to describe assets, provide proof of regulatory compliance, map costs and profits on various operations and align strategy. The US government mandates EA to the public sector. EA would become a regulatory feature for public listed companies. Review checklist 1. Describe the current situation in the EA field. 2. What is usually not in scope of EA and how does it affect adoption? 3. Why is the Enterprise more and more virtualized? 4. Explain the EA layers virtualization. 5. What is the role of SOA in virtualization. 6. Describe the link between virtualization and outsourcing. 7. What are the suggested trends for EA evolution? 128

129

References I. described by M. E. Porter in his book, “Competitive Advantage” II. http://www.value-chain.org/en/cms/?1960 III. http://www.supply-chain.org/cs/root/home IV. Kurzweil’s Law – Ray Kurzweil: KurzweilAI.net March 7, 2001 V. Concepts of Framework for Enterprise Architecture – John Zachman, 1996 VI. ANSI/IEEE Std 1471-2000 VII. GAO6-831, August 2006, http://www.gao.gov/new.items/d06831.pdf VIII. SearchCIO.com - CIO Definitions, June 8, 2005. October 13, 2006 IX. TOGAF FAQ 8.1 X. Jeanne W. Ross, Peter Weill, David C. Robertson, Enterprise Architecture As Strategy, Harvard Business School Press, 2006 XI. Enterprise Architecture-Achieving Business Value with IT - MS Solutions , 1999 XII. You Can’t Cost-Justify Architecture - John Zachman, 2003 XIII. described by M. E. Porter in his book, “Competitive Advantage” XIV. 1993, Robert S. Kaplan and David P. Norton published the Balanced Scorecard. In 1996 XV. "Concepts of Framework for Enterprise Architecture" 1993- Zachman International XVI. TOGAF v 8.1.1 Enterprise Edition, http://www.opengroup.org/togaf. a summary XVII. https://www.tmforum.org/browse.aspx XVIII. more information available at http://www.enterprise-architecture.info/ XIX. http://www.pera.net/ XX. Zachman on architecture frameworks, 1996 XXI. From www.ashlandschool.org XXII. http://www.doi.gov/ocio/architecture/documents/core/rpt-FEA_TRM.html XXIII. http://www.opengroup.org/sib.htm XXIV. Ostenwalder , Y. Pigneur, and C.L. Tucci http://www.businessmodeldesign.com/ publications/Preprint%20Clarifying%20Business%20Models%20Origins,%20 Present,%20and%20Future%20of%20the%20Concept.pdf XXV. Jeanne W. Ross, Peter Weill, David C. Robertson, "Enterprise Architecture As Strategy" book, Harvard Business School Press, 2006. Posted October 3, 131

2006 XXVI. http://www.value-chain.org/ XXVII. http://ww.itjobswatch.co.uk/charts/permanent-demand- trend.aspx?s=enterprise+ architecture&l=uk 132

Acronyms TERM DESCRIPTION Authentication Authorization and Accounting – a framework AAA for controlling access to computer resources ABC Activity Based Costing Application Programming Interface - A language and message API format used by an application program to communicate with the operating system or other control programs B2B Business to Business - E-commerce models that help companies work together via the Internet Business to Consumer - E-Commerce models for selling to B2C consumers over the Internet A framework with recommendations by bank supervisors and Basel II central bankers from the 13 countries making up the Basel Committee on Banking Supervision to revise the international standards for measuring the adequacy of a bank's capital BC/DR Business Continuity/Disaster Recovery BFM Business Functions Map/Model BI Business Intelligence BRM Business Reference Map BOA Business Oriented Architecture BoB Best of Breed Business Process Execution Language - standard XML based BPEL language BPEL4People BPEL for Human Interactions 133

TERM DESCRIPTION BPM Business Process Map/Model Business Process Management - Monitoring and altering BPM business processes that span multiple applications and systems within and across the Enterprise Business Process Modeling Language - a platform BPML independent XML based language for modeling business processes BPO Business Process Outsourcing Business Reference Map; the generic Enterprise Business BRM Functions Map CAPEX Capital Expenditure - Money spent to acquire or upgrade physical assets such as buildings and machinery CDI Customer Data Integration Chief Executive Officer - The executive responsible for a CEO company's operations Chief Information Officer – The executive responsible for CIO management information systems or data processing in a company Clinger-Cohen The Clinger-Cohen Act (or Information Technology Act Management Reform Act legislation) was created to improve the way the US Federal Government acquires and manages information technology CMDB Configuration Management Database Capability Maturity Model: organizational model describing 5 CMM levels in which an organization manages its processes (usually used in IT) Customer Relationship Management - An integrated software CRM system used to plan, schedule and control the pre-sales and post-sales activities in a company 134

Acronyms TERM DESCRIPTION CRUD Create, Read, Update, Delete Critical Success Factors - Key areas of activity in a company in CSFs which favorable results must be achieved to successfully meet objectives Chief Technology Officer - The executive responsible for a CTO company's technical part DoDAF Department of Defense Architecture Framework (US) DPMO Defects Per Million Opportunities (Six Sigma) DW Data Warehouse E2AF Extended Enterprise Architecture Framework from IFEAD EA Enterprise Architecture Enterprise Application Integration - connecting multiple EAI applications within the Enterprise for the purpose of interchanging data and coordinating business processes EAP Enterprise Architecture Planning, Spewak Enterprise Portfolio Management - how the organization is EPM managing investment portfolios and makes investment decisions Enterprise Resource Planning - a multi-module software ERP application used by companies to manage inventory, resources, and business processes across departments Enterprise Services Bus - open standards-based distributed ESB messaging middleware that provides secure interoperability between Enterprise applications via Web Services interfaces enhanced Telecommunication Operations Map - a business process model or framework that describes all the Enterprise eTOM/NGOSS processes for a service provider in the Telecommunication Industry Next Generation Operations Systems Support 135

TERM DESCRIPTION Federal Enterprise Architecture Program Management Office, FEA PMO Reference Model US Federal Enterprise Architecture - an EA framework used by FEAF US government FFLV Function-Flow-Layer-View - author’s proposed EA framework Porter’s Five Forces Analysis – a formal industry analysis used Five Forces in marketing strategies Governance Operations Development Support – author’s Main GODS Functions classification in an Enterprise GUI Graphical User Interface HR Human Resources Hyper Text Transfer Protocol - a communications protocol that HTTP enables Web browsing IEEE Institute of Electrical and Electronics Engineers Internal Rate of Return - A present-value based measure used IRR for determining the compounded annual rate of return on investments held for a time period of one year or more ISO International Organization for Standardization IT Information Technology IT Infrastructure Library - Developed for the UK Government, is ITIL a set of best practices in IT services ITSM IT service management, based on ITIL Java 2 Platform, Enterprise Edition - developed by SUN J2EE Microsystems is a platform for the development and operation of web-based applications Java Database Connectivity - An IT standard for database- JDBC independent connectivity between a computer platform or 136

Acronyms TERM DESCRIPTION device operating in the JavaTM environment and a wide range of databases Key Performance Indicators - Indicators used by an KPIs organization to define and measure its progress toward the goals and objectives LoB Line of Business, Business Area MDM Master Data Management MOF Microsoft Operations Framework Net Present Value - The future stream of benefits and costs NPV converted into equivalent values today Organization for the Advancement of Structured Information OASIS Standards – an organization that drives the development and adoption of e-business standards. ODBC Object Data Base Connectivity Operating Expenses - Expenses incurred in conducting normal OPEX business operations like wages, salaries, administrative, research and development costs Open System Interconnect - a reference model for OSI communications and computer network protocol design Political, Economical, Social, Technological, Environmental, PESTEL Legal – a strategic analysis framework used by a company to identify the key influences of its environment and industry Payback Period - The amount of time taken to break even on Payback an investment PMO Program Management Office Return on Enterprise Architecture – author’s proposed RoEA financial indicator to measure Enterprise Architecture benefits Return on Investments - a financial ratio used as a measure ROI of company’s performance SaaS Software as a Service, outsourced, off premises application a 137

TERM DESCRIPTION successor of the Application Service Provider, ASP Supply Chain Management - An integrated software system SCM used to plan, schedule and control the supply chain of an Enterprise SEI Software Engineering Institute Service Level Agreements – agreement between an SLAs Application Service Provider and an end-user SMB Small to Medium Business Service Oriented Architecture - Provides a blueprint for SOA services-based, Enterprise business solutions Simple Object Access Protocol - a XML based protocol for SOAP exchanging information in a distributed environment SOEA Service Oriented Enterprise Architecture Sarbanes-Oxley Compliance - U.S. Public Company Accounting SOX Reform and Investor Protection Act SPEA Single Page Enterprise Architecture SQL Structured Query Language SSL Secure Socket Layer Single Sign-On – An authentication process that permits a SSO user to identify himself once in order to get access to multiple applications SWOT Analysis - a strategic planning tool used to evaluate the SWOT Strengths, Weaknesses, Opportunities, and Threats of a company 138

Acronyms TERM DESCRIPTION TCO Total Cost of Ownership Universal Description Discovery and Integration - a directory UDDI model for Web Services Unified Modeling Language - an object-oriented analysis and UML design language VPN Virtual Private Network eXtended Mark-up Language - language used to design a XML markup language for easy interchange of documents on the World Wide Web WOA Web Oriented Architecture W3C World Wide Web Consortium Web Services - self-contained, modularized functions using WS open standards that can be accessed across a network independent of technical architecture. Web Services Description Language - an XML formatted WSDL language used for describing Web services WS-Human Web Services process specifications for Human Tasks Task interaction 139

INDEX A Agile Processes .............................................................................................................................................................. 72, 199, 237 Agility ................................................................................................................................................. 18, 36, 46, 48, 54, 153, 167 Alignment .................................................................................................................................................................... 18, 45, 55, 159 Application16, 19, 28, 42, 45, 106, 109, 114, 115, 129, 130, 154, 161, 162, 164, 168, 221, 223, 225, 250, 272, 273, 286, 2 Applications Reference Map ............................................................................................................................................. 120, 122 Architecture principles ....................................................................................................................................................................147 As-Is24, 94, 105, 126, 147, 155, 169, 170, 173, 176, 197, 201, 213, 215, 223, 229, 244, 252, 268, 281, 282, 283 B B2B .......................................................................................... 19, 115, 116, 151, 172, 176, 224, 236, 256, 271, 276 Balanced Scorecard .................................................................................................................. 71, 181, 199, 246, 263, 291 Basel II........................................................................................................................................................................... 26, 34, 35, 286 Best Practices ..................................................................................................... 16, 23, 25, 83, 147, 172, 193, 194, 200 Blueprint ................................................................................................................................................................................................... 55 Bottom-Up .......................................................................................................................................................... 177, 197, 201, 282 BPEL .....................................................................................................................................................66, 67, 163, 236, 263, 273 BPM1, 16, 45, 55, 63, 66, 67, 71, 72, 109, 114, 154, 162, 163, 164, 165, 169, 172, 174, 176, 177, 195, 210, 234, 236, 251 BPMN ........................................................................................................................................................................................................ 67 BPO ................................................................................................ 28, 35, 45, 174, 225, 258, 271, 274, 276, 277, 294 BRM ............................................................................................................................................................................ 19, 20, 140, 294 Business (Functions) Reference Map ................................................................................................................ 116, 120, 222 Business Architecture .............................................................................................. 32, 66, 96, 120, 234, 246, 251, 269 Business Case ............................................................................. i, 51, 194, 195, 243, 244, 245, 256, 279, 282, 288 Business Flow ........... 20, 22, 93, 99, 117, 118, 120, 127, 132, 139, 140, 142, 149, 203, 212, 234, 279 Business Flows Map .............................................................................................................................. 20, 120, 127, 132, 139 Business Flows Reference Map .......................................................................................................... 22, 93, 117, 118, 120 Business Functions20, 22, 43, 78, 92, 99, 118, 120, 129, 132, 139, 140, 141, 142, 149, 157, 173, 200, 203, 206, 207, 214, Business Functions Map20, 22, 99, 118, 120, 132, 139, 140, 142, 157, 173, 203, 206, 207, 214, 279, 282, 283, 294 Business Process Management ............................................................................. 16, 26, 45, 66, 162, 236, 251, 294 Business Process Outsourcing............................................................................................................................. 274, 275, 294 Business Reference Map15, 19, 26, 83, 93, 117, 127, 133, 137, 140, 141, 173, 201, 206, 280, 281, 294 Business Strategy................................................................................ 18, 28, 54, 100, 179, 195, 201, 216, 236, 283 C CAPEX ...................................................................................................................... 31, 46, 51, 52, 53, 54, 55, 56, 230, 294 CDI ......................................................................................................................................................................... 152, 212, 268, 294 Checklist ................................................................................................................................................................................................. 282 Clinger-Cohen Act ..................................................................................................................................................................... 35, 294 CMM ................................................................................................................ 34, 35, 47, 68, 72, 153, 169, 236, 244, 294 COBIT...................................................................................................................................................................................... 65, 66, 236 Compliance .................................................................................................................... 22, 28, 48, 49, 56, 71, 90, 153, 298 141

Context ........................................................................................................................................90, 91, 99, 140, 157, 205, 282 CRM ............................................................................................... 64, 88, 96, 100, 151, 153, 163, 223, 232, 237, 294 CRUD .................................................................................................................................................................... 102, 103, 212, 295 CSFs ................................................................................................................................................................................. 199, 244, 295 Culture ...................................................................................................................................................... 101, 249, 254, 260, 266 D Data Architecture ........................................................................................................................................ 43, 78, 90, 182, 283 Developmenti, 17, 19, 52, 56, 65, 70, 80, 83, 92, 109, 110, 113, 114, 116, 119, 193, 199, 220, 225, 226, 237, 249, 267, 279, 280 DoDAF ................................................................................................................................ 16, 21, 73, 76, 149, 234, 236, 295 Drivers ............................................................................................................................................................................................31, 153 E E2AF ................................................................................................................................................................ 82, 83, 147, 235, 295 EA definition.............................................................................................................................................................. 41, 42, 243, 246 EA Framework ......... 21, 73, 86, 87, 102, 138, 195, 196, 219, 220, 221, 223, 224, 225, 236, 279, 286 EAI16, 28, 42, 45, 63, 64, 66, 109, 129, 161, 162, 163, 209, 220, 237, 251, 252, 295 EAP .......................................................................................................................................................... 74, 82, 83, 147, 235, 295 Encapsulation ...................................................................................................................................................................................... 105 Enterprise Architecture definition ......................................................................................................................................... 41, 63 Enterprise Architecture Framework ..............................................................................................................................196, 295 Enterprise Reference Map ............................................................................................................................................. i, 109, 279 Enterprise Service Bus..................................................................................................................................... 42, 162, 169, 197 Enterprise Strategy ........................................................................................................................................ 179, 187, 215, 307 Enterprise Transformation ................................................ 43, 90, 171, 179, 188, 215, 219, 282, 283, 286, 287 Enterprise view ................................................................................................................................................................................... 199 EPM ......................................................................................................................................................................................................... 295 ERP16, 32, 64, 96, 100, 151, 162, 163, 197, 199, 201, 223, 226, 232, 235, 237, 257, 258, 281, 282, 295 ESB42, 45, 63, 64, 66, 106, 109, 129, 161, 162, 163, 166, 167, 169, 172, 174, 197, 209, 215, 237, 252, 263, 276, 295 eTOM ............................................................................................................................ 82, 83, 150, 216, 236, 255, 268, 295 F FEA ......................................................................... 16, 73, 75, 76, 82, 83, 101, 104, 147, 234, 235, 277, 291, 295 FFLV97, 102, 137, 139, 140, 141, 143, 144, 145, 147, 148, 149, 150, 163, 226, 247, 279, 280, 284, 288 Finance ........................................................................................................................................................................................102, 117 Financial ....................... 17, 35, 54, 55, 56, 65, 90, 99, 100, 105, 114, 153, 181, 183, 199, 224, 236, 259 Five Forces .................................................................................................................................................................... 181, 183, 296 Flow78, 80, 85, 87, 88, 93, 94, 96, 98, 99, 100, 102, 118, 137, 138, 139, 142, 144, 149, 202, 208, 209, 212, 215, 279, 280, 281, Framework Tree .....................................................................................................................................................................139, 140 Functional Architecture ................................................................................................................................................. 94, 99, 214 Functions16, 20, 21, 78, 87, 88, 89, 90, 92, 93, 94, 95, 96, 97, 98, 99, 101, 102, 103, 104, 107, 113, 114, 116, 118, 120, 132, 13 G GODS.............................................................. 19, 92, 93, 97, 109, 113, 114, 116, 119, 127, 220, 226, 279, 296 Governance16, 19, 45, 92, 100, 109, 110, 113, 117, 119, 181, 195, 220, 223, 225, 227, 236, 259, 271, 276, 279, 280, 296 142

Index I Information Architecture ........................................ 78, 96, 102, 103, 120, 142, 148, 149, 157, 177, 212, 282 Infrastructure41, 55, 65, 71, 80, 96, 100, 121, 124, 129, 142, 147, 148, 155, 159, 211, 215, 220, 223, 225, 233, 237, 253, Infrastructure Reference Map ......................................................................................................................................... 121, 124 IT Architecture .......................................................................................................28, 114, 151, 162, 163, 170, 220, 253 ITIL ........................................................ 28, 64, 65, 72, 162, 163, 164, 219, 220, 221, 226, 236, 258, 259, 296 J J2EE .........................................................................................................................................................................................................296 JDBC .............................................................................................................................................................................................. 64, 296 L Layer85, 87, 88, 89, 96, 98, 99, 100, 101, 102, 104, 105, 109, 129, 137, 138, 139, 144, 149, 201, 202, 212, 215, 221, 279 Leadership ................................................................................................................................................................................ 238, 239 Lean Sigma ................................................................................................... 28, 32, 45, 67, 69, 153, 216, 234, 251, 252 Line ................................................................................... 25, 88, 102, 110, 119, 127, 132, 138, 144, 173, 285, 297 Line of Business........................................................................................................................ 110, 119, 127, 132, 173, 297 LoB ...........................................................................................................................104, 109, 110, 119, 132, 203, 229, 297 Location .................................................................................................................................................................................................. 104 M MDA ......................................................................................................................................................21, 91, 197, 236, 280, 284 MDM ................................................................................................152, 153, 174, 210, 212, 232, 259, 274, 276, 297 Metamodel........................................................................................................................................................................................ i, 141 Mission ............................................................................................................................................................................ 194, 204, 282 MOF ............................................................................................................................................................................................. 163, 297 N NGOSS ......................................................................................................................................................... 82, 236, 255, 268, 295 NPV ................................................................................................................................ 15, 52, 58, 59, 60, 61, 247, 263, 297 O Operating Model ............................................................................. 43, 100, 109, 110, 111, 120, 236, 269, 281, 284 Operations19, 35, 65, 70, 82, 92, 93, 109, 113, 114, 117, 153, 163, 206, 212, 220, 225, 226, 258, 279, 280, 295, 296, 297 OPEX ......................................................................................................................... 31, 47, 51, 52, 53, 54, 55, 56, 230, 297 Organization design............................................................................................................................................................... 109, 214 OSI ......................................................................................................................................................................... 166, 237, 272, 297 143

P Performance ............................................................. 28, 42, 76, 77, 83, 102, 104, 198, 199, 236, 251, 258, 297 PESTEL ............................................................................................................................................................................ 181, 184, 297 Porter ......................................................... 19, 70, 93, 112, 113, 114, 181, 183, 236, 269, 271, 276, 291, 296 R Return on Enterprise Architecture ........................................................................................................................... 15, 52, 297 Roadblocks .................................................................................................................................................................... 249, 250, 259 Roadmap ........................................................................................................................................................................ 187, 188, 220 RoEA .......................................................................................................................................... 15, 28, 51, 52, 53, 57, 247, 297 S SaaS ............................. 16, 28, 35, 45, 162, 163, 169, 171, 174, 225, 258, 269, 271, 274, 276, 277, 297 SCOR ............................................................................................................................. 19, 93, 113, 114, 116, 150, 236, 268 Security ............................................................................. 65, 89, 90, 102, 103, 104, 161, 166, 198, 221, 226, 281 Security Architecture ............................................................................................................................................................221, 226 Service Oriented Architecture ...................................................................................... 16, 45, 162, 165, 167, 236, 298 Single Page Architecture ................................. i, 26, 120, 129, 134, 200, 209, 234, 280, 281, 283, 284, 285 Single Page Enterprise Architecture ................................................................................................................. 132, 135, 298 Six Sigma ...................................................................................... 34, 35, 67, 162, 163, 164, 169, 236, 263, 285, 295 SOAi, 16, 24, 25, 26, 28, 35, 43, 45, 48, 55, 63, 64, 67, 106, 109, 129, 152, 153, 155, 162, 163, 165, 166, 167, 168, 169, 170, Solution Architecture ...............................................................................16, 155, 156, 157, 158, 159, 164, 229, 232 SOX ...................................................................................................................................... 26, 35, 49, 71, 105, 285, 286, 298 SPEA................................................................................................................................................................................. 132, 135, 298 Stakeholders .............................................................. 43, 48, 56, 90, 91, 140, 147, 183, 185, 205, 206, 256, 281 Strategic Planning ....................................................................................................................... i, 16, 18, 147, 179, 277, 307 Support ... 17, 33, 65, 70, 92, 101, 109, 113, 114, 117, 119, 132, 195, 220, 225, 226, 267, 279, 296 T Target Architecture.......................................................................................................................................................................... 283 TCO .............................................................................................................................................................................. 34, 47, 224, 298 Technology Architecture ....................................................................................................................................... 32, 43, 90, 149 Time to Market ............................................................................................................................................ 34, 52, 54, 55, 56, 57 To-Be .. 24, 55, 94, 103, 105, 126, 147, 169, 185, 197, 199, 200, 201, 215, 244, 252, 268, 281, 282 Trends ........................................................................................................................................................................... 1, 33, 181, 182 Triggers ................................................................................................................................................................................................. 249 U UDDI ...................................................................................................................63, 64, 166, 167, 172, 174, 263, 273, 298 Use Cases................................................. 43, 87, 91, 147, 203, 205, 236, 250, 256, 268, 280, 281, 282, 284 Utility.............................................................................................................................................................................................114, 182 144

Index V View36, 85, 87, 88, 89, 93, 94, 96, 98, 99, 100, 101, 102, 103, 104, 105, 115, 132, 137, 138, 139, 144, 145, 147, 148, 149 Views77, 81, 83, 87, 88, 89, 90, 96, 98, 99, 100, 101, 102, 103, 104, 105, 107, 121, 137, 138, 139, 140, 141, 144, 145, 14 Virtual Enterprise ............................................................................................................. 16, 113, 267, 269, 270, 271, 274 W Web Services63, 66, 106, 129, 162, 165, 166, 167, 171, 172, 195, 232, 236, 237, 258, 271, 273, 295, 298, 299 WOA ............................................................................................................................................................. 67, 165, 167, 177, 299 WS .................................................................................................................................63, 67, 162, 166, 167, 263, 271, 299 WSDL .........................................................................................................................63, 166, 167, 172, 174, 263, 273, 299 X XML............................................................................... 63, 129, 130, 154, 161, 167, 168, 172, 263, 294, 298, 299 Z Zachman.. 16, 21, 22, 31, 73, 74, 79, 82, 83, 147, 148, 150, 216, 234, 235, 236, 255, 256, 277, 291 145

i Kurzweil’s Law – Ray Kurzweil: KurzweilAI.net March 7, 2001 ii Concepts of Framework for Enterprise Architecture – John Zachman, 1996 147

Book extracts: An Enterprise Architecture Development Framework

0 comments

Notes on slide 1

2 Favorites