Description

College of Computing and Informatics

PROJECT
Deadline: Day 22/04/2024 @ 23:59
[Total Mark for this Assignment is 14]
Student Details:

CRN: ###

Name: ###

ID: ###

Name: ###

ID: ###

Name: ###

ID: ###

Name: ###

ID: ###

Instructions:

• You must submit two separate copies (one Word file and one PDF file) using the Assignment Template on Blackboard
via the allocated folder. These files must not be in compressed format.

• It is your responsibility to check and make sure that you have uploaded both the correct files.
• Zero mark will be given if you try to bypass the SafeAssign (e.g. misspell words, remove spaces between words, hide
characters, use different character sets, convert text into image or languages other than English or any kind of
manipulation).

• Email submission will not be accepted.
• You are advised to make your work clear and well-presented. This includes filling your information on the cover page.
• You must use this template, failing which will result in zero mark.
• You MUST show all your work, and text must not be converted into an image, unless specified otherwise by the question.
• Late submission will result in ZERO mark.
• The work should be your own, copying from students or other resources will result in ZERO mark.
• Use Times New Roman font for all your answers.
Restricted – ‫مقيد‬

Project Description and tasks

Pg. 01
Learning
Outcome(s):
Instructors: State
the Learning
Outcome(s) that
match this
question

Project Description and tasks

14 Marks

Project title: “AlBaik” Business Process Improvement
Group requirement: 4 students per group
Submission Guidelines:
•
•
•

Ensure all diagrams and analysis are clear and well-organized.
Use real-world examples to back up your suggestions for process
improvements.
Submit your work as a single document by group leader only once

Total marks: 14
Marking criteria:
Tasks

Mark

Introduction

1 mark

Identify and Describe 5 business processes

4 marks

Modelling the As-Is Process using BPMN 2.0 (2 Models)

4 marks

Analysis of the As-Is Process

3 marks

Suggestions for Improvement

2 marks

Total

14 marks

Case study: Al-Baik, a Saudi Arabian fast-food chain, was founded in 1974. The
industry specializes in selling crispy fried chicken mainly. The meals prices are
affordable for everyone and there are more than 100 branches across the
country. The rapid growth of a l Baik caused operational challenges.
Based on the above case study, you are required to do the following:

Restricted – ‫مقيد‬

Question One

Pg. 02
Learning
Outcome(s):
CLO1: Explain the
interdisciplinary
concepts,
theories, and
trends in ES and
their role in
supporting
business
operations

Restricted – ‫مقيد‬

Question One

1 Marks

1. Introduction:
Giving a brief outline of the business model of Al-Baik industry,
highlighting the current situation and the operational challenges

Question Two

Pg. 03
Learning
Outcome(s):
CLO2: Describe
the development
life cycle of ES
and reengineering
best practices.

Restricted – ‫مقيد‬

Question Two

4 Marks

2. Identify and Describe 5 Business Processes
Identify and describe five key business processes at Al Baik. For each
process, provide:
•

Description of the activity in details

•

How the business process is performed?

•

Identify the main Input and Output for each process.
(If there are too many processes, focus on the most relevant one with
current issues).

Question Three

Pg. 04
Learning
Outcome(s):
CLO4: Design ES
architectural
models for
various business
processes.

Restricted – ‫مقيد‬

Question Three

4 Marks

3. Modelling the As-Is Process using BPMN 2.0
From the business processes identified above, select 2 main business
processes to create the BPMN 2.0 diagram representing the process, include
Swimlanes for relevant participants.
Any BPMN 2.0 tool can be used (ex: Visio)

Question Four

Pg. 05
Learning
Outcome(s):
LO1: Explain the
interdisciplinary
concepts,
theories, and
trends in ES and
their role in
supporting
business
operations

Restricted – ‫مقيد‬

Question Four

3 Marks

4. Analysis of the As-Is Process
Analyse the business processes mentioned in the above step from the time and
quality perspectives. Make sure to include the related issues and explain the
impact on the business.

Question Five

Pg. 06
Learning
Outcome(s):
LO3: Discuss the
issues and
challenges
associated with
implementing ES
and their impacts
on corporate
enterprises.

Restricted – ‫مقيد‬

Question Five

2 Marks

5. Suggestions for improvement:
As a business expert, what is the steps that Al-Baik must take into consideration
to improve their business processes. Give suggestions focusing on operational
efficiency and customer satisfaction.

‫ر‬
‫الجامعة السعودية االلكتونية‬
‫ر‬
‫االلكتونية‬
‫الجامعة السعودية‬

‫‪26/12/2021‬‬

College of Computing and Informatics
Information Technology
IT402
Integrated Enterprise Systems

IT402
Integrated Enterprise Systems
Week 1
Introduction

1.
2.
3.
4.

Contents

Saudi Vision 2030
Saudi Digital Library
Git and Github
Stackoverflow

• Demonstrate the Saudi Digital Library and searching for
knowledge
• Understand the Major Objective of Saudi Vision 2030

Weekly
Learning
Outcomes

• Saudi Vision 2030

Weekly
Learning
Outcomes

Saudi Vision 2030
• Under the leadership of the Custodian of the Two Holy Mosques, Vision
2030 was launched, a roadmap drawn up by His Royal Highness the Crown
Prince, to harness the strengths God bestowed upon us – our strategic
position, investment power and place at the center of Arab and Islamic
worlds. The full attention of the Kingdom, and our Leadership, is on
harnessing our potential to achieve our ambitions.

Reference:

Saudi Vision 2030
• Vision 2030 Draws on The Nation’s Intrinsic Strengths
1. Saudi Arabia is the land of the Two Holy Mosques which positions the Kingdom at
the heart of the Arab and Islamic worlds
2. Saudi Arabia is using its investment power to create a more diverse and
sustainable economy
3. The Kingdom is using its strategic location to build its role as an integral driver of
international trade and to connect three continents: Africa, Asia and Europe

Reference:

• Saudi Digital Library

Weekly
Learning
Outcomes

Saudi Digital Library
• Saudi Digital Library, is the largest academic gathering of information
sources in the Arab world, with more than (310،000) scientific reference,
covering all academic disciplines, and the continuous updating of the
content in this; thus achieving huge accumulation cognitive in the long run.
Library has contracted with more than 300 global publisher. The library
won the award for the Arab Federation for Libraries and Information
‘know’ for outstanding projects in the Arab world in 2010.

Reference:

Saudi Digital Library
• Advantages:
• One central management, manages this huge content, and constantly updated.
• Common share for the benefit of, any University would benefit other universities
that are now available to the other, in any scientific field.
• Enhance the status of universities when evaluating, for Academic Accreditation, and
through sources rich, modern, and publish the best Global Publishers.
• Bridging the gap between Saudi universities, where emerging universities can get
the same service, you get major Saudi universities.

Reference:

• Git and Github

Weekly
Learning
Outcomes

What is GIT?
• Git
• is a version control system for tracking changes in computer files and
coordinating work on those files among multiple people.
• It is primarily used for source code management in software development and
was initially created by Linus Torvalds for development of the Linux Kernel.

• Git is not Github.
• Git is the version control software
• Github is a git repository hosting service which offers all the source code
management provided in git.
• Github is where you upload your git repository.
Reference:

Version control
• Version control is:
• a system that records changes to a file or set of files over time so that you can
recall specific versions later.
• If you are a graphic or web designer and want to keep every version of an
image or layout (which you would most certainly want to), a Version Control
System (VCS) is a very wise thing to use.
• It allows you to revert selected files back to a previous state, revert the entire
project back to a previous state, compare changes over time, see who last
modified something that might be causing a problem, who introduced an issue
and when, and more.
• Using a VCS also generally means that if you lose files, you can easily recover.

Reference:

What Is GitHub
• GitHub is
• a for-profit company that offers a cloud-based Git repository hosting
service.
• Essentially, it makes it a lot easier for individuals and teams to use Git for
version control and collaboration.

• GitHub’s interface is user-friendly enough so even novice coders
can take advantage of Git.

Reference:

Create a Repository

Reference:

Make and commit changes

Reference:

• Stack overflow

Weekly
Learning
Outcomes

Stack overflow
• Stack Overflow is
• a question-and-answer website for professional and enthusiast programmers.
• It is the flagship site of the Stack Exchange Network, created in 2008 by Jeff Atwood
and Joel Spolsky.
• It features questions and answers on a wide range of topics in computer programming.
• Stack Overflow only accepts questions about programming that are tightly focused on a
specific problem.
• Questions of a broader nature–or those inviting answers that are inherently a matter of
opinion– are usually rejected by the site’s users and marked as closed.

Reference:

Thank You

‫ر‬
‫الجامعة السعودية االلكتونية‬
‫ر‬
‫االلكتونية‬
‫الجامعة السعودية‬

‫‪26/12/2021‬‬

College of Computing and Informatics
Information Technology
IT402
Integrated Enterprise Systems

IT402
Integrated Enterprise Systems
Week 2
Enterprise Systems and Enterprise Resource Planning

Required Reading
1. Chapter 1 (Enterprise Process Management Systems:
Engineering ProcessCentric Enterprise Systems using
BPMN 2.0 by Vivek Kale)

Recommended Reading
1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise
information systems: A pattern-based approach (3rd ed.)

Weekly Learning Outcomes

1. Introduce the concept of Enterprise Systems (ES) and
Enterprise Resource Planning (ERP)

2. Describe the importance of business processes in enabling
flexible and adaptable enterprise-wide cross-functional

integration.

Contents

1. Evolution of Enterprise Systems
2. Extended Enterprise Systems

