Week 1: Introduction to the Zachman Framework Flashcards Preview

Enterprise Architecture > Week 1: Introduction to the Zachman Framework > Flashcards

Flashcards in Week 1: Introduction to the Zachman Framework Deck (33)
Loading flashcards...
1

IT Components

- Hardware
- Software
- Data
- Network
- Procedures
- People

2

GUI

Graphical User Interface

3

Database

A structured set of data. It is a combined set of tables.

4

Random Access Memory (RAM)

In-memory and temporarily.

5

Hard disk

Has a database. Still saved when unplugged.

6

IT Architecture

Is about models:
- A model is used for communication and understanding a phenomenon.
+ A symbolic representation of a phenomenon.
+ Created using a visual language with grammar.
+ Map/diagram/artifacts/model
- As the phenomenon gets more complex, the need for a model rises.
- Not just a model
+ Sometimes many models are needed.
+ For different people/perspectives.
Architecture means models for IT to understand hardware, software, data, network, procedures, and people in the business. Understand the grammar and map different models together.

7

Flowcharts (for programs)

It's hard to understand a code written by another program. Therefor, programmers communicate in flowcharts. These are language independent.
Purpose of flowcharts: visualize what is going on in a program.
Why? For communication and understanding.
User View (command line) -> Developer View (C-language) -> Designer View (language-independent)

8

Parts of a flow chart

- Start/End
- Input/Output: Getting data from user or displaying data to him/her.
- An operation: e.g. i=1
- Decision: e.g., if i=1 then
- Order of operation

9

Engineer perspective

Flowchart

10

Developer perspective

C, Python, Java, or another language.

11

User perspective

Executable file, script, Java program.

12

Primary key

The unique identifier for a table.

13

Foreign key

Primary key in another table (parent table). Makes sure that you cannot enter a value that is not present in the parent table.

14

Logical Data Model (Relational Model)

When you want to communicate, but do not want it to be program dependent.

15

Grammar of a Relational Model

Relation: A table = a set of connected rectangles with a name in capital letters.
Attribute: A column in a relation (table) = a rectangle
Primary key: an attribute that uniquely identify all rows in a relation. = a solid line.
Foreign key: A primary key in a parent table borrowed by the child table. = connected with an arrow to the primary key of the parent table.

16

Conceptual Data Model

Cares about the design. This is higher level data model, and is easier to understand for the customer.

17

Grammar of a Conceptual Data Model

Entity: A thing that can be uniquely identified and the business needs to store data about. = A rectangle with a name in capital letters.
Attribute: a property of an entity that is of interest to the business. = an item in a rectangle with a name whose first letter is capitalized.
Relationship: an association between one or several entities primary key in a parent table borrowed by the child table. = a line connecting one, two, or more rectangles.
Identifier: an attribute whose value distinguishes instances of an entity. = underscored attribute.
Composite attribute: has several components. = round brackets.
Multi-valued attribute: may take more than one value for a given entity. = curly brackets.
Calculated attribute: its value can be calculated from other attributes or relationships. = square brackets.

18

Differences between a conceptual model (ER model) and a logical model (Relational model)

- M:N relationships: Logical model has only 1-N and 1-1 relationships. Unlike conceptual models, logical models cannot have many to many (N-N) relationships.
- Primary keys: Entities in a conceptual diagram for the current state of an organization may lack identifiers (primary keys). In a logical model, all tables must have a primary key.
Mapping current state: To develop a system, we usually start by developing a conceptual model for the current state of the organization. Then, we create a conceptual model for the future state. Then, we map the conceptual model to the logical model.

19

System-use-case Diagram

- What functionalities are supported in a system?
- What relationships between functionalities?
- What external actors interact with the system?
- Note the direction of arrows.

20

System-use-case Diagram language

