Lecture 6 Business Process Management Dr Taysir Hassan

Lecture 6: Business Process Management Dr. Taysir Hassan A. Soliman November 16, 2015 INF 411 Information Engineering Information Systems Dept. Faculty of Computers & Information

Outline ü Zachman framework for Enterprise Architecture ü Zachman in Healthcare ü Zachman in Education ü The Open Group Architecture Framework (TOGAF) ü Gatner • Federal Enterprise Architecture (FEA) • Comparison • Definitions • EUP & RUP • Business Process Management

Case Study: • IT systems that have become unmanageably complex and increasingly costly to maintain. • IT systems that are hindering the organization's ability to respond to current, and future, market conditions in a timely and cost-effective manner. • Mission-critical information that is consistently outof-date and/or just plain wrong. • A culture of distrust between the business and technology sides of the organization.

Med. AMore Case Study • Med. AMore is a chain of drug stores. It started as a regional chain in 1960. • In 1995, it developed an innovative software system that enabled it to run drug stores very efficiently. • It called this system Med. AManage, or MAM incorporated some innovate business ideas, such as patient-relationship management, inventory management, automated insurance billing, and even utility optimization.

Example case: MEM-EA • Internal conflicts between the technical and the business side. – Business side saw IT as reducing business agility. – IT side saw the business side as making impossible demands. Ø Crisis! Cath, CEO Bret, Business Manager Irma, CIO

CRV - from strategy to business requirements Cath, CEO Greg, Gartner Consultant • Greg asks Cath to specify her visions in business (not technical terms). • The visions are prioritised. • Cath decides the highest priority is "Med. AMore will reduce its purchasing costs by 10% by consolidating all regional purchasing into a central system". Ø CRV = Common Requirements Vision

What is CRV? • A process for capturing, discussing and documenting a shared common view of the strategic requirements driving the enterprise: 5 Position on the impact of environmental trends to the enterprise 5 Set of enterprise business strategies 5 Set of common strategic requirements derived from enterprise business strategies Business Change Requirements Environmental Trends Enterprise Business Strategies Business Information Requirements Information Technology Requirements Business Solutions Requirements The CRV document is an articulation of what will drive the enterprise’s future state

What is FEAF? • FEAF (Federal Enterprise Architecture Framework) provides an organised structure and a collection of common terms by which Federal segments can integrate their respective architectures into the FEA (Federal Enterprise Architecture).

What is FEAF? (Cont…) • FEA is a strategic information asset base that defines the business, information necessary to operate the business, technology necessary to support the business operations and transitional processes for implementing new technologies in response to the changing needs of the business.

Why FEAF?

Value of FEAF

External stimuli or change agents for the enterprise architecture. Defines the ”as-is” enterprise architecture. Consists of 2 parts: current business and design architectures (i. e. data, applications and technology). FEAF Components Refer to all standards (some of which may be mandatory), guidelines and best practices. Defines the ”to-be” enterprise architecture. Consists of 2 parts: current business and design architectures (i. e. data, applications and technology).

FEAF Components Consists of focused architecture efforts on major cross-cutting business areas and program areas. Supports the migration from the current to the target architecture. This includes migration planning, investment planning, engineering change control, etc. Guides the development of the target architecture and consists of a vision, principles, goals and objectives. Defines the business and design models that compromise the segments of the enterprise descriptions.

FEA – Federal Enterprise Architecture • FEA is the latest attempt by the US federal government to unite its agencies and functions in a single common and ubiquitous enterprise architecture. • FEA is the most complete methodology. It has a: – A comprehensive taxonomy, like Zachman’s framework. – An architectural process, like TOGAF. • FEA can be viewed as either a methodology for creating an enterprise architecture or the result of applying that process to a particular enterprise. • FEA includes everything necessary for building an enterprise architecture.

FEA – Reference Models: descriptions • Business Reference Model (BRM): – Gives a business view of the various business functions. • Service Components Reference Model (CRM): – Gives a more IT view of systems that can support business functionality. • Technical Reference Model (TRM): – Defines the various technologies and standards that can be used in building ITsystems. • Data Reference Model (DRM): – Defines standard ways of describing data. • Performance Reference Model (PRM): – Defines standard ways of describing the value delivered by enterprise architecture.

