Recommended
Recommended
More Related Content
Similar to Lecture -4-Enterprise-Security-Zachman-Framework.pptx
Similar to Lecture -4-Enterprise-Security-Zachman-Framework.pptx (20)
Recently uploaded
Recently uploaded (20)
Lecture -4-Enterprise-Security-Zachman-Framework.pptx
- 1. ITSY 4111 CYBER SECURITY ENTERPRISE SECURITY & ZACHMAN FRAMEWORK 1 LECTURE - 4
- 2. OBJECTIVES At the end of this lecture, students should be able to understand • The Zachman Framework for Enterprise Architecture • Primitive Models versus Composite Models • How Does the Zachman Framework Help with Cybersecurity? • Architectural Problem Solving Patterns • Enterprise Workshop • Matrix Mining • Nominal Group Technique • Minipatterns for Problem Solving Meetings 2
- 3. THE ZACHMAN FRAMEWORK FOR ENTERPRISE ARCHITECTURE • The Zachman Framework, invented by John A. Zachman, is an intellectual tool for describing enterprises. • Because enterprises are inherently complex, we need a powerful framework to describe them—a framework that divides and conquers complexity. 3
- 4. • The Zachman Framework (Figure 4-1) slices and dices complexity into rows and columns. • The columns are the six basic questions you could ask about any subject. • These interrogatives include: What? How? Where? Who? When? Why? • The rows represent a general overview of the human roles. 4
- 5. 5 Figure 4.1
- 6. 6
- 7. 7
- 8. • The hierarchy of every complex enterprise has: executives, business management, architects, engineers,technicians, and users. • Each of these roles can ask the same six questions; hence six cells per row. • Each row-column intersection in the Zachman Framework is a cell to be populated with models and specifications, which are representations of the enterprise. 8
- 9. PRIMITIVE MODELS VERSUS COMPOSITE MODELS • A primitive model is one that only includes entities from a single column. • Row 1 contains lists of primitives from each column. • Row 2 has hierarchies built from those lists (refer to Figure 4-1). • Keeping the columns separate in our models has many advantages. 9
- 10. • It makes the framework conceptually simple; • The model based upon the Zachman Framework can also be simple; and because the columns are independent, we can populate them in parallel. • Primitive models are relatively stable and slow- changing. 10
- 11. • Composite models combine primitives from multiple columns. • An example is a matrix that shows relationships between primitives, such as processes versus data. • With that matrix we can answer the question, “Which processes use which data?” • Composite models are necessary for assessing impacts between columns (such as what data is manipulated by which processes) and for describing implementations. 11
- 12. HOW DOES THE ZACHMAN FRAMEWORK HELP WITH CYBERSECURITY? NIST(National Institute of Standards and Technology) recommends the establishment of an organization wide risk management activity. This activity is responsible for the enterprise’s risk executive(function). • The risk executive is a key stakeholder in enterprise investment decisions, in particular information technology (IT) investments. 12
- 13. • The risk executive provides a business management perspective on risk (Row 2). • The Zachman Framework empowers the risk executive to have visibility in the enterprise in the context of making wise decisions in order to manage the enterprise’s security risks. • The risk executive ensures that from inception, every decision leading to an IT project and an IT system will consider security risk from day one. 13
- 14. • The Zachman Framework suggests that every organization should have an Enterprise Architecture (EA), a blueprint for change. • The risk executive uses the EA to assess risks, levy security requirements, and ensure continuous monitoring of implementation. 14
- 15. • One of the first actions that the risk executive should take is to establish an “auditor” user role in the architecture of every system. • Security control auditors can use the auditor user role to assure continuous monitoring of the systems and adequate levels of confidentiality, integrity, and availability. 15
- 16. EVERYONE HAS THEIR OWN SPECIFICATIONS • Zachman Framework is the Periodic Table of enterprise models. • It is a scientific abstraction that helps us to manage the real world. The true value of the Zachman Framework is the realization that everyone has their own models. • If the models are not meeting our needs or we don’t know how to organize them, we can reorganize them using the Zachman Framework. • The models should answer all the important questions from our perspective. 16
- 17. THE GOLDMINE IS IN ROW 2 • Row 1 of the Zachman Framework contains exhaustive lists of enterprise things, which are not inherently useful by themselves. • But when they’re turned into hierarchies in Row 2, we can visualize our enterprise and can navigate to clusters of commonality. 17
- 18. • Imagine, every type of data our enterprise manages,or every role in the enterprise, and every system. • Seeing this kind of information helps business management (which is the Row 2 perspective) make informed recommendations for executive decisions. • Because Row 2 models help people visualize the enterprise, we now have a new basis for fact-based decision making. 18
- 19. FRAMEWORKS FOR ROW 3 • Row 3 contains models from the Architect’s perspective. • Architects do not specify every detail, that’s what engineers do in Row 4. • The Row 3 frameworks generate mostly composite models which contain independent viewpoints. • The Institute of Electrical and Electronics Engineers (IEEE) has captured this concept formally in the standard IEEE-1471 . • IEEE-1471 is the recommended Practice for Architecture Description of Software-Intensive Systems. 19
- 20. • From an international perspective, there is a standard and universally applicable Row 3 framework. • This framework is jointly standardized by the International Telecommunications Union(ITU) and the International Standards Organization(ISO). • It is the Reference Model for Open Distributed Processing (RM-ODP). 20
- 21. ARCHITECTURAL PROBLEM SOLVING PATTERNS • People have been applying the Zachman Framework pervasively since its public release two decades ago. • An early method, documented by Stephen Spewak in the classic book ‘Enterprise Architecture Planning’ explained how to populate the first few rows with models. • It was a laborious process, easily taking six months or more. 21
- 22. • More than twenty years have passed and the techniques have evolved through thousands of engagements. The key techniques are as follows: • Business Question Analysis • Document Mining • Hierarchy Formation • Enterprise Workshop (explained in slide 21) • Nominal Group Technique • Minipatterns for Problem Solving Meetings (explained in slide 23) 22
- 23. ENTERPRISE WORKSHOP Also Known As: Large Group Consensus Forming, Review Meeting Problem Solving Type: Information Sharing, Convergent Thinking Process Roles: Customer Lead (ideally) or Facilitator Content Roles: Customer Review Team Communication Techniques: Hierarchy Posters, Written Descriptions on PowerPoint, Sticky Wall Range of Durations: 1 and 1/2 hour to 6 and 1/2 hours 23
- 24. • The purpose of this workshop is to share information and build consensus by soliciting input into the solution. • Document Mining and Hierarchy Formation can be conducted by non-expert teams. • The non-experts draft a 70% solution, imperfect, but much better than a blank page. • Business owners and experts are called into the Enterprise Workshop to take the 70% solution to 100%, in terms of accuracy and completeness. 24
- 25. MINIPATTERNS FOR PROBLEM SOLVING MEETINGS These minipatterns are additional techniques to round out your meeting facilitation skills. Following are the techniques for conducting effective meetings: 1.Get Organized • If you have no agenda, brainstorm these two questions on a flipchart: ■Why are we here? ■What outcomes do we want? 25
- 26. 2.Breakouts • Meetings are least productive when only one person talks. • In general, people’s creativity is inhibited in groups larger than five. • The facilitator can ask the group to form smaller discussion groups to address a particular question and ask them to report back their conclusions subgroup by subgroup. 26
- 27. 3.Flipcharts • Flipcharts are group notes; people do not need to be taking their own notes. • When a page of a flipchart is filled, it is moved and taped to a nearby wall. • People can have their heads up & be fully engaed in the meeting. • Flipcharts are also highly portable, unlike whiteboards. 27
- 28. 4.Time Management • If you plan an agenda, plan the time of each meeting topic, and stick to it. • Or ask the group if they want to extend the time. • Assign a time keeper to remind the group. • Time consciousness keeps people focused on problem solving. • Make sure there is a highly visible clock in the meeting room. 28
- 29. 5.Ground rules • Have some ground rules for each meeting so that distractions are minimized, and the group doesn't waste time. 6.Idea Parking Lot • Post a separate flipchart to capture ideas that are outside the meeting’s purpose. Revisit these ideas at the end of the meeting and decide as a group how they should be addressed. 29
- 30. SUMMARY • This chapter discusses the ‘Zachman Framework’ which is a baseline reference model for enterprise architectures. • Zachman Framework’s role in cyber security is explained in the context of the enterprise risk executive. 30
- 31. John A. Zachman is the originator of the “Framework for Enterprise Architecture” (The Zachman Framework™) which has received broad acceptance around the world as an integrative framework, an ontology for descriptive representations for Enterprises. Mr. Zachman retired from IBM in 1990, having served them for 26 years. He is Founder and Chairman of his own education and consulting business, Zachman International®. 31 TIPS JOHN A. ZACHMAN
Editor's Notes
- The columns represent various aspects of the enterprise that can be described or modeled; and the rows represent various viewpoints from which the aspects can be described. Thus each cell formed by the intersection of a column and a row represents an aspect of the enterprise modeled from a particular viewpoint. The architect selects and models the cells that are appropriate to the immediate purpose, with the ultimate objective of modeling all the cells. The six viewpoints are: The Scope (Contextual) viewpoint - aimed at the planner The Business Model (Conceptual) viewpoint - aimed at the owner The System (Logical) viewpoint - aimed at the designer The Technology (Physical) viewpoint - aimed at the builder The Detailed Representations (Out-of-Context) viewpoint - aimed at the subcontractor The Functioning Enterprise viewpoint The six aspects - and the interrogatives to which they correspond - are: The Data aspect - What? The Function aspect - How? The Network aspect - Where? The People aspect - Who? The Time aspect - When? The Motivation aspect - Why? Although the Zachman Framework applies to enterprises, the Framework itself is generic. It is a comprehensive, logical structure for the descriptive representations (i.e., models or design artefacts) of any complex object, and it does not prescribe or describe any particular method, representation technique, or automated tool. The strength of the Framework is that it provides a way of thinking about an enterprise in an organized way, so that it can be described and analyzed. It also enables the individuals involved in producing enterprise information systems to focus on selected aspects of the system without losing sight of the overall enterprise context. In designing and building complex systems, such as enterprise systems, there are simply too many details and relationships to consider simultaneously. At the same time, isolating single variables and making design decisions out of context results in sub-optimization, with all the attendant costs and risks. The challenge is the same whether the system is physical (like an aircraft) or conceptual (like an enterprise system). How do you design and build it, piece by piece, and step by step, such that it achieves its purpose without losing its value and raising its cost by optimizing the pieces and sub-optimizing the overall?
- The columns in the Zachman framework represent different areas of interest for each perspective. The columns describe the dimensions of the systems development effort. These are: 1. Data: Each of the rows in this column address understanding of and dealing with any enterprise’s data. This begins in row one with an list of the things that concern any company in this industry, affecting its direction and purpose. As you pass down through the rows, you move to progressively more rigorous descriptions of the data (row two is the business person’s view, and row three is a disciplined translation of this), until you get to row four, where a specific design approach (and a specific database management system) is specified. Row five is the detailed representation of the data on the computer (tablespaces and the like), and row six is the working database. 2. Function: The rows in the function column describe the process of translating the mission of the enterprise into successively more detailed definitions of its operations. Where row one is a list of the kinds of activities the enterprise conducts, row two describes these activities in a contiguous model. Row three portrays them in terms of data transforming processes, described exclusively in terms of the conversion of input data into output data. The technology model in row four then converts these data conversion processes into the definition of program modules and how they interact with each other. Pseudo-code is produced here. Row five then converts these into source and object code. Row six is where the code is linked and converted to executable programs
- 3. Network: This column is concerned with the geographical distribution of the enterprise’s activities. At the strategic level (row one), this is simply a listing of the places where the enterprise does business. At row two, this becomes a more detailed communications chart, describing how the various locations interact with each other. Row three produces the architecture for data distribution, itemizing what information is created where and where it is to be used. In row four, this distribution is translated into the kinds of computer facilities that are required in each location, and in row five, these facilities requirements are translated into specification of particular computers ,protocols, communications facilities, and the like. Row six describes the implemented communications facilities. 4. People: The fourth column describes who is involved in the business and in the introduction of new technology. The row one model of people is a simple list of the organizational units and each unit’s mission. In row two, this list is fleshed out into a full organization chart, linked to the function column. Here also, requirements for security are described in general terms. In row three, the potential interaction between people and technology begins to be specified, specifically in terms of who needs what information to do his job. In row four, the actual interface between each person and the technology is designed, including issues of interface graphics, navigation paths, security rules and presentation style. In row five, this design is converted into the outward appearance of each program, as well as the definitions of access permissions in terms of specific tables and/or columns each user can have access to. In row six, you have trained people, using the new system. 5. Time: The fifth column describes the effects of time on the enterprise. It is difficult to describe or address this column in isolation from the others, especially column two. At the strategic (row one) level, this is a description of the business cycle and overall business events. In the detailed model of the business (row two), the time column defines when functions are to happen and under what circumstances. Row three defines the business events which cause specific data transformations and entity state changes to take place. In the technology model (row four), the events become program triggers and messages, and the information processing responses are designed in detail. In row five,these designs become specific programs. In row six business events are correctly responded to by the system. 6. Motivation: As Mr. Zachman originally described this column, it concerned the translation of business goals and strategies into specific ends and means. This can be expanded to include the entire set of constraints that apply to an enterprise’s efforts. In row one, the enterprise identifies its goals and strategies in general, common language terms. In row two, these are translated into the specific rules and constraints that apply to an enterprise’s operation. In row three, business rules may be expressed in terms of information that is and is not permitted to exist. This includes constraints on the creation of rows in a database as well as on the updating of specific values. In row four, these business rules will be converted to program design elements, and in row five they will become specific programs. In row six, business rules are enforced.