Assessing Component based ERP Architecture for Developing Organizations

Assessing component based ERP
architecture for developing
organizations
Masoud Rafighi,
University Of Qom
Yaghoub Farjami,
University Of Qom

Introduction
• Software Architecture describes the high-level
structure of a system in terms of components and
component interactions. In design, architecture is
widely recognized as providing a beneficial
separation of concerns between the gross system
behavior of interacting components and that of its
constituent components. Similarly this separation
is also beneficial when considering deployed
systems and evolution as it allows us to focus on
change at the component level rather than on
some finer grain.
IJCSIS, Vol. 14, No. 1, January 2016
https://sites.google.com/site/ijcsis/

Software architecture
• Architecture is the fundamental organization of a
system consisting of components, each of which is
associated with each other and with the system
and the principles governing its design and
evolution. Software architecture in fact is the
selection of a general structure for implementing a
software project based on a set of user
requirements and business of software systems in
order to be able to implement the intended
applications and also to optimize and accelerate
the quality of software, its production and
maintenance.

ERP
• Enterprise Resource Planning (ERP) programs are
core software used by companies to coordinate
information in every area of the business. ERP
programs help to manage company-wide business
processes, using a common database and shared
management reporting tools. A business process is a
collection of activities that takes one or more kinds of
input and creates an output, such as a report or
forecast that is of value to the customer. ERP software
supports the efficient operation of business processes
by integrating throughout a business tasks related to
sales, marketing, manufacturing, logistics, accounting,
and staffing.
Your logo here

Architectures for development of
Software distributed
• Data- centric architecture
• The goal of this architecture is to maintain the
integration and the ability of aggregation. The
word “data-centric” refers to systems in which
the availability and timeliness of the data is
an appropriate descriptive of system
performance. A client runs on a set of
independent control field and common data
that is accessed by all customers and it can
be as a passive source (such as a file) or an
active source (blackboard).

Architectures for development of
Software distributed
• Architecture Component-based
• Software components are a comprehensive and extendable
piece which its function is well defined. Through interfaces
with other components can be combined and interact with
each other. Three goals of component-based architecture
include: Overcoming complexity, manage the changing, re-
usability.
• Plug in architecture
• Plug-in architectures and platforms represent a promising
approach for building software systems which are extensible
and customizable to the particular needs of the individual
user, However, there are several technical features which
have contributed to the success of plug-in system.

Measurement and analysis of the
architecture criteria
• Layout of components
• Create
• Connection
• Development
• The main advantage
• The main problem