3. Enterprise Resource Planning (ERP)
4. Enterprise Business Processes

• Evolution of Enterprise Systems

Evolution of Enterprise Systems
• Enterprise systems (ES) are an information system that integrates
business processes with the aim of:
1. creating value
2. reducing costs

• Achieved by making the right information available to the right
people at the right time
➢Result – Making good decisions in managing resources proactively and
productively.

• ES have evolved from simple materials requirement planning (MRP)
to ERP, extended enterprise systems (EES), and beyond.

Evolution of Enterprise Systems

Materials Requirement Planning (MRP)
• MRP is a heuristic based on three main inputs:
1. the Master Production Schedule, which specifies how many products are
going to be produced during a period of time;
2. the Bill of Materials, which describes how those products are going to be
built and what materials are going to be required;
3. the Inventory Record File, which reports how many products, components,
and materials are held in-house.

• MRP employs backward scheduling,
➢lead times are used to work backwards from a due date to an order release
date.

• While the primary objective of MRP was to compute material
requirements, the MRP system is also a useful scheduling tool.

Closed-Loop Materials Requirement Planning
• Real-time (closed loop) MRP systems replaced regenerative MRP systems in
response to:
1.
2.

Changing business needs
Improved computer technology
➢ Time-sharing replaced batch processing as the dominant computer processing mode.

• This closed the control loop with timely feedback for decision-making by
incorporating current data from the factory floor, warehouse, vendors,
transportation companies, and other internal and external sources
➢ Gives the MRP system the capability to provide current information for
better planning and control.
• The transformation of MRP into a planning and control tool by closing the loop,
planned and controlled various manufacturer resources that led to MRP II.

Manufacturing Requirement Planning II
• The MRP system evolved from a “material” requirements planning system
into a planning and control system for resources in “manufacturing”
operations.
• MRP II systems became more widespread and sophisticated, particularly
when used in manufacturing to support and complement computerintegrated manufacturing.
• Databases started replacing traditional file systems, allowing for better
systems integration and greater query capabilities to support decisionmakers.
• Telecommunications network became an integral part of these systems in
order to support communication between distributed systems
components.

Manufacturing Requirement Planning II
• MRP II was developed based on MRP principles, but incorporated some
important operational restrictions such as available capacity, maintenance
turnaround time, and financial considerations.
• MRP II introduced simulation options to enable the exploration and
evaluation of different scenarios.
• MRP II is defined as business planning, sales and operations planning,
production scheduling, MRP, capacity requirements planning, and the
execution support systems for capacity and material.
• MRP II integrated financial considerations, improved management control
and performance of operations and made different manufacturing
approaches comparable.

Enterprise Resource Planning (ERP)
• New advances in information technology (IT), such as local area
networks, personal computers, and object-orientated programming
allowed some of MRPs deterministic assumptions to be relaxed.
• Early ERP systems typically ran on mainframes like MRP and MRP II,
but many migrated to client/server systems where networks were
central and distributed databases were more common.

• Extended Enterprise Systems (EES)

Extended Enterprise Systems
• Businesses are looking beyond the enterprise.
• Enterprises look for ways to support and improve relationships and
interactions with customers, suppliers, partners, and other
stakeholders.
• While integration of internal functions is still important and, in many
enterprises, still has not been achieved to a great extent, external
integration is now receiving much attention.

Extended Enterprise Systems Framework
The conceptual framework of EES consists of four distinct layers:
• Foundation layer – consists of the core components of EES, which shape
the underlying architecture and also provide a platform for the EES systems
• Process layer – the central component of EES, which is Web-based, open,
and componentized and may be implemented as a set of distributed Web
services.
• Analytical layer – consists of the corporate components that extend and
enhance the central ERP functions by providing decision support to manage
relations and corporate issues.
• Electronic business layer – the portal of the EES systems and this layer
consists of a set of collaborative components.

Extended Functionality
• The capability of Web services to allow businesses to share data,
applications, and processes across the Internet may result in ES of the future
relying heavily on the idea of service-oriented architecture, within which
Web services are created and stored, providing the building blocks for
programs and systems.
• The use of “best in breed” Web service-based solutions might be more
palatable to businesses, since it might be easier and less risky to plug-in a
new Web service-based solution than replace or add-on a new product
module.
• While the “one source” alternative seems most popular at present, the “best
in breed” approach will be good if greater interoperability/integration
among vendor products is achieved.
• There is a need for greater “out of the box” interoperability, thus a need for
standards.

Traditional vs. ES Software Implementations
The traditional software implementation involving the development of
applications was characterized by the following:
• Requirement-driven functional decomposition
• Late risk resolution
• Late error detection
• Use of different languages or artifacts at different phases of the
project
• Large proportion of scrap and rework
• Adversarial stakeholder relationships with non-IT users
• Priority of techniques over tools
• Greater emphasis on current, correct, complete, and consistent
documentation
• Greater emphasis on testing and reviews

Traditional vs. ES Software Implementations
ES software implementations are characterized by the following:
• Primacy of the architecture, process-oriented configurability
• Primacy and direct participation of the business user
• Early risk resolution
• Early error and gap detection
• Iterative life-cycle process, negligible proportion of scrap and rework
• Changeable and configurable functionality
• Participatory and cohesive stakeholder relationships with non-IT users
• Priority of functionality over tools followed by techniques
• Quality of the functional variability and flexibility of the available
functionality

Traditional vs. ES Software Implementations
Off-the-shelf packages and especially enterprise-wide solutions such as
ES were considered to be the best approach due to:
• ES ensure better validation of user requirements directly by the user.
• ES ensure consistent quality of delivered functionality.
• ES provide a cohesive and integrated information system architecture.
• ES ensure a fair degree of standardization.
• ES provide a consistent and accurate documentation of the system.
• ES provide outstanding quality and productivity in the development
and maintenance of the system

• Enterprise Resource Planning (ERP)

The Concept of Enterprise Resource Planning
• The main focus of ERP has been to integrate and synchronize the
isolated functions into streamlined business processes.
• ERP not only coordinates multiple divisions but also requires
companies to enter data only once for the information to be
distributed to all of the integrated business processes.
• ERP systems consist of several integrated suites of software modules,
which share common data and provide connectivity.
• The information about the processes in the company is represented
consistently and is up to date in all business divisions at all times.

Enterprise Resource Planning System
ERP could be defined reasonably as follows:
“An ERP software applications package is a suit of pre-engineered,
ready-to-implement integrated application modules catering to all of
the business functions of an enterprise and which possesses the
flexibility for configuring and customizing dynamically the delivered
functionality of the package to suit the specific requirements of the
enterprise. ERP enables an enterprise to operate as an integrated
enterprise wide, process-oriented, information-driven real-time
enterprise.”

Enterprise Resource Planning System
• At the heart of an ERP system, resides a CASE-like repository that
stores all details of these predeveloped applications.
• These details include every single data item, data table, and software
program that is used by the complete system.
• The major development of the ERP systems over the information
engineering approaches was in terms of providing predefined,
already-built-in comprehensive functionality of the application
systems.
• The success of ERP packages is based on the principle of reusability.

Enterprise Resource Planning System

• Information and
material flows
in a functional
business model

Enterprise Resource Planning System

• Information
and material flows
in a business process
model.

Characteristics of Enterprise Resource Planning
The distinguishing characteristics of ERP are as follows:

1. ERP transforms an enterprise into an information-driven enterprise.
➢ ERP began treating information as a resource for the operational requirements
of the enterprise.
➢ Unlike the traditional resources, information resource as made available by ERP
systems can be reused and shared multiply without dissipation or degradation.
➢The impressive productivity gains resulting from the ERP systems are related to
using information as an inexhaustible resource.

Characteristics of Enterprise Resource Planning
2. ERP fundamentally perceives an enterprise as a global enterprise.
➢ ERP systems cater to corporate-wide requirements even if an enterprise is
involved in disparate businesses such as discrete industries; process
industries; and services industries.
➢ ERP enables the management to plan, operate, and manage such
conglomerates without any impediments of mismatching of systems for
different divisions.

Characteristics of Enterprise Resource Planning
3. ERP reflects and mimics the integrated nature of an enterprise.
➢ ERP offerings like SAP provides a powerful medium for supporting,
reconciling, and optimizing the conflicting goals of different functions of the
enterprises.

4. ERP fundamentally models a process-oriented enterprise.
➢ Process modeling permits the true comprehension of the characteristic
structure and dynamics of the business.
➢ Business processes are the most important portions of the reality that had
been ignored by the traditional IS.

Characteristics of Enterprise Resource Planning
5. ERP enables the real-time enterprise.
➢ In non-ERP enterprises, closely related processes are typically done
sequentially because they are usually handled by the same set of personnel,
who may be obviously constrained to address them only in a sequence.
➢ ERP systems like SAP can perform all these processes concurrently because of
ready availability of all of the relevant, complete, and consistent information
at the same time.

Characteristics of Enterprise Resource Planning
6. ERP Elevates Information Technology Strategy as a Part of the Business Strategy
➢ This arises primarily from the fact that information itself has become a vital
resource for an enterprise in the same league as the traditional resources like
manpower, materials, money, and time.
7. ERP Represents a Major Advance on the Earlier Manufacturing Performance
Improvement Approaches
➢ ERP systems provide the basic platform for devising techniques and tools for
better implementations of the earlier approaches

Characteristics of Enterprise Resource Planning
8. Represents the Departmental Store Model of Implementing Computerized
Systems
➢ An ERP is the analog of the great departmental store of functionalities or
processes required within an enterprise.

