08/12/20

System Integration & Architecture

System Integration
& Architecture
Nagwovuma Margaret

1
 Introduction

08/12/20
• Many systems are built to easy, improve and
transform organizations.

System Integration & Architecture

• Some organizations have many departments which
run systems which are independent of each other.
• And systems built sometimes, may not have an
abstract view (architecture) which leads to failure
of system interoperability.
• There is need to have architectural view of the
system as a priority to help in the design to avoid
the likeliness of system failure. 2
 Introduction

08/12/20
• Besides after the system has been designed and developed in

System Integration & Architecture

consideration of the size of the organization, i.e. most
especially when the organization is large, need is required to
integrate such systems to ensure flexibility, Speed, Cost ,
Standardization, Data integrity, reliability and robustness.
• This can help Information Technology (IT), energy, and
financial services industry among others to have an easy to
use integrated system. 3
What students need to know

08/12/20
• Systems Integration (SI) process, approaches,
drivers, tools and techniques required for successful

System Integration & Architecture

SI, critical success factors, and best practices.
• The course focuses on how a proposed system will
be integrated with other existing or planned
systems.
• It addresses the System Integration problem using
architectures as the basis and then addresses the
evaluation of the architectures in terms of the
capabilities they provide. 4
What students need to learn

08/12/20
System Integration & Architecture
• The theory and practice of business process integration,

legacy integration, new systems integration, business-to-

business integration, integration of commercial-off-the-

shelf (COTS) products, interface control and

management, testing, integrated program management,

integrated Business Continuity Planning (BCP). 5

 Aims

08/12/20
• To provide the students an understanding
of the technical and business process issues

System Integration & Architecture

involved in systems integration.

6
Learning outcomes

08/12/20
• On completion of this course, the students will be
able to:

System Integration & Architecture

• Identify integration issues upfront in the
process of System Integration and should be
able to identify the best practices that ensure
successful System Integration.
• Have an understanding of the technical and
business process issues involved in systems
integration.
7
Teaching and learning

08/12/20
pattern
• Teaching this course will be in lecture
form. A number of case studies will also be

System Integration & Architecture

used to illustrate some concepts as
mentioned in the indicative content.

8
 Indicative content

08/12/20
• The System of Systems Integration Problem
• Human, Organizational, Societal Cultural, Economic,

System Integration & Architecture

and Technological aspects;
• Processes, approaches, drivers, tools and techniques required
for successful SI, critical success factors, and best practices in
Systems Integration;
• The Role of Architectures in Systems Integration;
• Integration in a System of Systems and a Federation 60 of
Systems;
• Model Based Architecture, Design, and Integration;
• Systems of Systems Interoperability;
• Evaluation of architectures; 9
• Measures of Performance and Effectiveness;
 Indicative content

08/12/20
• Assessment of System Capabilities;
• Analysis of Alternatives;

System Integration & Architecture

• Case studies and examples from the Information Technology
(IT), energy, and financial services industry to illustrate the
concepts discussed.
• The theory and practice of business process integration,
legacy integration, new systems integration, business-to-
business integration, integration of commercial-off-the-
shelf (COTS) products, interface control and
management, testing, integrated program management,
integrated Business Continuity Planning (BCP). Specific
focus will be given to issues of interface integration and 10
interoperability of systems.
Key terminologies in this

08/12/20
course
• Various key terminologies shall be used
throughout this course as follows
• System

System Integration & Architecture

• Systems thinking
• System Integration
• System Architecture
• Project

11
 System

08/12/20
• An array of components designed to
accomplish a particular objective according to

System Integration & Architecture

plan. Many sub-systems many be designed
which later on are combined together to form a
system which is intended to achieve a specific
objective which may be set by the Project
manager.

12
Systems thinking

08/12/20
Is a way of understanding an entity in terms of its purpose, as
three steps

System Integration & Architecture

The three major steps followed in systems thinking
1. Identify a containing whole (system), of which the thing to be
explained is a part.
2. Explain the behavior or properties of the containing whole.
3. Explain the behavior or properties of the thing to be explained
in terms of its role(s)or function(s) within its containing whole
(Ackoff, 1981)

