03. Modeling Organizations - DISI, University of Trentodisi.unitn.it/~dalpiaz/ois/lib/exe/fetch.php?media=03-modelingorgs.pdf · The Zachman framework ... Row 2 – Enterprise Model

© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 1

03. Modeling Organizations


Enterprise Architectures (EAs)

● An enterprise architecture (EA) is a rigorous description of the structure of an enterprise, which comprises

● enterprise components (business entities)● the externally visible properties of those components● the relationships (e.g. the behavior) between them

● EA describes the guiding principles for the requirement (analysis), design, and evolution of an enterprise.


Enterprise Architectures (EAs)● This description is comprehensive, including

● enterprise goals● business processes● roles● organizational structures● organizational behaviors● business information● software applications and computer systems

● EAs are an important tool for managing large organizations, such as the European Commission (EU), Department of Defense (US), among others.


Enterprise Architects

● Practitioners of EA call themselves "enterprise architects." An enterprise architect is a person responsible for developing the enterprise architecture and is often called upon to draw conclusions from it

● By producing an enterprise architecture, architects are providing a tool for identifying opportunities to improve the enterprise, in a manner that more effectively and efficiently pursues its purpose

● Enterprise architects use models and tools!


(Enterprise) Architects

Architect: a building Enterprise architect: a running organization


The Zachman framework

● The Zachman Framework is an EA which provides a formal and highly structured way of viewing and defining an enterprise.

● It consists of a two dimensional classification matrix based on the intersection of:

● six communication questions (What, Where, When, Why, Who and How) ● six rows that define different operationalization levels

● The Zachman Framework is not a methodology in that it lacks specific methods and processes for collecting, managing, or using the information that it describes. It was named after its creator John Zachman, who first developed the concept in the 1980s at IBM.


The Zachman framework

● The framework is basically a taxonomy for organizing architectural artifacts (in other words, design documents, specifications, and models)

● that takes into account both whom the artifact targets (for example, business owner and builder)

● and what particular issue (for example, data and functionality)


Zachman Framework


Rows 1-3

● Row 1 – Scope: External Requirements and Drivers:● Definition in gross terms of the size, shape, partial relationships, and

purpose of the final structure [Business Function Modelling]

● Row 2 – Enterprise Model● Represent the architecture from the perspective of its owner, who will

have to live with daily routines [Business Process Models]

● Row 3 – System Model● Takes the designer's perspective on the architecture, with insights from

rows 1 and 2 [Logical Models, Requirements Definition]


Rows 4-6

● Row 4 – Technology Model● Focus on how the architecture is going to be built: tools, technology, and

materials [Physical Models, Solution Definition & Development]

● Row 5 – As Built● Detailed specifications on how the system is actually built and is going to

operate [As built, Deployment]

● Row 6 – Functioning Enterprise● The functioning enterprise, i.e. the outcome of the design in rows 1-5


Framework rules

● Rule 1: Columns have no order

● Rule 2: Each column has a simple, basic model

● Rule 3: Basic model of each column is unique

● Rule 4: Each row represents a distinct view

● Rule 5: Each cell is unique

● Rule 6: Combining the cells in one row forms a complete description for that view

1

2

3

4

5

6

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Contextual

Conceptual

Logical

Physical

As Built

Functioning

Why

Why

Who

Who

When

When

Where

Where

What

What

How

How

Basic Model = Entities and Relationships

EntityRelationship

Entity


R1: Scope/Planner's view

● External Requirements and Drivers + Business Function Modelling● Motivation/Why: Business goals, and performance measures for each

function (Key Performance Indicators, KPIs)● Function/How: High-level business functions● Data/What: High-level data classes related to each function● People/Who: Stakeholders related to each function● Network/Where: Locations related to each function● Time/When: Cycles and events related to each function

[Keyword: goals]


R2: Ent Model/Designer's view

● Business Process Models, Business Function Allocation, Elimination of Function Overlap and Ambiguity

● Motivation/Why: Policies, procedures and standards for each process ● Function/How: Business processes● Data/What: Business data● People/Who: Roles and responsibilities in each process● Network/Where: Locations related to each process● Time/When: Events for each process and sequencing of integration and

process improvements

[Keyword: processes]


R3: System Model/Designer's view

● Logical Models, Project Management, Requirements Definition ● Motivation/Why: Policies, standards, procedures, associated with a

business rule model● Function/How: Logical view of information; systems and their

relationships ● Data/What: Logical data models; relationships underlying information ● People/Who: Logical view of access privileges; by role and responsibility● Network/Where: Logical view of distributed system architecture● Time/When -- Logical events and their triggered responses,constrained

by business events and responses

[Keyword: logical model]


R4: Technology Model/Builder's view

● Physical Models, Technology Management, Solution Definition and Development

● Motivation/Why: Business rules constrained by IS standards● Function/How: Specifications of applications that operate on

particular technology platforms● Data/What: Database management system (DBMS) type● People/Who: Specification of access privileges to platforms and