9. ERP is a Mass-User-Oriented Application Environment
➢ ERP brings computerization to desktops and, in this sense, is an end-useroriented environment.
➢ In traditional systems, users access the system directly only in well-defined
pockets within the enterprise.
➢ In ERP, end users are truly the personnel actually involved with the
operations of the business.

Advantages of Enterprise Resource Planning
• Reconciliation and optimization of the conflicting goals of different divisions or
departments.
• The ability to know and implement global best practices.
• Alteration of the function-oriented organization toward a more team-based,
cross-functional, process-oriented enterprise, thus leading to a more flexible,
flatter, and tightly integrated enterprise.
• ERP provides a responsive medium for undertaking all variants on process
improvement programs and methodologies including PI, process improvement,
and business process.
• ERP also provides a responsive medium for quality improvement and
standardization efforts including quality control, quality assurance, and TQM.

Advantages of Enterprise Resource Planning
• ERP is a fertile ground for implementing activity-based management efforts, be it
for budgeting, costing, efficiency, or quality.
• ERP could assist in the implementation of, for instance, the balanced scorecard
within the enterprise.
• ERP systems, because they customarily implement best-of-class practices, provide
the best means for benchmarking the organization’s competitiveness.
• An ERP system enables an enterprise to scale up its level of operations drastically
or even enter into different businesses altogether without any disruption or
performance degradation.
• An ERP system ensures real-time creation of data directly during the actual
physical transaction or processes by the persons who are actually responsible for
it.

Advantages of Enterprise Resource Planning
• An ERP system pushes the latest data and status to the actual operational-level
persons for better and faster decisions at least on routine issues and empowers
and gives ownership to the operational personnel at the level of actual work.
• An ERP system prompts the integration of data of the enterprise into a single
comprehensive database.
• An ERP system enables online availability of correct and up-to-date data.
• ERP provides the most current, correct, consistent, and complete operational
data that could be populated into the enterprise data warehouse for analysis and
reporting.
• ERP greatly reduces the cost of maintaining systems.

Disadvantages of Enterprise Resource Planning
• ERP reinforces the silo-oriented functioning of the traditional
functional organizations.
• ERP enhances team-based operations in the organization, but, often,
these teams remain confined to the traditional functional silos in that
they do not cross the boundaries of the functional departments.
• ERP implementations render the personnel enabled for system-based
operations but do not necessarily do so for collaborative operations
especially across traditional departmental boundaries.

Enterprise Business Processes
• Businesses take inputs (resources) in the form of material, people, and
equipment and transform these inputs into goods and services for
customers.
• Managing these inputs and the business processes effectively requires
accurate and up-to-date information.
• In the process-oriented model, the flow of information and management
activity is horizontal across functions, in line with the flow of materials and
products.
• This horizontal flow promotes flexibility and rapid decision-making and
stimulates managers to see the importance of managing business
processes.
• Now, information flows between the operating levels without top
management’s involvement

Main Reference
1. Chapter 1 (Enterprise Process Management Systems:
Engineering ProcessCentric Enterprise Systems using
BPMN 2.0 by Vivek Kale)
Additional References

1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise
information systems: A pattern-based approach (3rd ed.)

Thank You

‫ر‬
‫الجامعة السعودية االلكتونية‬
‫ر‬
‫االلكتونية‬
‫الجامعة السعودية‬

‫‪26/12/2021‬‬

College of Computing and Informatics
Information Technology
IT402
Integrated Enterprise Systems

IT402
Integrated Enterprise Systems
Week 3
Characteristics of Business Processes

Required Reading
1. Chapter 2 (Enterprise Process Management Systems:
Engineering ProcessCentric Enterprise Systems using
BPMN 2.0 by Vivek Kale)

Recommended Reading
1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise
information systems: A pattern-based approach (3rd ed.)

Weekly Learning Outcomes

1. Describes the framework for measuring business process
performance in terms of the dimensions of timeliness, cost,
and quality.

Contents

1. Business Process
2. Process Performance
3. Process Cycle Time
4. Process Costs
5. Process Quality
6. Measuring Process Performance

• Business Process

Business Process
• A business process is a set of logically related tasks performed to achieve a
well-defined business outcome.
• A business process defines:

➢ The results to be achieved,
➢ The context of the activities,
➢ The relationships between the activities,
➢ The interactions with other processes and resources.

• A business process may produce events for input to other applications or
processes.
• A business process is a coordinated and logically sequenced set of work
activities and associated resources that produce something of value to a
customer.

Business Process
Business
Steps

Business
Goals

Business
Process

Stakeholders

Business Process
A business process has the following behaviors:

• It may contain defined conditions triggering its initiation in each new
instance and defined outputs at its completion.
• It may involve formal or relatively informal interactions between
participants.
• It has a duration that may vary widely.
• It may contain a series of automated activities and/or manual activities.

Business Process (cont.)
A business process has the following behaviors:
• It exhibits a very dynamic nature.
• It is widely distributed and customized across boundaries within and
between enterprises.

• It is usually long-running—a single instance of a process may run for
months or even years.

Process Performance
Process-oriented enterprises consider any enterprise as a process that converts
input into output characterized by:
1. Inputs and outputs:
• Inputs are any tangible or intangible items that flow into the process from the
environment.
• Outputs are any tangible or intangible items that flow from the process back
into the environment.
2. Flow units: A flow unit or job is an item that flows throughout the process.
3. A network of activities and buffers:
• An activity is the simplest form of transformation; it is actually a miniprocess
in and of itself.
• A buffer stores flow units that have finished one activity but are waiting for
the next activity to start.

Process Performance
4. Resources are tangible assets that are usually divided into two
categories: capital and labor.
5. Information structure describes the information that is needed and
available in order to perform activities or to make managerial decisions.
➢ The process flow is a dynamic process that starts when an input
enters a process and continues processing throughout different kinds
of process activities and ends when it leaves the process as its
output.

Process Performance
Three key measures of the process flow:
1. Cycle time or flow time, which is the time it takes to complete an
individual flow unit or job from start to finish.
➢ Processing time
➢ Inspection time
➢ Transporting time
➢ Storage time
➢ Waiting time

2. Flow rate or throughput, which is the number of jobs per unit of
time.

Process Performance
3. Inventory, which is the total number of flow units present within the
process boundaries.
• The inventory within the framework of the process depends on the difference
between the inflow rate and outflow rate.

R(t) means the flow rate at a certain point of time t.
Ri(t) means inflow; this is the flow rate of flow units that enter the process
through its entry points.
Ro(t) means outflow; this is the flow rate of flow units that leave the process
through its exit points.

Process Performance
4. Little’s Law For a stable process: defines the fundamental
relationship between average inventory, average flow rate, and
average cycle time in a stable process.
• Average flow rate or throughput is the average number of flow units that
flow through the process per unit of time.
• A stable process is one in which the average inflow rate is the same as the
average outflow rate across an extended period of time; that is R = Ri = Ro
• The average cycle time is the average across all flow units that exit the
process during a specific period of time.
• Average inventory is the number of flow units within the process boundaries
at any point in time.
➢ The average inventory equals the average flow rate times the average cycle time;
that is, I = R*T.
➢ Example.

Process Cycle Time
1. Theoretical cycle time
• The theoretical cycle time of a process is the minimum amount of time
required for processing a typical flow unit without any waiting.
• It is the sum of the times of those activities that the flow unit passes through
and where specific kinds of tasks are undertaken to process it.
• Activity time is the time required by a typical flow unit to complete the
activity once.

2. Critical path: A process flow is presented using a diagrammatic
technique like a flowchart. The longest path in the process
flowchart is the critical path.
• All activities that constitute the critical path of the process flowchart are
called critical activities.

Process Cycle Time
3. The critical path method is based on calculating a variable called the
slack time of an activity.
• The extent to which an activity could be delayed without affecting process flow
time.
• A critical activity is an activity whose slack time is equal to 0.
➢ The critical path consists of all those activities for which the slack time is
equal to 0.
• To determine the critical path, two schedules have to be calculated:
a. Forward schedule – calculates the earliest possible start time (ES) and the
earliest possible finish time (EF) of each activity within the process.
1st activity, ES = 1, where 1 means 1 time unit.
Other activities, ES = 1 + max(EF) of immediate predecessor activities.
EF = ES + d + 1, where d is duration time of the activity

Process Cycle Time
b. Backward schedule – calculates the latest possible start time (LS) and the latest
possible finish time (LF) for each activity of the process.
1st activity, LF = EF
Other activities, LF = min(LS) of immediate successor activities −1
LS = LF − d + 1, where d is the duration time of the activity.

4. Slack time (S): The slack time of an activity is the amount of time that could be
spent in addition to the duration time of the activity, without causing a delay to the
start times of immediate successor activities.
S = LF − EF = LS − ES

5. Cycle-time efficiency: the ratio between the theoretical cycle time and the
average cycle time.
Cycle-time efficiency = theoretical cycle time/average cycle time

Computing Cycle Time
1. The sum of the theoretical and waiting times.
Cycle time = theoretical cycle time + waiting time
Average cycle time of a process can be obtained by:
• Treating waiting in each buffer as an additional (passive) activity with an
activity time equal to the amount of time in that buffer.

• Adding waiting times to the theoretical cycle time of the appropriate path.
• Obtaining the average cycle time of the process by finding the path whose
overall length (activity plus waiting) is the longest.

Computing Cycle Time
2. Using value-adding and non-value-adding activities.
• Value-adding activities are those activities that increase the economic value
of a flow unit because the customer values them.
• Non-value-adding activities are activities that, while required by the firm’s
process, do not directly increase the value of a flow unit.

