<<Everything is moving toward on-demand business where service providers react to impulses - events - from the environment. To excel in a competitive market, a high level of autonomy is required, including the freedom to select the appropriate supporting systems. This magnified degree of separation creates a need for agility, a loose coupling between services so as to support continuous, unimpeded augmentation of business processes in response to the changing composition of the organizational structure.
To achieve "true" agility the supporting applications must be agnostic to organizational changes like reshuffling responsibilities and roles, out-sourcing or in-sourcing, the splitting up or consolidation of departments, and all kinds of other reorganizations. Furthermore, the agility of business processes to follow organizational changes must not be limited by the IT systems that support them. All of these requirements are accommodated by loose coupling. Services with reduced coupling are more easily able to "take the scissors" to the organizational structure without disturbing the continuity of the supporting IT systems. This is the basis of organizational agility. Agility in application construction can be achieved by using shareable services in a well-defined functional boundary. Standards-based technology can also contribute to agility by addressing time-to-market concerns for the delivery of applications (as long as the standards are mature and adequate tools are used). Much of this ties into the ability to carry out a more agile restructuring of applications in support of business process redesign. The ultimate result is lower IT costs for the business and faster project delivery cycles. Both EDA and SOA promise to increase agility on an organization level, but each goes about this in a in different way. EDA in Relation to SOA Though EDA and SOA share common goals, how do we know when to utilize event-driven and service-oriented approaches? Let's take a closer look at when each architectural style is most appropriate. Unlike traditional distributed architectures, EDA does not advocate synchronous command-and-control type of exchange pattern. Instead, it is based on the asynchronous publish-and-subscribe pattern, where the publisher is completely unaware of the subscriber and vice versa; services are loosely coupled in the sense that they only share the semantics of the message. If you are seeking to support independence between business process steps, EDA can provide significant benefit, especially in federated and autonomous processing environments. Recognizable situations where EDA might be applicable are: Horizontal communication between tiers in a process chain. Processes that cross recognizable functional organization borders (internal and external). Processes that cross physical organizational boundaries. However, when looking to apply strong cohesion in business processes, SOA can provide significant benefit. This is generally suitable in the following situations: Vertical interaction between hierarchical layers of functional decomposition. Functional request-and-response processes, such as man-machine dialogues where the user waits for an answer. Processes with a transactional nature which require commit and rollback facilities. Like EDA, SOA is frequently implemented with a messaging framework that can therefore also leverage asynchronous message patterns to implement request-and-reply communication. This allows for loose coupling by separating the issuer of the request from the consumer of the reply as well as separating the consumer of the request and issuer of the reply. However, due to the common misperception that an SOA is synonymous with a (still tightly-coupled) RPC-style architecture that happens to use Web services, there are many implementations in which traditional, synchronous exchange patterns are still deeply engrained. To establish an environment wherein SOA and EDA can harmoniously co-exist, some up-front analysis is required. Here are some suggested, preparatory steps: 1. Model business requirements into functions at the granularity level of the desired autonomy. 2. Outline the application landscape to identify all affected systems. 3. Map the application landscape to the business function model. 4. Identify applications that cross functional borders as potential "agility bottlenecks" (assign a special high priority to those applications that are required to cross external organization borders). Step 4 forms the basis for the decoupled service boundaries further described in the upcoming section. It is this cross-boundary communication that we are very interested in when looking to position the EDA publish-and-subscribe patterns as a means of connecting these boundaries while allowing them to maintain their decoupled state. Carrying out a simple process, such as this, can lay the groundwork for introducing an extent of loose coupling and establishes a good starting point for moving a technology landscape toward a modern, flexible and adaptable environment capable of leveraging both SOA and EDA together. Loose Coupling and "Points of Decoupling" Loose coupling means independence. Loosely coupled services have less dependency on each other than tightly coupled ones. This applies to both functionality and data. The level of coupling between services can be potentially increased (tightened) if data associated with a given service is isolated to that service's implementation boundary only. This design approach essentially increases the chances that other services will form dependencies on each other in order to access the isolated data. Coupling levels between services can be decreased (loosened) if data redundancy is allowed via established mechanisms such as replication, avoiding any kind of shared layers other than shared layers for transport and semantic harmonization. Maintaining data redundancy across the decoupling borders makes loose coupling more robust. EDA is suitable in this type of environment, as it can support automatic data synchronization mechanisms in redundant environments. When working with SOA and EDA, it is furthermore helpful to find "points of decoupling" by looking for parts of the business process where you are sure they always will stay together in one organizational unit (strong cohesion and atomic business functions). In this way a functional composition of the business will become visible. The borderlines between the business functions are the points of decoupling. If atomic transactions cross decoupling borders, then compensating rollback transactions can be implemented at these at these decoupling points.>> You can read this in full at: http://www.soamag.com/I4/0207-2.asp Gervas