technologies ● Network/Where: Network devices and inter-connections● Time/When: Triggers to respond to system; events on specific platforms

and technologies [Keyword: physical model]


R5: Built/Integrator's view

● As Built, Configuration Management, Deployment ● Motivation/Why: Business rules constrained by tech. standards● Function/How: Programs coded to operate on specific platforms ● Data/What: Data definitions constrained by physical data models ● People/Who: Access privileges coded to specific platforms and

technologies to control access ● Network/Where: Network devices configured to conform to standards ● Time/When: Timing definitions coded to sequence activities on specific

platforms, technologies

[Keyword: configuration]


R6: Functioning Ent/User's view

● Functioning Enterprise, Operations Management, Evaluation ● Motivation/Why: Operating characteristics of technologies constrained

by standards● Function/How: Functioning computer instructions● Data/What: Data values stored in actual databases ● People/Who: Personnel and key stakeholders working within their roles

and responsibilities ● Network/Where: Sending and receiving messages ● Time/When: Timing definitions operating to sequence activities

[Keyword: operation]


High-level modeling notation

● At a high-level of abstraction (e.g. row 2), for example:● What – ER model/UML class diagrams● How – Business process model● Who – i* + organizational chart● Where – map notation● When – Event-condition-action (ECA) rules● Why – i*


Models – all rows


CIMOSA

● CIMOSA is an Open System Architecture for Enterprise Integration. It was originally proposed for Computer-Integrated Manufacturing (CIM) applications as a series of ESPRIT projects 1986 until 1994) with support from the European Commission.

● Its aim is to provide the manufacturing industry with:● an Enterprise Modelling Framework (EMF) that can accurately represent

business operations, support their analysis and design, and lead to executable enterprise models;

● an Integrating Infrastructure (IIS), used to support application and business integration as well as execution of the implementation model to control and monitor enterprise operations;

● a methodology to be used along the System Life Cycle (SLC) to assist users in applying CIMOSA principles.“


CIMOSA cube


CIMOSA life cycle


TOGAF

● Framework for EA proposed by 'The Open Group'

● Adopted in industries

● Features:● Centered around requirements● Begins with a vision of the

architecture● Includes governance● Deals with change mgmt● Iterative / cyclic


BPMS

● BPMS: The Business Process Management Systems Paradigm● Published in 1994 (Karagiannis tutorial “Towards Business Process

Management Systems” at CoopIS’94, Toronto) ● Method-independent framework● Enterprise models form the basis for BPMS lifecycle● Support for all levels from strategic management to operational business

