Lecture 5 ENTERPRISE ARCHITECTURE METHODS 1 Methods for

Lecture 5 ENTERPRISE ARCHITECTURE METHODS 1

Methods for Building Enterprise Architecture 2

Evolution of Systems Development 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 1960 s to 1970 s these had evolved into the “software engineering methods” 3

Evolution of Software Engineering SE methods analyzed current manual processes ◦ Documenting them with: § Data flow diagrams (DFDs) § Functional decomposition diagrams (FDDs). § Structure of modular programs to structure charts (SCs). Programs were 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!” 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 1960 s & 1970 s, 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 DB 2 RDBMS) ◦ Oracle Corporation (Oracle RDBMS) From the mid-1970 s, approaches emerged addressed the development of data modeling methods, using normalization to eliminate redundant data versions. 8

Evolution of O-O Methods In 1980 s, 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 1990 s. 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 business flexibility? 13

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 (2) Consider the 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 (3) 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, tomorrow communication now takes minutes—often seconds. 17

EA and the Pace of Change (4) Business activities and processes change, faster than the existing systems in an enterprise. A focus of enterprise transformation. architecture for business 18