‫ر‬

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

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

‫‪26/12/2021‬‬
College of Computing and Informatics
Information Technology
IT342
Enterprise Systems
IT342
Enterprise Systems
Week 4
Systems Theory
Required Reading
1. Chapter 3 (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. Review the basic concepts of systems thinking, systems science,

systems engineering, and systems architecting.
2. Understand the origin of the significance of enterprise architecture
and the constituting business architecture, information architecture,
application architecture, and technical architecture.
3. Provide the context for the significance of business processes in
contemporary enterprises.
Contents

1. Systems Thinking
2. Systems Engineering
3. Systems Architecting
4. Enterprise Processes
Systems Theory
Systems Thinking
• A system is defined as a set of elements that have one or more
relationships between them.
• Systems thinking is the process by which one seeks to understand
those elements and relationships so as to be able to understand the
behavior of the system as a whole.
• The relationships between system elements can be:
• Strictly deterministic (i.e., controlled by physical or other laws)
• Completely stochastic (subject to chance)
• More complex
• System predictability - the ability to forecast the system’s next state
or states. This change in state might be:
• An inevitable response to endogenous vulnerabilities that are already present
in the system
• An unanticipated response to an exogenous shock
Paradigms of Systems Thinking
1. Hard systems thinking (HST)
• Goal-seeking strategies using quantitative tools to achieve an optimal or near-
optimal solution.
• Require a clear definition of ends and the optimal means for achieving those
ends.
• Best-suited for tackling problems that don’t involve human activity systems.

2. Soft systems thinking (SST)

• A form of systemic thinking that understands reality as the creative thinking
of human beings.
• Takes into consideration social reality as the construction of people’s
interpretation of their experiences and works with the aspirations of people’s
views, interpretations, and intentions.
Paradigms of Systems Thinking

3. Critical systems thinking

• Practitioners have used both HST and SST, and found that emancipatory
interests for dealing with inequalities, such as power and economic
differences in society, were not being adequately considered by SST.
• Critical systems thinking emerged to address these inequalities.

4. Multimodal systems thinking (MST)

• MST uses 15 performance indicators to question the validity of decisions
made by planners and policy-makers.
• Many of these performance indicators cover issues of sustainability as well as
environmental and ethical issues.
Principles of Systems Science
1. The idea of systemness. Systems interact with other systems, forming still
larger systems. The universe is composed of systems of systems.

2. Systems are processes organized in structural and functional hierarchies.

3. Systems are themselves and can be represented abstractly as networks of

relations between components.

4. Systems are dynamic on multiple timescales.

5. Systems exhibit various kinds and levels of complexity.

6. Systems evolve.
Principles of Systems Science
7. Systems encode knowledge and receive and send information.

8. Systems have regulation subsystems to achieve stability.

9. Systems contain models of other systems (e.g., protocols for interaction with
anticipatory models).

10. Sufficiently complex adaptive systems can contain models of themselves

(e.g., brains and mental models).

11. Systems can be understood (a corollary of 9)—science.

12. Systems can be improved (a corollary of 6)—engineering.

System’s Properties
1. Elements- the kinds of parts (things or substances) that make up a
system. These parts may be atoms or molecules, or larger bodies of
matter like sand grains and plants.

2. Attributes- characteristics of the elements that may be perceived

and measured (e.g. quantity, size, color, volume, and mass)

3. Relationships- the associations that occur between elements and

attributes. These associations are based on cause and effect.
System’s Classification
1. Isolated system, which has no interactions beyond its boundary
layer. Many controlled laboratory experiments are this type of
system.

2. Closed system, which is a system that transfers energy, but not

matter, across its boundary to the surrounding environment. Our
planet is often viewed as a closed system.

3. Open system, which is a system that transfers both matter and

energy across its boundary to the surrounding environment. Most
cosystems are examples of open systems.
Systems Engineering
• The purpose of systems engineering (SE) is to support organizations that desire
improved performance.

• SE is a comprehensive, iterative technical management process that includes

translating operational requirements into configured operational systems.

• SE is a life cycle activity that demands a concurrent approach to both product and
process development.

• SE encourages the use of modeling and simulation to validate assumptions or

theories on systems and the interactions within them.
System Dynamics via Simulation Modelling
• System dynamics simulations enables one not only to observe events but also see
patterns of behavior over time.
• Understanding patterns of behavior, instead of focusing on day-to-day events, can
offer a radical change in perspective.
• It shows how a system structure is the cause of its successes and failures.
• System dynamics simulations are good at communicating not just what might
happen, but also why.
• The primary assumption of the system dynamics paradigm is that the persistent
dynamic tendencies of any complex system arise from its internal causal
structure.
• A system dynamicist is likely to look for explanations of recurring long-term social
problems within this internal structure rather than in external disturbances, small
maladjustments, or random events.
System Dynamics via Simulation Modelling
• System dynamicists understand system structure based on the idea of two-way
causation or feedback.
• It is assumed that social or individual decisions are made on the basis of
information about the state of the system or environment surrounding the
decision-makers.
• The decisions lead to actions that are intended to change (or maintain) the state of
the system.
• New information about the system state then produces further decisions and
changes.
• Each such closed chain of causal relationships forms a feedback loop.
• System dynamics models are made up of many such loops linked together, which
are basically closed-system representations.
Changeable Systems
1. Increasing Complexity - New technologies create new opportunities and
challenges. Interfaces are increasingly more complex and system integration is
more difficult.
2. More Dynamic - Systems interact with their environment and the needs of
stakeholders evolve in concert with this interaction. Rapid changes in the
environment require systems to be dynamic to continue to provide value to
consumers of products and services.
3. Growing Security Concerns - Many systems face increasing security
challenges due to threats from malicious adversaries ranging from hackers to
terrorists.
4. Rising Privacy Concerns - As systems become more complex, more
interconnected, and face more security challenges, the potential for privacy
violations increases.
Changeable Systems

5. Increasing Interconnectedness - The Internet and advances in information

technology (IT) have led to business-to-business collaboration and a global
economy enabled by pervasive interconnectedness.

6. Many Stakeholders - The increasing complexity and interconnectedness has

contributed to the rise in the number of stakeholders involved in the system life
cycle.
Systems Architecting

• Architecture design is turning the corner from the requirements space to the
design space.
• Coarse-grained designs that describe gross partitioning of a system into some
collection of elements that can be code-oriented, runtime, or physical structures.
• Architecture provides a means to partition the system into elements that can
later be designed in detail.
• Architecture can be scrutinized and studied to expose weaknesses prior to
detailed element design and implementation.
• Architecture can be used to guide overall construction by serving as a
prescription for how the elements can be assembled, resulting in a system with
predictable properties and behavior.
Comparison of Architectural and Detailed Designs
Systems Design

The process of defining the architecture, components, interfaces, and

other characteristics of a system or component of a system where:
• “Component” refers to a physical part or element that is a member of
the system.
• “Interface” refers to the boundary of a component and the point of
connection between components.
• “Other characteristics of a system or component of a system” refers
to the functional behavior of the system as well as the broad systemic
properties it possesses (e.g. performance and scalability)
Systems Architectural Design
• Systems architecture is concerned with partitioning the system into components
and identifying their responsibilities and rules for interaction to ensure that the
necessary functional and quality attribute requirements are met.

• Architectural design is not a state of being but rather of becoming—it is a

process.

• Architectural designs identify the parts of the system, enterprise, or software and
how they will interact to render a service.

• Architectural requirements are those that will influence the architecture utmost
as it initially decomposes the system and selects the fundamental structures that
will form it.
Functional Architectural Requirements

• Functional architectural requirements have the least influence on design.

• High-level functional requirements are best described with use cases.

• Use cases are not models for functional decomposition, nor should designers use
them to describe how the system provides services.

• Use case models describe what is needed in a system in terms of functional

responses to given stimuli.

• Use case models serve as a communication vehicle and encourage dialog

between technical and nontechnical stakeholders.
Nonfunctional Architectural Requirements
• Nonfunctional architectural requirements will have the most
influence over the design.
• Nonfunctional scenarios describe some requirement in terms of:
• Stimulus.
• Source(s) of the stimulus.
• Relevant environmental conditions.
• Architectural element(s).
• System response.
• Response measure.
• For change stimuli, we might have response measures that measure the cost
of change in terms of time and cost.
• For a performance stimulus, we might have response measures in terms of
throughput and response time.
Enterprise Architecture
• Enterprise architecture frameworks (EAF) are essentially design methodologies
focused on business modeling, business processes, application functionality, and the
technological infrastructure that supports the enterprise.

• EAF embody design strategies and provide step-by-step guidance and even
templates for designing and documenting the enterprise.

• EAFs prescribe a set of artifacts for specific enterprise stakeholders.

• Using an EAF, the enterprise architect creates various artifacts intended to be views
of the system from the perspective of the enterprise stakeholders.
Enterprise Architecture

• The purpose EAF is to help enterprise architects manage the

complexity of highly distributed systems of systems by providing
techniques and methods to identify key stakeholders and their role in
the enterprise.
• Most EAFs identify a number of concerns that will guide the design of
enterprises, such as:
• Business requirements
• Stakeholders
• Business processes
• Environment
• Software
• Data
• Infrastructure
Organizational Architecture
Business Architecture
• Business Architecture dictates the functional requirements of business
processes that determine the ISs that will operationally support the
business.
• The core concept within the business architecture is the business process.
• A business process is a set of value-adding activities that operates over
input entities producing output entities.
• An activity describes the business roles required of the organizational
entities for its operation.
1. The actor role –requires one actor or a combination or team of actors to be
executed.
2. The resource role –used as input or output of an activity during its operation.
3. The observable state role –used as a means to observe the status of an activity.
Business Architecture

The major components for describing the business architecture are:

• Business strategy: key business requirements, processes, goals,
strategies, key performance indicators, business risks, and the
business-operating model
• Business function: key business services, processes, and capabilities
that will be affected by the organization architecture efforts
• Business organization: the high-level nature of organizational
structures; business roles (internal audiences, external customers,
and partners); the decision-making process; and organizational
budget information
Information Architecture
• The information architecture describes what the organization needs
to know in order to run its processes and operations as described in
the business architecture.
• The principal components for describing information architecture are:
• Information strategy: Information architecture principles,
information governance and compliance requirements, and
canonical data models.
• Information assets: A catalog of critical business data types and
models; relationships between such business data types; and all
the processes and services that interact with these data.
Application Architecture

The application architecture fulfills two major goals:

1. Supporting the business requirements
2. Allowing efficient management of the organization’s entities
• It defines the applications required to enable the business
architecture.
• It includes descriptions of automated services that support the
business processes and of the interactions and interdependencies
between an organization’s application systems.
• It plans for developing new applications, and revisions of old
applications based on the enterprises objectives.
Application Architecture

• Service is the aggregation of a set of operations provided by an

architectural block.
• Service is composed of three types:
1. Business service, or a set of operations provided by IS blocks
supporting business processes.
2. IS service, or a set of operations provided by an IS block to other IS
blocks. This is used to aggregate multiple IS blocks.
3. IT service, or a set of technological services provided by the specific
application platforms.
 Application Architecture
The principal components for describing application architecture are:
• Application strategy: The key application architecture principles (e.g., build
vs. buy, hosted vs. in-house) application governance; portfolio management;
and a set of reference application architectures relevant to the customer
• Application processes: A series of application-specific processes that support
the business processes in BA
• Application services: An inventory of the key application services exposed to
internal and external applications that support the business services
• Logical components: An inventory of relevant product-agnostic enterprise
application systems that is relevant to stated business objectives
• Physical components: Actual products that support the logical application
components and their relationships to relevant components and services in
information and technology architectures
Abstraction Granularity Levels
Technical Architecture

• Represents the technologies behind application implementation as

well as the infrastructure and environment required for the
deployment of the business process support systems.
• Addresses a large number of concepts since it must cope
simultaneously with continuous technological evolutions and the
need to provide different specialized technological perspectives.
• These concepts are abstracted as an IT block.
• An IT block is the infrastructure, application platform, and/or
technological or software component that realizes or implements a
set of IS blocks.
Principal components for describing technology architecture
• Technology strategy, comprises technology architecture principles;
technology asset governance methodology; portfolio management
strategy; and technology standards, patterns, and RAs.
• Technology services, or an inventory of specific technology services
and their relationships as well as the business services, application
services, information assets, and logical or physical technology
components that realize such services.
• Logical components, or the product-agnostic components that exist
at the technology infrastructure tier to support each technology
service.
• Physical components, or the set of technology products that exists
behind each logical technology component to implement the
technology service.
Enterprise Processes

• Enterprise processes are business structures that make up the

enterprise.
• An enterprise might be composed of customer service, inventory,
shipping, and production organizations.
• A business process is a description of the dynamic interaction of
stakeholders and the flow of information between the various entities
that compose the enterprise.
• Business processes drive the analysis and design of the enterprise
architecture and are used to identify organizations, pertinent
stakeholders, systems, data, and other entities relevant to the
enterprise.
Enterprise Processes

• Processes are means for identifying, documenting, and analyzing

complex networks of human interactions with organizations and the
IT systems they use to provide services, communicate, and generally
conduct business operations.
• Business processes might describe the dynamic aspects of
• How a customer’s order is processed.
• How the product is manufactured.
• How the inventory is updated.
• How quickly the product is delivered to the customer
Main Reference
1. Chapter 3 (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