Pamantasan ng Cabuyao

(University of Cabuyao)
 Integrating Disparate
Codes
WEEK 5

Prepared by:
Ms. Elaine Bolambot, MIT
 INTRODUCTION

•Code disparities happen at different levels of the software production cycle. The disparities happen
because of the varying design and development environments.
•
•The differing environments provides alongside issues on software propriety, collaboration, access &
constraints, technology compatibilities and security features.
•
•This module identifies the different methodologies which can be used to bridge differing computing
solutions.
•
• The purpose of this module is to introduce the software, hardware and platform modality congruent
to code integration which are foundational to developing systems and applications for design and
development of integrated computing solutions. In addition. this module explores the means for these
software components to interface with web application modality.
•
 SOFTWARE DISPARITY

Disparities in software happen because different people are coming from different
environments. When a builder tries to develop something, his handprints are etched
along with the development process. The uniqueness and individuality of the
developer is being asserted in his over-all creation.

The Software Propriety Game. Software developers take pride in “owning” their
work. And they assert propriety with their work. Propriety takes on several
appearances.

There is the great tendency for software developers to attach themselves to their
creation. And the “developer’s hand print” may be seen in the proprietary appeal to
their software imprints like in styles, secret codes, look & feel and code constraints.
•Unwashed Codes. Software engineers provide the systematic means of software
development. However, individual developers are less stringent. Codes need to be
neatly provided so as to make software maintenance an appreciable job. To be neat
with the coding some standards are to be followed such as naming conventions for
variables, data structures, functions, classes, objects, procedures, and other coder-
supplied identifiers.
•
•Part of the code neatness is in the provision of physical structure (like in indentations,
code pairing (e. g. alignment of start and end tags), uniformity of casing, and
syntactical arrangements.

•Legacy Codes. Some organizations could be quite inclined to go on utilizing the

software they have been with for quite so long. Resistance to change is a common
stance, especially with people who value legacy systems for sentimental reasons. They
are simply not attuned to quickly migrate to new system implementations.
•A legacy code is source code inherited from someone else or inherited from an older
version of the software. It can also be any code that subsequent developers may not
understand and that is difficult to change.
• Legacy code refers to an application system source code type that is no longer
supported.

•
 METHODOLOGIES FOR INTEGRATING DISPARATE SOFTWARE

Most organizations did not start out with large, dispersed business units. They
started small. And with the small units are relatively small information as coded for
the minimal requirements. As the organization grows, so are a lot of things like more
employees, more office space, and more technology resources are being built in
congruence with the existing requirements. Some previous departments that did not
exist will spring up. This has resulted in a number of different systems being used for
different tasks, but those systems may not have been designed to communicate
effectively with each other.

Disparate software systems can lead to a wide range of problems for the
organization, including an increase in budget due to higher costs stemming from
system upgrades, business partner connection difficulties, and employee resources.
 BRIEF HISTORY OF INTEGRATION

As IT systems grow and develop over time, they start to sprawl away
from one another. One developer or vendor’s solutions may not
communicate so well with another’s. Next thing the IT administers
realize is that they are having an entire IT stack that was connected
only by the fact that they were all owned by the organization. So
there needed to be a way to organize this technology “spaghetti” to
stop duplicating efforts—especially when it comes to implementing
and acting on business logic.
•Enterprise application integration. A solution to all of this
disparate sprawl was enterprise application integration (EAI),
which is technologies, tooling, and a framework that implements
real-time, message-based integration between apps. These
messages are triggered by changes or parameters built within the
individual apps. EAI was accomplished in one of 2 ways, point-to-
point and hub-and-spoke.
•
•Point to point integration vs. hub and spoke integration. The
point-to-point model meant that each application had to be
customized to talk to the other applications and pieces of your IT.
This is all customized for each IT asset and for each asset that it
connects to. This is also very tedious work and, understandably,
highly error prone. To further complicate things, as you update
your infrastructure and apps this model can be very hard to
maintain over time.
•
•The Enterprise Service Bus. Following the EAI hub-and-spoke approach is the
enterprise service bus (ESB), a tool providing message-based abstraction—
modularizing services between applications.
•
•An ESB also acts as a central hub where all of these modularized services get
shared, routed, and organized to connect your apps and data to one another. It
is a better solution to the EAI hub-and-spoke, but perhaps not the end-all as
organizations grow, add assets, and need more speed across all of their
properties and software resources.
•
•Enterprise Service Bus Integration. An ESB has some very distinct features that
set it apart in terms of functionality. ESBs present themselves as a service using
open standards. This removes the need to write unique interfaces for each
application.
•Integration services can be deployed with minimum changes to applications.
ESBs rely on industry-standard, open protocols and interfaces to ease new
deployments.
•
•Agile integration. Integration in itself is the key to software,
hardware and the technologies to make everything work together.
Agile integration sees the future of connected systems and how they
support the real work the IT teams must accomplish to thrive—
especially as change occurs more frequently.
•
•Agile Integration - Hybrid Platform. The traditional approach to
integration, with centralized teams controlling monolithic
technologies, can impede the development and long-term usefulness
of distributed applications. Traditional integration technologies like
the ESB have benefits like prioritizing security and data integrity, but
they also rely on a single team to define integrations for the entire
enterprise.
•Version Control Systems. Version control is a system that records
changes to a file or set of files over time so that you can recall
specific versions later. For the examples in this book, you will use
software source code as the files being version controlled, though
in reality you can do this with nearly any type of file on a
computer.
•Version control, also known as source control, is the practice of
tracking and managing changes to software code. Version control
systems are software tools that help software teams manage
changes to source code over time.
• Version controls are primarily used for two major purposes: 1)
backward compatibility and/or 2) forward compatibility.
Changes in codes are tracked and are classified as major
versions, patches, or upgrades.
Activity will be posted
in the pinnacle
Thank you for listening!!!