13
System Integration

08/12/20
• Is the combination of inter-related elements to achieve a
common objective (s).

System Integration & Architecture

14
 System Architecture

08/12/20
• The architecture of a system defines its high-level structure,
exposing its gross organization as a collection of interacting
components.

System Integration & Architecture

• Elements needed to model a software architecture include:
• Components, Connectors, Systems, Properties and Styles.

15
What is a project?

08/12/20
• From the key terms described above, a system developer and
architects cannot do anything without first establishing various
projects. These projects may be new or existing.

System Integration & Architecture

• So it is inevitable to first understand what a project is, factors
that influence the project, who the owners are and many more
as discussed below.

16
 What Is a Project?

08/12/20
• A project is a temporary endeavor undertaken to

System Integration & Architecture

accomplish a unique product or service
• Attributes of projects
• unique purpose
• temporary
• require resources, often from various areas
• should have a primary sponsor and/or customer
• involve uncertainty

17
 Where do information Systems Projects

08/12/20
Originate (Sources of Projects)?
New or changed IS development projects come from problems,
opportunities, and directives and are always subject to one or more
constraints.

System Integration & Architecture

1.Problems – may either be current, suspected, or anticipated.
Problems are undesirable situations that prevent the business from
fully achieving its purpose, goals, and objectives (users discovering
real problems with existing IS).

2. An Opportunity – is a chance to improve the business even in the

absence of specific problems. This means that the business is hoping
to create a system that will help it with increasing its revenue, profit,
or services, or decreasing its costs.

3.A Directive – is a new requirement that is imposed by 18

management, government, or some external influence i.e. are
mandates that come from either an internal or external source of the
business.
Projects Cannot Be Run in Isolation

08/12/20
System Integration & Architecture
• Projects must operate in a broad organizational
environment
• Project managers need to take a holistic or systems view
of a project and understand how it is situated within the
larger organization

19

19
Stakeholders

08/12/20
• Stakeholders are the people involved in or affected by

System Integration & Architecture

project activities
• Stakeholders include
• the project sponsor and project team
• support staff
• customers
• users
• suppliers
• opponents to the project

20
Importance of Stakeholders

08/12/20
• Project managers must take time to identify,
understand, and manage relationships with all

System Integration & Architecture

project stakeholders
• Using the four frames of organizations can help
meet stakeholder needs and expectations
• Senior executives are very important
stakeholders

21
Table 2-2. What Helps Projects

08/12/20
Succeed?
According to the Standish Group’s report
“CHAOS 2001: A Recipe for Success,” the

System Integration & Architecture

following items help IT projects succeed, in order
of importance:
• Executive support
• User involvement
• Experienced project manager
• Clear business objectives
• Minimized scope
• Standard software infrastructure
• Firm basic requirements
• Formal methodology 22
• Reliable estimates

22
Understanding Organizations
We can analyze a formal organization using the following 4

08/12/20
(four) frames;
Structural frame: Human resources frame:

System Integration & Architecture

Focuses on roles and Focuses on providing
responsibilities, harmony between needs of
coordination and control. the organization and needs
Organizational charts of people.
help define this frame.
Political frame: Symbolic frame:
Assumes organizations Focuses on symbols and
are coalitions composed meanings related to events.
of varied individuals and Culture is important.
23
interest groups. Conflict
and power are key issues.
23
Many Organizations Focus on the

08/12/20
Structural Frame
• Most people understand what organizational charts are

System Integration & Architecture

• Many new managers try to change organizational structure when other
changes are needed
• 3 basic organizational structures
• Functional-
• project
• matrix

24

24
Basic Organizational Structures

08/12/20
• Organizational structure depends on the company and/or the
project.
• The structure helps define the roles and responsibilities of

System Integration & Architecture

the members of the department, work group, or
organization.
• It is generally a system of tasks and reporting policies in
place to give members of the group a direction when
completing projects.
• A good organizational structure will allow people and
groups to work effectively together while developing hard
work ethics and attitudes.
• The four general types of organizational structure are
25
functional, divisional, matrix and project-based.
Basic Organizational Structures

