03. Modeling Organizations - DISI, University of...
-
Upload
nguyennhan -
Category
Documents
-
view
216 -
download
0
Transcript of 03. Modeling Organizations - DISI, University of...
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 1
03. Modeling Organizations
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 2
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.
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 3
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.
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 4
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!
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 5
(Enterprise) Architects
Architect: a building Enterprise architect: a running organization
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 6
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.
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 7
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)
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 8
Zachman Framework
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 9
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]
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 10
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 11
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 12
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]
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 13
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]
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 14
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]
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 15
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]
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 16
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]
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 17
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]
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 18
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*
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 19
Models – all rows
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 20
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.“
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 21
CIMOSA cube
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 22
CIMOSA life cycle
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 23
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 24
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 25
Core Elements of Organizations
Organizationalunits
Informationtechnology
Informationtechnology
BusinessprocessesBusiness
processes
Product X
Productcomponent YProductsProducts
: are interdependent: supported by
: affecting the design
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 26
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 27
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
StrategicStrategicDecisionDecisionProcessProcess
PerformancePerformanceEvaluationEvaluationProcessProcess
WorkflowWorkflowProcessProcess
Re-Re-EngineeringEngineering
ProcessProcess
Resource Resource AllocationAllocationProcessProcess
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 28
BPMS: tool support
• Executive IS• Business Intelligence• . . .
Business ProcessManagement Tools
(e.g. ADONIS)
• Groupware-Tools • Workflow-Tools• CASE-Tools• Standard-SW• Legacy Systems• . . .
StrategicStrategicDecisionDecisionProcessProcess
PerformancePerformanceEvaluationEvaluationProcessProcess
WorkflowWorkflowProcessProcess
Re-Re-EngineeringEngineering
ProcessProcess
Resource Resource AllocationAllocationProcessProcess
Met
hods
Met
hods
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 29
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.
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 30
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
...
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 31
Enterprise models in ADONIS
Business ProcessModels
Product Models
OrganizationalModels
IT Models
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 32
Interdependencies between models
Product Model
IT Model
OrganizationalModel
BusinessProcessModel
Process has Product
Responsible Role
Performer
Performer has Resource
Further Models(Skills, ...)
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 33
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 34
Person
● Single person = Performer● Mr. John Smith● Mrs. Liz Turner
● Attributes● Name● Hourly wage● Comment● Availability● Calendar
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 35
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 36
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 37
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 38
An example
More details about ADONIS later in the course
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 39
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
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 40
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))
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 41
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]
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 42
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)
© F. Dalpiaz & J. Mylopoulos -- OIS 2011-12 Slide 43
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