process execution● Continuous control and adaptation of company goals (“control circuit")● Does not focus on a single business area/level, but rather on a global view


Core Elements of Organizations

Organizationalunits

Informationtechnology

Informationtechnology

BusinessprocessesBusiness

processes

Product X

Productcomponent YProductsProducts

: are interdependent: supported by

: affecting the design


ProductsProducts

operated by

EmployeesEmployeesEmployeesEmployeesITITITIT

ExecutedExecutedBusiness ProcessesBusiness Processes

ExecutedExecutedBusiness ProcessesBusiness Processes

EvaluatedEvaluatedBusiness ProcessesBusiness Processes

EvaluatedEvaluatedBusiness ProcessesBusiness Processes

are realised by

BusinessBusinessprocessesprocesses

Which Which productsproducts do do we offer?we offer?

How do we design How do we design our our business-business-processesprocesses??

How do we How do we operateoperate our our

business business processes?processes?

How do we How do we controlcontrol our (daily) our (daily) business?business?

How do we How do we evaluateevaluate our our

business?business?

StrategicStrategicDecisionDecisionProcessProcess

Re-EngineeringRe-EngineeringProcessProcess

Resource Resource AllocationAllocationProcessProcess

WorkflowWorkflowProcessProcess

PerformancePerformanceEvaluationEvaluationProcessProcess

The BPMS Paradigm


BPMS subprocesses

Execution of businessprocesses in operational environment, gathering operational data for further analysis and evaluation

Aggregation and processingof business process and organizational data,extraction of measurementsand metrics




Re-Re-EngineeringEngineering

ProcessProcess


Implementation of business processes based on IT or organizational issues,assignment of technical and human resources for execution

Documentation, adaption, Modeling and optimization of business processes,identification of reorganisationpossibilities and capacities

Definition of strategic andgeneral conditions, success factors and essential criteria for business processes


BPMS: tool support

• Executive IS• Business Intelligence• . . .

Business ProcessManagement Tools

(e.g. ADONIS)

• Groupware-Tools • Workflow-Tools• CASE-Tools• Standard-SW• Legacy Systems• . . .




Re-Re-EngineeringEngineering

ProcessProcess


Met

hods

Met

hods


ADONIS

● Model of the organizational structure● Overview of interdependencies of persons and roles● Information about persons and roles● Skills of a corporation● Links to other models

● Activities within a business process model are executed by role "Clerk"● Person "Smith" accesses the resource "customer database"● Etc.


Enterprise modeling levelsBusiness Process Modelling

IT ProcessModelling

Target SystemLevel

ExecutionProcess

XXXX

XXXX

XXXX

XXXXXXXXXXXXXXXXXXXXXX

XXXX

XXXX

XXXXXXXXXXX

XXXXXXXXXXX

XXXXXXXXXXX

XXXXXXXXXXX

XXXXXXXXXXX

XXXXXXXXXXX

...

...

...

etc.case/4/0, Rose

CASE

etc.SAP R/3

ERP

XXXX

XXXX

XXXXXXXXXXX

XXXXXXXXXXX

etc.MQSeries WF

WORKFLOW

etc.J2EE

Web-Systems

XXXX

XXXX

XXXXXXXXXXXXXXXXXXXX

etc.Lotus Notes

GROUPWARE

XXXX

XXXX

XXXX

XXXXXXXXXXXXXXXXXXXXXX

...


Enterprise models in ADONIS

Business ProcessModels

Product Models

OrganizationalModels

IT Models


Interdependencies between models

Product Model

IT Model

OrganizationalModel

BusinessProcessModel

Process has Product

Responsible Role

Performer

Performer has Resource

Further Models(Skills, ...)


Interorganizational units

● Type: Department, Project group, Member of the Board, Division,Cost/Profit Center

● Name● Description● Comment

● Graphical representation: labeled rectangle● Differences to distinguish org. units

Dep1 Group2


Person

● Single person = Performer● Mr. John Smith● Mrs. Liz Turner

● Attributes● Name● Hourly wage● Comment● Availability● Calendar


Roles

● Role (corresponds to "group" or "competence"): The term "role" describes a special type of employee with defined qualification and competence

● "Clerk"● "Head of department"● "Authorized signatory"

● Attributes ● Description● Comment

R


Skills

● Special form of role: describes the ability of an employee to perform a particular task (e.g., write, type,…)

● Novice, Good skills, Expert, ...

● Attributes● Name, Description, Kind of skills ● (PC knowledge, marketing experience, ...)● Values (bad, medium, good, ...)

● Possible references to other Modelling constructs● Person, Role, Activity in business process

Marketingexperience …

…PC knowledge


Resources

● Depending of the type and the amount of resources, they are modeled directly in the context of the other concepts or in a special resource model.

● Type of resources● Computer, Database, Office Document, ...

● Attributes● Name, Description, Type


An example

More details about ADONIS later in the course


Modeling events: ECA rules

● Consist of an Event+Condition+Action● Syntax event [condition] action

● An event is a happening that occurs instantaneously● A condition is a Boolean expression that expresses a temporal constraint

on events● An action is a process or task that actors/systems in the environment

can perform

● Semantics:● If the event happens, and the condition is true, the action is to be

performed


ECA Events

● Different types of events exist● start(week-ofFeb.21.2012) is true at the start of a particular week;

start(week) is true at the start of every week; likewise with end(year), start(December), etc.

● change event exprs occur when a condition becomes true; denoted by the keyword ‘when’, e.g. when(balance < 0)

● Action/process event exprs occur when an action/process is initiated or terminates, e.g., start(openDoor), end(openDoor)

● Signal events occur when an object sends an explicit (real-time) signal, e.g., messageReceived

● Elapsed-time event marks the passage of a designated period of time from some other event, e.g. after(10sec from start(openDoor))


ECA Conditions

● Impose temporal constraints on observed events● We assume a discrete model of time, i.e., for every time instance there

is a next and a previous time instance● Use before, after, follows/preceeds: e.g., time(e) before time(d)● T follows/preceeds T’ means that T immediately follows/preceeds T’● For example, here is an event-condition combination

doorOpened[d] AND passengerOut[p] AND (NOT(pressButton)

[time(d) before time(p) AND time(p) before time(d) + 60sec]


ECA Actions

● Consist of an action an actor or the system can perform.● For example,

doorOpened[d] AND passengerOut[p] AND (NOT(pressButton)

[(time(d) before time(p)) AND (time(p) before time(d) + 60sec)]

doorClose[d]

● More examples …

start(December) [] prepareFinancialStatement

end(runProject(p)) [budget(p) > €10K] generateReport(p)


Toolset for Assignment 1

● Assignement 1 not described yet...● However, let's get started with the toolset [homework]

● Tool 1: Any i*-based goal modeling tool – SI* reccommended http://sistar.disi.unitn.it/index.php/SI*_Tool– Other options in the tutorials

● Tool 2: ADONIS:CE– http://www.adonis-community.com/– Windows only...– Other Business Process modeling tools are fine... as long as they support the

same types of analysis that we need

http://sistar.disi.unitn.it/index.php/SI*_Tool

http://www.adonis-community.com/

03. Modeling Organizations - DISI, University of Trentodisi.unitn.it/~dalpiaz/ois/lib/exe/fetch.php?media=03-modelingorgs.pdf · The Zachman framework ... Row 2 – Enterprise Model

Documents