08/12/20
• Functional Structure - People who do similar tasks,
have similar skills and/or jobs in an organization are
grouped into a functional structure. The advantages of

System Integration & Architecture

this kind of structure include quick decision making
because the group members are able to communicate
easily with each other. People in functional structures can
learn from each other easier because they already possess
similar skill sets and interests.
• Divisional Structure - In a divisional structure, the company will
coordinate inter-group relationships to create a work team that can
readily meet the needs of a certain customer or group of customers.
The division of labor in this kind of structure will ensure greater
output of varieties of similar products. An example of a divisional
structure is geographical, where divisions are set up in regions to
work with each other to produce similar products that meet the needs
of the individual regions. 26
Basic Organizational Structures

08/12/20
• Matrix Structure - Matrix structures are more complex in
that they group people in two different ways: by the function
they perform and by the product team they are working with. In a

System Integration & Architecture

matrix structure the team members are given more autonomy and
expected to take more responsibility for their work. This
increases the productivity of the team, fosters greater innovation
and creativity, and allows managers to cooperatively solve
decision-making problems through group interaction.
• Project Organization Structure - In a project-organizational
structure, the teams are put together based on the number of
members needed to produce the product or complete the project.
The number of significantly different kinds of tasks are taken
into account when structuring a project in this manner, assuring
that the right members are chosen to participate in the project.
27
 Structures
Basic Organizational

System Integration & Architecture 08/12/20

28

28
Project Phases and the Project Life

08/12/20
Cycle

System Integration & Architecture

• A project life cycle is a collection of project phases
• Project phases vary by project or industry, but some general
phases include
• concept
• development
• implementation
• support

29

29
 System Integration & Architecture 08/12/20
30
Phases of the Project Life Cycle

30
Product Life Cycles

08/12/20
Products also have life cycles

System Integration & Architecture

The Systems Development Life Cycle (SDLC) is a
framework for describing the phases involved in
developing and maintaining information systems

Systems development projects can follow

Predictive models: The scope of the project can be clearly articulated and
the schedule and cost can be predicted.
Adaptive models: Projects are mission driven and component based,
using time-based cycles to meet target dates. 31

31
Predictive Life Cycle Models

08/12/20
The waterfall model has well-defined, linear stages of

System Integration & Architecture

systems development and support.
The spiral model shows that software is developed using an
iterative or spiral approach rather than a linear approach.
The incremental release model provides for progressive
development of operational software.
The prototyping model is used for developing prototypes to
clarify user requirements.
32
The RAD model is used to produce systems quickly without
sacrificing quality.
 Adaptive Life Cycle Models

08/12/20
Extreme Programming (XP): Developers program

System Integration & Architecture

in pairs and must write the tests for their own code.
XP teams include developers, managers, and users.

Scrum: Repetitions of iterative development are

referred to as sprints, which normally last thirty days.
Teams often meet every day for a short meeting, called
a scrum, to decide what to accomplish that day. Works
best for object-oriented technology projects and
requires strong leadership to coordinate the work 33

33
Distinguishing Project Life Cycles

08/12/20
and Product Life Cycles

System Integration & Architecture

• The project life cycle applies to all projects, regardless of the products
being produced
• Product life cycle models vary considerably based
on the nature of the product
• Most large IT systems are developed as a series of projects
• Project management is done in all of the product life cycle phases

34

34
Why Have Project Phases and

08/12/20
Management Reviews?

System Integration & Architecture

• A project should successfully pass through each of the project
phases in order to continue on to the next

• Management reviews (also called phase exits or kill points) should

occur after each phase to evaluate the project’s progress, likely
success, and continued compatibility with organizational goals

35

35
System Development Life
Cycle

08/12/20
(Kendall & Kendall terminology)

System Integration & Architecture

36
 Topic 1
Requirements

System Integration & Architecture 08/12/20

37
Requirements

08/12/20
• A system cannot be analyzed, designed, implemented and
evaluated unless the problem is understood and requirements
elicited.

System Integration & Architecture