Cycle time = value-adding cycle time − non-value-adding cycle time
3. Computing the cycle time using Little’s law.
• Computing the average cycle time of a process by finding the longest cycle
time of the process flowchart—that is, by finding the critical path of the
process.

Process Flow Aspects
1. Rework
• A process flowchart may contain one or more segments of a number of sequential
activities whose execution needs to be repeated several times, depending on a
decision activity, where the value of a certain condition is defined.
• This is known as a rework or execution loop; each repetition of a rework loop is called a
visit.

2. Multiple Paths
• There are a number of cases in a process flowchart where, after a decision activity, the
process flow splits into two or more paths.
• This formula can be used to compute the average cycle time for a process flow that
splits into multiple paths after a decision activity:
T = p1*T1 + p2*T2 + … + pm*Tm
pi is the probability of following the flow of path i
Ti is the sum of times of activities within path i
m is the number of paths

Process Flow Aspects
3. Parallel Paths
• The process flowchart may contain one or more segments that are
constructed from parallel activities.
• The cycle time of the part of the process with parallel paths is represented by
the maximum sum of times of activities in the parallel paths.
T = max( T1, T2, … , Tm)
Ti is the sum of times of activities within path i
m is the number of paths

Process Capacity
• Considering that the average flow rate or throughput is defined as the
average number of flow units or jobs that flow through the process
per unit of time, the process capacity is the maximum sustainable
flow rate of a process.
• Resources – the capacity of a process depends on the resources that
are used in the process. Performing any activity requires one or more
resources, and every resource may be involved in performing one or
more activities.
• Resource pool – a collection of interchangeable resources that can
perform an identical set of activities.
• Resource-pooling – associating different resource pools into a joint
resource pool in order to carry out a set of activities within a process.

Process Capacity
• Theoretical Capacity – The theoretical process capacity is the
maximum sustainable throughput rate for the process operating
without interruption. The actual process capacity will always be less
than the theoretical capacity due to:
• Resource breakdowns: A machine may become unavailable due to a
breakdown or a human resource may be absent.
• Preventive maintenance: Machines require regular maintenance to operate at
maximum efficiency; this scheduled preventive maintenance makes the
resource unavailable for processing.
• Process flow inefficiencies: A resource may become idle due to the
unavailability of work.
• Demand variation: As described earlier, the mismatch between demand and
capacity can cause underutilization.

Process Capacity
• The flow unit on its way through different activities is processed by a
number of resource pools with predetermined capacities;
• The pool with the lowest capacity is termed as the resource bottleneck of
the process.
• Since the capacity of a process cannot be better than the process’s
bottleneck resource pool, this effectively makes it the defining capacity of
the whole process.
• Assuming that we have a resource pool p with cp resource units,
Rp = cp / Tp
Rp is the theoretical capacity of the resource pool
cp is the number of resource units in the pool p
Tp is the unit load of the resource pool

Process Capacity
• If the resource units in a certain resource pool do not have the same
theoretical capacity,
➢ the theoretical capacity of the resource pool is computed as the sum of all of the
theoretical capacities of its constituting resource units, provided the following
conditions are true:
1.
2.

The flow units are performed by resource units sequentially one by one.
The resource units are available the same quantity of time.

• Load-batching and scheduled availability are important factors that have a
real effect on the theoretical capacity of the process.
• Load batching as the ability of a resource unit to process a number of flow units
simultaneously
• Scheduled availability as the quantity of time in which a resource unit is scheduled to
perform a determined work

• Thus, the theoretical capacity of resource pool p with cp resources is,
Rp = cp / Tp * load batch * scheduled availability

Process Capacity
• Capacity Utilization – measures the degree to which resources are
effectively utilized by a process.
• It indicates the extent to which resources, which represent invested capital,
are utilized to generate outputs.
• For each resource pool, capacity utilization of the process is defined as the
capacity utilization of the bottleneck resource pool.
ρp = R / Rp
R is the throughput
Rp is the theoretical capacity of a resource pool

Process Capacity
The theoretical capacity can be improved by:
1. Decreasing the unit load on the bottleneck resource pool (i.e., work
faster, work smarter)
2. Increasing the load batch of resources in the bottleneck resource
pool (i.e., increase the scale of the resource)
3. Increasing the number of units in the bottleneck resource pool (i.e.,
increase the scale of the process)
4. Increasing the scheduled availability of the bottleneck resource
pool (e.g., work longer)

Process Costs
A cost component is any activity for which a separate cost measurement is
desired (e.g. the materials consumed, inventory, labor, or overhead of the
process).
1. Direct costs – costs that can be directly and exclusively attributed to a
particular cost object. These are traced to the work unit and assigned
2. Indirect costs – costs that cannot be directly and exclusively attributed to a
particular cost object. These cannot be traced to the work unit because they
are common to many work units.

Other ways to classify the process cost components are:
1. Fixed costs, which remain constant for all levels of output.
2. Variable costs, which are the costs per work unit and therefore vary with the
amount of sales.

Process Quality
Quality can be defined from the two different perspectives:
1. Customer’s perspective – the degree to which a product or service satisfies the
needs and expectations of the customer.
2. Enterprise’s perspective – the degree to which a product or service conforms to
the specifications designed for the product or service.
• Quality-by-Design – A product or service cannot meet customer needs unless
the enterprise perceives those customer needs and designs a product or service
to fulfil those needs and designs a product or service to fulfil those needs.

Process quality
To institute quality processes, an enterprise performs three main
functions:
1. Design quality products and services by understanding customer needs and
translating them into product and service specifications.
a. The quality functional deployment methodology and tools translate the customer
needs into the attributes of a product or service. The primary tool of quality
functional deployment is:
➢ The house of quality, a matrix that denotes the strength of the association between a
product or service attribute and customer expectations using a range from 0 to 9, with 9
indicating a very strong association.
➢ This matrix indicates the degree of correlation between product attributes as either
weak, medium, or strong.

Process Quality
b. Poka-yoke: To design quality into the product, the process that produces the product
should be failproof.
➢ In manufacturing, parts may be designed so that they can only be assembled in the correct
way, thus removing the need for the worker to think about how the parts go together and
possibly making an error.
➢ In service industries, checklists are used to remind the person to do all of the procedures for
every customer.

• Poka-yoke designs the process so as to eliminate the possibility of quality problems
before they can happen.
c. Taguchi method: Any deviation from the target is undesirable. Normally, any value that
fell within the lower and upper specifications was considered good.
➢ The quadratic loss function says that any deviation from the target value results in a loss.

Process Quality
2. Deliver quality products and services by having processes that produce no
defects and demonstrate little variability.
• The underlying principle of statistical quality control is that all processes
exhibit variation in their output.
• Some of the variation is called common cause variation and is due to the
inherent characteristics of the process.
• Other variation is the result of special causes that can be attributed to a
specific problem.
• Statistical process control uses control charts to monitor processes.
• The design of a quality process involves instituting the correct feedback loops
so as to constantly monitor and control the process.
• The usage of control charts helps to maintain process variability within a small
range of values within which the variability is explained only by common
cause variation.

Process Quality
3. Improve the quality of their processes by establishing continuous process
improvement programs (e.g. DMAIC, Six Sigma) that run parallel to the core
business processes.
The analysis teams need to identify improvement opportunities to:
• Eliminate waiting time (a waste)
• Eliminate wasted movement or effort
• Minimize inventory
• Eliminate repair and rework
• Minimize material movement 40 Enterprise Process Management Systems
• Minimize inspections
• Reduce the variation of inputs, process, and outputs
• Reduce cycle time
• Improve machine reliability
• Improve flexibility of resources

Measuring Process Performance
A process performance measurement
system focuses on an individual
business process, rather than on the
entire company or an organizational
unit.

Concepts for Performing Measurement
1. Process performance measurement based on indicators, measures,
and figures.
• Two performance indicators can be identified: time (as an input factor) and
service quantity (as an output factor).
• Performance measures represent the operationalization of each identified
performance indicator.
• Performance figures enable the summarization and representation of large
amounts of data in a condensed and precise manner.

Concepts for Performing Measurement
2. Measurements to determine process performance
• Performance figures are highly dynamic. The selection of strategically
important performance indicators is related to the notion of “critical success
factors”.
• Quality indicators describe the degree to which the actual product attributes
and properties conform to the underlying product specifications.
• Time indicators are considered to be an indicator of competitiveness and
process performance.
• Flexibility indicators describe the degree to which a production or service
process can be modified, including the timeline and costs associated with the
restructuring of a production or service process.

Frameworks for Measuring Process Performance
• The performance pyramid framework stresses a hierarchical view of performance.
It considers the relationship between:
• Strategic performance
(e.g., fulfilling the vision)
• Process performance
(e.g., quality, cycle time)
• The layer connecting the two
hierarchical levels depicts those
performance indicators that impact
both levels (e.g., customer
satisfaction, flexibility, and productivity).

Frameworks for Measuring Process Performance
This framework constructs a process-oriented performance measurement system
that highlights the distinction between input, throughput, and output that is
considered for determining performance indicators according to this classification.

Main Reference
1. Chapter 2 (Enterprise Process Management Systems:
Engineering Process-Centric Enterprise Systems using
BPMN 2.0 by Vivek Kale)
Additional References
1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise
information systems: A pattern-based approach (3rd ed.)

Thank You

‫ر‬
‫الجامعة السعودية االلكتونية‬
‫ر‬
‫االلكتونية‬
‫الجامعة السعودية‬

