System Integration and Architecture

System Integration
Process of connecting different systems or software applications so that they work
together as unified whole
System Architecture
Refers to the design or blueprint of how the components of a system are arranged
and interact

Why is system integration and system architecture important?

1. Efficiency – Reduce Errors
2. Scalability – Helps system to grow
3. Cost saving – Helps to build the system at low cost
4. Flexibility – Allows to change some information or data easily

Basic steps in System Integration & Architecture

1. Understand the components - need to identify part that we will use
2. Design the Architecture - how will the system connect and interact
3. Develop the system - build system based on design.
4. Test the System - Check if the parts work together properly.
5. Deploy and monitor - Launch to user and to make sure it's running without
issues.

Key Concepts in Integration

APIs (Application Programming Interfaces) – Allows different software system
to communicate with each other
Middle ware – Middle ware acts as a bridge between different systems
Interoperability – Ability of different systems to work together without having any
issues

Types of System Integration

Point-To-Point Integration – Most simplest form of integration
Middleware Integration – Instead of connecting system directly you use a piece
of software called middleware to allow communication between systems
Enterprise Service Bus – Much more complex integration because multiple
system are connected into central bus or hub

System Architecture Styles

Monolithic Architecture – All parts of the systems are combined to make big
piece
Microservices Architecture – Broken down into smaller parts to or before building
a system
Client-Server Architecture – This is where a server provides service to a client

Enterprise Architecture
Blueprint for an organization. It helps align a company business goal with its
technology, processes, and data systems.

Core Elements of Enterprise Architecture

Business Architecture – Blueprint of business or organization ensure that their
business is growing and napapatakbo ng tama
Information Architecture – How the data is organized and being use within an
organization
Application Architecture – Software and Application that the organization used
together
Technology Architecture – Focused on hardware network and technological
infrastructure that supports the application

The Layers of Enterprise Architecture

Strategic Layer – Focused on what your business want to achieve and how IT can
support the goals
(1. What are business goals 2. How can technology help achieve the goals)
Tactical Layer – Focuses on how the organization achieve its goals using
technology
(1. What specific tools and systems are needed)
Operational Layer – If your business run on day o day operation
(1. Are the tools and technology working as they should)
Framework of Enterprise Architecture
TOGAF – The open group architecture framework
Similarities of TOGAF AND GARTNER
 TOGAF AND GARTNER is almost the same wherein they help the organization
plan their IT system to align business goals
Differences of TOGAF AND GARTNER
 TOGAF helps build to manage enterprise architecture
 GARTNER helps to pick what is the right technology you can use
Zachman Framework – Is a tool that helps you organize and breakdown the
organization complex part for you to understand easily
FEAF (FEDERAL ENTERPRISE ARCHITECTURE FRAMEWORK) – It helps the
government organize and manage its system and technology to ensure that they
work together

Key Benefits of Enterprise Architecture

Improved Decision Making – Because enterprise architecture provide clear
insights into how complex parts of the organization fit together
Cost Reduction – Lessen Cost because less redundancy because you know what
you are doing
Better Communication – Between business and IT Department

Tools And Technologies for Enterprise Architecture

Modeling Tools – Use to create visual diagrams and blueprints of an organization
system
Governance Tools – Is a software tools that helps to manage and enforce rules
Collaboration Tools – It is a software tool that help different teams within an
organization to work together involves designing, managing and improving the
enterprise architecture

UNIFIED MODELING LANGUAGE

