Process orientation in general and business process management in particular
are parts of a larger development that has been affecting the design of
information systems since its beginning: the evolution of enterprise systems
architectures.
Enterprise systems architectures are mainly composed of information systems.
These systems can be distinguished from software systems in the area
of embedded computing that control physical devices such as mobile phones,
cars, or airplanes. Business process management mainly deals with information
systems in the context of enterprise systems architectures.
The guiding principle of this evolution is 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.
While this principle has many applications in theoretical and applied computer
science, in the context of software systems design�and therefore also in
information systems design�it means identifying sets of related functionality
and packaging them in a subsystem with clearly identified responsibilities and
interfaces. Using this approach, complex and powerful software systems can
be engineered. 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 flexibility of software systems, because
individual subsystems can be modified or even exchanged with another subsystem
providing the same functionality without changing other parts of the
system�provided the interfaces remain stable.
Since local changes do not affect the overall system, a second guiding principle
of computer science is realized: information hiding, originally introduced
by David Parnas. Reasons for changes can be manifold: new requirements in
an ever-changing dynamic market environment, changes in technology, and
changes in legal regulations that need to be reflected in software systems.
While effective response to change is an important goal of any software system,
it is of particular relevance to business process management systems, as
will be detailed below.
Before addressing the evolution of enterprise systems architectures, the
understanding of software architectures as used in this book is described. In
general, software architectures play a central role in handling the complexity
of software systems.
Tuesday, September 1, 2009
Goals, Structure, and Organization in business management:
Arguably, the most important goal of business process management is a
better understanding of the operations a company performs and their relationships.
The explicit representation of business processes is the core concept
to achieving this better understanding.
Identifying the activities and their relationships and representing them
by business process models allows stakeholders to communicate about these
processes in an efficient and effective manner. Using business process models
as common communication artefacts, business processes can be analyzed, and
potentials for improving them can be developed.
Flexibility�the ability to change�is the key operational goal of business
process management. The subjects of change are diverse. Business process
management not only supports changing the organizational environment of
the business process, but also facilitates changes in the software layer without
changing the overall business process. Flexibility in business process management
is discussed in detail in Section 3.10.
A repository of the business processes that a company performs is an
important asset. To some extent, it captures knowledge of how the company
performs its business. Therefore, business process models can be regarded as
a means to expressing knowledge of the operation of a company.
But business process management also facilitates continuous process improvement.
The idea is to evolutionarily improve the organization of work
a company performs. Explicit representations of business processes are well
suited for identifying potentials for improvement, but they can also be used
to compare actual cases with the specified process models. While in principle
more radical business process reengineering activities can also be supported
by business processes, evolutionary measures to improve business processes
might in many cases be the favourable solution.
Business process management also aims at narrowing the gap between
business processes that a company performs and the realization of these processes
in software. The vision is that there is a precisely specified relationship
between an activity in the business process layer and its realization in software.
A metamodel is used to specify the semantics
of control flow patterns. An important part of this book deals with process
modelling techniques and notations. The most important ones are discussed in
a concise manner, including Petri nets, event-driven process chains, workflow
nets, Yet Another Workflow Language, a graph-based workflow language, and
the Business Process Modeling Notation.
better understanding of the operations a company performs and their relationships.
The explicit representation of business processes is the core concept
to achieving this better understanding.
Identifying the activities and their relationships and representing them
by business process models allows stakeholders to communicate about these
processes in an efficient and effective manner. Using business process models
as common communication artefacts, business processes can be analyzed, and
potentials for improving them can be developed.
Flexibility�the ability to change�is the key operational goal of business
process management. The subjects of change are diverse. Business process
management not only supports changing the organizational environment of
the business process, but also facilitates changes in the software layer without
changing the overall business process. Flexibility in business process management
is discussed in detail in Section 3.10.
A repository of the business processes that a company performs is an
important asset. To some extent, it captures knowledge of how the company
performs its business. Therefore, business process models can be regarded as
a means to expressing knowledge of the operation of a company.
But business process management also facilitates continuous process improvement.
The idea is to evolutionarily improve the organization of work
a company performs. Explicit representations of business processes are well
suited for identifying potentials for improvement, but they can also be used
to compare actual cases with the specified process models. While in principle
more radical business process reengineering activities can also be supported
by business processes, evolutionary measures to improve business processes
might in many cases be the favourable solution.
Business process management also aims at narrowing the gap between
business processes that a company performs and the realization of these processes
in software. The vision is that there is a precisely specified relationship
between an activity in the business process layer and its realization in software.
A metamodel is used to specify the semantics
of control flow patterns. An important part of this book deals with process
modelling techniques and notations. The most important ones are discussed in
a concise manner, including Petri nets, event-driven process chains, workflow
nets, Yet Another Workflow Language, a graph-based workflow language, and
the Business Process Modeling Notation.
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.
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.
Traditional Application Development:
The main goal of this section is to categorize business process management
systems from a software systems point of view into major developments that
information systems design underwent in the last decades. It depicts
the first stages in the evolution of information systems. The dates in that figure
provide only rough estimates�the respective systems architectures were not
uncommon at the dates given.
In the early days of computing, applications were developed from scratch,
without taking advantage of prior achievements other than subroutines of
fine granularity. Application programmers needed to code basic functionality
such as, for instance, access to persistent storage and memory management.
Basic functionality needed to be redeveloped in different applications, so that
application programming was a costly and inefficient endeavour. As a result
of the tight coupling of the programmed assembler code with the hardware,
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 separation of operating systems concerns
from the application. Operating systems provide programming interfaces to
functionality provided by the computer hardware. Applications can implement
functionality by using interfaces provided by the operating system, realizing
increased efficiency in system development.
Specific properties of the computer hardware could be hidden from the
application by the operating system, so that changes in the hardware could
bereflected by a modified implementation of the operating system�s interface, for
instance, by developing a new driver for a new hardware device. An operating
systems (OS) layer is depicted in as the lowest level subsystem.
systems from a software systems point of view into major developments that
information systems design underwent in the last decades. It depicts
the first stages in the evolution of information systems. The dates in that figure
provide only rough estimates�the respective systems architectures were not
uncommon at the dates given.
In the early days of computing, applications were developed from scratch,
without taking advantage of prior achievements other than subroutines of
fine granularity. Application programmers needed to code basic functionality
such as, for instance, access to persistent storage and memory management.
Basic functionality needed to be redeveloped in different applications, so that
application programming was a costly and inefficient endeavour. As a result
of the tight coupling of the programmed assembler code with the hardware,
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 separation of operating systems concerns
from the application. Operating systems provide programming interfaces to
functionality provided by the computer hardware. Applications can implement
functionality by using interfaces provided by the operating system, realizing
increased efficiency in system development.
Specific properties of the computer hardware could be hidden from the
application by the operating system, so that changes in the hardware could
bereflected by a modified implementation of the operating system�s interface, for
instance, by developing a new driver for a new hardware device. An operating
systems (OS) layer is depicted in as the lowest level subsystem.
Enterprise Application Integration in business management:
Enterprises are facing the challenge of integrating complex software systems
in a heterogeneous information technology landscape that has grown in an
evolutionary way for years, if not for decades. Most of the application systems
have been developed independently of each other, and each application stores
its data locally, either in a database system or some other data store, leading
to siloed applications.
Data heterogeneity issues occur if a logical data item�for instance, a
customer address�is stored multiple times in different siloed applications.
Assume that customer data is stored in an enterprise resource planning system
and a customer relationship management system. Although both systems use
a relational database as storage facility, the data structures will be different
and not immediately comparable.
These differences involve both the types of particular data fields (strings
of different length for attribute CustomerName), but also the names of the
attributes. In the customer example, in one system the attribute CAddr will
denote the address of the customer, while in the other system the attribute
StreetAdrC denotes the address.
The next level of heterogeneity regards the semantics of the attributes.
Assume there is an attribute Price in the product tables of two application
systems. The naming of the attribute does not indicate whether the price
includes or excludes value-added tax. 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 in enterprise application integration.
In this section, the traditional point-to-point enterprise application.
in a heterogeneous information technology landscape that has grown in an
evolutionary way for years, if not for decades. Most of the application systems
have been developed independently of each other, and each application stores
its data locally, either in a database system or some other data store, leading
to siloed applications.
Data heterogeneity issues occur if a logical data item�for instance, a
customer address�is stored multiple times in different siloed applications.
Assume that customer data is stored in an enterprise resource planning system
and a customer relationship management system. Although both systems use
a relational database as storage facility, the data structures will be different
and not immediately comparable.
These differences involve both the types of particular data fields (strings
of different length for attribute CustomerName), but also the names of the
attributes. In the customer example, in one system the attribute CAddr will
denote the address of the customer, while in the other system the attribute
StreetAdrC denotes the address.
The next level of heterogeneity regards the semantics of the attributes.
Assume there is an attribute Price in the product tables of two application
systems. The naming of the attribute does not indicate whether the price
includes or excludes value-added tax. 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 in enterprise application integration.
In this section, the traditional point-to-point enterprise application.
Enterprise Resource Planning Systems in business process management:
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,
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.
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,
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.
The hub-and-spoke paradigm is based on a centralized hub and a number of
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.
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.
Subscribe to:
Posts (Atom)