3) Module 2: Rapid Delivery Methods for EA
This Course comprises 10 Sections and a total of 58 lectures, over 16.5 hours. Each Section covers a rapid delivery method, together with many Exercises. Problems and Sample Solutions to ensure that you completely understand each method.
Section 5 teaches rapid, manual methods using visual inspection that have not been used before by technical data modelers. These methods have been used successfully over 20 years by Enterprise Engineering to deliver systems and databases into production progressively in 3-month deliveries. Using visual inspection, these manual methods:
- Identify business activities and business processes in a data map;
- Determine the project phase number of each entity in a data map;
- Derive project plans from a data map;
- Derive an Enterprise Architecture Portfolio Plan (EAPP) from any data map for project management purposes;
- Derives a Project Map for early milestone deliverables of sub-projects into production from complex business processes, so that early business benefits can be realized
This Section 5 includes Case Study Problems and Sample Solutions so you can learn how to use these rapid delivery methods effectively.
Section 1: Other Enterprise Architecture Frameworks
Lecture 0 provides a narrated introduction to Module 2: Rapid Delivery Methods fo Enterprise Architecture. It discusses the methods that are taught in a workshop environment, with Exercises, Problems and Sample Solutions. The Exercises are presented in Section 2 on Business-driven Data Modeling and in Section 3 on Business Normalization. Sample Solutions for these exercises are discussed during the relevant Lectures. Case Study Problems are more comprehensive and are downloaded in PDF as a Resource in each Lecture that uses them. The Sample Solutions are downloaded in Bonus Lectures at the end of the relevant Sections. The back of each Section Cover Page (when printed double-sided) includes a table of the various Resources Available for download in relevant Sections and Lectures.
Lecture 1 introduces the Federal Enterprise Architecture Framework (FEAF). The Clinger-Cohen Act of 1996 in the USA mandated that all US Federal Government Departments and the Dept. of Defense (DoD) use Enterprise Architecture. The Act ensured this mandate would be followed, by making the use of Enterprise Architecture a prerequisite for approval of the annual budget of funds paid to each Department to enable it to continue to operate in the forthcoming year.
Steven Spewack had published his book: “Enterprise Architecture Planning” in the mid-1990s, so this book and Enterprise Architecture Planning (EAP) was used as the original basis for developing the FEAF, extending EAP to support a federation of enterprises. We see how EAP is mapped to the Zachman Framework for Enterprise Architecture. FEAF explicitly states that: “It does not explain how to define the top two rows of the Zachman Framework in detail, but for the sake of the planning exercise, abbreviates the analysis”. FEAF provides no advice on the methods to be used for the Planner and Owner rows of the Zachman Framework. However, fortunately the methods presented in this workshop can be applied to the data models in the FEAF to identify reusable processes and to derive project plans from the FEAF data models to deliver priority processes rapidly into production as databases and systems in 3-month increments.
The FEAF is comprised of five Reference models: the Performance Reference Model (PRM); the Business Reference Model (BRM); the Service Component Reference Model (SRM); the Data Reference Model (DRM); and the Technical Reference Model (TRM). Each of these Reference Models is introduced during the lecture, as well as their relationship to each other.
Lecture 3 continues the discussion of the five Reference models of the FEAF, addressing each in greater detail: the Performance Reference Model (PRM); the Business Reference Model (BRM); the Service Component Reference Model (SRM); the Data Reference Model (DRM); and the Technical Reference Model (TRM).
The original intent of the FEAF was to integrate the Enterprise Architecture models of the various Federal Government Departments and Agencies. But the Federal Enterprise Architecture Program Management Office experienced difficulty in achieving this integration due to the different terminology used in each Govt. Dept. and Agency.
The BRM was an attempt to standardise on the terminology. It establishes common terminology for functions across Government and a foundation for the reuse of functions. Examples of the BRM for different functions (such as the BRM for Financial Management) are available from the Federal Enterprise Architecture Program Management Office website.
The lecture concludes by showing how the FEAF maps to the rows of the Zachman Framework for Enterprise Architecture. The later sections of this workshop will cover methods that can be directly applied to the FEAF Reference Models.
Click on the Resources button, then on the Download icon for Course Handouts (U M2S01L03.pdf) of this Lecture (3 slides per page, with room for hand-written notes adjacent to each slide). Save, Open and Print the Course Handouts in black & white or color. They show the full content of each slide.
Lecture 3 discusses The Open Group Architecture Framework V8 (TOGAF 8), although V9 had been announced when the video was recorded. TOGAF is a methodology for analyzing overall business architecture. It has a number of phases that are discussed in terms of the TOGAF Architecture Development Method Cycle (ADM Cycle): Phase A addresses the Architecture Vision; Phase B addresses the current and target business architecture; Phase C covers the information system architecture; Phase D addresses the technology architecture; Phase E addresses opportunities and solutions; Phase F is migration planning; Phase G is implementation Governance; and Phase H addresses architecture change management. Each of these phases expands into a number of sub-phases.
The advantage of TOGAF is that it documents each of the standards that should be followed in each of the phases and sub-phases, but it does not provide guidance on methods for rapid delivery of results. Each organization using TOGAF can apply its own methods in each phase. Fortunately, the methods covered in this Module 2 of the Workshop can be applied also to TOGAF – mainly in Phase C: information system architecture - to assist in achieving the rapid delivery into production of data and applications for Enterprise Architecture results.
Lecture 4 discusses the Department of Defense Architecture Framework (DoDAF). We earlier saw in Lectures 2 - 3 with FEAF that the Clinger-Cohen Act of 1996 in the USA mandated that every US Federal Government Department and Agency, including the Dept. of Defense (DoD), all use Enterprise Architecture.
Lecture 4 first reviews the initial DoD framework to meet this mandated Enterprise Architecture requirement. This was called C4ISR: which is an acronym that expands to “Command, Control, Communication, Computers, Intelligence, Surveillance, Reconnaissance”. The key requirement for DoD is interoperability – of equipment, communications and systems. Chapter 5 of the Reference textbook provides many examples of interoperability problems between DoD and its friendly Allied forces in various conflicts. C4ISR was based on Steven Spewak’s Enterprise Architecture Planning (EAP), as we saw for FEAF. We saw in that earlier lecture that FEAF was loosely based on the Zachman Framework. So also was C4ISR, but this foundation was not documented in C4ISR, with the result that it expanded its Product Deliverables with many diagrams that existed across many columns and in many rows of the Zachman Framework. That is, they represented “composites”, not “primitives”. You will remember in Section 1 of Module 1 we viewed a video clip of John Zachman where he discussed the importance of using diagrams that are primitives and the problems that arise with diagrams that are composites.
The Strategic Planning hierarchical terminology used in Commercial organizations: of Strategic; Tactical; and Operational differs somewhat from that used in DoD: Strategic; Operational; and Tactical. C4ISF uses three Views: the Operational View; the Systems View; and the Technical View. These are broadly mapped to the Zachman Framework rows. The C4ISR Product Deliverables are discussed, showing how many deliverables map across multiple columns and rows of the Zachman Framework, so confirming that they are indeed composites. C4ISR was V1.0 of the DoD architecture Framework. With V2.0 of C4ISR the name was formally changed to DoDAF V1.0. This is discussed in the next lecture.
Lecture 5 continues with a detailed discussion of C4ISR V2.0, now called DoDAF V1.0. With its evolution from C4ISR V2.0, DoDAF V1.0 Product Deliverables suffer from the same composite problems as did C4ISR V1.0 Product Deliverables, as discussed in Lecture 5. However, now the DoDAF documentation acknowledges the power of the Zachman Framework and starts from the Strategic Plans: i.e. from Col 6 (“Why”) of the Zachman Framework. The method of Entity Dependency Analysis, which is covered later in Section 5 of this Module 2 course (and in Chapter 7 of the Reference textbook) can be used very effectively with DoDAF to derive project plans from DoDAF data maps.
Lecture 6 discusses the detailed mapping of DoDAF V1.0 to each of the Zachman Framework rows and shows which Product Deliverables map to which columns. The problems of Product Deliverables mapping across multiple columns and down many rows - that we saw in Lecture 5 with C4ISR - also exist with DoDAF V1.0 because of its common origin in C4ISR.
Lecture 6 illustrates the various Product Deliverables examples in the DoDAF V1.0 Workbook. These are quite complex diagrams, but are all documented in the Course Handouts of this lecture in PDF. This means that - when downloaded – these PDF diagrams can all be greatly enlarged for readability as you view this lecture.
Section 2: Business-Driven Data Modeling for Strategic Modeling
Lecture 8 introduces the main conventions of data modeling. The purpose of data modeling is first defined. The concepts of data entities, data attributes and data associations are defined with examples.
A data entity (or just “entity”) is represented as a rectangular box in a logical data map diagram, where the name of the entity is shown in capitals and represents a physical database table when it is later implemented. The name of the entity is also expressed in the singular to represent one occurrence of the entity.
A data attribute (or just “attribute”) provides some detail about an entity and is shown in lower-case. It may appear inside the entity box in which it resides, or may be included in an Entity List, where each entity name is shown in capitals: its attributes are shown in lower-case, separated by commas and with surrounding brackets.
A data association (or just “association”) is shown in a data map as a line joining two related entities. Symbols are placed at each end of the association line where it touches each entity. The symbols represent business rules that govern the association between the related entities.
Slightly different symbols for association “degree” or “cardinality”and for association “nature” are used by the business-driven data mapping notation and the IT-driven data mapping notation.
The business-driven data mapping notation uses a “crows-foot” symbol to represent the association “degree” of one or many, while the absence of a crows-foot represents the association “degree” of one.
The business-driven data mapping notation for association nature uses a short bar across the association line to represent mandatory or “must”, with a zero on the line to represent optional or “may” and a zero and a bar on the line to represent optional becoming mandatory or “will”. Will is used to represent more complex business rules that are often time-dependent.
Lecture 9 continues with the conventions for associations.
The IT-driven data mapping notation uses a “crows-foot” symbol to represent the association “degree” of one or many, while a short bar across the association line represents the association “degree” of one.
The IT-driven data mapping notation for association nature uses a second short bar across the association line to represent mandatory or “must”, with a zero on the line to represent optional or “may”. However, the IT-driven notation does not have a symbol to represent optional becoming mandatory or “will”. More complex business rules that are often time-dependent are instead expressed as a text purpose statement that is attached to the association line.
This Lecture concludes with Exercise 1. Guidance is provided to assist in solving Exercise 1, Reference in the video is made to the Sample Solution on the CD that is provided with the First Edition Hardcover version of the Reference text. This Sample Solution can be downloaded in PDF from the Internet in the Third Edition eBook version of the Reference text. All Sample Solutions are discussed in the final Bonus Lectures 19-21 of this Section and are also able to be downloaded in PDF from the final Bonus Lectures 19-21 of this Section.
Click on the Resources Available button, then click on the “Chap-06-Problems.pdf” document to download it Save, Open and Print this document, which is from Chapter 6 of the Reference Textbook and documents all of the Exercises in this section.
Lecture 10 introduces the various data entity types, with many examples. It covers: Type entities; Principal (or “super-type”) entities; Secondary (or “sub-type”) entities; Exclusive Type entities; Inclusive Type entities; and Intersecting entities. Intersecting entities result from the decomposition of many to many associations. Intersecting entities typically indicate the presence of business activities, business processes or business systems.
Lecture 11 discusses Intersecting entities further, and then introduces a special form of Intersecting entities: Role entities, where a many to many association exists between a Type entity and its related Principal entity. Several examples are provided.
This Lecture concludes with Exercise 2, which requires you to draw a simple data map for an Airline Sales organization. The steps you should follow are discussed as Tasks.
The Sample Solution to Exercise 2 is also provided to be downloaded in PDF from the final Lecture 20 of this Section 2.
Lecture 12 introduces the final data entity type: Structure entities. The typical format of a Structure entity is discussed. With the entity types we have discussed in the earlier lectures of this section, all occurrences of an entity are related (by associations) to all occurrences of one or more other entities.
Sometimes an entity can be related to itself: this is called a recursive association. (It is sometimes called a “convoluted” association.) Structure entities are used to represent recursive associations, where one occurrence of an entity can be related to one of more other occurrences of the same entity.
Structure entities can be used to capture expert rules that govern which occurrences are related to other occurrences of the same entity. These expert rules constitute expert business knowledge. Structure entities can be used for very efficient processing of this expert knowledge. Several examples are given of Structure entities. Structure entities are covered in further detail in Section 3 on Business Normalization.
Lecture 13 demonstrates how data map associations can be used to express various business rules that illustrate alternative business strategies. A number of data map fragments are used to illustrate these alternative strategies.
This Lecture concludes with Exercise 3. This requires you to draw a data map for a furniture store with a range of products. Guidance is provided to assist in solving IExercise 3, Reference in the video is made to the Sample Solution on the CD that is provided with the First Edition Hardcover version of the Reference text. This Sample Solution can be downloaded in PDF from the Internet in the Third Edition eBook version of the Reference text. The Sample Solution is also provided to be downloaded in PDF from the final Lecture 20 of this Section.
Lecture 14 first discusses the need for clear Purpose Descriptions to be defined for every data entity, data attribute and data association. These Purpose Descriptions clarify their real meaning and intent: in agreeing on these definitions, additional entities and attributes may be indicated.
If there is business expert agreement that these newly identified data entities, attributes or associations are important to the business now and in the future, they should be added. Entities are added to the data map and entity list. If additional associations are needed to other related entities, those associations are added to the data map. Newly identified attributes are added to the entity list.
Lecture 14 next introduces the concepts of Model-View Authority and Attribute Authority: for security and privacy control. It illustrates this control with many examples. Static Attributes, such as in Look-up tables and entities are covered.
Lecture 15 introduces Entity – Control links, also used for privacy and security control. Key Attributes are next discussed, with many examples for: primary keys; foreign keys; candidate keys; and compound keys.
Non-Key Attributes are covered next, with examples for: Selection attributes (also called Secondary keys); Group attributes; Elemental attributes; Repeating Group attributes; and Derived attributes.
Lecture 16 introduces Non-Key Attributes, which are covered next, with many examples for: Selection attributes (also called Secondary keys); Group attributes; Elemental attributes; Repeating Group attributes; and Derived attributes. Optional attributes are introduced, which will be covered further in Section 3 – when we learn about Business Normalization. Logical data domains for attributes are discussed, which are translated to physical data types by Modeling Tools when generating the physical database DDL from logical data models.
Lecture 17 summarizes the data attribute types that we have covered in Lecture 14 – 17.
Next IExercise 4 is discussed. This requires you to document in Entity List format, an Employee Register page as a source document, for later use in developing a data model from that Employee Register document.
Lecture 18 requires you to develop data maps for two exercises.
Exercise 5 requires a data map for a Garments Manufacturer. You are given the exercise statement and a number of tasks, to help you develop the data map.
Exercise 6 requires you to develop a data map for a more complex Exercise: that of an Vehicle Insurance Company. You are given a process-oriented, operational Exercise statement over several slides describing the various documents that must accompany a Vehicle Accident Insurance Claim. A number of tasks and hints are provided to help you develop the data map.
The Sample Solutions for all of the Exercises in this Section 2 are available in Bonus Lectures 19 – 21 for you to check against your solutions. These are the next three Lectures.
Lecture 19 discusses the sample solutions for each of the data mapping exercise Exercises 1 – 4 that you completed in this Section 2.
Have your solutions to Exercises 1 – 4 with you when you view and listen to my discussion of each sample solution. There will be differences between our respective solutions, as we were unable to get input from the relevant business experts for each Exercise.
Click on the Resources Available button, then on the “Chap-06-Solutions.pdf” document to download it. Save, Open and Print this document, which is from Chapter 6 of the Reference Textbook and documents all of the Sample Solutions for the Exercises in this section. Use this for reference in addition to the discussion of each Sample Solution in these Bonus Lectures 19-21.
Lecture 20 discusses the sample solution for Exercise 5 that you completed in this Section 2.
Have your solution to Exercise 5 with you when you view and listen to my discussion of each sample solution. There will be differences between our respective solutions, as we were unable to get input from the relevant business experts for each problem.
Lecture 21 discusses the sample solution for Problem 6 that you completed in this Section 2.
Have your solution to Exercise 6 with you when you view and listen to my discussion of each sample solution. There will be differences between our respective solutions, as we were unable to get input from the relevant business experts for each Exercise.
Data Section 3: Business-Driven Normalization to Define Future Business Needs
Lecture 22 provides a basic introduction to the concepts of Business Normalization, by using a real-life example of an Employee Register form to show how good document design, that allows for flexible business change, follows a number of important rules.
The concepts of the Relational Model for Data Base Management Systems (DBMS) is introduced by using the Employee Register form - that we first saw in Lecture 22 - to show how it is implemented as several relational database tables, joined by common keys.
Exercises 1 – 6 are presented to test your understanding of Primary Keys.
Exercise 7 is introduced as a Restaurant Receipt source document that will be normalized in further Exercises throughout section 3, to develop a Restaurant data model. The Sample Solution for Exercise 7 will be provided and discussed in the final Bonus lectures at the end of this Section 3.
Click on the Resources Available button, then on the “Chap-09-Problems.pdf” document to download it. Save, Open and Print this document, which is from Chapter 9 of the Reference textbook and documents all of the Exercises in this Section 3.
Lecture 24 discusses the origin of Normalization in mathematical set theory, as defined by Edgar (Ted) Codd in 1969 when he was a Fellow of IBM. It was developed further and documented in books by Chris Date. I refer to this as Traditional Normalization;, it has been used extensively by IT data modeling staff since then. However, it is quite complex and difficult for business people to apply.
From 1976 – 1980 as part of the development of Information Engineering (IE), I developed Business Normalization, which was designed to be easier for business experts and IT experts to use: working together in a design partnership. The main differences between Traditional Normalization and Business Normalization are discussed in the lecture.
Lecture 25 introduces the rule of First Business Normal Form (1BNF): remove repeating groups into a new entity; with examples. Following this, the Sample Solution to Exercise 7 from Lecture 23 is discussed and the unnormalized entity resulting from the Restaurant Receipt source document is used as the starting point for Exercise 8: to remove repeating groups into a new entity.
Lecture 26 introduces the rule of Second Business Normal Form (2BNF) - with examples. 2BNF states that attributes are removed that are: partly dependent on the primary key and dependent also on some other primary key; or are dependent on only part of a compound primary key. These partly-dependent attributes are moved into a new entity where they are dependent on the whole primary key.
Following this, the Sample Solution to Exercise 8 from Lecture 25 is discussed and the entity normalized to 1BNF resulting from the unnormalized Restaurant Receipt source document is used as the starting point for Exercise 9: to normalize to 2BNF.
Lecture 27 covers the rule of Third Business Normal Form (3BNF) - with examples. 3BNF states that attributes are removed that are: not dependent at all on the primary key but are dependent on some other primary key. These non-dependent attributes are moved into a new entity where they are wholly dependent on the entire primary key.
Next, the Normalization Cross-Check method is covered. This examines each attribute in turn and applies each of the 1BNF, 2BNF and 3BNF rules to each attribute. This helps business experts and IT experts identify data required to support possible future business needs.
In Lecture 28, the Sample Solution to Exercise 9 from Lecture 26 is used as a starting point for Exercise 10. This Exercise requires you to normalize the Sample Solution Exercise 9 entities to Third Business Normal form (3BNF).
This 3BNF entity is next analyzed further in Exercise 11 by applying the method for Normalization Crosscheck: to identify data that may be required to support future business needs of the Restaurant.
Lecture 29 introduces Fourth Business Normal Form (4BNF). This rule identifies attributes within a 3BNF entity that are optional or are value-dependent: they may not always appear in every occurrence of that entity. These optional or value-dependent: attributes are moved from that entity into another entity where their existence is mandatory. These other entities are typically Secondary entities.
Lecture 30 develops the concepts of Fifth Business Form (5BNF) further. We first learned about 5BNF entities in Section 2 Lectures 12 and 13. Lectures 30 and 31 now provide many detailed business examples of 5BNF.
Firstly, the Employee Structure example introduced in Lectures 12 and 13 is developed further, with detailed data values to illustrate. Secondly, a Product Structure in 5BNF is used to show the value in using Product Structure expert knowledge for Bills of Material and Where Used applications in Manufacturing.
Lecture 31 illustrates 5BNF further, with a Market Intelligence example. This uses the roles that organizations may take when operating in various Markets. It shows how 5BNF enables expert market knowledge to be used and automated in 5BNF tables so that it can be shared throughout the organization.
Lecture 32 first recaps each Exercise covered in Section 3, then discusses the Sample Solution for each of these Exercises.
Click on the Resources Available button, then on the Chap-09-Solutions.pdf document to download it. Save, Open and Print this document, which is from Chapter 9 of the Reference Textbook and documents all of the Sample Solutions for the Exercises in this Section 3. Use this for reference in addition to the discussion of each Sample Solution in these Bonus Lectures 32-33.
Lecture 33 recaps each Exercise 11 – 13 covered in Section 3, then discusses the Sample Solution for each of these Exercises.
Lecture 33 recaps each Exercise 11 – 13 covered in Section 3, then discusses the Sample Solution for each of these Problems in Section 4: Strategic Modeling - Case Study Problem 2
Section 4: Strategic Modeling - Case Study Problem 2
Lecture 34 first reviews the initial development of the Strategic Model for the Project Management Division of XYZ Corporation. This was covered in detail in Module 1 Section 3.
All responses from the Strategic Modeling Questionnaire, distributed prior to the development of the initial Strategic Model, are discussed. These Policy statements will be used as catalysts to expand the Strategic Model with additional entities to support those Policies.
Lecture 35 begins with a quick review of each of the Policy Statements from the Strategic Modeling Questionnaire. The Project Teams statement is discussed first, which adds 8 new entities to the Strategic Model. The Project Activities statement is discussed next: this adds 3 new entities. The Project Skills statement adds a further 3 new entities, then the Project Skills statement adds a further 3 new entities and the Project Resources statement adds 5 new entities.
In Lecture 36, the Project Resources discussion continues, to add 5 new entities.
Finally, the Related Budgets and Related Projects statements each add a 5BNF entity to use the expert knowledge gained from previous budgets and projects.
With these additional Policy statements from the Strategic Modeling Questionnaire, the Initial Strategic Model of 8 entities developed in the initial Facilitated Session in Module 1 Section 3 has now expanded to a total of 29 entities.
The Expanded Strategic Model is next examined to identify business activities, business processes, or business systems.
Each Intersecting entity, created when we earlier decomposed many-to-many associations is typically a business management activity, a business process, or a business system. They are each named by adding the suffix: “Management”, “Process” or “System” to the Intersecting entity name. In this way, we identify a total of 14 business management activities from the 29 entities in the Expanded Strategic Model.
With these named business management activities, business processes, or business systems: the business managers and business experts who are in the audience are asked to prioritize these as to their importance. The highest priority databases and systems will be developed and delivered into production first: using the methods that we will cover next, in Section 5.
In Section 5, We will learn how to derive Project Plans for these databases and systems, documenting them in an Enterprise Architecture Portfolio Plan (EAPP) and a Project Map to manage the rapid delivery of these priority databases and systems into production.
Section 5: Deriving Project Portfolios for Rapid Delivery – Case Study Problem 3
Lecture 37 reviews the Entity Dependency Rules, which were first introduced in Module 1 Section 3. These rules are used to derive project plans from a data model, as we see later in this lecture.
We will learn about Endpoint Entities, which are intersecting entities with many associations touching the intersecting entity. We also learn about Prerequisite Endpoint Entities, which are entities that many associations and also at least a mandatory one association touching it. Prerequisite Endpoint Entities indicate Early Milestone Deliverable sub-projects in more complex projects, as we will see in a Problem later in this Section 5.
Lecture 38 uses an automatically derived Enterprise Architecture Portfolio Plan (EAPP) – using Visible Advantage – to illustrate the concepts and derivation of Project Maps. We will develop an EAPP and Project Map later in Problems in this Section 5.
Lecture 39 introduces Problem 3a and shows an alternative method for deriving project phase numbers for each entity in a data map.
1) We examine the data map, looking for any entities that have only mandatory one associations touching them. These entities are not dependent on any other entities and so are Phase 1 entities. “1” is written in the entity box to show that these are Phase 1 entities.
2) Next following each one-to-many association away from every Phase 1 entity, we add “1” to the phase number of these related many entities. Write “2” in these entity boxes to show that these are “Phase 2” entities.
3) Continue, following each one-to-many association away from every Phase 2 entity and add “1” to the phase number of these related many entities. Write “3” in these entity boxes to show that these are “Phase 3” entities.
4) Continue, until all entity boxes have a phase number written in every entity box.
5) Check your solution against Bonus Lectures 44 and 45, which provide the Sample Solutions for each of the Problems in this Section 5.
Click on the Resources Available button, then on “Chap-07-Problems.pdf” to download it. Save, Open and Print the Problems for this lecture and for reference during later lectures in this Section 5.
NOTE: This Chap-07-Problems.pdf document relates to the Problem numbers in Chapter 7 of the Reference Textbook. It provides a print-out of the Strategic Model that you can use to write a phase number into each entity box. Problem 7a describes Problem 3a in the video; Problem 7b describes Problem 3b in the video; and so on.
Lecture 40 first reviews the Sample Solution for Problem 3a. Problem 3b is then introduced. This asks you to derive the project plan for PERSON SKILL MANAGEMENT, using the entity phase numbers from Sample Solution 3a, building the project plan in Outline format up, from the intersecting entity positioned at the bottom right corner of the page.
Lecture 41 now reviews the Sample Solution for Problem 3b. Problem 3c is then introduced. TASK SKILL is Phase 5 in the Sample Solution for Problem 3a. Problem 3c asks you to derive the project plan for TASK SKILL MANAGEMENT, using the entity phase numbers from Sample Solution 3a, building the project plan in Outline format up, from the intersecting entity 5) TASK SKILL positioned at the bottom right corner of the page.
Lecture 42 first reviews the Sample Solution for Problem 3c. Problem 3d is then introduced. PROJECT TEAM MEMBER TASK SKILL is Phase 6 in the Sample Solution for Problem 3a.
Problem 3d asks you to derive the project plan for PROJECT TEAM MEMBER TASK SKILL MANAGEMENT, using the entity phase numbers from Sample Solution 3a, building the project plan in Outline format, upwards from the intersecting entity 6) PROJECT TEAM MEMBER TASK SKILL positioned at the bottom right corner of the page.
Lecture 43 reviews the Sample Solution for Problem 3d. Problem 3e is then introduced.
Problem 3e asks you to develop a Project Map of the cluster for PROJECT TEAM MEMBER TASK SKILL MANAGEMENT, using Sample Solution 3d. You are asked to work out a method for drawing the Project Map as a Pert Chart, working from the Strategic Data Map and guided by the Sample Solution cluster that was developed for Problem 3d. Compare your solution against the Sample Solution 3e, shown in Bonus lecture 45.
Lecture 44 revisits the Sample Solution 3d that was earlier discussed. We find that, surprisingly, PROJECT was not included in the Sample Solution 3d cluster. How can a project team not have a project to work on? The entity dependency analysis has found a serious deficiency in the strategic model that was first developed in the Facilitated Example of Module 1 Section 3. The association from PROJECT MANAGER to PROJECT at that time was defined as mandatory one to optional becoming mandatory many.
This is a very weak business rule: it means that the project team will sit idle if there is no project for them to work on. This means that if no revenue is received from projects to pay salaries and other expenses, the Project Management Division may become bankrupt.
This weak business rule must be made more rigorous: the association from PROJECT MANAGER to PROJECT should redefined as mandatory one to mandatory many. This means that if there is no project, then a Default project exists; that project is for the project manager to help the Sales staff to sell more projects – through demonstrations, by taking prospects to visit past satisfied clients to help sell more projects and other such sales assistance.
The Sample Solution 3d is redeveloped using the above rigorous business rule. We see that the inclusion of PROJECT in the cluster also brings in the earlier-identified reusable processes for Project Budget Management and for Project Resource Management: due to the rigorous associations of mandatory one to mandatory many between PROJECT and PROJECT BUDGET; between PROJECT and PROJECT RESOURCE.
Click on the Resources Available button, then on the “Chap-07-Solutions.pdf” document to download it. Save, Open and Print the Sample Solutions for reference during lectures in this Section 5.
Bonus Lecture 45 shows how to derive a Project Map from a data map, manually, rapidly and easily, by visual inspection: based on the identification of Prerequisite Endpoint entities. These have many associations touching an entity AND ALSO at least one mandatory one association touching the entity, so making it the owner of that related entity.The Prerequisite Endpoint entities indicate Early Milestone Deliverables for complex projects, so that early Stage sub-projects can be implemented first, while later sub-projects are still being developed. Typically, these early milestone sub-projects can be delivered into production as databases and systems in 3-month increments.
Solution 3e shows how a Project Map can be documented as a Pert Chart from any data map, easily, by inspection.
Click on the Resources Available button, then on “U M2S05EAPP.pdf” to download it. This is the EAPP Report from Appendix 1 of the 5-day Rapid Delivery Workshop for Enterprise Architecture. This is the automatically derived EAPP Report for the Strategic Model, produced by Visible Advantage. Save, Open and Print the EAPP Strategic Report.
Section 6: Activity Modeling and Activity Based Costing
Lecture 46 introduces the concepts of Activity Modeling. Activity Models document “What” is to be done; Process Models document “How” a process is executed.
Activity Modeling is based on the US Department of Defense (DoD) IDEF0 technique and shows how to develop Activity Maps, Context Diagrams and Activity Hierarchy Diagrams.
An Activity Map comprises rectangular boxes with arrows touching each of the four sides of the rectangle. These are Input arrows, where the arrow-head touches the left side of the activity box; Control arrows, where the arrow-head touches the top side of the activity box; Output arrows, where the arrow-head points out from the right side of the activity box; and Mechanism arrows, where the arrow-head touches the bottom side of the activity box. These are called ICOM arrows.
Mechanism arrows indicate the resources used by an activity and are used for Activity Based Costing, covered in Lectures 48 and 49.
Activity Hierarchy Diagrams (also called Dependency Diagrams) show how activity boxes are related to each other, where the Output from one activity becomes the Input of the next activity to be carried out.
Lecture 47 discusses Dependency Diagrams and introduces the concepts of Activities, conceptually being repositories for Tasks. Inputs (messages) invoke these tasks in a specific sequence to execute a process. An analogy is used of a shopping excursion, with a technology example based on the use of Web Services.
Lecture 48 introduces the concepts of Activity Based Costing (ABC) as a technique for evaluating the cost of existing (“As-Is”) activities against the cost of future (“To-Be”) activities. ABC considers the cost and productivity impacts on activities of different inputs, controls, outputs and mechanisms (resources) as well as process improvements and technologies.
ABC is an accounting technique that enables costs to be associated with specific products or services, as distinct from traditional accounting that allocates costs to different organizational areas, making it difficult to determine where the real costs actually originate. ABC provides managerial accounting and decision-making information and presents a cost model allocated to activities that assists in the identification of all areas for improvement. It provides the baseline for comparison of alternatives.
The five steps for analysis of alternatives are discussed and an example is used of Supplier Invoicing activities based on data entry of supplier invoices received by mail on paper for input to the Accounts Payable application. A Technology alternative is discussed; instead of paper Supplier Invoices, receiving Supplier Invoices electronically as XML messages that are converted by software into the same format of invoices that are input to the Accounts Payable application.
Another example is given of dramatic process cost improvements made by Ford in the 1980s in its Accounts Payable application by paying Component Supplier Invoices based on the number of cars that are produced by the Assembly Line that pass Ford’s Quality Control Checks.
Lecture 49 continues the steps of Activity Based Costing (ABC) by implementing superior methods of performing an activity (determined by benchmarking or best practices) or by eliminating wasteful activities (non-value added activities). An example is used of eliminating the removal cost of sawdust in a Timber Saw Mill by selling the sawdust as a raw material for manufacturers of Particle Board for building construction. Another process improvement alternative is by eliminating non-value-add activities.
Lecture 50 refers back to the use of Activity Models and Activity Based Costing in the very large Government real-life project example discussed in Module 1 Section 4 Lectures 37 – 40. This was used with EA in the first 20 days of a 55-day time-boxed project to cost justify to Treasury Board the complete redevelopment of all of that Government Department’s databases and systems, replacing them with fully integrated databases and reusable processes that represented cost savings of hundreds of millions of dollars in redevelopment costs, and further annual operating cost savings of hundreds of millions of dollars.
Five steps are outlined using EA for cost justification, then the lecture discusses a book on Enterprise Architecture for senior management:
- Enterprise Architecture as Strategy: Creating a Foundation for Business Execution” by Jeanne Ross, Peter Weill and David Robertson, Harvard Business School Press, Boston: MA (2006)
This book discusses the Operating Models Quadrant and covers company examples, using a Core EA Diagram on one page for senior management. Examples are included from Delta Airlines and ING Direct (for Banking) and the Benefits of Enterprise Architecture are covered.
Section 7: Developing Workflow And Interface Design
Lecture 51 discusses the transformation of an activity model into a workflow model, for subsequent development of a process model that can be documented using Business Process Modeling Notation (BPMN), which is now supported by many modeling tools.
This method is first related back to the Zachman Framework for Enterprise Architecture and the difference between activity models and process models, first introduced in Section 6, is discussed in more detail.
BPMN workflow diagrams or BPMN process diagrams can later be automatically generated as executable, XML-based Business Process Execution Language (BPEL). BPEL is covered in Module 3: Rapid Delivery Technologies for EA.
The concepts of Data Access Processes for Create “entity name”; Read “entity name”; Update “entity name”; and Delete “entity name” (CRUD) are discussed. These were developed in the late 1970s as a fore-runner to Object-Oriented Methods, which became generally accepted in the late 1980s.
The 7 steps to be followed to transform an activity model into a workflow model are then discussed using a data model example. Entity Dependency Analysis (as discussed in Section 5) is used to derive two clusters from an example data model: these re “Job Skill Requirements Management” and “Employee Skills Management”.
Lecture 52 continues the 7 steps. A Decomposition Diagram is used to show sub-activities, these are then sequenced and Business Events are added to produce the final workflow model.
Lecture 53 uses the principles of entity dependency rules that we learned in Section 5 to infer menu structures and screen designs.
For Menu Structures, a Phase 1 entity in a cluster suggests a first-level menu item, a Phase 2 entity suggests a second-level menu item; while a Phase 3 entity suggests a third-level menu item and so on. We can also use phase numbers in a cluster to suggest a tabbed menu structure, as demonstrated in this Lecture.
For Screen designs, a one-to-many association in a data map suggests a Master – Detail Screen Design, while a one-to-many association between entity A and entity B and a one-to-many association between entity B and entity C suggests a Master – Detail – Detail Screen Design.
Section 8: Transforming To Tactical Data Model – Problem 4
Lecture 54 provides Tactics Statements from the Finance Department for Project Financial Reporting and for Budget Analysis. The entities in the Strategic Data Model that are of interest to to the Finance Department are highlighted and Clusters from the Strategic Data Model are provided.
Problem 4 requires additional entities to be added, based on the two Tactics statements, to expand the Strategic Data Model to a Tactical Data Model for the Finance Department.
Typically, Business Normalization (from Section 3) would also be used to identify data attributes to be added to the Tactical Data Model. Because of time constraints, I will not require you to do this for Problem 4.
Section 9: Tactical Data Model – Sample Solutions - Problem 4
Lecture 55 discusses the Sample Solution for Problem 4. We review the Tactical Data Model that was developed by the Finance Department and find that some new entities have been added: in particular, CUSTOMER and CUSTOMER PROJECT.
These were found to be a part of three paragraphs of the XYZ Project Management Division Mission statement, but they had been omitted from the Initial Strategic Data Model that was developed in Module 1, Section 3.
XYZ senior management had forgotten to invite the Finance Department to participate in the Facilitated Session to develop the initial Strategic Data Model. This error was corrected in the Finance Department Tactical Data Model.
Additional opportunities are identified to determine the profitability of, and investment in, specific Customer Projects.
Click on the Resources Available button, then on “U M2S09EAPP.pdf” to download it. This is the EAPP Report from Appendix 2 of the 5-day Rapid Delivery Workshop for Enterprise Architecture. This is the automatically derived EAPP Report for the Tactical Model, produced by Visible Advantage. Save, Open and Print the EAPP Tactical Report.
Section 10: Managing and Sustaining Enterprise Architecture
Lecture 56 reviews the main messages from the course. We hear again from John Zachman as he discusses the three alternatives for managing Enterprise Change: 1) by trial and error; 2) by reverse engineering; or 3) by going out of business. He further discuses the need for an enterprise-wide view to achieve reusability and we briefly review the methods that we learned in this course to achieve fully-integrated databases with no data redundancy and to identify reusable processes.
Lecture 57 reviews the four stages of Enterprise Architecture Maturity that we first discussed in Module 1. These are:
n Stage 1: Business Silos
n Stage 2: Standardized Technology
n Stage 3: Optimized Core
n Stage 4: Business Modularity
We briefly discuss the emerging 5###sup/sup### Stage: Dynamic Venturing followed by a Summary of the entire Course.