‫‪26/12/2021‬‬

College of Computing and Informatics
Information Technology
IT402
Integrated Enterprise Systems

IT402
Integrated Enterprise Systems
Week 5
Enterprise Architecture (EA)

Required Reading
1. Chapter 4 (Enterprise Process Management Systems:
Engineering ProcessCentric Enterprise Systems using
BPMN 2.0 by Vivek Kale)

Recommended Reading
1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise
information systems: A pattern-based approach (3rd ed.)

Weekly Learning Outcomes
1. Explain enterprise architecture as a well-defined practice for
conducting enterprise analysis, design, planning, and implementation,
using a holistic approach at all times, for the successful development

and execution of enterprise strategy.
2. Describe the viewpoints, views, and perspectives that enable an

enterprise architecture.

Contents

1. Architecture
2. Viewpoints and Views
3. Change, Availability, and Scalability Perspectives
4. Enterprise Architecture Frameworks

Architecture
• An EA provides a high-level design of the entire enterprise that will
guide all other enterprise projects.
• An architecture represents significant, broad design decisions for the
enterprise, from which all other design decisions should be
consistent.
• The Software Engineering Institute (SEI) defines architecture as:
“The architecture of a software-intensive system is the structure or
structures of the system, which comprise software elements, the
externally visible properties of those elements, and the
relationships among them”.

Enterprise Architecture
EAs major goals:
1. For the EA, its units, policies, processes, strategies, and
technological infrastructure (e.g., IT systems) to successfully
support all stakeholders in achieving short and long-term business
goals and objectives of the enterprise.
2. For the EA to foster an alignment of the technological systems
developed by and used by an enterprise with its business goals and
strategic direction
3. For the EA to help an enterprise to learn, grow, innovate, and
respond to market demands and changing basic conditions
4. For the EA foster and maintain the learning capabilities of
enterprises so that they may be sustainable

Architectural Element
• An architectural element is a fundamental piece from which a system
can be considered to be constructed.
• An architectural element possesses several key attributes:
• A clearly defined set of responsibilities
• A clearly defined boundary
• A set of clearly defined interfaces, which define the services that the element
provides to the other architectural elements

Systems Structures
System structures are of two kinds:
1. The static structures of a software system define its internal designtime elements and their arrangement.
• Internal design-time software elements might be modules, object-oriented
classes or packages.
• Internal data elements include classes, relational database entities/tables,
and data files.
• Internal hardware elements include computers or their constituent parts such
as disk or central processing unit and networking elements such as cables.

2. The dynamic structures of a software system define its runtime
elements and their interactions.
• They show how the system actually works, what happens at runtime, and
what the system does in response to external (or internal) stimulus.

System Structures
External properties manifest in two forms:
1. The externally visible behavior of a software system defines the
functional interactions between the system and its environment.
• The externally visible behavior of a system (i.e., what it does) is determined
by the combined functional behavior of its internal elements.

2. A quality property is an externally visible, nonfunctional property of
a system such as performance, security, or scalability.
• The quality properties of a system such as performance, scalability, and
resilience (how it does it) arise from the quality properties of its internal
elements.

Quality Attributes
1. Implementation attributes (not observable at runtime); include:
a. Interoperability: Universal accessibility and the ability to exchange data
among internal components and with the outside world.
b. Maintainability and extensibility: The ability to modify the system and
conveniently extend it.
c. Testability: The degree to which the system facilitates the establishment of
test cases.
d. Portability: The system’s level of independence on software and hardware
platforms. Systems developed using high-level programming languages
usually have good portability (e.g. Java)
e. Scalability: A system’s ability to adapt to an increase in user requests.
Scalability disfavors bottlenecks in system design.
f.

Flexibility: The ease of system modification to cater to different environments or
problems for which the system was not originally designed.

Quality Attributes
2. Runtime attributes (observable at runtime); include:
a. Availability: A system’s capability to be available 24/7.
b. Security: A system’s ability to cope with malicious attacks from outside or
inside the system.
c. Performance: Increasing a system’s efficiency with regard to response time,
throughput, and resource utilization, which are attributes that are usually in
conflict with each other.
d. Usability: The level of human satisfaction derived from using the system.
e. Reliability: The failure frequency, the accuracy of output results, the
meantime-to-failure, the ability to recover from failure, and the failure
predictability
f. Maintainability (extensibility, adaptability, serviceability, testability,
compatibility, and configurability); the ease of software system change.

Quality Attributes
Business attributes, include:
a. Time to market: The time it takes from requirements analysis to the
date a product is released.
b. Cost: The expense of building, maintaining, and operating the
system.
c. Lifetime: The period of time that the product is “alive” before
retirement.

Attribute Tradeoffs
1. Tradeoff between space and time: For example, to increase the time
efficiency of a hash table means a decrease in its space efficiency.

2. Tradeoff between reliability and performance: For instance, Java
programs are well protected against buffer overflow due to security
measures such as boundary checks on arrays. Such reliability features
come at the cost of time efficiency, as compared with the simpler and
faster C language that provides the “dangerous,” yet efficient, pointers.
3. Tradeoff between scalability and performance: For example, one typical
approach to increase the scalability of a service is to replicate servers. To
ensure consistency of all servers, performance of the whole service is
compromised.

Candidate Architecture
• A candidate architecture for a system is a particular arrangement of
static and dynamic structures that have the potential to exhibit the
system’s required externally visible behaviors and quality properties.
• An architecture style (also known as an “architecture pattern”)
abstracts the common properties of a family of similar designs.
• An architecture style contains a set of rules, constraints, and patterns
of how to structure a system into a set of elements and connectors.
• An architecture style is a viewpoint abstraction for a software
structure that is domain-independent.
• A system can adopt heterogeneous architectures—that is, more than
one architecture style can coexist in the same design.

Architecture Style
Key components of an architecture style:
• Elements that perform functions required by a system
• Connectors that enable communication, coordination, and cooperation among
elements
• Constraints that define how elements can be integrated to form the system
• Attributes that describe the advantages and disadvantages of the chosen
structure

For example:
• In the data-centric style, the data store plays a central role and is accessed
frequently by other elements that modify data.
• In the dataflow style, input data are transformed by a series of computational
or manipulative elements.

Architecture Style
Multitier architecture is commonly used for distributed systems. It
usually consists of three element types, as follows:
1. The client element is responsible for graphical user interface presentation,
accepting user requests, and rendering results.
2. The middleware element gets the requests from the client element,
processes the requests based on the business logic, and sends a data
request to the backend tier.
3. The data store server element manages data querying and updating.

All three types of elements are connected via a network (e.g., the
Internet).

Stakeholder
• A stakeholder in a architecture is a person, group, or entity with an
interest in or concerns about the realization of the architecture.
• A concern about an architecture is a requirement, an objective, an
intention, or an aspiration a stakeholder has for that architecture.
• A good architecture is one that successfully meets the objectives,
goals, and needs of its stakeholders.
• Stakeholders (explicitly or implicitly) drive the whole shape and
direction of the architecture, which is developed solely for their
benefit and to serve their needs.
• Stakeholders ultimately make or direct the fundamental decisions
about scope, functionality, operational characteristics, and structure
of the eventual product or system.

Viewpoints and Views
• A view is a representation of structural aspects of an architecture that
illustrates how the architecture addresses concerns held by stakeholders.
• An architectural view is a way to portray those aspects of the architecture
that are relevant to the concerns with reference to this view.
• A viewpoint is a collection of patterns, templates, and conventions for
constructing one type of view.
• A viewpoint defines the stakeholders whose concerns are reflected in the
viewpoint and the guidelines, principles, and template models for
constructing its views.
• Viewpoints make available a library of templates and patterns that can be
used to guide the creation of an architectural view that can be inserted into
an architectural description.

Viewpoint Catalog
• Information, describes the way that the architecture stores, manipulates,
manages, and distributes information.
• Functional, describes the system’s functional elements, their
responsibilities, interfaces, and primary interactions.
• Concurrency, describes the concurrency structure of the system and maps
functional elements to concurrency units to clearly identify the parts of the
system that can execute concurrently and how this performance is
coordinated and controlled.
• Development, describes the architecture that supports the software
development process.
• Deployment, describes the environment into which the system will be
deployed, including capturing the dependencies the system has on its
runtime environment.
• Operations, describes how the system will be operated, administered, and
supported when it is running in its production environment.

Viewpoint Benefits
• Management of complexity
• Communication with stakeholder groups
• Separation of concerns
• Improved developer focus considers the idea that the architectural
description is the foundation of the system design

Perspectives
• An architectural perspective is a collection of activities, tactics, and
guidelines that are used to ensure that a system exhibits a particular
set of related quality properties that require consideration across a
number of the system’s architectural views.
• Most important perspectives for large information systems include:
• Performance and Scalability
• Availability and Resilience
• Security
• Evolution

Perspectives Advantages
1. A perspective is a useful store of knowledge, helping one to quickly
review their architectural models for a particular quality property
without having to absorb a large quantity of highly detailed
material.

2. A perspective acts as an effective guide when one is working in an
area that is new to them/when they are unfamiliar with its typical
concerns, problems, and solutions.
3. A perspective is a useful memory aid when one is working in an
area that they are more familiar with, to make sure that they don’t
forget anything important.

Benefits of Applying Perspectives to a View
• Provides common conventions, measurements, or even a notation or
language that can be used to describe the system’s qualities.
• Defines concerns that guide architectural decision-making to help
ensure that the resulting architecture will exhibit the quality
properties considered by the perspective.
• Describes how one can validate the architecture to demonstrate that
it meets its requirements across each of the views.
• May offer recognized solutions to common problems, thus helping to
share knowledge between architects.
• Helps working in a systematic way to ensure that the relevant
concerns are addressed by the system.

