Enterprise Applications and their Integration
Based on operating systems and communication systems as a basic abstraction
layer, relational database management systems for storing and retrieving
large amounts of data, and graphical user interface systems, more and more
elaborate information systems could be engineered.
Most of these information systems host enterprise applications. These applications
support enterprises in managing their core assets, including customers,
personnel, products, and resources. Therefore, it is instructive to look
in more detail at enterprise information systems, starting from individual
enterprise applications and addressing the integration of multiple enterprise
applications. The integration of multiple enterprise applications has spawned a new breed of middleware, enterprise application integration systems. Enterprise
application integration proves to be an important application area of
business process management.
These developments can be illustrated with an enterprise scenario. In the
early stages of enterprise computing, mainframe solutions were developed that
hosted monolithic applications, typically developed in assembler programming
language. These monolithic applications managed all tasks with a single huge
program, including the textual user interface, the application logic, and the
data. Data was mostly stored in files, and the applications accessed data files
through the operating system.
With the advent of database systems, an internal structuring of the system
was achieved: data was managed by a database management system. However,
the application code and the user interface code were not separated from each
other. The user interface provides the desired functionality through textual,
forms-based interfaces.
With lowering cost of computer hardware and growing requirements for
application functionality, more application systems were developed. It was
typical that an enterprise had one software system for human resources management,
one for purchase order management and one for production planning.
Each of these application systems hosted its local data, typically in a
database system, but sometimes even on the file system. In large enterprises,
in different departments, different application systems were sometimes used
to cope with the same issue.
What made things complicated was the fact that these application systems
hosted related data. This means that one logical data object, such as a
customer address, was stored in different data stores managed by different application
systems. Dependencies between data stored in multiple systems were
also represented by dedicated links, for instance through a contract identifier
or an employee identifier.
It is obvious that in these settings changes were hard to implement, because
there are multiple data dependencies between these disparate systems,
and changes in one system had to be mirrored by changes in other systems.
Detecting the systems affected and the particular change required in these
systems was complex and error-prone. As a result, any change of the data
objects, for instance, of a customer address, needed to be reflected in multiple
applications. This lack of integration led to inconsistent data and—in many
cases—to dissatisfied customers.
Enterprise Resource Planning Systems
In this setting, Enterprise Resource Planning systems (ERP systems) were
developed. The great achievement of enterprise resource planning systems is
that they provide an integrated database that spans large parts of an organization.
Enterprise resource planning systems basically reimplemented these disparate enterprise application systems on the basis of an integrated and
consistent database.
An enterprise resource planning system stores its data in one centralized
database, and a set of application modules provides the desired functionality,
including human resources, financials, and manufacturing. Enterprise resource
planning systems have effectively replaced numerous heterogeneous enterprise
applications, thereby solving the problem of integrating them.
Fig. 2.3. Two-tier client-server architecture
Enterprise resource planning systems are accessed by client applications,
as shown in Figure 2.3. These client applications access an application server that issues requests to a database server. We do not address the architectures
of enterprise systems in detail but stress the integrated data storage and the
remote access through client software.
With the growth of enterprises and new market requirements, driven by
new customer needs around the year 2000, the demand for additional functionality
arose, and new types of software systems entered the market. The most
prominent types of software systems are supply chain management systems,
or SCM systems, and customer relationship management systems, or CRM
systems. While basic functionality regarding supply chain management has
already been realized in enterprise resource planning systems, new challenges
due to increased market dynamics have led to dedicated supply chain management
systems. The main goal of these systems is to support the planning,
operation, and control of supply chains, including inventory management,
warehouse management, management of suppliers and distributors, and demand
planning.
Regarding the evolution of enterprise systems architectures, the main point
is that new types of information systems have entered the market, often developed
by different vendors than that of the enterprise resource planning
system many companies run. At the technical level, the supply chain management
system hosts its own database, with data related to supply chains. Since
large amounts of data are relevant for both enterprise resource planning and
supply chain management, data is stored redundantly. As a result, system architects
face the same problems as they did years ago with the heterogeneous
enterprise applications.
As with the settings mentioned, in order to avoid data inconsistencies and,
at the end of the day, dissatisfied customers, any modification of data needs
to be transmitted to all systems that host redundant copies of the data. If, for
example, information on a logistics partner changes that is relevant for both
the enterprise resource planning system and the supply chain management
system, then this change needs to be reflected in both systems. From a data
integrity point of view, this change even needs to take place within a single
distributed transaction, so that multiple concurrent changes do not interfere
with each other.
The source of the problem is, again, redundant information spread across
multiple application systems. Since this information is not integrated, the
user of an enterprise resource planning system can access only the information
stored in this system. However, the customer relationship management system
also holds valuable data of this customer.
When the customer calls and the call centre personnel can only access the
information stored in one system, and is therefore not aware of the complete
status of the customer, the customer is likely to become upset; at least, he does
not feel well served. The customer expects better service, where the personnel
is aware of complete status and not just of partial status that happens to be
stored in the software system that the call centre agent can access. In the
scenario discussed, the call centre agent needs to know the complete status of the customer, no matter in which software system the information might be
buried.
To characterize this unsatisfactory situation, the term siloed applications
has been coined, meaning that data is stored redundantly in different systems,
and these systems are not related at all. Figure 2.4 shows siloed enterprise
applications customer relationship management, supply chain management,
and enterprise resource planning systems. While these application systems
can be physically connected by, for instance, a local network, they are not
logically integrated.
As a result, the only way to integrate the information stored in these systems
is through the user, who accesses the information in the various systems
and does the integration manually. Obviously, this manual integration consumes
considerable resources and is error-prone, so that other solutions are
sought.
With enterprise resource planning systems, this problem had already been
solved by redeveloping an integrated solution. Unfortunately, due to the large
complexity of the systems at hand, the same approach to reimplementing
systems functionality in an integrated way is not feasible in the new context.
The only option is to integrate these systems, which leads to a new breed of
middleware system, the enterprise application integration system.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment