Integrated Program Planning

1. Integrated program planning

System integration planning is the process of incorporating smaller sub-systems into
one larger system to ensure they all work together. Integration is a cornerstone of today's
enterprise environments with their multitude of enterprise resource planning (ERP) systems.
... And that is not always the case in a project.
The power of those software applications does not lie only in the functionality that
they provide themselves, but in their ability to communicate with one another, in order to
make data flow seamlessly through the environment. This improves processes and makes
a company more efficient as a whole. When thinking of integration, web services standards
such as Simple Object Access Protocol (SOAP) and REpresentational State Transfer
(REST) come to mind. Those are meant to simplify the integration with the large number of
support tools that are built around them.
Unfortunately, the tools themselves are not the solution to your integration problems,
but only the means to a faster implementation. The real solution is proper system
integration planning and design, which need to be based on the right criteria. And that is not
always the case in a project.

So, what are the best methods for the design when integrating two systems? Well,
there are a number of questions that need to be answered in the planning stage, later the
discussion of ERP system.

1.1 Enterprise Resource Planning (ERP) system

(ERP) systems are the specific kind of enterprise systems to integrate data
across and be comprehensive in supporting all the major functions of the organization

Evolution of ERP
During the 1960s and 1970s, most organizations designed silo systems for their
departments. As the production department grew bigger, with more complex inventory
management and production scheduling, they designed, developed, and implemented
centralized production systems to automate their inventory management and
production schedules. These systems were designed on mainframe legacy platforms
using such programming languages as COBOL, ALGOL, and FORTRAN. The
efficiencies generated with these systems saw their expansion to the manufacturing
area to assist plant managers in production planning and control. This gave birth to
material requirements planning (MRP) systems in the mid-1970s, which mainly
involved planning the product or parts requirements according to the master production
schedule. Later, the manufacturing resources planning (MRP II) version was
introduced in the 1980s with an emphasis on optimizing manufacturing processes by
synchronizing the materials with production requirements. MRP II included such areas
as shop floor and distribution management, project management, finance, job-shop
scheduling, time management, and engineering. ERP systems first appeared in the
early 1990s to provide an integrated solution to the increased complexity of businesses
and support enterprise to sustain their compatibility in the emerging dynamic global
business environment. Built on the technological foundations of MRP and MRP II, ERP
systems integrated business processes across both the primary and secondary
activities of the organization’s value chain, including manufacturing, distribution,
accounting, finances, human resource management, project management, inventory

ITEC 116 – ELECTIVE 4 (System Integration and Architecture 2)

 management, service and maintenance, and transportation. ERP systems’ major
achievement was to provide accessibility, visibility, and consistency across all functions
of the enterprise. ERP II systems today have expanded to integration of
interorganizational systems providing back-end support for such electronic business
functions as business-to-business (B2B) and electronic data interchange (EDI). From
the technological platform perspective, therefore, ERPs have evolved from mainframe
and centralized legacy applications to more flexible, tiered client–server architecture
using the Web platform. Table 1-1 summarizes the evolution of ERP from 1960s to
2000s.

The CoBOL, ALGOL and ForTran programming languages

were the systems were designed on mainframe legacy platforms

Material Requirements Planning (MRP) systems

ITEC 116 – ELECTIVE 4 (System Integration and Architecture 2)

 1.2 Five (5) key questions in the planning stage:
1.2.1 What is the data that the target system requires to complete the integration
task?
Identifying the target data is an important first step. It defines what objects
or tables need to be accessed, and the rules the data needs to comply to.
Typically, the target data model drives the design of a custom integration point,
should one be required.

ITEC 116 – ELECTIVE 4 (System Integration and Architecture 2)

 Identifying the target data is an important first step
1.2.2 Where is the data required by the target system located in the source system,
and what transformations are needed?
Common examples for data types that need to be transformed are
numbers and dates. For example, date formats and time zones may be
different between the systems and have to be converted.

Common examples for data types that need to be

transformed are numbers and dates.

1.2.3 What is considered a transaction within the integration task and are there any
dependencies between the transactions?
A transaction is an atomic unit of work. It only changes the state of the
target system if the data was successfully transferred and processed.
If any failure occurs, whether it is during the transport or processing (i.e.
validation), it must be ensured that the target system remains unchanged. For
example, if a transaction creates multiple records in the target system (i.e. an
account and a contact, and the account was successfully created but the
contact failed the validation), it must be ensured that the account record is
removed again. This way the target system has the same state at the end of
the transaction as when it started.

Successful transferred and processed

ITEC 116 – ELECTIVE 4 (System Integration and Architecture 2)

 1.2.4 How will you connect to the target system (domain name, IP, etc.) and what
