Module 1

Review of Systems Integration

Concepts
Intended Learning Outcomes
By the end of this module, you should be able to

1. Define and explain key concepts, approaches, requirements, life cycles,

and strategies related to systems integration projects.
2. Differentiate CRM System from ERP System.
3. Identify the three types of System Integration.
4. Identify the methods of system integration.
Share
What did you learn from
your previous course
Systems Integration and
Architecture 1?
Introduction
•Many systems are built to easy, improve and transform organizations.

•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.
Introduction
•Besides after the system has been designed and developed in 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.
Key terminologies in this course
Various key terminologies shall be used throughout this course as follows

•System

•Systems thinking

•System Integration

•System Architecture

•Project
System
•An array of components designed to accomplish a particular objective
according to plan.

Many subsystems are combined together to form a system which is intended

to achieve a specific objective which may be set by the Project manager.
Systems thinking
Systems thinking is the ability or skill to perform problem solving in complex
systems.

It is a way of understanding an entity in terms of its purpose.

System Integration

•It is the combination of interrelated elements to achieve a

common objective (s).
System Architecture

•The architecture of a system defines its high-level structure,

exposing its gross organization as a collection of interacting
components.
•Elements needed to model a software architecture include:
•Components, Connectors, Systems, Properties and Styles.
System integration and architecture
System integration and architecture is the conceptual model that defines the
structure, behavior, and more views of a system. An architecture description is
a formal description and representation of a system, organized in a way that
supports reasoning about the structures and behaviors of the system.
System Integration and Architecture are like a blueprint of
a company.

It has a detailed structure in how the design can be

operated and the frameworks of the system. Like a
proposal to a company, the system architecture should
understand what the user’s needs are.
What is a Project?
•From the key terms described, a system developer and architects cannot do
anything without first establishing various projects. These projects may be new
or existing.

•So it is necessary to first understand what a project is, factors that influence
the project, who the owners are and many more.
What is a Project?
•A project is a temporary endeavor undertaken to 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/riskiness
Origin of Information System Projects
● Problems may either be current, suspected, or anticipated. These are
undesirable situations that prevent the business from fully achieving its purpose,
goals, and objectives (users discovering real problems with existing IS).
● Opportunities are chances 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.
● Directives are new requirements that are imposed by 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

•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
Stakeholders
•Stakeholders are the people involved in or affected by project activities
•Stakeholders include
•the project sponsor and project team
•support staff
•customers
•users
•suppliers
•opponents to the project
Importance of Stakeholders
•Project managers must take time to identify, understand, and manage
relationships with all project stakeholders

•Using the four frames of organizations can help meet stakeholder needs and
expectations

•Senior executives are very important stakeholders

What Helps Projects Succeed?
According to the Standish Group’s report “CHAOS 2001: A Recipe for Success,”
the following items help IT projects succeed, in order of importance:

•Executive support •Minimized scope

•User involvement •Standard software infrastructure

•Experienced project manager •Firm basic requirements

•Clear business objectives •Formal methodology

•Reliable estimates
Understanding Organizations
We can analyze a formal organization using the following 4 (four)
frames
Many Organizations Focus on the Structural Frame

•Most people understand what organizational charts are

•Many new managers try to change organizational structure when other
changes are needed
Basic Organizational Structures
•Organizational structure depends on the company and/or the project.

•The structure helps define the roles and responsibilities of 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.
Eight known organizational structures of project
management
1. organic
2. line
3. line & staff
4. functional
5. divisional
6. matrix
7. project
8. Virtual
Functional Organization
In a functional organization
structure, the entire organization
is divided into smaller groups or
departments based on
specialized functions.
Divisional Structure
In a divisional structure, people
are grouped together based on
the product or service they
provide, not the work they do.
Matrix Organization
A matrix structure is a hybrid of the
functional and divisional structures.
It may involve employees reporting
to different bosses depending on
their current assignment.
Project organization
The project organization is the structure of
the project. It’s created separately, with
specialists and workers from various
departments. These personnel work under
the project manager.
Project organization is a process. It
provides the arrangement for decisions on
how to realize a project. It decides the
project’s process: planning how its costs,
deadlines, personnel, and tools will be
implemented. The project organization is
then presented to the project stakeholders.
Project Life Cycle and Project Phases
Project life cycle is a collection of
project phases. These phases vary
by project or industry, but some
phases include

● concept
● development
● implementation
● support or close-out
Phases of the Project Life Cycle
Product Life Cycles
Products also have life cycles

Systems Development Life Cycle (SDLC) is a framework

for describing the phases involved in developing and
maintaining information systems. Systems development
projects can follow two models:

1. Predictive models: The scope of the project can