UML is a visual Language, meaning it uses diagrams to show how a system is
structured.
MODELING REQUIREMENTS
Actors: These are the people or things (Like another system) that interact with the
system.
Use Cases: These are the actions or tasks that the actors perform with the system.
System: This is the boundary that separates what's inside (the use cases) from
everything outside.
Attributes: These are the properties or characteristics of the class
Methods (or Actions): These are the actions or functions that the class can
perform
Objects: Represent the components or classes involved in the process
Messages: Show the interactions between objects
Time: The diagram flows from top to bottom, showing the order of interactions
Components: These are parts of the system, Like software modules or services.
Interfaces: Points of interaction where components communicate.
Connections: Lines showing how components are Linked together.
Nodes: These are the physical devices or servers (e.g., a computer, server.
Artifacts: These are the software components or programs

TYPES OF DIAGRAMS IN UML

USE CASE DIAGRAM
CLASS DIAGRAM
SEQUENCE DIAGRAM
COMPONENT DIAGRAM
DEPLOYMENT DIAGRAM

USE CASE DIAGRAM

It's like a map that shows the relationships between the users and the system's
features.
CLASS DIAGRAM
shows how different parts of a system are organized and how they relate to each
other.

SEQUENCE DIAGRAM
shows how objects interact over time, step by step, during a specific process.
COMPONENT DIAGRAM
shows the high-level structure of a system by illustrating its components (modules
or parts of the system) and how they interact with each other.

DEPLOYMENT DIAGRAM
shows how the software components of a system are physically placed on different
hardware devices or servers.

Components needed to model a software architecture

Components
Individual parts or Modules of Systems
Connectors
Paths or Channels through which components communicate with each other
Systems
Complete collection of components and connectors
Properties
Characteristics or Qualities of Systems
Style
It guides how the components or interacts with the system

Types of Components
Active Components
Parts that do something
Passive Components
Stores data or hold information

Types of Connectors
Message-Based Connectors
Sends Messages back and forth between components
Data-Based Connectors
Used to share data directly
Event-Based Connectors
When something happens, it will sent an alert

Component Interaction
Synchronous
Wait For a response before continuing
Asynchronous
Don’t wait for a response they just keep going

Architectural design process

Talks about the planning of the overall system and how it will works.

Software architecture
Talks about the structure and interaction of software components
System Structure
Talks about organizing the system in manageable parts

Control modeling
Defining how control flows through the system

Modular Decomposition
Breaking the system in smaller modules

Static structural model

It describes how different components are connected without considering their
dynamic behavior

Dynamic process model

It how data or control moves through the system and how components interact
dynamically during
runtime

interface model
It defines how different components of the system communicate with each other

Relationship model
Shows how components are related and connected

MVC ( Model View Controller )

A design pattern used for building user interfaces by separating the system into 3
interconnect
components

Model (Data)
View (Presentation)
Controller (Logic)

Design principles in architecture

Separation of concerns
It helps in managing complexity by focusing on one thing at a time
Modularity
Building things in self contains chunks
Loose coupling
Keeping parts independent from each other
High cohesion
Keeping related tasks together
Scalability
Scalable system can grow and adapt to new depends without significant changes

COMPONENT BASED DESIGN AND INTEGRATION

COMPONENT BASED DESIGN

 LEGO BLOCKS
 WEB APPLICATION

Component-Based Design is like building a system using Lego blocks.

Instead of creating every single part from scratch, you use pre-made blocks
(components) that do
specific tasks.
For example, in a web application, a login button, a search bar, or a shopping cart
could each be
individual components. When you arrange these components properly, you create
the full website or app.
So, it’s about using small, reusable parts (components) to build a bigger, working
system efficiently!
BENEFITS OF COMPONENT BASED DESIGN
 Reusability: Once you create a component, you can use it again in other
parts of the system or even in other projects. It's like having a tool you can
use over and over.
 Modularity: Components work independently, so you can build and test
each part separately. If something needs to change, you only update the
specific part, not the whole system.
 Maintainability: If there's a problem, you can easily fix just the broken part
(component) instead of searching through the entire system. It makes
troubleshooting faster and easier.

COMPONENT BASED INTEGRATION

Component-Based Integration is the process of making different components work
together, like
connecting puzzle pieces to form a complete picture.
 Integration: Involves connecting different components so that they can
share data and communicate properly to work together as a complete
system.

HOW COMPONENT BASED INTEGRATION WORKS

 Interfaces: Each component defines how it will interact with other
components, usually through a well-defined interface. Think of it as a
"contract" that says, "I can accept this
input and give this output.”
 Communication: Components communicate through these interfaces. For
example, a button component might send a message when clicked, and
another component might respond by showing a message on the screen.
 Assembly: In the final system, the components are put together, often using
a framework or platform that manages their interactions and ensures they
work together smoothly.

COMPONENT LIFECYCLE
4 stages A component goes through 4 main stages:
 Create – It's built and ready to go.
 Run – It's doing its job (showing stuff, handling input).
 Update – Something changes (like data), so it updates.
 Destroy – It's removed when no longer needed.
DEPENDENCY MANAGEMENT
Components need help from other code (called dependencies).
A dependency is something your code needs to work.
It’s like borrowing tools instead of building everything yourself.

Example:
If you build a website and want to:
Format dates 👉 you might use a date library
Animate buttons 👉 you might use an animation tool
Those tools = dependencies
You didn’t write them — you just use them.
Real-life analogy:
Building a bookshelf:
You need a hammer → that’s a dependency.
Instead of making your own hammer, you use one someone else made.
So, in coding, dependencies = other people's code your project uses.

DEPENDENCY HELL
Conflicts – Tools don’t get along.
Breaks – Updates can break your app.
Confusing – It’s hard to know what’s connected.
Slow – More tools = slower app.
Too many dependencies = problems (called “dependency hell”).