2

Process Integration

Process Integration
(Review of ITEC 75 – System Integration and Architecture)

Objectives:
After the completion of the chapter, students should be able to:
1. Give an overview of the pre-requisite subject and the importance of this course
to the program
2. Identify the keys in 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,

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

 2
Process Integration

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 management, service and maintenance, and transportation.
ERP systems’ major achievement was to provide accessibility, visibility, and
consistency across all functions of the enterprise.3 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)  | 

 2
Process Integration

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.

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?

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

 2
Process Integration

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

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.

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

 2
Process Integration

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.

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.)?

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

 2
Process Integration

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.

The OMS provides a standard SOAP interface that allows for the
typical data operations (CRUD – created, updated, delete) on the entities,

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

 2
Process Integration

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 channel causing an error
double. It also means that it requires 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 the two systems are integrated with one another, boosting the
productivity of your company.

Review Questions:
1. System integration planning is the process of incorporating smaller sub-systems into
one larger system to ensure they all work together. What examples can you give and
how does it apply?
2. Tell us what are the COBOL, FORTRAN and ALGOL’s features?
3. Evolution of ERP, during the 1960s and 1970s, As the production grew bigger, with
more complex inventory management and production scheduling, how does ERP
manage to develop the system?
4. From the examples provided in the chapter on ERP success and failure stories, what
are the critical factors of success and failures?
5. How do you relate to the better integration planning?

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