• Requirements are fundamental basis of all the system
development processes.
• System architects will always base of the requirements elicited
by the system analyst to design an architectural view of the
system. Besides much as the system is designed and there is
need for integration say business process integration, legacy
integration, new systems integration, business-to-business
integration, integration of commercial-off-the-shelf (COTS)
products, interface control and management, testing, integrated
program management, integrated Business Continuity Planning
(BCP), requirement is the basis. 38
Sub Topics

08/12/20
Requirements elicitation,
documentation, and maintenance

System Integration & Architecture

Modeling tools and methodologies
Using Unified Modeling Language
Testing

39
 Core learning outcomes:

08/12/20
• Compare and contrast the various requirements modeling techniques.
• Distinguish between non-functional and functional requirements.
• Identify and classify the roles played by external users of a system.

System Integration & Architecture

• Explain and give examples of use cases.
• Explain the structure of a detailed use case.
• Detail a use case based on relating functional requirements.
• Describe the types of event flows in a use case and under which
conditions they occur.
• Explain how requirements gathering fits into a system development
lifecycle.
• Explain how use cases drive testing throughout the system lifecycle.
40
What are requirements?

08/12/20
• Requirements are statements that identify the
essential needs of a system in order for it to have

System Integration & Architecture

value and utility.

41
Characteristics of Good Req’ts

08/12/20
• 1. Describes What, Not How.
• 2. Atomic. i.e., it should have a single purpose
• 3. Unique.

System Integration & Architecture

• 4. Documented and Accessible.
• 5. Identifies Its Owner.
• 6. Approved. After a requirement has been revised, reviewed,
and rewritten, it must be approved by its owner.
• 7. Traceable. A good requirement is traceable; it should be
possible to trace each requirement back to its source.
• 8. Necessary.
42
Characteristics of Good Req’ts

08/12/20
cont….
• 9. Complete.
• 10. Unambiguous
• 11. Quantitative and testable

System Integration & Architecture