Comparing EA Approaches

How can we choose an EA methodology? • Go through the criteria for comparing and evaluating EA methodologies, that are important for your organisation. • Rate the methodologies. Ø What you may find out is that you need a blended approach, in which you create your own enterprise architecture, taking parts of different methodologies that provide the highest value for your specific needs.

x Discussions x • Several different EA Methodologies, quite different from one another. • Some of the methodologies complement one another, e. g. Zachman framework provides a taxonomy while TOGAF provides a process. • Enterprise architecture is a path, not a destination. • Main goal: to bring alignment to the business side and the technology side.

Definitions (1) • Architect—One whose responsibility is the design of an architecture and the creation of an architectural description • Architectural Artifact—A specific document, report, analysis, model, or other tangible that contributes to an architectural description • Architectural Description*—A collection of products (artifacts) to document an architecture

Definitions (2) • Architectural framework—A skeletal structure that defines suggested architectural artifacts, describes how those artifacts are related to each other, and provides generic definitions for what those artifacts might look like • Architectural methodology—A generic term that can describe any structured approach to solving some or all of the problems related to architecture

Definitions (3) • Architectural Process—A defined series of actions directed to the goal of producing either an architecture or an architectural description • Architecture*—The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution

Definitions (4) • Enterprise Architecture—An architecture in which the system in question is the whole enterprise, especially the business processes, technologies, and information systems of the enterprise • Architectural Taxonomy—A methodology for organizing and categorizing architectural artifacts

Definitions (5) • A Taxonomy – The classification of organisms in an ordered system that indicates natural relationships; the science, laws, or principles of classification.

From Previous Lectures

RUP Overview Phases Process Workflows Inception Elaboration Construction Transition Business Modeling Requirements Architecture & Design Implementation Test Deployment In an iteration, you walk through all workflows Supporting Workflows group activities logically Configuration Mgmt Management Environment Preliminary Iteration(s) #1 #2 Iter. #n+1 #n+2 Iterations Iter. #m+1 26

Configuration Management (CM) is a systems engineering process for establishing and maintaining consistency of a product's performance, functional and physical attributes with its requirements, design and operational information throughout its life.

CM process v The CM process is widely used by military engineering organizations to manage complex systems, such as weapon systems, vehicles, and information systems. v Outside the military, the CM process is also used with IT service management as defined by ITIL and industrial engineering, such as canals and bridges. v The Information Technology Infrastructure Library, also known as ITIL, specifies the use of a Configuration management database (CMDB) as a means of achieving industry best practices for Configuration Management.

CM process v. CMDBs are used to track Configuration Items (CIs) and the dependencies between them, where CIs represent the things in an enterprise that are worth tracking and managing, such as but not limited to computers, software licenses, racks, network devices, storage, and even the components within such items. v. The benefits of CMDBs include being able to perform functions like root cause analysis

• Project Portfolio Management: the activity of selecting which projects to keep in portfolio (because of their anticipated value) and which one to discard (because they will not add any value )

Important Definitions • Configuration Management (CM): is a systems engineering process for establishing and maintaining consistency of a product’s performance, functional and physical attributes with its requirements, design, and operational information through its life. • CM is used by military engineering organizations to manage complex systems, such as weapon systems, vehicles, and information systems. • Other systems such as industrial engineering segments as roads, bridges.

Software Deployment v Software deployment is all of the activities that make a software system available for use. v These activities can occur at the producer side or at the consumer side or both. v Examples of activities are install, activate, deactivate, uninstall, and update.

Extension of RUP • An extension towards enterprise IT architecture is given in the form of the Enterprise Unified Process.

Enterprise Unified Process • The Enterprise Unified Process (EUP)'s Portfolio Management discipline extends iterative/agile processes such as the Rational Unified Process and extreme programming to help improve the overall efficiency and the effectiveness of information technology (IT) projects within an organization by selecting and then managing viable software development projects.