EVOLUTION OF

ENTERPRISE SYSTEMS
ARCHITECTURES

LECTURE 4
ENTERPRISE SYSTEMS ARCHITECTURES (GUIDING
PRINCIPLES OF EVOLUTION
• Enterprise systems architectures are mainly composed of information systems.

• Business process management mainly deals with information systems in the context of enterprise systems architectures.

• The guiding principle of this evolution is the separation of concerns, a principle identified by Edsger Dijkstra and characterized by “focusing one’s attention
upon some aspect.”

• It is one of the key principles in handling the complexity of computer systems.

• Separation of concerns also facilitates reuse at a level of coarse granularity, because well-specified functional units provided by subsystems can be used
by different applications.

• Separation of concerns also facilitates response to change and is therefore an important mechanism to support the flexibility of software systems.

• Local changes do not affect the overall system, and a second guiding principle of computer science is realized: information hiding
 SOFTWARE ARCHITECTURE
• Software architecture defines a structure that organizes a software system's elements and
resources.

• Software elements and resources are represented by subsystems. In a given software

architecture, these subsystems have specific responsibilities and relationships to other
subsystems.

• Software architectures do not detail the internal structure of a subsystem; but they detail
their externally visible behaviour and, thus, their relationships to other subsystems of the
architecture.
HISTORY OF EVOLUTION(OPERATING SYSTEM)
• Applications were developed from scratch. Basic functionality needed to be redeveloped in different
applications, so application programming was a costly and inefficient endeavour.

• Tight coupling of the programmed assembler code with the hardware, and porting an application to a
new computer system results in a more or less complete redevelopment.

• Operating systems were developed as the first type of subsystem with dedicated responsibilities,
realizing the separation of operating systems concerns from the application.

• Applications can implement functionality by using interfaces provided by the operating system,
realizing increased efficiency in system development.
HISTORY OF EVOLUTION (MANAGEMENT OF DATA)
• Before dedicated subsystems for handling data were developed, each application program was
responsible for storing its data persistently and retrieving it. Programming interfaces were used to
store data.

• Since the structure of the stored data matches the data structure in the application program, each
change in the data structures of the application results in a change of the data structures in persistent
memory, and vice versa.

• To provide a reusable set of functionality and to overcome the data in-consistency problem,
database management systems were introduced.
HISTORY OF EVOLUTION (MANAGEMENT OF
DATA)
• Following early data models, like the hierarchical data model and the network data model, relational
databases were developed. Relational database systems are the backbone of modern information
systems.

• Relational database systems allow modification of the structures of the physically stored data without
affecting the application programs. This important property is known as physical data independence.

• At the same time, logical data independence is covered, i.e., the ability to change the logical
organization of the data without the need to change applications.
HISTORY OF EVOLUTION (LAYERED ARCHITECTURE)
• The next step in the evolution of information systems is
dedicated to graphical user interfaces which were developed to
ease human interaction with application systems. Before the
advent of graphical user interfaces, users interacted with
application programs on the basis of mostly textual interfaces

• The layering of the subsystem—applications sit on top of

database systems that sit on top of operating systems

• Applications do not only use the functionality provided by the

database management system—as the layering might indicate.
Applications also directly use functionality provided by the
underlying operating system.
ENTERPRISE APPLICATION AND THEIR
INTEGRATION
• Information systems host enterprise applications. These applications support enterprises in managing their core assets,
including customers, personnel, products, and resources.

• A new breed of middleware, enterprise application integration systems. Enterprise application integration proves to
be an important application area of business process management.

• These application systems host related data. 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.
ENTERPRISE APPLICATIONS AND THEIR INTEGRATION

• 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—dissatisfied customers.
ENTERPRISE APPLICATIONS WITH REDUNDANT
DATA AND DATA DEPENDENICES
ENTERPRISE RESOURCE PLANNING SYSTEMS
• Enterprise Resource Planning systems (ERP systems) were developed. They provide an integrated database that spans large parts of an
organization

• 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.

• 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.

• 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.
ENTERPRISE RESOURCE PLANNING SYSTEMS
• 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
heterogeneous enterprise applications.
SILOED ENTERPRISE APPLICATIONS

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.

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 other solutions are sought.

The only option is to integrate these systems, which leads to a new breed of
middleware system, the enterprise application integration system.
ENTERPRISE APPLICATION INTEGRATION

• There would be different datatypes, attribute names, and semantics of the attribute.

• These semantic differences need to be sorted out if the systems are integrated. Data integration
technologies are used to cope with these syntactic and semantic difficulties.

• Data integration is an important aspect of enterprise application integration

• Two approaches

• Point-to-point Integration
• Hub and Spoke Integration
POINT TO POINT INTEGRATION
• Enterprise application integration faces the problem that each integration project requires design and implementation
efforts that might be considerable.

• When directly linking each pair of applications, system integrators run into the N × N problem, meaning that the
number of interfaces to develop rises to the square of the number N of applications to be integrated.

• The enterprise application integration architecture resulting from point-to-point integration does not
respond well to changes.

• The reason is due to the hard-wiring of the interfaces. Any change in the application landscape requires
adaptation of the respective interfaces. This adaptation is typically realized by reprogramming interfaces,
which requires considerable resources.
POINT TO POINT INTEGRATION
MESSAGE-ORIENTED MIDDLEWARE
• A specific realization platform of enterprise application integration is message-oriented middleware,
where applications communicate by sending and receiving messages.

• While conceptually the middleware realizes a centralized component, the direct connection between
the applications—and therefore the point-to-point integration—is still in place, because each sender
needs to encode the receiver of a message.

• The main aspect of message-oriented middleware is execution guarantees, such as guaranteed

message delivery.

• However, the problem mentioned above is not solved, since any change in the application landscape
needs to be implemented by changing the communication structure of applications.
MESSAGE-ORIENTED MIDDLEWARE
HUB-AND-SPOKE INTEGRATION
• The hub-and-spoke paradigm is based on a centralized hub and a number of spokes that are directly attached to the hub; the
spokes are not connected.

• The centralized enterprise application integration middleware represents the hub, and the applications to be integrated are
reflected by the spokes. The applications interact with each other via the centralized enterprise application integration hub.

• It is an important feature of hub-and-spoke architectures that the sender of a message need not encode the receiver of the
message. Instead, each message is sent to the enterprise application integration hub. The hub is configured in such a way that the
message structure and content can be used to automatically detect the receiver or receivers of a message.

• The advantage of these centralized middleware architectures is that the number of connections can be reduced. No longer are
connections in the order of N × N required to connect N application systems. Since each application system is attached to the
centralized hub, N interfaces will suffice.
HUB-AND-SPOKE INTEGRATION
HUB-AND-SPOKE INTEGRATION
• Depending on the complexity of these systems—and the availability of generic adapters provided by the enterprise application integration
vendor— the development of the adapter might consume considerable resources. When the adapters are in place and the hub is configured, the
applications can interact with each other in an integrated manner.

• On a technical level, message brokers can be used to realize a hub-and-spoke enterprise application integration system.

• Message brokers are software systems that allow a user to define rules for communication between applications. Therefore, the burden of
implementing—and changing—communication structures is taken away from applications

• The hub uses rules to manage the dependencies between the applications. Based on these rules, the hub can use the information on the identity
of the sender, the message type, and the message content to decide on which message queues to relay a message received.

• Besides relaying messages to recipients, message brokers also transform messages to realize data mapping between the applications, so that
data heterogeneity issues can be handled appropriately. Adapters of application systems are used to perform these message transformations.
HUB-AND-SPOKE INTEGRATION
• Publish/subscribe is a mechanism to link applications to message brokers. The idea is that
applications can subscribe to certain messages or types of messages. Applications can also publish
messages. The information received by publish and subscribe is used by the enterprise application
integration hub to realize the relaying of messages.
•
• This integration while message brokers are a feasible solution to the enterprise application
integration problem, there are also some drawbacks with them. First of all, the message broker
contains the considerable application logic. This application logic is hidden in the rules that the
message broker uses to relay messages. The configuration and management of these rules become
hard and cumbersome,
HUB-AND-SPOKE INTEGRATION
 THE END

ANY QUESTIONS?

THANK YOU