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. Using these
interfaces, the specific relationships between the applications can be reflected
in the configuration of the middleware.
The centralized hub provides
adapters that hide the heterogeneity of the application systems from
each other. Each application system requires the development of a dedicated
adapter to attach to the hub.
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-andspoke
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. By defining in a declarative way
how communication between applications takes place, implementation is redeemed
by declaration, i.e., by the declaration of the communication structures.
Response to change is improved, because the sender is not required to
implement these changes locally. These changes can be specified in a declarative
way in the central hub, rather than by coding in the applications.
The hub uses rules to manage the dependencies between the applications.
Based on these rules, the hub can use 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.
As shown in Figure 2.8, each application is linked to the message broker,
reflected by the directed arcs from the applications to the message broker, in
particular, to the rule evaluation component of the message broker. On receipt
of a message, the message broker evaluates the rules and inserts the message
into the queues of the recipients.
The queues are used for guaranteed delivery of messages. Note that any
change in the communication is handled through the message broker: by establishing
new rules or by adapting existing rules, these changes can be realized.
There is no implementation effort required for realizing these changes; just a
modification of the declarative rules.
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 are used by the enterprise application integration
hub to realize the relaying of messages. it also shows that at a technical
level enterprise application integration with a message broker relies on adapters
that are used for transforming data and protocols between senders
and receivers.
Tuesday, September 1, 2009
Enterprise application integration technology:
Enterprise application integration technology is based on middleware technology
that has been around for years. The goal is to take advantage of these
technologies so that data in heterogeneous information technology landscapes
can be integrated properly. In addition to data integration, the processes that
the application systems realize also need to be integrated. This means that
one system performs certain steps and then transfers control to another system
which takes the results and continues operation. In the context of this
book, the process integration part of enterprise application integration is at
the centre of attention.
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.
A sketch of this integration issue is represented in Figure 2.5, where N = 6
of siloed applications and their integration links are shown. Each link represents
an interface that connects the application systems associated with it.
Therefore, the number of interfaces between pairs of application systems
realize grows to the order of N �N, incurring considerable overhead. If there
were links between any pairs of application systems, then the number of interfaces
to develop would be 5 + 4 + 3 + 2 + 1 = 15. In the general case, the
number of links between N application systems is and therefore rises to the square
of the number of application systems. In the
scenario shown, not all pairs of application systems are connected, but the
problem of the large number of interfaces can nevertheless be seen .
In enterprise computing, changes are abundant, and a systems architecture
should support changes in an efficient and effective manner. 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.
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.
that has been around for years. The goal is to take advantage of these
technologies so that data in heterogeneous information technology landscapes
can be integrated properly. In addition to data integration, the processes that
the application systems realize also need to be integrated. This means that
one system performs certain steps and then transfers control to another system
which takes the results and continues operation. In the context of this
book, the process integration part of enterprise application integration is at
the centre of attention.
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.
A sketch of this integration issue is represented in Figure 2.5, where N = 6
of siloed applications and their integration links are shown. Each link represents
an interface that connects the application systems associated with it.
Therefore, the number of interfaces between pairs of application systems
realize grows to the order of N �N, incurring considerable overhead. If there
were links between any pairs of application systems, then the number of interfaces
to develop would be 5 + 4 + 3 + 2 + 1 = 15. In the general case, the
number of links between N application systems is and therefore rises to the square
of the number of application systems. In the
scenario shown, not all pairs of application systems are connected, but the
problem of the large number of interfaces can nevertheless be seen .
In enterprise computing, changes are abundant, and a systems architecture
should support changes in an efficient and effective manner. 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.
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.
The business motivation behind interacting business processes stems from business to business:
The business motivation behind interacting business processes stems from
value systems, which represent collaborations between the value chains of
multiple companies. These high-level collaborations are realized by interacting
business processes, each of which is run by one company in a business to
business process scenario. This section studies interactions between business
processes performed by different companies.
For the sake of concreteness, this section uses an example from the area of
order processing, described as follows. A buyer orders goods from a reseller,
who acts as an intermediary. The reseller sends a respective product request to
a manufacturer, who delivers to product to the buyer. In addition, the reseller
asks a payment organization to take care of the billing.
The manufacturer then ships the products to the buyer.
The value system shown on a high level of abstraction is detailled
Note that for each value chain in the value system shown
there is a participant in the business-to-business collaboration,
detailling its internal structure and its contribution to the collaboration.
There are many interesting issues to study: how do we make sure that the
business-to-business process created by putting together a set of existing business
processes really fulfils its requirements? Structural criteria, for instance,
absence from deadlock, need to be valid for these processes.
The problem is aggravated by the fact that internal business processes are
an important asset of enterprises. Therefore, few enterprises like to expose
their internal processes to the outside world. This means that
the properties of the overall business-to-business collaboration cannot be based on the actual
detailed local processes run by the enterprises, but rather on the externally
visible behaviour and the associated models to represent it.
value systems, which represent collaborations between the value chains of
multiple companies. These high-level collaborations are realized by interacting
business processes, each of which is run by one company in a business to
business process scenario. This section studies interactions between business
processes performed by different companies.
For the sake of concreteness, this section uses an example from the area of
order processing, described as follows. A buyer orders goods from a reseller,
who acts as an intermediary. The reseller sends a respective product request to
a manufacturer, who delivers to product to the buyer. In addition, the reseller
asks a payment organization to take care of the billing.
The manufacturer then ships the products to the buyer.
The value system shown on a high level of abstraction is detailled
Note that for each value chain in the value system shown
there is a participant in the business-to-business collaboration,
detailling its internal structure and its contribution to the collaboration.
There are many interesting issues to study: how do we make sure that the
business-to-business process created by putting together a set of existing business
processes really fulfils its requirements? Structural criteria, for instance,
absence from deadlock, need to be valid for these processes.
The problem is aggravated by the fact that internal business processes are
an important asset of enterprises. Therefore, few enterprises like to expose
their internal processes to the outside world. This means that
the properties of the overall business-to-business collaboration cannot be based on the actual
detailed local processes run by the enterprises, but rather on the externally
visible behaviour and the associated models to represent it.
Organizational Business Processes in business:
The early 1990s saw process orientation as a strong development not only to
capture the activities a company performs, but also to study and improve the
relationships between these activities.
The general approach
of business process reengineering is a holistic view on an enterprise where
business processes are the main instrument for organizing the operations of
an enterprise. Business process reengineering is based on the understanding
that the products and services a company offers to the market are provided
through business processes, and a radical redesign of these processes is the
road to success.
Process orientation is based on a critical analysis of Taylorism as a concept
to organize work, originally introduced by Frederick Taylor to improve industrial
efficiency. This approach uses functional breakdown of complex work to
small granularities, so that a highly specialized work force can efficiently conduct
these work units of small granularity. Taylorism has been very successful
in manufacturing and has, as such, fuelled the industrial revolution in the late
eighteenth and early nineteenth century considerably.
Small-grained activities conducted by highly specialized personnel require
many handovers of work in order to process a given task. In early manufacturing
in the late eighteenth and early nineteenth century the products
were typically assembled in a few steps only, so that handovers of work did
not introduce delays. In addition, the task were of a rather simple nature, so
that no context information on previously conducted steps was required for a
particular worker.
Using Taylorism to organize work in modern organizations proved inefficient,
because the steps during a business process are often related to
each other. Context information on the complete case is required during the
process. The handovers of work cause a major problem, since each worker
involved requires knowledge on the overall case. For this reason, the functional
breakdown of work in fine-granular pieces that proved effective in early
manufacturing proves inefficient in modern business organizations that mainly
process information.
From a process perspective, it is instrumental to combining multiple units
of work of small granularity into work units of larger granularity. Thereby, the
handover of work can be reduced. But this approach requires workers to have
broad skills and competencies, i.e., it requires knowledge workers who have a
broad understanding of the ultimate goals of their work.
At an organizational level, process orientation has led to the characterization
of the operations of an enterprise using business processes. While there
are different approaches, they have in common the fact that the top-level business
processes are expressed in an informal way, often even in plain English
text. Also each enterprise should not have more than about a dozen organisational
business processes. These processes are often described by the same
symbols as those used for value systems, but the reader should be aware of
the fact that different levels of abstraction are in place.
The structure of organization-level business process management .
The business process management space is influenced by the
business strategy of the enterprise, i.e., by the target markets, by business
strategies opening new opportunities, and, in general, by the overall strategic
goals of the enterprise.
Information systems, shown in the lower part of , are valuable
assets that knowledge workers can take advantage of.
capture the activities a company performs, but also to study and improve the
relationships between these activities.
The general approach
of business process reengineering is a holistic view on an enterprise where
business processes are the main instrument for organizing the operations of
an enterprise. Business process reengineering is based on the understanding
that the products and services a company offers to the market are provided
through business processes, and a radical redesign of these processes is the
road to success.
Process orientation is based on a critical analysis of Taylorism as a concept
to organize work, originally introduced by Frederick Taylor to improve industrial
efficiency. This approach uses functional breakdown of complex work to
small granularities, so that a highly specialized work force can efficiently conduct
these work units of small granularity. Taylorism has been very successful
in manufacturing and has, as such, fuelled the industrial revolution in the late
eighteenth and early nineteenth century considerably.
Small-grained activities conducted by highly specialized personnel require
many handovers of work in order to process a given task. In early manufacturing
in the late eighteenth and early nineteenth century the products
were typically assembled in a few steps only, so that handovers of work did
not introduce delays. In addition, the task were of a rather simple nature, so
that no context information on previously conducted steps was required for a
particular worker.
Using Taylorism to organize work in modern organizations proved inefficient,
because the steps during a business process are often related to
each other. Context information on the complete case is required during the
process. The handovers of work cause a major problem, since each worker
involved requires knowledge on the overall case. For this reason, the functional
breakdown of work in fine-granular pieces that proved effective in early
manufacturing proves inefficient in modern business organizations that mainly
process information.
From a process perspective, it is instrumental to combining multiple units
of work of small granularity into work units of larger granularity. Thereby, the
handover of work can be reduced. But this approach requires workers to have
broad skills and competencies, i.e., it requires knowledge workers who have a
broad understanding of the ultimate goals of their work.
At an organizational level, process orientation has led to the characterization
of the operations of an enterprise using business processes. While there
are different approaches, they have in common the fact that the top-level business
processes are expressed in an informal way, often even in plain English
text. Also each enterprise should not have more than about a dozen organisational
business processes. These processes are often described by the same
symbols as those used for value systems, but the reader should be aware of
the fact that different levels of abstraction are in place.
The structure of organization-level business process management .
The business process management space is influenced by the
business strategy of the enterprise, i.e., by the target markets, by business
strategies opening new opportunities, and, in general, by the overall strategic
goals of the enterprise.
Information systems, shown in the lower part of , are valuable
assets that knowledge workers can take advantage of.
Enterprise Modelling and Process Orientation:
In addition to developments in software architecture, business administration
also contributed to the rise of business process management. There were two
major factors that fuelled workflow management and business process management.
Value chains as a means to functionally break down the activities a
company performs and to analyze their contribution to the commercial success
of the company, and process orientation as the way to organize the activities
of enterprises.Value chains are a well-known approach in business administration to organize
the work that a company conducts to achieve its business goals.
Value chains were developed by Michael Porter to organize high-level business functions and
to relate them to each other, providing an understanding of how a company
operates.
Porter states that �the configuration of each activity embodies the way
that activity is performed, including the types of human and physical assets
employed and the associated organizational arrangements� and he continues
to look at the enterprise and its ecology by stating that �gaining and sustaining
competitive advantage depends on understanding not only a firm�s value chain
but how the firm fits in the overall value system.�
In order to fulfil their business goals, companies cooperate with each other,
i.e., the value chains of these companies are related to each other. The ecology
of the value chains of cooperating enterprises is called value system. Each value
system consists of a number of value chains, each of which is associated with
one enterprise.
The value chain of a company has a rich internal structure, which is represented
by a set of coarse-grained business functions. These high-level business
functions, for instance, order management and human resources, can be broken
down into smaller functional units, spanning a hierarchical structure of
business functions of different granularity.
The process of breaking down a coarse-grained function into finer-grained
functions is called functional decomposition. Functional decomposition is an
important concept to capture and manage complexity. For instance, order
management can be broken down into business functions to obtain and store
an order and to check an order.
also contributed to the rise of business process management. There were two
major factors that fuelled workflow management and business process management.
Value chains as a means to functionally break down the activities a
company performs and to analyze their contribution to the commercial success
of the company, and process orientation as the way to organize the activities
of enterprises.Value chains are a well-known approach in business administration to organize
the work that a company conducts to achieve its business goals.
Value chains were developed by Michael Porter to organize high-level business functions and
to relate them to each other, providing an understanding of how a company
operates.
Porter states that �the configuration of each activity embodies the way
that activity is performed, including the types of human and physical assets
employed and the associated organizational arrangements� and he continues
to look at the enterprise and its ecology by stating that �gaining and sustaining
competitive advantage depends on understanding not only a firm�s value chain
but how the firm fits in the overall value system.�
In order to fulfil their business goals, companies cooperate with each other,
i.e., the value chains of these companies are related to each other. The ecology
of the value chains of cooperating enterprises is called value system. Each value
system consists of a number of value chains, each of which is associated with
one enterprise.
The value chain of a company has a rich internal structure, which is represented
by a set of coarse-grained business functions. These high-level business
functions, for instance, order management and human resources, can be broken
down into smaller functional units, spanning a hierarchical structure of
business functions of different granularity.
The process of breaking down a coarse-grained function into finer-grained
functions is called functional decomposition. Functional decomposition is an
important concept to capture and manage complexity. For instance, order
management can be broken down into business functions to obtain and store
an order and to check an order.
Technical Integration Challenges in Challenges for Workflow Management:
While system workflows are well equipped to support the process aspect of
enterprise application integration scenarios, the same technical integration
problems need to be solved in system workflow projects as those in traditional
enterprise application integration projects.
Application systems that need to be integrated are typically not equipped
with well-documented interfaces that can be used to get hold of the required
functionality. Functionality of application systems might also be implemented
in the graphical user interfaces, so that low-level implementation work is required
to access the application system functionality.
Another important source of trouble is relationships between different applications
at the code level. Direct invocation between software systems is an
example of these relationships, so that an invocation of an application system
automatically spawns off an invocation of another application system. In
these settings, the overall process flow is in part realized at the application
code level, so that the workflow management system is capable of controlling
only parts of the actual process flow, but not the complete process.
The granularity of the workflow activities and the granularity of the functionality
provided by the underlying application systems might be different.
Fine-granular business activities might have been designed in the process
model that cannot be realized, because the underlying application system
only provides coarse-grained functionality. In some cases, the interface to the
application can be modified so that fine-grained functionality is available.
This alternative is likely to incur considerable cost, or it might be impossible
for some applications. Another alternative is changing the granularity of
the business activities. In this case, certain properties of the process might
not be realizable�for instance, the concurrent execution of two fine-granular
activities. As a result, the run time of the workflow will not be optimal.
Service-oriented architectures and service-enabling of legacy applications
are important concepts currently being investigated to address these technical
problems.
enterprise application integration scenarios, the same technical integration
problems need to be solved in system workflow projects as those in traditional
enterprise application integration projects.
Application systems that need to be integrated are typically not equipped
with well-documented interfaces that can be used to get hold of the required
functionality. Functionality of application systems might also be implemented
in the graphical user interfaces, so that low-level implementation work is required
to access the application system functionality.
Another important source of trouble is relationships between different applications
at the code level. Direct invocation between software systems is an
example of these relationships, so that an invocation of an application system
automatically spawns off an invocation of another application system. In
these settings, the overall process flow is in part realized at the application
code level, so that the workflow management system is capable of controlling
only parts of the actual process flow, but not the complete process.
The granularity of the workflow activities and the granularity of the functionality
provided by the underlying application systems might be different.
Fine-granular business activities might have been designed in the process
model that cannot be realized, because the underlying application system
only provides coarse-grained functionality. In some cases, the interface to the
application can be modified so that fine-grained functionality is available.
This alternative is likely to incur considerable cost, or it might be impossible
for some applications. Another alternative is changing the granularity of
the business activities. In this case, certain properties of the process might
not be realizable�for instance, the concurrent execution of two fine-granular
activities. As a result, the run time of the workflow will not be optimal.
Service-oriented architectures and service-enabling of legacy applications
are important concepts currently being investigated to address these technical
problems.
Challenges for Workflow Management in Lack of Adequate Support for Knowledge Workers:
In contrast to many developments in software architecture and technology,
workflow management systems have massive effects on the daily work for their
users. The method of data storage and whether the program was developed
with a procedural programming language or an object oriented programming
language are relevant only for system designers and developers; these implementation
aspects do not matter for the users of these systems. Therefore,
special care has to be taken in the rollout of workflow applications; early participation
of users in the design of these systems is important to avoid user
acceptance issues.
Workflow management systems represent not only processes but also the
organizational environment in which these processes are executed. This means
that persons are represented by their skills, competences, and organizational
positioning. This information is used to select persons to perform certain
activities. The active selection of persons by the workflow management system
has not been considered appropriate, since human workers felt that a machine
burdened them with additional work. This feeling might also be due to crude
interfaces of early workflow management systems.
The role of knowledge workers is another area where traditional workflow
management systems scored low. Workflow models prescribe the process flow,
and a workflow management system makes sure that the workflow is performed
just as it is described. This also means that there is little room for creativity
for the knowledge worker. Any process instance that has not been envisioned
by the process designer cannot be realized. This might lead to situations where
certain parts of the overall business process are not handled by the workflow
management system. Sometimes, even paper-based solutions were used by the
knowledge workers, leading to inconsistent states in the overall process.
workflow management systems have massive effects on the daily work for their
users. The method of data storage and whether the program was developed
with a procedural programming language or an object oriented programming
language are relevant only for system designers and developers; these implementation
aspects do not matter for the users of these systems. Therefore,
special care has to be taken in the rollout of workflow applications; early participation
of users in the design of these systems is important to avoid user
acceptance issues.
Workflow management systems represent not only processes but also the
organizational environment in which these processes are executed. This means
that persons are represented by their skills, competences, and organizational
positioning. This information is used to select persons to perform certain
activities. The active selection of persons by the workflow management system
has not been considered appropriate, since human workers felt that a machine
burdened them with additional work. This feeling might also be due to crude
interfaces of early workflow management systems.
The role of knowledge workers is another area where traditional workflow
management systems scored low. Workflow models prescribe the process flow,
and a workflow management system makes sure that the workflow is performed
just as it is described. This also means that there is little room for creativity
for the knowledge worker. Any process instance that has not been envisioned
by the process designer cannot be realized. This might lead to situations where
certain parts of the overall business process are not handled by the workflow
management system. Sometimes, even paper-based solutions were used by the
knowledge workers, leading to inconsistent states in the overall process.
Subscribe to:
Posts (Atom)