Perspectives Catalog

Perspectives Catalog
Perspectives are defined with details like:
• Applicability: explains which of your views are most likely to be
affected by applying the perspective.
• Concerns: defines the quality properties that the perspective
addresses.
• Activities: identifies the important quality properties, analyzing the
views against these properties, and making architectural design
decisions that modify and improve the views.
• Architectural tactics: an established and proven approach one can
use to help achieve a particular quality property.
• Problems and pitfalls: explains the most common things that can go
wrong and gives guidance on how to recognize and avoid them.

Perspectives Catalog

The Change Perspective
• Desired quality: The ability of the system to be flexible in the face of the
inevitable change experienced after deployment.
• Applicability: More important for longer-lived and widely used systems.
• Concerns: Magnitude of change, dimensions of change, likelihood of
change, timescale for change, and when to pay for change.
• Activities: Characterize the change needs, assess the current ease of
change, and consider the change tradeoffs.
• Architectural tactics: Contain change, create flexible interfaces, apply
change-oriented architectural styles, and build variation points into the
software.
• Problems and pitfalls: Prioritization of the wrong dimensions, changes that
never happen, and impacts of change on critical quality properties.

Applicability of the Change Perspective
a. Functional view may be informed by the Change perspective by enabling
the functional structure to reflect the required change.
b. Information view may be informed by the Change perspective by
mandating a flexible information model.
c. Concurrency view may be informed by the Change perspective by
dictating a particular element packaging or some constraints on the
concurrency structure
d. Development view may be informed by the Change perspective by
determining the impact on the development environment.
e. Deployment view may be informed by the Change perspective by
defining impact on the Deployment view because system change usually
affects structures described in other views.
f. Operational view may be informed by the Change perspective to the
extent that it impacts on the operational view.

Tactics for enhancement
• Contain change
• Create flexible interfaces
• Build variation points into the system
• Use standard extension points
• Implement reliable changes
• Apply change-oriented architectural styles

Availability Perspectives
• Desired quality: the ability of the system to be fully or partly operational as and
when required and to effectively handle failures that could affect system
availability.
• Applicability: any system that has complex or extended availability requirements,
complex recovery processes, or a high visibility profile
• Concerns: classes of service, planned downtime, unplanned downtime, time to
repair, and disaster recovery
• Activities: capture the availability requirements, produce the availability
schedule, estimate platform availability, estimate functional availability, and
assess against the requirements.
• Architectural tactics: select fault-tolerant hardware, use hardware-clustering and
load-balancing, log transactions, and apply software availability solutions.
• Problems and pitfalls: a single point of failure, ineffective error detection,
overlooked global availability requirements, and incompatible technologies.

Applicability of the Availability Perspective
• The Functional view may be informed by the Availability perspective by
enabling the business’s ability to operate effectively.
• The Information view may be informed by the Availability perspective by
considering the set of processes and systems for backup and recovery.
• The Concurrency view may be informed by the Availability perspective by
incorporating features such as hardware replication and failover in the
system.
• The Development view may be informed by the Availability perspective by
imposing design constraints on the software modules
• The Deployment view may be informed by the Availability perspective by
mandating a fault-tolerant production environment.
• The Operational view may be informed by the Availability perspective to
allow the identification and recovery of problems in the production
environment.

Tactics for Enhancement
• Select fault-tolerant hardware
• Use hardware clustering and load balancing
• Log transactions
• Implement fault-tolerant software
• Implement software availability solution
• Implement backup and disaster recovery solutions

Scalability Perspective
• Desired quality: the ability of the system to predictably execute
within its mandated performance profile.
• Applicability: systems with complex performance requirements; and
systems where future expansion is likely to be significant
• Concerns: response time, throughput, scalability, predictability,
hardware resource requirements, and peak load behavior.
• Activities: capture the performance requirements, create the
performance models, and analyze the performance models.
• Architectural tactics: optimize repeated processing, reduce
contention via replication, and prioritize processing.
• Problems and pitfalls: imprecise performance and scalability goals,
unrealistic models, and use of simple measures for complex cases.

Applicability of the Scalability Perspective
• The Functional view may be informed by the Scalability perspective
by revealing the need for changes and compromises to one’s ideal
functional structure to achieve the system’s performance
requirements.
• The Information view may be informed by the Scalability perspective
by providing useful input to performance models, identifying shared
resources and the transactional requirements of each.
• The Concurrency view may be informed by the Scalability perspective
to change the concurrency design by identifying problems such as
excessive contention on key resources.

Applicability of the Scalability Perspective
• The Development view may be informed by the Scalability
perspective through a set of guidelines related to performance and
scalability that should be followed during software development.
• The Deployment view may be informed by the Scalability perspective
through crucial inputs to the process of considering performance and
scalability.
• The Operational view may be informed by the Scalability perspective
by highlighting the need for performance monitoring and
management capabilities.

Tactics for Enhancement
• Optimize repeated processing
• Reduce contention through replication
• Prioritize processing
• Minimize use of shared resources
• Minimize partition and parallelize
• Make design compromises

Enterprise Architecture Frameworks
• Helps stakeholders to make decisions about enterprise design and
operation.
• Provides users with some confidence that the use of the reference
architecture will be successful in the current project.
• Facilitates communication of the enterprise design.
• Applicable to a wide range of enterprise systems and scenarios.
• Establishes a common means to organize, interpret, and analyze
architectural descriptions
• Identifies architectural concerns, generic stakeholders, viewpoints, and
abstraction levels.
• Encourages reuse.
• Provides a unified, unambiguous definition of terminology.

The Zachman Framework
Six types of views
1. Planner’s View – executive summary for the project.
2. Owner’s View – a high-level view of the system from the owner’s point of
view.
3. Designer’s View – more technically detailed view of the system.
4. Builder’s View – emphasis will be on implementation issues and
constraints.
5. Subcontractor’s View – detailed designs that are given to the development
team.
6. Actual System View – the actual systems that are being developed.

The Open Group Architecture Framework
• TOGAF provides an approach for designing, planning, implementing,
and governing an enterprise IT architecture.
• TOGAF is a set of phases and associated processes in the form of an
architecture development method (ADM) that will enable an EA to be
created for an organization.
• Instead of views, TOGAF focuses largely on management and
planning, rather than the actual development of the architecture and
its views.

TOGAF ADM
The ADM is an iterative process
covering all phases of EA development
that is adaptable to the specific needs
of any enterprise.

Federal Enterprise Architecture Framework
• FEAF is primarily intended for EA development ongoing in federal
agencies for the purpose of standardizing the development and use of
architectures within and between these federal agencies.
• FEAF provides both, a structure (the Consolidated Reference Model)
and a methodology (the Collaborative Planning Methodology).
• The Consolidated Reference Model consists of six reference models
and provides standardized categorization for strategic, business, and
technology model.
• The Collaborative Planning Methodology is a full planning and
implementation life cycle for federal EAs consisting of two main
phases: (1) organize and plan and (2) implement and measure.

Department of Defense Architecture Framework
• DODAF is a view-oriented architecture framework that provides an
organized meta-model-based visualization infrastructure for
addressing specific stakeholders concerns.
• The framework consists of eight main viewpoints that define specifies
rules for constructing a view on the system under development.
• All DODAF views must follow a Unified Modeling Language-based
meta-model.
• DODAF contains only a high-level, six-step phase model for dealing
with the development process of an EA.

Ministry of Defense Architecture Framework
• Each viewpoint of MODAF offers a different perspective on the system
of a systems project to support different stakeholder concerns and
interests.
• MODAF consists of seven different viewpoints:
1. All Views viewpoint – define the generic, high-level information
that applies to all of the other viewpoints.
2. Strategic View viewpoint –defines views that support the analysis
and optimization of military capability.
3. Operational View viewpoint –contains views that describe the
operational elements required to meet the capabilities defined in
the strategic views.

MODAF Viewpoints
4. System View viewpoint –contains views that relate directly to the
solution that is being offered to meet the required capabilities that
have been identified in the strategic views and expanded upon in the
operational views.
5. Technical Standards View viewpoint – contains two views that allow
all of the relevant standards to be defined.
6. Acquisition View viewpoint –used to identify programs and projects
that are relevant to the framework and that will be executed to
deliver the capabilities that have been identified in the strategy
views.

Main Reference
1. Chapter 4 (Enterprise Process Management Systems:
Engineering ProcessCentric Enterprise Systems using
BPMN 2.0 by Vivek Kale)
Additional References
1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise
information systems: A pattern-based approach (3rd ed.)

Thank You

‫ر‬
‫الجامعة السعودية االلكتونية‬
‫ر‬
‫االلكتونية‬
‫الجامعة السعودية‬

‫‪26/12/2021‬‬

College of Computing and Informatics
Information Technology
IT402
Integrated Enterprise Systems

IT402
Integrated Enterprise Systems
Week 6
Process Architecture

Required Reading
1. Chapter 5 (Enterprise Process Management Systems:
Engineering ProcessCentric Enterprise Systems using
BPMN 2.0 by Vivek Kale)

Recommended Reading
1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise
information systems: A pattern-based approach (3rd ed.)

Weekly Learning Outcomes

1. Describe the process views and perspectives that enable an
enterprise process architecture.
2. Describe the workflow reference model (WFMS) as the
reference process architecture for the enterprise process
architecture.