Compare architectures
Plug inComponentData- centric
Criterion
Architecture
They are placed in the outer
layers of software [22].
Components are integrated
and modular,
A unit is independent
establishment and is
independent of other
components
A unit of independent
deployment [12,14]
Data is stored in a database and
a common data is accessed by
all customers [24, 26].
Layout
The plug-in creates a
configuration file is executed
and all the settings will be in
the file [22].
Special languages for
deﬁning interfaces,
(IDL).[11,12]
There's a lot of software
components
1.Input/output types
2.Functional behavior
3.Concurrent behavior
4.Timing behavior
5.Resource usage
6.Security[11,15]
The architecture emphasizes
the accessing and updating data
[24, 26].
Creation
In this architecture, plug-
connected to the outer layer
software [21].
IPC protocol IIOP )Internet
Inter-ORB Protocol([12,11]
Not context dependent
Not related to a specific
area and can be used in the
system [15]
The connection is established in
two ways:
When the shared data, as a
passive source, acts like file.
When the shared data is as a
blackboard [24, 26].
Connection
Plugins can be deployed
globally or only for a specific
environment and not limited
in its development.
[19,20].
Components are
interchangeable for
example component B can
be replaced with
component A Compassable
with other components A
good combination of
mechanisms is used [14,11]
It has high Corrigibility Due to
the change of each customer
having no effects on other
customers [24, 26].
Development
This function is a
component-based
architecture [22].
The conference was
published in Germany in
1968,is not selected from
other architectures [9,10]
It's not selected from another
architecture[26].Elected or a
combination of
other architectures
It will active Customization
with attention to user’s
needs
Simple and Powerful
Its structure is such that the
Reuse of software in order
to reduce development
costs
Variability, performance,
Support for parallel
distributed systems on
The data integrity is provided by
mechanism of blackboard and
common data is an independent
part of the customer. Therefore,
this style is scalable and can
easily add new customers [24,
The main advantage

Problems architectures
• Extensibility problem involving (the laws
that have been changed, change in data,
the changes in the organization,
integration, change in operations, changes
in systems, developing new systems).
• Problem of imprisonment or trapped data.
• Programmer locked-in problem, the only
programmer can develop the system
further.

Separation-of-Concerns (SOC)
A key principle of software development and architecture is the
notion of Separation-of-Concerns. At an architectural level,
separation of concerns is a key component of building layered
applications. In a traditional N-tier application structure, layers
might include data access, business logic, and user interface.
More modern N-tier application designs might include a core
domain model and separate infrastructure modules in addition to
one or more front end services and/or user interfaces. Web
pages, to a greater or lesser degree, separate concerns relating
to structure, logic, and formatting through the use of HTML,
JavaScript, and CSS. At a lower level, the networking model
used by the Internet is broken into a series of layers each with
specific concerns and responsibilities, and demonstrates how
separation of concerns can be effectively applied.

The proposed model
This architecture made of combining Data- centric architecture,
plug-in architecture and component architecture so that in this
architecture all components are connected to the data center but
the components must appear with two hands (it is getting from
plug-in architecture with this innovation that both hands
SERVICE INTERFACE and Plug in interface added to every
component. It means components have two hands instead of
one hand). So in addition to connection they can transfer
services and data.By using SOC discuss we concluded that
every component must maintain its own data and just Common
data such as Authentication and etc. will be kept in Data-
Centric. We called the proposed architecture, CPDC Architecture
which contains bellow parts:

The proposed model
12
Data center: Information in the data center, public data, such as user categories,
authentication and organizational chart of the organization need to be placed in the
center.
Service interface: An interface to transfer services from one component to another
component
Plug in interface: Certain protocol for connecting components
Service: Services and operations that are performed on the data in each module
Plug in manager: management, control and configure of plugin will done.
Specific data: Data that is for a special system and there is no need to exist in other
systems.
Host component: The various modules which are available in the organization

The proposed model

Evaluation and testing the soundness
of architecture
• Extensibility SYSTEMS
• The merge of the two organizations

Extensibility SYSTEMS
In the first problem of the development
system and add a new system to program in
a way that the integration didn’t lose; If you
use CPDC Architecture model, we can
easily add a system to our organization
system and the new system is able to
transfer data.

Now, adding a new system to organization with the following two
approaches:
• First approach: similar systems exist in the organization so they can
merge together and in the format of the old system used in
organization. In this approach, the following steps are performed.
The proof is shown in Figures 3 and 4.
• First step: adding processes of both systems in a single system
• Second step: adding Specific data of both system in a single system
• Third step: adding services of both system in a single system
• Forth step: the aggregated system should connect to the data center
• Fifth step: management of new and old systems must be removed
and a single management stays on aggregate systems.

The second approach is that the new system does not
exist in the organization and should fully be added as a
new system, these steps can be done in this approach.
• Step One: with adding a new system to organization it
should be connected to the data center to authenticate
from data center
• Step Two: If the new system wants to connect to other
existing systems, it can use both hands plug in
interface and service interface, so after the connection
they can send and receive data. The proof is shown in
Figures 5 and 6.
• The third step: defining the management of new
system in the organization

• Algorithm Extensibility SYSTEMS
• Input: A new subsystem and all the relationships with other subsystems and all the relationships in an org
• Output: A new extensibility system
• Org organization;
• I New Host Component;
• J Similar subsystem in org;
• Q (merge I&J);
• If I equal J;
• Do merge I and J;
• specific data of Q Merge specific data of I with specific data of J;
• services of Q Merge services of I with services of J;
• Add Q relation with data center;
• Revoke Privileges Manager I;
• Revoke Privileges Manager J;
• Grant Privileges Manager Q;
• End if.
• If subsystem Q need to connect with other subsystem;
• Add relation between plug in interface Q and other subsystem service interface;
• Else
• Add I relation with data center in org;
• Grant Privileges Manager I;
• End if.
• If subsystem I need to connect with other subsystem;
• Add relation between plug in interface I and other subsystem service interface;
• End if.
• End.

The merge of the two organizations
The problem of merging two organizations can keep
integration in organization and merge all systems by
using CPDC architecture. Some systems such as Host
component A2 and Host component B2 are common with
Host components of other organizations will combine to
gather, they work the same in both organization, systems
that are different must first be separated from the
previous data- centric and connect to new data- centric,
then they can connect to each of necessary systems of
new organization with both hands SERVICE
INTERFACE and Plug in and transfer data. So the new
processes will be defined easily by systems of new
organization.

As mentioned, when two organizations use our architecture they can
merge together easily, follow these steps:
• First step: merge data center of both organizations.
• Second step: Systems that are common in both organizations
should be integrated with each other and made a single system.
• Third step: Systems that are uncommon in both organizations
should be connecting to data center. Fig11
• Fourth step: Any of systems can connect and communicate to other
systems with using two hands plug in interface and service interface
(fig.12) in a way that they can send/ receive data
• Fifth step: Management systems that are common in both
organization and management must be removed and a single
management stays on aggregate systems.
• Sixth step: Management systems that are uncommon in both
organizations will be defined as new management in the new data
center.

•Algorithm Merge (ORG1, ORG2)
• Input: subsystems and all the relationships in org1 and subsystems and all the relationships in org2
• Output: A new integrate system
• Org1 organization 1;
• Org2 organization 2;
• Data Center marge (DataCenter1, Data Center2) ;
• Data Center all public data in data center1;
• Data Center all public data in data center2;
• For all Host Component i ∈ Org1 and Org2
• Delete i relations with data center 1 or data center 2;
• Revoke Privileges Manager Host Component I;
• End for.
• For common subsystems in the org1 and org2
• Do merge common subsystems;
• Add i relations with data center;
• Merge specific data of common subsystems of org1 and org2;
• Merge services of common subsystems of org1 and org2;
• Grant Privileges Manager Host Component I;
• End for.
• For uncommon subsystems in the org1 or org2
• Add i relations with data center;
• Grant Privileges Manager Host Component I;
• End for.
• If subsystem i need to connect with subsystem j;
• Add relation between plug in interface i and service interface j;
• End if
• End.

Now that the problem development of the
system and merging of the two organizations
systems was resolved with the proposed
model, systems can transfer data between the
old and new systems, the second Problem of
imprisonment or trapped data will solved by
using the proposed architecture. With attention
to development of system the third problem
programmer locked-in problem, the only
programmer can develop the system further will
disappear.

Conclusions
According to studies, each of architectures has problems. In
plug in architecture database is not appropriate place to store
information, component architecture is week in data integration,
components will connect to gather hardly and in datacenter
architecture there is no link between systems and all systems
are connected to database, finally with the proposed architecture
‘CPDC Architecture’ which is a special combine of three
architecture not only solve all above problems but also Take
advantages of them to Resolving problems like: developing new
systems, merging common systems of different organization,
imprisonment or trapped data, programmer locked-in problem,
the only programmer can develop the system further. The
architecture responds to the issues, ensures scalability and
versatility of the systems of organization and eventually ensures
the integrity between all systems.

Questions

Assessing Component based ERP Architecture for Developing Organizations

Recommended

More Related Content

What's hot (20)

Viewers also liked (12)

Similar to Assessing Component based ERP Architecture for Developing Organizations (20)

Recently uploaded (20)

Assessing Component based ERP Architecture for Developing Organizations