Enterprise Systems

Week 4
Systems Theory
1. Systems Thinking
1. 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 behaviour of the system as a whole.
1. Systems Thinking
• 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 the state might be:
• An inevitable response to endogenous vulnerabilities that are already present
in the system
• An unanticipated response to an exogenous shock
1.1 Systems Science
Paradigms of Systems Thinking:
1. Hard system 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.
1.1 Systems Science – Cont.

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.
1.2 Principles of Systems Science
The principles of systems science include the following:
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.
* For the complete list of the principal, see page 49 in the textbook
1.2 Principles of Systems Science – Cont.
Within the boundary of a system, we can find three kinds of
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, colour, volume, and mass)

3. Relationships- the associations that occur between elements and

attributes. These associations are based on cause and effect.
1.2 Principles of Systems Science – Cont.
The state of the system can be defined by determining the value of its properties
(the elements, attributes, and/or relationships).
So, Systems can be classified as:
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 ecosystems are
examples of open systems.
2. 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.
2.1 System Dynamics via Simulation Modelling
• System dynamics simulations enable one not only to observe events but also to
see patterns of behaviour over time.
• Understanding patterns of behaviour, 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.
2.2 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.
2.2 Changeable Systems – Cont.

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.
3. 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.
3. Systems Architecting – Cont.
Table 3.2: Comparison of Architectural and Detailed Designs
3. Systems Architecting – Cont.
Systems design:
It is 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 behaviour of the system as well as the broad systemic properties
it possesses such as performance, availability, scalability, modifiability, and so on.
3. Systems Architecting – Cont.
• Systems architecture
It 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
It 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.
3.1 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 describes what is needed in a system in terms of

functional responses to given stimuli.

• Use case models serves as a communication vehicle and encourage dialogue

between technical and non-technical stakeholders.
3.2 Nonfunctional Architectural Requirements

• Nonfunctional architectural requirements will have the

most influence on the design.
• Nonfunctional scenarios describe some requirements 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.
4. Enterprise Architecture
• Enterprise architecture concepts evolved from the systems engineering community
but are specialized to address the specific design concerns of very large, highly
distributed IT systems and the organizations dependent upon them.
• 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.
4. Enterprise Architecture – Cont.

• The purpose of EAF is to help enterprise architects manage the complexity of

highly distributed systems by providing techniques and methods to identify key
stakeholders and their roles 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
4. Enterprise Architecture – Cont.

• Enterprise Architecture consisting of

1. Business Architecture,
2. Information Architecture,
3. Application Architecture and
4. Technical Architecture.
4.1 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. These roles include:
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 activity during its operation.
3. The observable state role –is used as a means to observe the status of an
activity.
4.1 Business Architecture – Cont.
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.
4.2 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 catalogue of critical business data types and
models; relationships between such business data types; and all the
processes and services that interact with these data.
4.3 Application Architecture

The application architecture fulfils 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 enterprise’s objectives.
4.3 Application Architecture – Cont.

• 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 services, or a set of technological services provided by the specific
application platforms.
 4.3 Application Architecture – Cont.
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
4.4 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.
4.4 Technical Architecture – Cont.
Principal components for describing technology architecture are:
• 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.
5. 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.
5. Enterprise Processes – Cont.
• 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