Contents

1. Process Change, Perspectives, and Views
2. Reference Process Architecture: Workflow Systems
3. Workflow Reference Model

Lewin’s Change Management Model
Lewin observed three stages of change:
1. Unfreeze phase: In order to encourage change, it is necessary to
unfreeze the environment by motivating people to accept the
change.
2. Transition phase: This is where the change (plan) is executed and
actual change is being implemented.
3. Refreeze stage: This is when the organization once again becomes
unchanging/ frozen until the next time a change is initiated

Deming Cycle Change Management Model
• A continuous improvement model composed of four sequential
subprocesses.
1. Plan: Recognize an opportunity and plan a change. Understand the gap
between residents’ expectations and what is being delivered; set
priorities for closing gaps; and develop an action plan to close the gaps.
2. Do: Execute the plan in a small scale to prove the concept. Implement
changes and collect data to determine if gaps are closing.
3. Check: Evaluate the performance of the change and report the results to
the sponsor(s). Observe the effects of the change and test—analyze data
and pinpoint problems.
4. Act: Decide on accepting the change and standardizing it as part of the
process.

Hierarchical Orientation
The key concepts associated with hierarchical orientation are:
a. Environments are characterized by stability, limited
uncertainty, and limited “consumerism”.
b. People follow the structure and rules defined by virtue of
their position and responsibilities.
c. Markets do not change rapidly and the focus is not on
flexibility, quality, service, or innovation.

Process Orientation
• A process orientation adopts a horizontal view of organizations by
emphasizing notions of processes, process owners, teams, and
empowerment and deemphasizing hierarchical structures.
• Business process change integrates different views from quality,
information technology, organizational change, innovation, and work
redesign.
• A process-oriented organization is an organization that defines and
manages business processes explicitly.

Business Process Management
• Models of business processes are the basis for BPM.
• BPM includes areas such as business process modeling, formal
models, analysis and verification of business processes, process
mining, and workflow management.
• A BPM support system is a generic software system driven by explicit
business process designs that enacts and manages operational
business processes.
• A BPM system allows for the modification of the processes it
supports, the deletion of processes, or the incorporation of new
processes.

Process Architecture
• Process architecture is the design and organization of business
processes and related components into a unified structure and
hierarchy.
• Process components, also known as process elements, describe the
various units of a process.
• Process Architecture aligns perspectives and efforts across all levels
and functions in a business.

Process Architecture Benefits
• Process ownership: ensures accountability for the improvement of end-toend processes across the enterprise.
• Strategy creation: A comprehensive overview of the processes across a
company aid in the creation and adjustment of business strategies.
• Strategic alignment: provides a line of sight between corporate strategies
and frontline operational improvement activities.
• Change management: helps get employees ready, willing, and able to
accept and embrace new ways of working.
• Standardization: serves as a guideline for process analysts to devise best
practices for high-level and basic processes.
• Costing: assist with highlighting areas of waste as well as where process
outputs do not justify investment.

Process Architecture Benefits
• Automation opportunities: identify activities within processes that
could be automated to reduce the burden on staff members and
increase speed and efficiency.
• Simplification: enables process architectures to highlight redundant
and complicated processes.
• Process visibility: provides the ability to view and analyze end-to-end
processes individually and in the wider context of the enterprise.
• Performance metrics: embeds key performance indicators within
processes to provide immediate feedback on process performance.
• Reduced cost: The automation of processes should result in reduced
operational costs for the enterprise.

Process Architecture Benefits
• Faster reactions: Simplification and increased automation should also
result in quicker reaction to changing market conditions.
• Impact prediction: offer managers insight into how processes
interrelate and how modifications to any process may affect
synchronized processes.
• Training benefits: provide a visual representation of the processes
and procedures of an enterprise and can be a powerful for training
new or existing staff.

Process Perspectives
• Process architecture designs and organizes business processes and related
components into a unified structure and hierarchy.
• Architecting the business processes entails looking at it through various
perspectives or viewpoints
• Functional perspective: describes the processes themselves and their
structures.
• Data and dataflow perspective: describes which data (or documents) a
process step consumes or produces
• Behavioral perspective: describes the order in which processes must be
executed.
• Organizational perspective: defines persons or roles that are responsible
for the execution of a given process.
• Operational perspective: defines tools or systems that support the
execution of a process.

Process Views
• An architectural view is a representation of a system from the
perspective of a related set of concerns.
• The architectural view concept offers a separation of concerns that has
the potential to resolve the complexity challenges of a Service
Oriented Architecture (SOA) process.
• Perspectives on business process and service interactions are used as
central views, in which each of them represents a certain part of the
processes and services.
• A basic view is defined called the core view as a foundation for the
other views.
• Other views are defined by extending the core view.

The Core View
• The core view is the place wherein the relationships among the views
are maintained.
• The core view provides a number of important abstract elements,
specifically, View, Process, and Service.
• At the heart of the core view is
the View element that captures
the architectural view concept.
• Each specific view represents
one perspective on a particular
Process.

The Core View
• A Service specifies external functions that the Process provides or
requires.
• A view acts as a container for view elements representing the objects
which appear inside the Process.
• The view that represents concerns of a business process are mostly
derived from the core view.
• The hierarchical structures in which those elements are roots can be
used to define the integration points that are used to merge views.

The Control-flow View
• An Activity element is the base class for other elements such as
Sequence, Flow, and Switch.
• Sequence: An activity is only enabled after the completion of another
activity in the same sequence structure.
• Flow: All activities of a flow structure are executed in parallel.
• Switch: Only one of many alternative paths of control inside a switch
structure is enabled according to a condition value.
• A SimpleActivity element represents a concrete action such as a
service invocation, a data processing task, and so on.
• The StructuredActivity element is an abstract representation of a
group of related activities.

The Collaboration View
• The collaboration view extends the relationship between Process and
Service elements in the core view.
• The Service element from the core view is extended by a specific Service
element that exposes a number of Interfaces.
• An Operation represents an action that might need some inputs and
produces some outputs via correspondent Channels.
• A Channel only holds a reference to a Message entity.
• The ability and the responsibility of an interaction partner are modeled by
the Role element.
• These concepts are captured by using the PartnerLink and the
PartnerLinkType elements, as are their relationships with the Role
element.
• An interaction between the process and one of its partners is represented
by the Interaction element that associates with a particular PartnerLink.

The Control-flow (a) vs. Collaboration View (b)

The Information View
• Involves the representation of data object flows inside the process
and message objects traveling back and forth between the process
and the external world.
• Consists of a number of BusinessObjects elements.
• Data flowing inside the process might go through some
transformations that convert existing data to form new pieces of data.
• The transformations are performed inside a DataHandling object.
• The source or the target of a certain transformation is an
ObjectReference entity that holds a reference to a particular
BusinessObject.

The Human View
• The Human view defines human roles and their relationships to the
respective process and tasks.
• It Process elements that require human interactions are called as
Tasks.
• It establishes a role-based abstraction.
• This role-based abstraction can be used for role-based access control.
• Role-based access control is administered through roles and role
hierarchies that mirror an enterprise’s job positions and
organizational structure.
• Users are assigned membership into roles consistent with their
duties, competency, and responsibility.

The Information (a) vs. Human (b) View
(a)

(b)

Reference Process Architecture: Workflow Systems
• Workflows are useful for the coordination of interrelated activities carried
out by organization members in order to execute a business process.
• A WfMS defines, creates and manages the execution of workflows through
the use of software, running on one or more workflow engines.
• Workflow is defined, according to the WfMC, as the automation of a
business process, in which documents, information, or tasks move from
one participant to another in order to perform some actions in accordance
with a set of procedure rules.
• A distributed workflow is executed across an extended enterprise, in
which different individuals participate in order to reach global objectives.
• Collaborative process planning can be considered as a business process
that can be managed using distributed workflows.

Basic Workflow Components
• Activity: A description of a piece of work that forms one logical step within a
process.
• Participant: A resource that performs the work represented by a workflow
activity instance.
• Role: A mechanism that associates participants to a collection of workflow
activities.
• Routing: A route defines the sequence of the steps that information must
follow within a workflow.
• Transition rule: A transition rule is a logic expression that determines what
actions need to be carried out, depending on the value of logic operators.
• Event: An occurrence of a particular condition that causes the workflow
management software to take one or more actions.
• Deadline: A time-based scheduling constraint, which requires that a certain
activity work be completed by a certain time.

Types of Workflow
1. Administrative workflow: used to perform workflow processes
with defined procedures, though not as structured as in the case of
Production workflow, as each instance of the workflow can have a
different amount of work associated with it.
2. Production workflow: consists of highly automated workflow
processes—the goal of a Production workflow is to automate the
process as much as possible.
3. Ad hoc workflow: implemented by a user to perform a string of
actions that arise for a business scenario.
4. Collaborative workflow: involves a team of people working
together.

Workflow Perspectives
1. Data or Informational Perspective:

• Consists of data flow between workflow activities.
• Each activity is assigned a set of input and a set of output parameters.
• The transfer of data between workflow activities is known as data
flow.
• The modeling of data is required to permit workflow management
systems to control the transfer of workflow relevant data as
generated by workflow activities during workflow executions.
• By providing graphic language constructs to represent data flow
between activities, the informational perspective can be visualized
and used to validate and optimize application processes.