Actor: a class of person, organization, device, or external software component that interacts with your system. Symbol: Face or Person.
Use-case: the actions that are performed by one or more actors in the pursuit of a particular goal. Symbol: Oval
System: whatever you are developing. Symbol: Square
Association: Which actor or functionality initiates the communication. Symbol: Arrow.
Include: one use case describes some of the detail of another. Symbol: broken-line-arrow (with include).
Extend: show that one use case may add functionality to another use case under certain circumstances. Symbol: broken-line-arrow (with extend).
Generalization: show that a specialized use case is a particular way to achieve the goals expressed by another general use case. Symbol: broken-line-arrow with large head.

21

System Activity Diagram

Shows the details of a use-case. User interfaces do not have to be added. It is important to have consistency between the different diagrams.

22

System Activity Diagram language

Action: a non-interruptible action. Symbol: Rectangle
Action flow: the transitions from one action to another. Symbol: Arrow
Decision: a decision needs to be made. Symbol: Diamond
Guard: a statement written next to a decision diamond that must be true before moving to the next activity. Symbol: Arrow with words.
Synchronization: several actions can be done in parallel. Symbol: Double line.
System/System components: show that one use case may add functionality to another use case under certain circumstances. Symbol: Rectangle with word.
Initial state: the start point of the activity diagram. Symbol: filled dot.
Final state: the end point of an activity diagram. Symbol: filled dot with ring.
Generalization: show that an actor or specialized use case is a particular way to achieve the goals expressed by another general use case. Symbol: broken-line-arrow with large head.

23

Business diagram

Are about the business. They provide information for business analysts and business managers. Contains:
- What the business does.
- How the business does that.

24

System diagram

System diagrams are about systems. The provide information for system designers and system developers. Contains:
- What the systems do.
- How the systems do it.

25

System and business use-case diagrams

Provide bird views.

26

System and business activity diagrams

Provide huge details.

27

CRUD Matrix

Create, Read, Update, Delete. Where functionality (process) and data (inventory) meet.
Connecting:
- System use-case (or activity) diagram and relational model (logical data model).
- Business use-case (or activity) diagram and entity-relationship model (conceptual data model).

28

CRUD Matrix process

Used for analyzing the current state of an organization. CRUD is created for current processes and entities. Based on missing C, R, U, or D, a new process is suggested.
CRUD can also suggest improving a process by looking at the process row and check if C, R, U, or D is missing. CRUD matrix is used to come up with the future (to-be) state of the organization.

29

Zachman Framework

Zachman created a sort of periodic table for business.
- Model doesnot suggest any diagrams.
- It just tells that a diagram exists. If you miss a model, your understanding of the company is missing.
- The phenomenon in 1989-1992 is an IT organization. IT architecture -> 3 columns: what, how, and where.
- The phenomenon in 2011 is an organization -> Enterprise architecture.
Systems are nog just information systems, they can also be manufacturing systems etc.

30

Zachman Framework - Content

Table is 6X6.
- Primitive interrogatives as columns:
+ What (data), How (process), Where (network), Who (people), When (time), Why (goal).
+ If you answer the 6 questions you have a complete picture of the organisation.
- Stakeholders as rows:
+ Executives, business managers, architects, engineers, technicians, users.

31

Operational Node Connectivity (OV-2)

Constructs nodes (oval as a symbol) and needline (line as the symbol).
Construct node: a place belong to the organization.
Operational needline: a need for exchanging resources.

32

System Resource Flow Description (SV-2)

System: an application server or a network node. Symbol: Oval.
Port: the port used for info exchange. Symbol: at the connection of oval and arrow.
Resource flow: exchanged information. Symbol: Arrow.

33

Core components of Enterprise Architecture

- As-it -> the current state assessment of the organization.
- To-be -> the future state and, generally, the main focus of an EA assignment.
- Migration plan: without a viable route from as-is to to-be the architecture already failed.
- Principles: guidelines for the users of the architecture, such as buy or build, adherence to publish data standards.
- Decisions log: started during the development of the EA but a key part of the living architecture.