be clearly articulated and the schedule and cost
can be predicted, e.g., Waterfall, Spiral,
Incremental, Prototyping, or Rapid Application
Development (RAD) models
2. Adaptive models: Projects are mission-driven and
component-based, using time-based cycles to
meet target dates, e.g., Extreme Programming
(XP), Scrum or Agile models.
Predictive Development: When and Why?
Predictive, or Incremental, development is a method of software development
where the model is designed, implemented, and tested incrementally (piece by
piece) until the product is finished — or until all the requirements have been
satisfied. This model combines the elements of the waterfall model with the
iterative philosophy of prototyping. In this model, each module passes through
the requirements, design, implementation, and testing phases.
Predictive Life Cycle Models
● The waterfall model has well-defined, linear stages of 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.
● The RAD model is used to produce systems quickly without sacrificing
quality.
Predictive Development: When and Why?
Pros:

● The predictive model generates a working software product quicker than the adaptive model.
● It’s easier to manage risk with this model because potential obstacles are identified and handled
during their first iterations.
● It is easier to test and debug during iterations of smaller pieces than on the full product.
● This model allows for more flexibility, as changes to scope and requirements may be made to every
increment.

Cons:

● This model requires good planning and design. If tasks aren't done properly in each phase, the entire
project can be impacted.
● A clear and complete definition of the whole system is required before it can be broken down and
built incrementally.
● Additional efforts are required to integrate each individual component of the system.
When to use the predictive model:
● When the requirements are clear and can be implemented in logical
phases, even though some details may evolve with time.
● When there are some high-risk features and goals or when the product
calls for new technology.
● When the client needs clarity on and strict adherence to the target
delivery/end date based on the agreed-upon scope.
Adaptive Development
Adaptive life cycles like SCRUM or Kanban (also known as agile or
change-driven) are designed to iterate rapidly on projects that are a little more
experimental or less certain. They’re dependent on ongoing stakeholder
contribution, and they react quickly to the changes in project scope and
system requirements. This approach is sometimes referred to as freeform
software design as it offers an incredibly flexible design model, promoting
adaptive planning and evolutionary development when the end goal is not
quite as concrete.
Adaptive Life Cycle Models
Extreme Programming (XP): Developers program 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
Adaptive Development
Pros:
● This model allows for evolving requirements so change can be implemented very easily
given the shorter planning cycles (sprints).
● This model encourages customer satisfaction through fast and continuous delivery.
● Adaptive development encourages active involvement and interaction from key project
stakeholders, which allows for product build based on priority and accuracy.
Cons:
● Team members must be highly skilled and cross-skilled as core teams are small.
● The project can easily get thrown off track if the customer is not clear on the desired
final outcome.
When to use the adaptive model:
● When the end goals of projects are not clearly defined.
● When it’s important that the implementation process starts faster. (For large
and dynamic projects with quickly evolving requirements, it makes no
sense to elaborate the process of predefining requirements in minute
detail.)
Distinguishing Project Life Cycles and Product Life Cycles
•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

Why Have Project Phases and Management Reviews?
•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
System Development Life Cycle
(Kendall & Kendall terminology)
Requirement Life Cycle
Requirements
Requirements are statements that identify the essential needs of a system for it
to have value and utility. These are fundamental basis of all the system
development processes.
 Analyzed
Requirements
Requirement Life Cycle
1) Elicitation Phase. It is the starting point of the requirements production process is an elicitation process that
involves several people to ensure consideration of a broad scope of potential ideas and candidate problems.

2) Organization Phase. In this step, there is no transformation of the requirements, but simple classification and
categorization, e.g. requirements may be grouped into functional vs. non-functional requirements.

3) Analysis Phase. It represents a transformation.

4) Prototype Phase. If the requirements are poorly understood, in this way, you may be tested and perhaps
strengthened, corrected, or refined. This phase is often done as a proof of concept and serves to bring feedback
from both the stakeholders and developers (engineers).

5) Requirements documentation and specification. This represents the requirements as the finished product of
the stakeholder requirements team. The requirements are compiled into a requirement list or into some
equivalent document format. These collected requirements are then transformed into a specification.
Requirements determination

•Requirements determination addresses the gathering and documenting

of the true and real requirements for the Information System being
developed.
•Requirements is the wants and /or needs of the user within a problem
domain. elicit
Requirements determination questions
•Requirements determination questions
•Who does it?
•What is done?
•Where is it done?
•When is it done
•How is it done
•Why is it done?
Systems Requirements
•Characteristics or features that must be included to satisfy business requirements
•Outputs
•Inputs
•Processes
•Timing
•Controls
•Volumes. sizes, and frequencies
•Data/Information collected can be about; people, organisation, work and work
environment.
Fact – Finding Methods

•Sampling (of existing documentation, forms, and databases).

•Research and site visits. (Participation)
•Observation of the work environment.
•Questionnaires.
•Interviews.
•Prototyping.
•JAD/Joint requirements planning (JRP).
Types of Requirements
● 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
■ 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
○ Contract between Client and contractor
Functional requirements
•What inputs the system should accept
•What outputs the system should produce
•What data the system should store that other systems might use
•What computations the system should perform
•The timing and synchronization of the above
Non-functional requirements
•Non-functional requirements are global constraints on a computer system

•e.g. development costs, operational costs, performance, reliability,

• 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

Non-functional requirements

•Define system properties and constraints e.g. reliability,