Workflow Perspectives
2. Context of Organizational Perspective:
• WfMS requires information on the context that is organizational as well as
on the technical environment in which the workflows will be executed.
• Atomic workflows can be either automatic or manual.
• Manual atomic workflows are executed by persons who may use
application programs to do so.
• automatic atomic workflows are executed by software systems without
human involvement.
• The role concept is defined dependent on the structure of an organization
in which the workflow is executed.
• When an activity is about to start, the system uses predefined role
information to select people to perform the requested activity.

Workflow Perspectives
3. Interaction or Operational Perspective:
1. When persons are selected by role resolution to perform workflow
activities.
2. When a person chooses to perform an activity, then the defined
application program is started and the input data as specified in the
workflow model are transferred to that application program.
3. When the person completes that activity, the output data generated
by that activity are collected in the output parameters of the activity
to be transferred by the WfMS to the next workflow activity, as
specified in the respective workflow model.

Workflow Perspectives
4. Processing or Functional and Behavioral Perspective:
• The processing perspective covers the functional decomposition of
activities as present in application processes.
• It specifies which activities have to be executed within a workflow.
• Workflows have a tree structure, where root node represents the toplevel workflow, inner nodes represent other complex workflows, and
leaf nodes represent bottom-level atomic activities.
• The controlled execution of a complex workflow by a WfMS has to
take into account interrelationships of the subworkflows covered in
the subordinate behavioral perspective.

Workflow Reference Model
• The WRM divides the workflow system into five components:
1.
2.
3.
4.
5.

Process definition tool
Workflow engine
Workflow client application
Invoked application
Administration and monitoring tool

• The WRM provides the following guidelines:
• Common terminology for the workflow product category
• WRM is the functional components necessary in a WfMS.
• Interfaces that connect the various functional components

WRM Components and Interfaces

Workflow Process Definition Tool
• The process definition tool is a design tool that allows the workflow
designer to design and model the workflow process.
• It provides a graphical interface for the process designer to graphically
design the business process.
• The result of the design activity is a workflow process model.
• Once the workflow process model has been designed, the process
definition tool creates an output of the model using a process
definition language.
• The workflow process that is included in the calling workflow process
is called a subprocess and can be nested further.

Workflow Process Definition Tool
• An activity is work performed by a specific resource.
• The participants in a workflow process could be an explicitly named
human user, a role defined in an organizational structure, a position
that is part of the organizational unit, or an information system.
• There are four generic flow control mechanisms: sequential, parallel,
iteration, and nesting.
• Transition defines the criteria for moving to the next activity and it is
usually represented as a line from one activity to the next in the
graphical workflow process model.
• Transition can be of two types: conditional and unconditional.

Workflow Client Application
• Workflow client application is an application that requests services
from the workflow engine including the retrieval of a worklist
generated by the workflow engine for participants to execute.
• The workflow engine generates the work items assigned to specific
users, which are retrieved by the workplace portal and then displayed
to each user for action.
• The workflow client application would need to instantiate a workflow
process instance, execute a work item, and update the worklist in the
workflow engine as to the status of a particular work item.

Workflow Engine
• The workflow engine is the runtime environment of the WfMS.
• It creates process instances of the workflow process based on a
trigger event for the creation of a workflow process instance.
• An event is a predefined circumstance the workflow engine is
listening for.
• The trigger could be some status change of an application
transaction.
• When a workflow process instance is created, the workflow engine
manages workflow relevant data throughout the life cycle of the
workflow process instance.

Invoked Application
• The workflow engine to perform work calls the invoked application.
• The invoked application is the backend application that creates
business transactions.
• It is a system participant that usually performs a transaction as a
result of the workflow process.
• An example is the purchasing requisition process; an online request
form completed by a human participant might trigger the process.
• Once the workflow engine has received the purchase request form,
the next activity in the workflow process is to create a purchase
requisition in the backend ERP system.

Administration and Monitoring Tool
• Allows system administrators to manage the WfMS users, roles, and
resources.
• Provides functions such as audit reporting, querying of process status,
and updating active process instances.
• Workflow engines store events and record updates to process
instances in workflow logs.
• The administration and monitoring tool retrieves workflow logs for
process instances that have completed and instances that are still in
progress.
• These statistics provide data for process analysis, which lead to
process improvements.

Workflow Reference Model Interfaces
1. Interface 1 links the workflow process definition tool to the
workflow engine.
2. Interface 2 links the workflow client application to the workflow
engine.
3. Interface 3 connects the workflow engine to the business
applications invoked during the processing of the workflow model.
4. Interface 4 enables integration between heterogeneous workflow
engines by providing a set of APIs that one WfMS can invoke on
another.
5. Interface 5 enables integration between workflow engines with the
administration and monitoring tool.

Main Reference
1. Chapter 5 (Enterprise Process Management Systems:
Engineering ProcessCentric Enterprise Systems using
BPMN 2.0 by Vivek Kale)
Additional References
1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise
information systems: A pattern-based approach (3rd ed.)

Thank You

‫ر‬
‫الجامعة السعودية االلكتونية‬
‫ر‬
‫االلكتونية‬
‫الجامعة السعودية‬

‫‪26/12/2021‬‬

College of Computing and Informatics

IT402
Integrated Enterprise Systems

IT402
Integrated Enterprise Systems
Week 7 – Enterprise and Process Modeling

Contents

1. Model and Types of Models
2. Modeling and Modeling Ontology
3. Requirements of Modeling
4. Enterprise Modeling
5. Process Modeling
6. Process Description for Storing Business Process Models

Weekly Learning Outcomes

1. Understand Enterprise Modeling and Process Modeling
2. Modeling Ontology and recognizing various requirements of
modeling
3. Process Description for Storing Business Process Models

Required Reading
1. Chapter 6: Enterprise Modeling
Recommended Reading
1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise information

systems: A pattern based approach (3rd ed.). New York: McGraw Hill
Higher Education. ISBN: 007240429 (print), 9781308469676 (e-text).
2. Enterprise Modeling

This Presentation is mainly dependent on the textbook: Enterprise Information Systems: Contemporary Trends and Issues

Enterprise Modeling

Enterprise Modelling
• Implementing process-oriented architectures has proven to be
difficult for many companies.
• Implementing process concepts within organizations is only one step
toward achieving an enterprise-wide focus on processes.
• Process management deals with the efficient and effective execution
of business processes.

Enterprise Modelling
• It consists of the planning, implementation, enactment, and
controlling of processes and forms a life cycle that leads to continuous
process improvement.
• There is a gap between approaches for modeling business processes
and those for modeling information systems.
• There is a strong need for a methodology for creating a supporting
information system that is based on the process architecture of an
organization.

Model
• A model is a form of representing something: it is not a replication
but rather an intentional selective construction of a new thing or
system that has the purpose of representing another thing or system.
• No model is unique or exclusive, as there can be a multitude of them;
furthermore, models are generally not correct or incorrect—it is only
what it is with reference to the defining purpose of the respective
model.

Characteristics of a model
Characteristic

Description

Abstraction:

A model is a reduced description of the system.

Accuracy:

For the properties of interest, a model provides a true-to-life representation of the
system.

Understandability:

Removing details that are irrelevant for a given view or viewpoint and specifying in
a form that is intuitive enables easier understanding of the concerned system
properties.

Reasoning:

A model helps with correctly analyzing and reasoning about the interesting but
nonobvious properties of the system, either through some type of formal analysis
or experimentation (e.g., by simulating the model on a computer).

Inexpensiveness:

A model is drastically cheaper to construct and analyze than the system.

Types of Models

Types of Models
• Descriptive: A descriptive model is used to describe or mimic a realworld phenomenon or system. With a descriptive model, one can
reason about the properties or the behavior of the system.
• Prescriptive: A prescriptive model is used to define how a yet-to-bebuilt system is supposed to be. Prescriptive models are adopted as
part of so-called forward engineering.

Types of Models
• Structural: A structural model is focused on the static aspects of a
system. These models are used for describing the components or
modules that are part of the system, so they serve for conceptualizing
the system architecture.

• Behavioral: A behavioral model emphasizes the dynamic, functional,
and temporal aspects of the system.

Types of Models
• Symbolic: These models are much more easily changed in comparison
with physical models. By manipulating and changing the
mathematical relationships, one can see how the model reacts and
consequently how the system would react. The creation of a symbolic
model requires:
• A set of signs (or symbols)
• A set of rules to operate on those signs

• Physical: Typically, a physical model is a smaller representation of the
original object but, sometimes, it can be larger if the original object is
too small for humans.

Modeling
• Modeling is the process of identifying adequate concepts and
selecting adequate abstractions to construct a model that reflects a
given universe of discourse appropriately.
• Modeling permits the cost-effective use of the model in place of the
real-world object or process for some purpose, such as simulation,
construction effort estimation, and so on.

Modeling Ontology
• An ontology is an explicit representation of a shared understanding of
the important concepts in some domain of interest.
• Ontologies are represented by conceptual maps that constitute a
simple and well-known form of organizational knowledge.
• This ontology considers two different separate perspectives:
• Reverse engineering
• Forward engineering

Modeling Ontology
• Reverse engineering employs descriptive models to model an existing
system. Reverse engineering is a process of analysis in which the
system is seen by means of a model.
• Forward engineering employs prescriptive models for modeling the
envisaged system. Forward engineering is a process of synthesis
wherein the system is developed starting from a model.

Modeling Ontology
• Reverse engineering employs descriptive models to model an existing
system. Reverse engineering is a process of analysis in which the system
is seen by means of a model.
• Forward engineering employs prescriptive models for modeling the
envisaged system. Forward engineering is a process of synthesis wherein
the system is developed starting from a model.

Requirements of Modeling
• Domain Models
• A doma…
Purchase answer to see full
attachment