• 12. Identifies applicable states
• 14. States Assumptions. All assumptions should be stated.
• 15. Use of Shall, Should, and Will. A mandatory requirement
should be expressed using the word shall (e.g., "The system shall
conform to all state laws
• 16. Avoids Certain Words. The words optimize, maximize, and
minimize should not be used in stating requirements, because we
could never prove that we had achieved them. 43
 Requirements Life cycle

08/12/20
SPECS
SPECS
Analys Complet
Raw Organise ed e user

System Integration & Architecture

The Req’ts d Req’ts Req’ts Req’ts
User

Elicitation Organisati Analysis Prototype Transform

Phase on Phase Phase Phase to spec

44
Requirement Life Cycle .. Cont..

08/12/20
Elicitation Phase
The starting point of the requirements engineering process is an elicitation
process that involves a number of people to ensure consideration of a

System Integration & Architecture

broad scope of potential ideas and candidate problems
Organisation Phase
In this step there is no transformation of the requirements, but simple
classification and categorization. For example, requirements may be
grouped into functional vs. nonfunctional requirements.
Analysis Phase
This represents a transformation.

45
Requirement Life Cycle ..

08/12/20
Cont..
Prototype Phase
In this way poorly understood requirements may be tested and

System Integration & Architecture

perhaps strengthened, corrected, or refined. This activity is
often done as a proof of concept and serves to induce feedback
from both the stakeholders and engineers.
Requirements documentation and specification
This represents the requirements as the finished product of the
stakeholder requirements team. The requirements are compiled
into a requirements list or into some equivalent document
format. These collected requirements are then transformed into
a specification.
46
Requirements
elicitation,

08/12/20
documentation, and

System Integration & Architecture

maintenance

47
Requirements elicitation

08/12/20
• Requirements determination addresses the
gathering and documenting of the true and

System Integration & Architecture

real requirements for the Information System
being developed.

• Requirements is the wants and /or needs of the

user within a problem domain. elicit

48
Requirements determination

08/12/20
questions
• Requirements determination questions
• Who does it?

System Integration & Architecture

• What is done?
• Where is it done?
• When is it done
• How is it done
• Why is it done?

49
 08/12/20
Systems Requirements
• Characteristics or features that must be included to
satisfy business requirements

System Integration & Architecture

• Outputs
• Inputs
• Processes
• Timing
• Controls
• Volumes. sizes, and frequencies

• Data/Information collected can be about; people,

organisation, work and work environment.
50
Fact – Finding Methods

08/12/20
• Sampling (of existing documentation, forms, and
databases).
• Research and site visits. (Participation)

System Integration & Architecture

• Observation of the work environment.
• Questionnaires.
• Interviews.
• Prototyping.
• JAD/Joint requirements planning (JRP).

51
 Types of Requirements

08/12/20
User Requirements: these are statements in Natural language plus
diagrams of services the system provides, together with its operational
constraints. These can be categorised into 2; functional requirements and
non-functional requirements

System Integration & Architecture

Functional requirements
Describe what the system should do
Non-functional requirements
Consists of Constraints that must be adhered to during
development (design and implementation)
Remember ‘Constraints.’

System requirements
What we agree to provide
Describes system services 52

Contract between Client and contractor

Functional requirements

08/12/20
• What inputs the system should accept

• What outputs the system should produce

System Integration & Architecture

• What data the system should store that other systems might use

• What computations the system should perform

• The timing and synchronization of the above

53
Non-functional requirements

08/12/20
• Non-functional requirements are global constraints on a
computer system
• e.g. development costs, operational costs, performance, reliability,

System Integration & Architecture

• The challenge of Non-functional requirements:
• Hard to model
• Usually stated informally, and so are:
• often contradictory,
• difficult to enforce during development
• difficult to evaluate for the customer prior to delivery

54
 08/12/20
Non-functional requirements
• Define system properties and constraints e.g.
reliability, response time and storage

System Integration & Architecture

requirements. Constraints are I/O device
capability, system representations.
• Process requirements may also be specified
mandating a particular programming language
or development method
• Non-functional requirements may be more
critical than functional requirements. If these are
not met, the system is useless. 55
Examples of NFR

08/12/20
• Interface requirements
• how will the new system interface with its

System Integration & Architecture

environment?
• User interfaces and “user-friendliness”
• Interfaces with other systems
• Performance requirements
• Time - response time
• Throughput - transactions per second

56
Examples of NFR

08/12/20
• Security
• permissible information flows

System Integration & Architecture

• Or who can do what
• Survivability – e.g. system will need to survive fire
natural catastrophes, etc
• Operating requirements
• physical constraints (size, weight),
• personnel availability & skill level
• accessibility for maintenance
• environmental conditions
57
Examples of NFR

08/12/20
• Lifecycle requirements
• Maintainability, Enhanciability, Portability, expected market or

System Integration & Architecture

product lifespan
• limits on development
• E.g. development time limitations, resource availability and
methodological standards.
• Economic requirements
• e.g. restrictions on immediate and/or long-term costs.

58
Requirements Documentation

08/12/20
• There are basically two types of documents realised

System Integration & Architecture

from the requirements elicitation phase. These
include;

• User Requirements Specification Document

• System requirements specification Document

59
User Requirements Specification –

08/12/20
URS/URD
The URS document outlines precisely what the User (or customer) is
expecting from this system.

System Integration & Architecture

User Requirement Specification may incorporate the functional
requirements of the system or may be in a separate document
labelled the Functional Requirements Specification - the FRS.

The URD has the following

information:
1. Functional Requirements
60
2. Non-Functional Requirements
 08/12/20
System Requirements
Specification Document

System Integration & Architecture

A detailed description of the system services.

• What do we agree to provide?

• A structured document setting out detailed
descriptions of the system services.
• Written as a contract between client and
contractor.
61
TOOLS THAT AID IN DEVELOPING &

08/12/20
UNDERSTANDING
• Affinity diagrams
SYSTEM REQ’TS
• Force-field analysis

System Integration & Architecture

• Ishikawa fishbone (cause-and-effect) diagrams
• Pareto diagrams
• Pugh charts
• Quality function deployment (QFD)

62
 Comparison of the tools

System Integration & Architecture 08/12/20

63