response time and storage 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.
Examples of NFR

•Interface requirements
•how will the new system interface with its environment?
•User interfaces and “user-friendliness”
•Interfaces with other systems
•Performance requirements
•Time - response time
•Throughput - transactions per second
Examples of NFR
•Security
•permissible information flows
•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
Examples of NFR

•Lifecycle requirements
•Maintainability, Enhanciability, Portability, expected market or 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.
Requirements Documentation

•There are basically two types of documents realized from

the requirements elicitation phase. These include;
•User Requirements Specification Document
•System requirements specification Document
User Requirements Specification –URS/URD
The URS document outlines precisely what the User (or customer) is expecting
from this system.
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
2.Non-Functional Requirements
System Requirements Specification Document
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.
What is System Integration?
System Integration (SI) refers to the process by which multiple individual subsystems or
sub-components are combined into one all-encompassing larger system thereby allowing the
subsystems to function together. In other words, the symbiosis created through system integration
allows the main system to achieve the overarching functionality required by the organization.

In most organizations that use system integration, there is a need to improve efficiency and thereby
productivity and quality of their operations. The objective is usually to get the company’s various IT
systems to communicate with each other in the background so as to avoid the time and effort spent
manually sharing information with other departments/components of the organization including upper
management. Through system integration, the organization will experience an increase in information
flow speeds as well as reduced operational costs.
Seven comprehensive steps
Integration project requires extensive planning, system design, and software development to ensure
successful implementation.

From a business’s point of view, can begin the process by following seven comprehensive steps
(self-explanatory):

(1) Determine Requirements,

(2) Conduct Analysis,

(3) Design Software Infrastructure,

(4) Develop a Management Plan,

(5) Design System Integration,

(6) Implement the Solution,

(7) Perform Maintenance Checks.

Three types of System Integration
Given the zone of utilization and sort of utilization, integration administrations
can be separated into three classifications:

1. Enterprise Application Integration (EAI)

2. Data Integration (DI)
3. Electronic Document Integration/Interchange (EDI)
Enterprise Application Integration (EAI)
Enterprise application integration is an ongoing
process between two incompatible systems, which
can involve hardware components, software
applications, or a combination of both. This
integration can allow for differing financial
applications to interface effectively and process
data or transactions.

Also known as enterprise app integration, this

refers to the process of syncing or aligning the
various systems and databases used within a
company, network or industry.
Data Integration (DI)
Data integration is the process of
combining data from different sources into
a single, unified view.
Integration begins with the ingestion
process, and includes steps such as
cleansing, ETL (Extract, Transform, Load)
mapping, and transformation.
Data integration ultimately enables
analytics tools to produce effective,
actionable business intelligence.
Electronic Data Integration/Interchange (EDI)
EDI (Electronic Data Integration/Interchange) is a central
business-to-business situated interaction. Its capacities are for the paperless
trade of reports and electronic regulations.
CRM Systems Vs ERP Systems – What’s the difference?
Customer Relationship Management (CRM)
system, which helps organize, manage and, at the
end of the day, use customer data.
A CRM is a form of system integration that keeps
the business up to date on each customer’s
contact details, transaction history, accounts as
well as communication.
In other words, your company’s entire
‘relationship’ with customer is available briefly and
the primary objective of the system is to help you
improve sales, e.g., SalesForce.com, Devtac Asia,
and Avanza, Inc.
CRM Systems Vs ERP Systems – What’s the difference?
Enterprise Resource Planning (ERP) system
is designed to manage all business processes
and automate various backend or back office
functions that need not be carried out
manually. In many ways, it is the
representation of the concept of system
integration. An ERP software typically
integrates all aspects of operations which
includes product planning and development,
procurement, vendor management,
manufacturing, sales, and marketing, all in one
database and user interface.
What are the methods of system integration?
(1) Point-to-Point Integration

(2) Star Integration

(3) Horizontal Integration

(4) Vertical Integration.

(1) Point-to-Point Integration
A point-to-point integration system consists of simple connections between
two subsystems rather than a complex network. The simplicity of this method
makes it ideal for businesses that focus on enhancing one function instead of
implementing an entire database.
(2) Star Integration
A star integration, also known as spaghetti integration, is a collection of point-to-point
connections in a star polyhedron sequence. This structure is not only able to connect
software but also makes interconnections between other subsystems. However,
because of its complex mechanism, if a developer were to make a physical model of star
integration, it would look like a plate of spaghetti, hence its nickname, it requires more
maintenance.
(3) Horizontal Integration
This integration establishes a subsystem that acts as the centralized database
that all other software connects to. This reduces the number of connections
needed to integrate all processes by eliminating interconnections. Thus,
minimizing links saves time, capital, and effort required to build and maintain
the solution.
(4) Vertical Integration
This integration method forms individual silo structures based on the
subsystems' functions. In other words, this strategy groups similar software
together without making interconnections to systems handling other
operations, e.g., a silo would be created for linking a point-of-sale (POS)
processor with inventory management and ordering software because they
handle similar functions.