MANAGING INFORMATION FLOW DYNAMICS WITH AGILE
ENTERPRISE ARCHITECTURES
Nancy Alexopoulou, Panagiotis Kanellis, Drakoulis Martakos
Department of Informatics and Telecommunications, University of Athens, Athens, Greece
Keywords: Enterprise systems, integration, information flow, flexibility
Abstract: New organization forms and ways of conducting business require architectures for enterprise s
ystems that
can support and not hinder entrepreneurial activities. Primarily this means that the information flow between
both internal as well as cross-enterprise processes must be managed by underlying systems that offer a high
level of automation as well as being highly flexible and integrated. In this respect, we present an agile
architecture that offers a coherent and high level conceptualisation of the above properties that enterprise
information systems should display, consider a number of technologies as potential implementation
candidates and demonstrate how the architecture addresses node density, velocity, viscosity and volatility as
parameters for managing and controlling the dynamics of information flows.
1 INTRODUCTION
Enabled via the utilization of the new technologies,
companies in the electronic marketplaces of the new
economy are able to form partnerships only for the
duration of the transaction, as opposed to long-term
hierarchical supply chain collaborations of the
yesteryear (Hammer, 2001; Yang and Papazoglou,
2000). “On demand” partner relationships can be
formed with enterprises that have published their
profiles on the web and best satisfy ones’ own
requirements, regarding price, quality standards,
delivery schedules and other attributes. As firms
continuously sense opportunities for competitive
action in their product-market spaces, it is agility
which underlies firms’ success in continuously
enhancing and redefining their value creation
(Sambamurthy et al., 2003). It follows that agile
enterprise infrastructures that can meet the
performance criteria in terms of efficiency required
for the execution of both inter and intra-
organizational processes are a prerequisite. By
‘efficiency’ we mean smooth business process
execution that does not suffer from delays or errors
and, ease in altering the business logic of a process
and adjusting it to the needs of the moment. In turn,
both of the above need seamless integration of
internal enterprise processes (private processes) with
external ones (public processes).
According to Krovi et al
(2003), to attain such
levels of performance, it is imperative to enable and
manage agility in terms of the flow of information in
an organization. These parameters that affect
directly the information flow, namely node density,
velocity, viscosity and volatility should be taken into
consideration when designing enterprise system
architectures.
The purpose of this paper is to present, primarily
at a concept
ual level, such an enterprise systems
architecture that offers the required flexibility whilst
enabling full automation and high integration. Its
design caters for the criteria set by the information
flow parameters as defined by Krovi et al. (2003)
and, is based on a Business Process Engine (BPE)
that acts as a coordinator for end-to-end processes.
The term ‘end-to-end’ is used in a holistic manner to
denote processes that comprise both internal
enterprise activities, as well as external Business-to-
Business (B2B) transactions between one or more
trading partners. The paper proceeds as follows. In
the next section we provide a brief discussion on
information flow parameters whilst in the section
that follows we present the architecture. In section 4,
we propose a number of enabling technologies as
possible candidates for the implementation of the
architecture. In section 5 we demonstrate how
flexibility, automation and integration as provided
by the architecture can help in the management of
454
Alexopoulou N., Kanellis P. and Martakos D. (2004).
MANAGING INFORMATION FLOW DYNAMICS WITH AGILE ENTERPRISE ARCHITECTURES.
In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 454-459
DOI: 10.5220/0002612204540459
Copyright
c
SciTePress
the enterprise information flow in terms of node
density, velocity, viscosity and volatility. Section 6
offers our conclusions.
2 INFORMATION FLOW
PARAMETERS
The brief discussion in this section is based on the
work of Krovi et al. (2003) where the reader is
referred for a detailed description and explanation of
the parameters affecting information flow dynamics.
Node density denotes the number of intermediate
nodes in the information processing channel, where
a node is used to describe an entity or a group of
entities capable of altering the properties of
information flow.
Velocity refers to the speed of incoming
information at a node. It is inferred that architectures
which are designed to facilitate fully and not
partially the automation of information exchange,
help to streamline the organisational processes and
thus increase efficiency in this respect.
Viscosity refers to the degree of conflict that can
be observed at a node. The conflict arises due to the
presence of contradictory information components.
In such cases, viscosity appears in the form of
multiple values of information that must be resolved
before the node can begin processing.
The uncertainty in information content, format
and/or timing is expressed by the value of volatility.
External forces having their roots in industry or
economy-wide factors can impact the degree of
volatility creating in terms of transaction volume
either laminar or turbulent information flows.
3 AN AGILE ARCHITECTURE
FOR ENTERPRISE SYSTEMS
In this section we present an architecture for
enterprise information systems that enables
flexibility, full automation and high integration.
Flexibility, in general, means the ability to make
changes easily, i.e. in a timely and cost-effective
manner. Full automation means that the flow of
information between activities, processes and nodes
is carried out electronically with no manual
intervention. Integration is the process whose
ultimate aim is to create an infrastructure where
different entities (applications, databases, etc.) can
communicate efficiently with each other.
Integration, as well as flexibility, can be approached
at three different levels: business processes, data and
application components. Integration at business
process level means that business processes can span
multiple applications, whether these applications
belong to a single or to different companies.
Integration at data level means that data reside in
any data source anywhere and can be used by any
application or system anywhere. Integration of
application components means that components can
communicate efficiently with each other as well as
with legacy applications. A system that is integrated
at all three levels is a highly integrated system.
Flexibility at business process level means that a
business process definition (activities, roles, routes
and rules) can be altered without requiring
modification of the application components.
Flexibility at the data level denotes the efficient
transformation of data from one format to another
that can be realised at run-time. Finally, at
application components level, flexibility means that
new components can be easily embodied into the
existing architecture and also that components can
be re-used across multiple business scenarios.
Based on the above and the discussion on
information flow parameters in the previous section,
we derive that a flexible architecture can satisfy
performance criteria associated with node density
and volatility, while a fully automated and integrated
system can satisfy criteria associated with velocity
and viscosity. The former stands because with a
flexible infrastructure, alterations in the number of
nodes within a business process can be performed
fast and easily. Similarly, any operational changes
imposed by external factors can be accommodated in
a timely and cost effective manner. Automation and
integration on the other hand, mean that information
is not error-prone, keeping thus the value of
viscosity low at nodes. In terms of velocity, it means
the ability to accommodate variances in the flow of
information without bottlenecks.
Our proposed architecture is presented in figure
1. At the heart of the architecture is the Business
Process Engine (BPE), which interacts through the
exchange of messages with (a) users via a
Document-based Worklist Browser, (b) customers
via a Web Browser, (c) trading partners via the B2B
engine, and (d) applications and components via the
Component Management Service (CMS).
The BPE acts as a coordinator of activities
spanning across the enterprise entities (users,
applications, trading partners, etc.) invoking for each
activity the entity that is responsible for performing
it. The BPE reads and executes business logic
defined in process definition documents. This
implies that the process definition is expressed in a
business process definition language that is
machine-readable.
MANAGING INFORMATION FLOW DYNAMICS WITH AGILE ENTERPRISE ARCHITECTURES
455
The role of the document-based worklist browser
is to inform the user about the tasks that need to be
accomplished within the context and sequence of a
specific business process. In general, it provides a
graphical user interface that helps the user with his
everyday tasks.
The B2B engine (Bussler, 2002) is responsible
for handling communication (transport, security,
etc.) with trading partners and other external entities
(financial institutions, insurance agencies, etc.)
through the implementation of any open B2B
protocol.
Finally, the CMS finds and invokes the
appropriate application components that deliver the
requested business service. The components can
intercommunicate over a common communication
infrastructure. Legacy applications can be connected
to the communication infrastructure via adapters. In
essence, the CMS together with this infrastructure
constitute an Enterprise Application Integration
(EAI) implementation that follows some of the
principles of the NGOSS (New Generation
Operations Systems and Software) framework
(TMF, 2001). NGOSS is an initiative of the
TeleManagement Forum set to develop a framework
for rapid and flexible integration of operations and
business support systems in telecommunications, but
it can be equally applied to other business areas as
well. NGOSS defines a service-oriented system
framework, which is based on a collection of loosely
coupled, re-usable components that perform
business services.
Finally, we should mention that whenever
messages sent by the BPE need to be transformed
into another format, a transformation mechanism is
used. For example, if a message is to be directed to a
worklist browser, it must be first transformed into
HTML. Likewise, at the application components
level, if for example Common Object Request
Broker Architecture (CORBA) is used, then the
messages sent by the BPE will have to be
transformed into CORBA IDL messages. Overall,
the B2B engine will have to transform them into the
format required by the protocol used in the specific
business collaboration.
Based on the above description, it becomes clear
Figure 1: Architecture for Enterprise Systems
Transformation
Transformation
Transformation
Business
Process
Engine
ICEIS 2004 - DATABASES AND INFORMATION SYSTEMS INTEGRATION
456
how the architecture enables full automation;
business processes are described in a machine-
readable document, which is executed by the BPE.
The machine-readable document is generated at
build time through a process definition tool. Of
course, there are cases at this level that human
intervention may be inevitable, hence the inclusion
of the document-based worklist browser as an
element of the architecture.
Integration at business process level is attained
because of the fact that the BPE operates with users,
applications and trading partners in a transparent
manner. This is feasible due to the existence of the
CMS that is responsible for invoking the necessary
applications for the accomplishment of a business
process, as well as the existence of the B2B engine
that hides the communication and B2B protocol
details from the BPE. As a result, the BPE can
efficiently execute end-to-end processes, since the
B2B transactions are integrated with the internal
enterprise activities. Also, regarding integration at
the application component level, it is reminded that
this is addressed in the architecture by an EAI
implementation based on the principles of the
NGOSS framework. As far as data integration is
concerned, this is achieved through the
transformation mechanism described above.
Flexibility at process level ensues from the
abstraction of the business process flow into an
entity separate from the components themselves. As
a result, business process steps can be easily
rearranged or altered, since the only action required
is to update the process definition document. The
underlying component interactions will be
automatically reconfigured. As far as data format
transformations are concerned, the transformation
mechanism we mention in the next section enables
also run time transformations. Finally, in a NGOSS
infrastructure, new components can be easily
embodied into the infrastructure and communicate
with the already existing applications via the
common communication vehicle. Due to this
abstraction, components can also be re-used across
multiple business scenarios.
4 ENABLING TECHNOLOGIES
The key enabling technology for the architecture
presented in the previous section is the eXtensible
Markup Language (XML) (Bray et al, 2000). XML
can help (a) to automate the execution of business
processes, and (b) to form the foundation for both
EAI and B2B integration.
Automation of business process execution is
enabled by the fact that XML-based business
process definitions are machine-readable and thus
can be executed by a BPE. More specific, XML acts
as the bridge between the human-readable versions
required for modeling activities and the machine-
readable versions required by the run time
environment, filling thus the gap between business
processes and application components. Currently,
there are various XML-based business process
definition languages, such as the Business Process
Modelling Language (BPML) (BPMI, 2001), Web
Services Flow Language (WSFL) of IBM
(Leymann, 2001) and XLANG of Microsoft (Satish,
2001). Also, ebXML (2001b) has defined a Business
Process Specification Schema (BPSS) (ebXML,
2001a) that provides a shared view of the
interactions between trading partners regardless of
the actions that lead to any particular interaction.
The issue here is whether each of the three business
process definition languages suffices for the
description of an end-to-end process or they will
have to include BPSS for the implementation of
B2B collaborations. As a matter of fact, BPML,
WSFL and XLANG do not support basic business
notions such as mutual non-repudiation and
authentication between parties. Nickull et al (2001)
present how BPSS can be bound to each of the three
leading business process specification languages
(BPML, WSFL and XLANG).
During the execution of the business process, the
BPE communicates with the CMS, which in turn
invokes the appropriate components. At the
application components level, messages sent by the
BPE are transformed into an appropriate format, for
example into CORBA IDL. An efficient
transformation mechanism that can be used for such
transformations is XSLT (Clark, 1999). XSLT is
used for the transformation of an XML format to
another XML format, to aware non-XML or to any
arbitrary format (Holman, 2000).
As far as integration is concerned, XML is not an
integration solution in itself – it is just a definition
language, as explained earlier. For XML messages
to be interpreted by other companies, both trading
parties need to agree on common XML-based B2B
standards, which will specify the document
structures and the process descriptions. Such
standards have already been developed by various
B2B initiatives. Two major B2B initiatives are
RosettaNet and ebXML (2001b). Hence, the B2B
engine must be able to support any B2B protocol so
as to provide for more flexibility.
For EAI, a candidate XML-based technology is
Web Services (Fremantle et al., 2002). Web
Services enable interoperability via a set of open
standards such as WSDL (Web Services Description
Language), SOAP (Simple Object Access Protocol)
and UDDI (Universal Description Discovery and
Integration).
MANAGING INFORMATION FLOW DYNAMICS WITH AGILE ENTERPRISE ARCHITECTURES
457
5 MANAGING INFORMATION
FLOW DYNAMICS
We have used the terms ‘agility’ and ‘agile’ to
denote enterprise system architectures that offer the
flexibility, integration and level of automation
necessary for the management and control of
information flow dynamics and, in particular via
node density, velocity, viscosity and volatility. In
this section we further elaborate on the ways that our
proposed architecture addresses those parameters.
5.1 Node Density
Node density, according to Krovi et al., (2003),
refers to the number of nodes included in a business
process, where a node is used to describe an entity or
a group of entities capable of altering the properties
of information flow. In the proposed architecture,
both internal entities and external constituencies are
regarded as nodes within an end-to-end process and
the BPE interacts with them without discrimination.
The abstraction of business process flow into an
entity (BPE) separate from the application
components themselves allows an easier and more
flexible way to adjust node density, i.e. to add or
remove nodes from business process sequence,
whenever new circumstances arise or a modification
is needed. The only action required in such a case is
a reconfiguration in the business process definition
that is executed by the BPE, while no modification
is needed at the application component level.
Separating process control removes the need for
individual components to have knowledge of the
business logic associated with process operation.
When invoked by process control, a component
simply performs the service offered through its
interface.
5.2 Velocity
The decoupling of business process flow from
application components leads also to easier system
integration. A highly integrated system, in turn,
allows for high velocity, as all its entities can
intercommunicate fast and in a seamless manner.
Moreover, in the proposed architecture, the control
of information flow is completely automated, since
the BPE has the overall ‘supervision’ of business
processes and is always aware of where to forward
the information. In effect, the execution of business
processes is much faster. All necessary information
is available at the respective edge (user, application,
and partner) in a timely manner. The information
flow is smooth and conflicts, discontinuities or
unnecessary delays, are prevented.
In addition, the fact that the BPE does not
discriminate in the way it handles operations
between internal and external entities helps in the
integration of internal processes with B2B
transactions. As a result, the internal enterprise
activities are synchronised with the B2B transactions
and therefore any temporal misalignment between
them is eliminated ensuring at the same time the
accommodation of high velocity levels. At another
level, open communication protocols implemented
internally through Web Services or externally via the
B2B engine, ensure a high level of integration
providing thus for the accommodation of high
velocity levels in the flow of information.
5.3 Viscosity
The high level of automation and integration offered
by the proposed architecture helps also in the
attainment of low viscosity, since it leads to more
accurate and streamlined information and ensures
lower probability of error occurrence. As a result,
conflicts that may arise at the nodes due to the
arrival of contradictory information particles are
avoided. Since the BPE offers a high level of
automation and ensures that the correct routes will
be followed for the required information when this is
needed by the various nodes along the value chain,
the appearance of errors and contradictory
information particles will ultimately depend on how
well the business process has been designed by the
business process engineer.
5.4 Volatility
Volatility denotes the associated uncertainty in
information content, format and/or timing (Krovi et
al., 2003). Generally speaking, to cope with
volatility in system terms means to develop a
flexible system that can be easily adjusted so as to
accommodate the extent of turbulence. This
turbulence is of a polymorphous nature and one
cannot claim without the benefit of hindsight that
any enterprise architecture or system could by
design accommodate all its manifestations.
However, as far as content and format are
concerned, we believe that both the design and the
underlying implementation technologies as
described in the previous section provide the highest
possible flexibility. For example, nodes can be
added easily, new application components can be
embodied into the infrastructure and communicate
with existing applications via the common
communication bus, etc.
In addition the architecture can help manage
volatility as it enables connectivity with a large
ICEIS 2004 - DATABASES AND INFORMATION SYSTEMS INTEGRATION
458
number of external entities, which may themselves
be sources of change. This is feasible because the
BPE is scalable due to the existence of the B2B
engine, which enables BPE to handle all equivalent
relationships with a single business process
definition. More specifically, the use of the B2B
engine provides for the decoupling of the business
process definition from the communication and
business protocol details.
6 CONCLUSIONS
Contemporary architectures for enterprise systems
should enable and not hinder the management of
information flow dynamics. In this paper, we
proposed an architecture that caters for the above by
offering the necessary flexibility for the
management and control of node density and
volatility and enabling automation and high
integration needed for accommodating variances in
velocity and viscosity. Beyond conceptualisation
we also outlined a number of implementation
technologies for the key parts of the architecture. We
must note however that high agility requires a
revisiting of the ways enterprises develop and handle
their capabilities to organise and manage agile
system infrastructures. ‘Organizational Emergence’–
“a theory of social organization that does not assume
that stable structures underpin organizations” (Truex
et al, 1999) (p. 117) can aid in this respect. This
means that an extended number of organisational
capabilities is required to enable the successful
institutionalisation of agile IT architectures. Further
research is urgently needed towards this direction.
ACKNOWLEGDEMENTS
We would like to thank the partners of EURESCOM
P1106 and in particular Derrick Evans of British Telecom
whose input gave form to a number of ideas presented
herein. We are also grateful to Nikos Korres of the
University of Athens for his valuable assistance in the
preparation of this paper.
REFERENCES
Assaf Arkin, 2002. Business Process Modeling Language
(BPML). Business Process Management Initiative,
http://www.bpmi.org/.
Christoph Bussler, Oracle Corporation, 2002. The Role of
B2B Engines in B2B Integration Architectures.
SIGMOD Record, Vol. 31, No. 1, pp. 67-72.
David Raymer, Steve Afrin and Raghav Trivedi, 2001.
NGOSS Architecture Technology Neutral
Specification. TeleManagement Forum,
http://
www.tmforum.org
.
Duane Nickull, Jean-Jacques Dubray, Colleen Evans, Pim
van der Eijk, Vivek Chopra, David A. Chappell, Betty
Harvey, Marcel Noordzij, Jan Vegt, Tim McGrath,
Bruce Peat, 2001. Professional ebXML Foundations.
WROX Press Inc. 1
st
edition.
ebXML 2001. Business Process Specification Schema
v1.01. ebXML,
http://www. ebxml.org/.
ebXML, 2001. ebXML Technical Architecture
Specification v1.0.4. ebXML,
http://www.ebxml.org/.
Frank Leymann, 2001.Web Services Flow Language
(WSFL 1.0). IBM Software Group,
http://www-
3.ibm.com/software/
.
G. Ken Holman, 2000. What is XSLT? XML.com,
http://www.xml.com/.
James Clark, 1999. XSLT Transformation Version 1.0.
W3C Recommendation,
http://www.w3.org/ TR/xslt.
Jian Yang, Mike P. Papazoglou, 2000.
Interoperation
Support for Electronic Business
. Communications of
the ACM, Vol. 43, No. 6, pp.39-47.
Michael Hammer, 2001.
The Superefficient Company.
Harvard Business Review, September, pp.82-91.
Paul Fremantle, Sanjiva Weerawarana and Rania Khalaf,
2002. Enterprise Services. Communications of the
ACM, Vol. 45, No. 10, pp. 77-82.
Ravindra Krovi, Akhilesh Chandra and Balaji
Rajagopalan, 2003. Information flow parameters for
managing Organizational Processes. Communications
of the ACM, Vol. 46, No. 2, pp. 77-82.
Sambamurthy, V., Bharadwaj, A., Grover, V. 2003.
Shaping Agility through Digital Options:
Reconceptualizing the Role of Information
Technology in Contemporary Firms. MIS Quarterly,
Vol. 27, No. 2, pp. 237-263.
Satish Thatte, 2001. XLANG Web Services for Business
Process Design. Microsoft Corporation,
http://www.gotdotnet.com/team/xml_wsspecs/xlang-
c/default.htm
.
Truex, D., Baskerville, R. and Klein, H. 1999. Growing
Systems in Emergent Organizations. Communications
of the ACM, Vol. 42, No. 8, pp. 117-123.
MANAGING INFORMATION FLOW DYNAMICS WITH AGILE ENTERPRISE ARCHITECTURES
459