security constraints apply (certificates, credentials, etc.)?
Connectivity and security constraints should be identified and verified
early on in the project. As those can often be reasons for a project to be
delayed or even fail altogether. The reasons are manifold like: missing firewall
rules, required certificates, setup of new security roles and credentials,
protocol incompatibilities between source and target system – just to name a
few.

Connectivity and security

From a technical perspective, most of those issues can be resolved.

But it is often the processes or additional constraints that are only identified
during the validation, which add more risk and effort to the system integration
project.
For example, the target or source system may need to be patched up
before they can communicate with one another. On the other hand, the
networking team may need to open up the firewall and create new domain
name (DNS) entries for the connection to be established. These are typically
not very complex technical problems, but depending on the size of the
company, they may require approvals and involvement of other groups
requiring additional time.

The firewall is needed in or while the processes or additional constraints that

are only identified during the validation, this will lessen the risk and effort to the
system integration project.

ITEC 116 – ELECTIVE 4 (System Integration and Architecture 2)

 In some cases, changes such as patching a system may introduce
conflicts to other parts of the organization, which may make the integration
much more difficult or even impossible.

1.2.5 What interface options do you have available (REST, SOAP, Custom, etc.)?

Comparison of SOAP and REST

The interface options have an impact on the tools and implementation

design. This is because they help determine whether the solution must be
entirely custom or whether productized solutions are an effective system
integration method.
Creating the right design may not always include the path of the
simplest or most straight forward solution.
The Influence of Transactional Requirements on the System
Integration Process
To demonstrate the impact of transactional requirements on an
integration design, let’s look at the example of an order submission from a
Customer Relationship Management (CRM) system to an order management
system (OMS). Before the order can be submitted, the system needs to
ensure that an account exists since the order must be linked to it. If it does not
exist, let’s assume the requirement is to create one as part of the integration
as well. The account should only be created for a successful order submission,
but not if the order submission fails.

ITEC 116 – ELECTIVE 4 (System Integration and Architecture 2)

 The OMS provides a standard SOAP interface that allows for the
typical data operations (CRUD – created, updated, delete) on the entities,
such as account and order. It also provides the ability to create custom web
service endpoints exposed through the same SOAP interface.
Now, choosing the standard SOAP interface has the advantage that no
custom development is needed inside the OMS. The CRM can first create the
account using the account interface and then create the order through the
order interface. However, while this seems like a desirable approach for the
implementation, there are disadvantages that need to be considered.
Since the account and order interface are separated by different
endpoints, it requires two independent SOAP requests to submit the order.
This means that the risk of a communication an additional request to delete
the account if the order submission fails to fulfill the transactional requirement
for accounts to only be created with a successful order. That deletion request
itself has the risk of failure, and that would leave the OMS in an invalid state,
because the account exists, but the order does not.

Better Integration Planning

To address all those issues mentioned above, a custom endpoint could
be created in the OMS that would consume the data for the account and order
in a single request. The logic processing the request would have the ability to
validate all the transmitted data for the account and order creation before even
attempting to persist the information in the database. And it would be able to
handle the cleanup of the account should the order entry fail.
On top of that, only a single request would be made from the CRM,
which means less overhead, less risk of failure, and the overall integration
process is completed faster than if using the multiple requests through the
standard interface.
This is just one example. Of course, even though there are many
reasons to consider custom endpoint in the given case, it does not mean that it
is always an option to go down that path. Using the standard interface is
obviously a feasible option as well, but it comes with increased risk and
complexity, and that needs to be understood and included in the project
planning.
Every system integration comes with its own challenges. Answering the
questions listed above will help to solve those challenges the right way. In
addition, if the right validations are done upfront to identify and address those
risk factors around connectivity and security, it will just be a matter of time until

ITEC 116 – ELECTIVE 4 (System Integration and Architecture 2)

 the two systems are integrated with one another, boosting the productivity of
your company.
Post-test:
1. Identification. Identify the given statement and write your answer to the spaces provided
for you.

a. It is the process of incorporating smaller sub-systems into one larger

system to ensure they all work together?
b. In integration, web services standards are meant to simplify the
integration with the large number of support tools that are built around
them. What are the two interface options which are commonly used?
c. Systems that integrate data across and be comprehensive in supporting
all the major functions of the organization?
d. it is an important first step. It defines what objects or tables need to be
accessed, and the rules the data needs to comply to?
e. what interface allows for the typical data operations (CRUD – created,
updated, delete) on the entities, such as account and order.

ITEC 116 – ELECTIVE 4 (System Integration and Architecture 2)