Enterprise Architecture & Integration - PDF

Enterprise Architecture & Integration Enterprise Architecture Enterprise – business or company Architecture - A framework and set of guidelines to build new systems What is Enterprise Architecture? A method for managing your business or enterprise :  A decision making tool...

Enterprise Architecture & Integration Enterprise Architecture Enterprise – business or company Architecture - A framework and set of guidelines to build new systems What is Enterprise Architecture? A method for managing your business or enterprise :  A decision making tool  A change management tool  The knowledgebase of your business or enterprise What is EA ? The primary reason for developing an enterprise architecture (EA) programmed is to have a clear picture of your organization and learn how it works from the business to IT and how business visions and strategy can be met. EA enables you to align organizational structures, processes, applications and technology to help business services get delivered at less cost, higher quality and higher speed. An enterprise architecture programmed helps steer your business in the right direction, prepare to deal with disruptive business and IT change, and invest in the right projects. “Enterprise architecture consists of the vision, principles and standards that guide the purchase and deployment of technology within an enterprise” Forrester, Gene Leganza. Scope of Enterprise Architecture? The scope of enterprise architecture includes the enterprise’s  People,  Processes,  Information Technology,  their relationships to each other,  And the external environment Who is Enterprise Architect? Enterprise architects are the people who:  create the solutions to address the business challenges  and support the enterprise in implementing those solutions. Scope of enterprise architecture ▪ Current perspectives, or beliefs, with regards to the meaning of the enterprise architecture, typically fall towards one or a hybrid of three schools of thought: ▪ Enterprise IT design – According to this school, the purpose of enterprise architecture is the greater alignment between IT and business concerns. ▪ The main purpose of enterprise architecture is to guide the process of planning and design the Information System capabilities of an enterprise, in order to meet desired organizational objectives. ▪ Enterprise integrating – According to this school, the purpose of EA is to achieve greater coherency between the various concerns of an enterprise (HR, IT, Operations, etc.) including the linking between strategy formulation and execution. ▪ Enterprise ecological adaptation – According to this school, the purpose of enterprise architecture is to foster and maintain the learning capabilities of enterprises so that they may be sustainable. Consequently, a great deal of emphasis is put on improving the capabilities of the enterprise to improve itself, to innovate. Benefits of enterprise architecture ▪ The benefits of enterprise architecture are achieved through its direct and indirect contributions to organizational goals, in the following areas: ▪ Organizational design - Enterprise architecture provides support in the areas related to design and re-design of the organizational structures during general organizational change. ▪ Project portfolio management - Enterprise architecture supports investment decision-making and work prioritization. ▪ Project management - Enterprise architecture enhances the collaboration and communication between project stakeholders. ▪ Requirements Engineering - Enterprise architecture increases the speed of requirement elicitation and the accuracy of requirement definitions, through publishing of the enterprise architecture documentation. ▪ IT management and decision making - Enterprise architecture is found to help enforce discipline and standardization of IT planning activities and to contribute to reduction in time for technology-related decision making. ▪ IT value - Enterprise architecture helps reduce the systems implementation and operational costs, and minimize duplication of IT infrastructure services across business units.  IT complexity - Enterprise architecture contributes to reduction in IT complexity, association of data and applications, and to better interoperability of the systems.  IT risk management - Enterprise architecture contributes to reduction of business risk from system failures and security breaches. Enterprise architecture helps reduce risks of project delivery. Enterprise Architect ▪ Enterprise architects are practitioners of enterprise architecture; ▪ Enterprise architects work with stakeholders, both leadership and subject matter experts, ▪ to build a holistic view of the organization's strategy, processes, information, and information technology assets. ▪ The role of the enterprise architect is to take his knowledge and ensure that the business and IT are in alignment. Enterprise Architect ▪ The enterprise architect links the business mission, strategy, and processes of an organization to its IT strategy, ▪ that show how the current and future needs of an organization will be met in an efficient, sustainable and adaptable manner. Integrated Enterprise Information Systems? Enterprise  A business, an industrious effort, especially one directed toward making money Information System  An Information System (IS) is a system composed of people and computers that processes or interprets information. Integrated  Joined together, united, made into a whole by having brought all parts together Enterprise Engineering (EE) EE is defined as the body of knowledge, principles, and practices to design all or a part of an enterprise. An enterprise is a complex system that comprises interdependencies, resources of people, information and technology that must interact with each other and their environment in support of a common mission. EE is a sub discipline of industrial engineering/System engineering. Zachman Framework Zachman Framework is an enterprise ontology and is a fundamental structure for enterprise architecture which provides a formal and structured way of viewing and defining an enterprise. The ontology is a two dimensional classification schema that reflects the intersection between two historical classifications. Example of a retail company integrating an e-commerce system What (Data) Planner: List of products, customers, orders, and inventory. Owner: Semantic model showing relationships between products, customers, and orders. Designer: Logical data model with entities like Product, Customer, Order, and their attributes. Builder: Physical data model, including database tables and schemas for Product, Customer, Order. Implementer: Data definitions for the actual databases and data storage systems. Worker: Actual data records in the system (e.g., list of all products, customer records, order transactions). How (Function): Planner: List of business processes like purchasing, sales, inventory management, and customer service. Owner: Business process model showing the workflow of order processing from customer purchase to delivery. Designer: Application architecture describing modules for order management, customer relationship management (CRM), and inventory control. Builder: System design specifications including detailed designs of modules and their interactions. Implementer: Programs and scripts that execute the business processes. Worker: Actual execution of the business processes in the system (e.g., processing an order, updating inventory). Example of a retail company integrating an e-commerce system Where (Locations): Planner: List of physical locations such as headquarters, warehouses, retail stores, and distribution centers. Owner: Business logistics system showing the distribution network and relationships between locations. Designer: Distributed system architecture showing how different system components are deployed across locations. Builder: Technology architecture describing the network infrastructure, servers, and communication links. Implementer: Network architecture detailing configuration of routers, switches, and servers. Worker: Actual network setup and operations ensuring communication between different locations. Who (People): Planner: List of organizational units like sales, marketing, customer service, and IT support. Owner: Workflow model detailing roles and responsibilities of different teams and individuals. Designer: Human interface architecture describing how users interact with the system, roles, and permissions. Builder: Presentation architecture including design of user interfaces for different roles. Implementer: Security architecture defining access controls, authentication, and authorization mechanisms. Worker: Actual users interacting with the system, following defined roles and responsibilities. Example of a retail company integrating an e-commerce system When (Time): Planner: List of business events like sales promotions, inventory restocking, and fiscal reporting periods. Owner: Master schedule for key business activities and cycles, such as quarterly reviews and marketing campaigns. Designer: Process structure defining timing and sequencing of business processes. Builder: Control structure specifying event-driven triggers and batch processes. Implementer: Timing definitions for job schedules, cron jobs, and automated tasks. Worker: Actual execution and monitoring of scheduled events and processes. Why (Motivation): Planner: List of business goals and strategies, such as increasing market share or improving customer satisfaction. Owner: Business plan detailing objectives, strategies, and tactics to achieve business goals. Designer: Business rule model defining policies, constraints, and business rules that govern operations. Builder: Rule design specifying implementation of business rules in the system. Implementer: Detailed rule definitions for the actual coding and configuration of business rules. Worker: Actual enforcement and application of business rules during operations. The Evolution of Enterprise Architecture Enterprise architecture was developed by John Zachman while with IBM in the1980s, after observing the building and airplane construction industries and the IT industry. He saw similarities between the construction of buildings, airplanes, and the information systems used by an enterprise. These industries manage the design, construction, and maintenance of complex products by considering the needs of different people. The Evolution of Enterprise Architecture The owner in the building industry, who uses architect’s drawings to decide that the building addresses specific requirements. For airplane manufacture, the owner uses the high-level work breakdown structure of the plane to determine requirements. For information systems, the owner uses a model of the business to determine the enterprise needs. The Evolution of Enterprise Architecture The designer, however, needs a different set of diagrams:  architect’s plans for the building,  sets of engineering design diagrams for the plane,  or information system models for the enterprise. The Evolution of Enterprise Architecture The builder relies on still different types of diagrams:  contractor’s plans for construction of the building,  a manufacturing engineering design for plane construction,  or technology models for information systems. The Evolution of Enterprise Architecture The Evolution of Enterprise Architecture What is needed is important to know. This is represented in Figure 2 by material, such as bills of materials for buildings and planes, and data models for information systems. How these are used is indicated by functions, such as functional specifications for buildings and planes, and functional models for information systems. Where is also important, as indicated by location—in drawings for building and plane construction and in network models for information systems The Evolution of Enterprise Architecture There are a further three columns— Who, When, and Why —in the complete Zachman framework for enterprise architecture Enterprise Architecture Methods 1  Methods for Building Enterprise Architecture 2 Evolution of Systems Development Methodologies Methodologies that have evolved since the beginning of the Information Age  Have helped to examine current manual processes so could automate them. From elementary methodologies in the 1960s to 1970s these had evolved into the “software engineering methods” 3 Evolution of Software Engineering SEmethods analyzed current manual processes  Documenting them with:  Data flow diagrams (DFDs)  Functional decomposition diagrams (FDDs).  Structure of modular programs to structure charts (SCs). Programswere then written in various programming languages to execute the automated processes. 4 Evolution of Software Engineering Manual processes, used in enterprise, often evolved different ways. For example,  A process to manually accept an order (an order entry process) may differ;  How the order was received: by mail, by phone, or from a salesperson,  Also depend on the specific products or services ordered 5 Evolution of Software Engineering All intended to achieve objective “accept an order for processing.” When processes were automated, found many automated order entry processes. When a change needed, that change had to be made to every version of that process throughout the enterprise. 6 Evolution of Software Engineering (3) The result was also chaos: “program maintenance chaos!” Resulted in redundant data store versions, moving us to “data maintenance chaos!” Redundant costs are regularly invited by enterprise today in redundant data, in redundant staffing, and in redundant training. A negative effect on the bottom line, in reduced profits for commercial Enterprises. 7 Evolution of Information Engineering Late 1960s & 1970s, a research fellow at IBM Labs, was foundation of the relational database technology that we still use today. The first relational database management systems (RDBMSs) were released by:  IBM Corporation (IBM DB2 RDBMS)  Oracle Corporation (Oracle RDBMS) From the mid-1970s, approaches emerged addressed the development of data modeling methods, using normalization to eliminate redundant data versions. 8 Evolution of O-O Methods In 1980s, the concepts of O-O development and UML were developed. Effective in developing reusable code. Use a number of diagrams to model various aspects for O-O development:  class, state transition, use-case, collaboration, sequence, and activity diagrams. 9  Evolution of UML Rational Corporation develop associated UML modeling Software tools, widely used in the late 1990s. IBM purchased Rational Corporation in 2003, The Rational software tools became IBM software tools 10 Review of Enterprise Architecture 11 Business Knowledge Needed for EA EA applied in a top-down approach, Business expertise is critical; “EA requires business specialist experts, including IT, to work together in a design partnership.”  Business experts know the business,  IT experts know the capability and limitations of computers. Each draw on their respective areas of expertise, to determine the most effective process and technology solutions for the business. EA builds on this business knowledge and allows experts to apply their respective knowledge 12 Technology Decisions Using EA IT is regarded as “overhead cost” expense, IT decisions should be treated exactly like any other business investment decision. For example, the criteria to investment whether for building a new plant, a new manual system, or a new automated system: What costs are involved in construction? What benefits will be delivered? How long will it take for the completed to realize these benefits? What is the expected ROI that will be delivered? Will the completed plant/system enhance future business13 flexibility? Technology Decisions Using EA Important condition is the last bulleted point,  “Support and enhance the ability of the business to change rapidly whenever required in the future” Because the only thing that is stable today... is CHANGE itself!!! 14 EA and the Pace of Change Most technology decisions are based on traditional systems development, unable to change. Focus on automating current processes, processes are typically instable parts of enterprises. To be able to be changed easily, rapidly, and often, systems must be stable. “Processes are instable, but data are stable.” 15 EA and the Pace of Change Considerthe following examples:  Accounting processes:  Past involved pencil, paper, and double ledger.  Today most accounting processes are automated.  Banking:  Past early twentieth centuries involved passbooks with handwritten teller entries.  Today most banking is automated via ATMs, phone banking, or Internet banking. 16 EA and the Pace of Change Data do change, but change slowly than processes. Current business processes are plans set by management some 5 or 10 years ago. The systems for tomorrow must be based on strategic plans:  “that are defined today, for that future tomorrow.” For example, communication with customers or suppliers;  Processes of yesterday assumed took days or weeks (via mail).  Processes of today and tomorrow, communication now takes minutes—often seconds. 17 EA and the Pace of Change Business activities and processes change, faster than the existing systems in an enterprise. A focus of enterprise architecture for business transformation. 18  Government Methods for Building Enterprise Architecture 19 Federal Enterprise Architecture Framework Much activities in defining approaches for building Enterprise Architecture, here we will discuss the federal enterprise architecture framework. This mandates, by law, that all U.S. federal government departments and agencies must use Enterprise Architecture. The Federal Enterprise Architecture Framework (FEAF) is well documented and readily available from the Internet. 20 FEAF approaches Enterprise Architecture The FEAF approaches Enterprise Architecture from four levels: Level I:  Referred as the view from 20,000 feet, When parachuting from a plane, the earth is very distant from this height.  This is the highest FEAF level, introducing major 8 federal enterprise architecture components: Architecture drivers, Transitional processes, Strategic direction, Architectural segments, Current architecture, Architectural models, Target architecture, Standards. 21 FEAF approaches Enterprise Architecture Level II:  Represents the view from 10,000 feet. The earth is also indistinct from this height.  Expands detail in the eight components for FEAF.  Greater detail of the business and design components. Level III:  This is the view from 5,000 feet. Some detail is noticeable, but it is still blurry.  The FEAF report states that it shows three design architectures: 1. data, 2. applications, and 3. technology.” 22 FEAF approaches Enterprise Architecture Level IV:  This is the view from 1,000 to 500 feet, detail can be overwhelming as the earth rushes toward you.  The FEAF report comments: “It identifies the business architecture and the first three design architectures: data, applications, and technology…..It defines enterprise architecture planning (EAP).” First three levels provide high-level views of the EA. At Level III there is a relationship to the Zachman framework is seen. 23 Enterprise Architecture Planning (EAP) EAP focuses on comparing and analyzing data, applications, and technology. The discussion from the FEAF report refers to the four EAP “layers” shown in Figure: 24 Federal Enterprise Architecture Framework & Enterprise Architecture Plan The FEAF draws on the work by Dr. Steven Spewak Called “Enterprise Architecture Planning”. Provides guidance on the top two rows of the Zachman framework;  for the Planner and Owner. The FEAF makes the point that the EAP approach used by Spewak does not address design. 25 Enterprise Architecture Plan “layers” Layer 1—Getting Started:  Produce an EAP work plan & Stresses the management to commitment  Planning initiation covers decisions on;  Which methodology to use,  who should be involved,  what other support is required,  and what toolset will be used. Layer 2—Where We Are Today:  A baseline for defining the architecture to be and the long-range migration plan.  Business Modeling is a compilation of a knowledge base about the business functions and the information used in supporting the various business processes.  Current Systems & Technology defines current application systems and supporting technology platforms. 26 Enterprise Architecture Plan “layers” Layer 3—The Vision of Where We Want to Be:  Basic process flow: data, applications and technology architecture.  Data Architecture: data needed to support the business.  Applications Architecture: application needed to manage that data and support the business functions.  Technology Architecture: technology platforms needed to support the applications that manage the data and support the business functions. Layer 4—HowWe Plan to Get There:  Implementation Plan/Migration Strategy  Defines the sequence for implementing applications,  layout a schedule & cost/benefit analysis 27 FEAF redefines the Zachman framework The FEAF was initially developed based on the first three Zachman interrogatives. FEAF is mapped to the first three columns of Zachman framework (What, How, and Where) as follows:  Data Architecture is mapped to column 1 (What);  Applications Architecture is mapped to column 2 (How);  Technology Architecture is mapped to column 3 (Where). 28 FEAF compose five basic models The use and observance of these models is vital for Office of Management and Budget (OMB) approval for resources. 29 Hierarchical relationship between five models Performance Reference Model (PRM):  Framework for performance measurement  Provides common application measures throughout enterprise.  Allows to better manage the business at a strategic level while providing a means for gauging progress toward the target FEA.  Version 1.0 was issued in September 2003 https://www.techopedia.com/definition/24247/performance- reference-model-prm 30 Hierarchical relationship b/w five models Business Reference Model (BRM):  A function-driven framework  Describing the business operations of the enterprise  Organizational view, thereby promoting intra- and inter-agency collaboration.  BRM, Version 2.1 had been published. Service Component Reference Model (SRM):  Business driven and is a functional framework  Classifies service components and describes how they support business and performance objectives.  Service areas that provide a foundation for reuse of applications, application capabilities, components, and business services.  Version 1.0 was completed in June 2003. 31 Hierarchical relationship b/w five models Technical Reference Model (TRM),  which Version 1.0 is now available,  TRM was Created to:  A model to join enterprise Technical Reference Model and existing e-guidance.  Focus technology standards, specifications, and recommendations on the Internet and related approaches.  Focus on the secure delivery and construction of service components and their interfaces. 32 Hierarchical relationship b/w five models Data Reference Model (DRM):  Released October 20, 2004.  It describes, an aggregate level, the data and information that support program and business line operations.  The DRM states that:  “the starting point from which data architects should develop modeling standards and concepts.”  Ensure that technology is business driven and the emphasis is on standardizing the business functions. 33 FEAF Summary TheFEAF is a good example of an enterprise approach:  Used to decrease the overall size of the IT & associated huge costs within enterprise.  Rationalize their information technology infrastructures across the various lines of business, services, and/or programs.  The FEAF report concludes with a discussion of  returns,  risks,  and costs of enterprise architecture.  Provides guidance on how to plan and manage a EA but it is inadequate if used as the sole source for EA guidance, because it does not provide any assistance with methods for defining the various artifacts or models (Who, When, Why). 34 Managing and Delivering Enterprise Architecture What is on-demand computing? On-demand computing is a delivery model in which computing resources are made available to the user as needed. The resources may be maintained within the user's enterprise, or made available by a cloud service provider. When the services are provided by a third-party, the term Cloud Computing is often used as a synonym for on-demand computing. The on-demand model was developed to overcome the common challenge to an enterprise of being able to meet fluctuating demands efficiently.  Because an enterprise's demand on computing resources can vary drastically from one time to another, maintaining sufficient resources to meet peak requirements can be costly. Conversely, if an enterprise tried to cut costs by only maintaining minimal computing resources, it is likely there will not be sufficient resources to meet peak requirements. The on-demand model provides an enterprise with the ability to scale computing resources up or down with the click of a button, an API call or a business rule. Virtualization Concepts Virtualization is a process that allows for more efficient utilization of physical computer hardware and is the foundation of cloud computing. Virtualization uses software to create an abstraction layer over computer hardware that allows the hardware elements of a single computer—processors, memory, storage and more—to be divided into multiple virtual computers, commonly called virtual machines (VMs). Each VM runs its own operating system (OS) and behaves like an independent computer, even though it is running on just a portion of the actual underlying computer hardware.  It follows that virtualization enables more efficient utilization of physical computer hardware and allows a greater return on an organization’s hardware investment. Today, virtualization is a standard practice in enterprise IT architecture. Benefits of virtualization Resource efficiency Easier management Minimal downtime Faster provisioning Costs of Integration Role of Modeling Tools Computer-aided software engineering (CASE) tools first appeared in the early 1980s. These tools were based on the premise that computer technologies could assist systems analysts and DBAs in their analysis and design efforts in much the same way that computer-aided design (CAD) tools provide design assistance to architects and product designers. Computer-aided manufacturing (CAM) tools further offer help by translating product designs to robotic commands, so that products can be manufactured using automated factory robots. These CAD tools are widely used today in building architecture and the automated robot-controlled manufacture of automobiles.  Many data modeling notations existed in the 1980s; most are still widely used today. Some of these include entity/relationship (E/R) modeling ,information engineering. These different data modeling approaches were based on the relational theory and normalization principles defined by Edgar Codd and documented by Chris Date Modeling Tool Products The following products of Modeling Tool are : Rational Software System Architect Proforma Provision IDS Scheer ARIS Visible Advantage and Visible Analyst Key Enterprise Architecture Principle Evolution to the Twenty-First-Century Enterprise Evolution to the Twenty-First-Century Enterprise By the second half of the twentieth century, we recognized that our manual processes were operating in a state of manual chaos. But with the introduction of the computer we did not change those processes; we automated them with improvements—but essentially without much change. The result: We moved from manual chaos to automated chaos. Today we have twenty-first-century enterprises functioning with eighteenth-century processes.  We have not effectively utilized the Internet technologies of today for the rapid-change environment in which most organizations find themselves. Architects of the Enterprise Enterprise architects are the senior managers who set the directions for the future, based on processes designed for that future and its technologies. The future cannot be based on eighteenth-century processes that no longer respond to the rapid-change environment of today and the even greater change environment of tomorrow. The future will be based on business transformation through processes that use the technologies of today and tomorrow to complete in minutes and seconds what before took days and weeks, with strategic directions set by senior management and with business experts and IT experts working together in a design partnership. Systems Development Directions in the Twenty-First Century In Chapter 1 we saw that traditional systems development methods that identify business needs from existing operational business processes are no longer responsive enough.. The traditional systems development approach—interviewing users based on existing business processes and then identifying their future needs—do not work well in periods of rapid change, such as today. If we base our needs for the future on operational processes that we still use today, we are implicitly assuming that the future will be similar to the past.  This is very dangerous; few industries and enterprises can say today that their future will be like their past. Most know that the future will be quite different. We saw that the rapid delivery methods of enterprise architecture, when applied under the direction of senior management, result in business transformation This brings us to a very important principle to accommodate change: We must design for tomorrow based on business plans for the future, not the existing business processes that we still have today. Many of these existing processes reflect our needs for a pre-Internet past that will never return. Even if the same processes must remain for regulatory or legislative reasons, the rapid delivery methods and technologies that are available today enable these existing processes to be implemented so that they are more responsive. Lecture 4 Strategy Analysis (SA) 1 Drucker’s questions A mission statement is also called a “mission and purpose”  To provide clear guidance it should answer Drucker’s questions: What is our business? Who is the customer? Where is the customer located? What products or services does the customer want from us? What does the customer consider as value? What is the customer prepared to “pay”? What will the business be, in the future? What should the business be, in the future? What is the key strategic thrust? Most organizations focus on business processes—on “how” they operate, rather than “what” their reasons are for existence. 2 Steps of Strategy Analysis 3 Steps of Strategy Analysis Strategy analysis has nine steps, as discussed in the following subsections. Carry out each of these steps to understand their application to strategy analysis when used for business planning.  Step 1: Understand the mission and purpose.  Step 2: Identify the major business areas.  Step 3: Determine what has to be achieved.  Step 4: Identify issues representing opportunities or problems.  Step 5: Determine what will achieve or resolve the issues.  Step 6: Define Key Performance Indicators (KPIs).  Step 7: Identify the current functions that exist.  Step 8: Allocate functional responsibility to implement strategies.  Step 9: Define job responsibilities for each function. 4  Step 1:Understand the Mission and Purpose The objective to understand the mission and purpose. An ideal mission should be timeless; identify directions now and into the future. It should clearly express:  What the business is doing now;  What is happening in the environment;  What the business should be doing in the future;  It should broadly indicate Geography, markets, customers, products, and services. To understand the mission and purpose, we must be aware of the environment and its change in the future. They also affect the public and private-sector organizations that operate in that environment as partners, customers, suppliers, and competitors. 5  Step 2: Identify the Major Business Areas After Step 1, analyze its focus to identify major business areas that should be involved. These are based on the organization structure. 6  Step 3: Determine What Has to Achieved Focuses on identifying and refining goals. This depends on the policies set by management. Goals and objectives are measurable targets. To be measured, they must be quantitative. They have three characteristics—measure, level, and time:  The measure defines what performance indicator will be used for measurement.  The level indicates what result value must be achieved.  The time specifies when that result should be achieved. Only when we know what result is to be achieved and the time frame, can we determine the most appropriate strategies or tactics—which indicate “how”. 7  Step 4 —Identify Issues Determine the strategies to follow for goals & issues.  Know problems or threats that are barriers to, or that delay goals.  Aware of the opportunities or technologies that enhance or facilitate their achievement. Issues can be internal or external to the organization. As well as defining issues, we can also list the organization’s strengths and weaknesses. Understanding of opportunities and threats, we can analyze strengths, weaknesses, opportunities, and threats in a SWOT analysis. 8  Step 5: Determine What Will Achieve or Resolve the Issues With SWOT knowledge of issues, know what has to be corrected or protected. Where we should focus our strengths to achieve opportunities or take advantage of technologies. Ask the following questions for each point discussed:  What should we do to take advantage of the opportunities?  What technologies are available to assist us?  What strengths can we use to help us?  What has to be done to resolve the problems?  What should we do to protect ourselves from the threats?  What should we do to correct our weaknesses? The focus is again “what should we do, not how do we do it”. 9 Step 6—Define Key Performance Indicators Performance measures are quantitative:  The result level to be achieved,  And the time for that achievement. But targets change over time, typically in the level or time for achievement.  “how to express goals that accommodate change”. A goal must define the performance measure. 10 Step 6—Define Key Performance Indicators KPIs cannot only define goal achievement, but also effectiveness of strategies.  E.g. The product pricing strategy was defined as; “Establish and maintain a pricing policy that will sustain achievement of market share”.  Set market share targets depends not only on pricing, but also on advertising.  Advertising costs money; a manager must decide what proportion of funding should be allocated to advertising. To allocate resources optimally, to achieve defined objectives 11 Step 7: Identify the Current Functions That Exist The managers provide us with a list of the current functions:  Corporate;  Finance;  Forecasting;  Marketing;  Sales;  Research and development;  Production;  Purchasing; For each strategy, identify the principal business activities, & may have to derive new functions and activities if needed. 12 Step 8: Allocate Functional Responsibility to Implement Strategies To establish action plans for strategy implementation, it allocates responsibility for achieving goals and KPIs. A matrix is developed, with each strategy on a separate row and each function listed as a column. Managers decide which function has primary responsibility for managing implementation. A solid bullet for primary function there can only be one solid bullet in each row. Other functions may involved; have secondary responsibility An open bullet in a cell indicates this. 13  Step 9—Define Job Role Responsibilities for Each Function The business function–strategy matrix also allows job role responsibilities for each function to be identified. Document the responsibilities for each manager appointed to a job role to manage these functions. For example, an arrow highlights the Finance column. Solid bullets that identify each strategy,  Where the chief financial officer (CFO) has primary job role responsibility, Open bullets that identify strategies,  Where finance and, its CFO has secondary job role responsibility with other functions. 14 Summary of Steps of SA  Benefits of Strategy Analysis SA is easy to learn and use. It normally requires 3 to 5 days of planning sessions by managers to develop tactical business plans.  Produces clear, performance-based goals, objectives, KPIs, and action plans.  Implements business plans.  Clear definition of quantitative goals and objectives.  Defines KPIs for performance measurement of changing goals.  Address opportunities and resolve issues.  Defines objectives or KPIs so implemented correctly and in a timely fashion. 16 Group Activity Create a SWOT Analysis and answer the following related to your capstone project. What costs are involved in construction? What benefits will be delivered? How long will it take for the completed to realize these benefits? What is the expected ROI that will be delivered? Will the completed plant/system enhance future business flexibility? 17 Individual Activity What is Strategy Analysis in your own explanation? Create your own SWOT (strengths, weaknesses, opportunities, and threats) Analysis as a Team Member. 18