Loose Coupling and On Demand Businesses

Loose Coupling and “On Demand” Businesses tend to change their structures quite often. This trend has been enforced by the ongoing focus on globalization and service orientation. Today’s business world is undergoing preparation for independent autonomous service providers as well as service consumers.

Many parts of the business process have begun to be outsourced to external partners. Business units and departments are then transferred to service providers. Such service providers do not merely focus on the internal workings of the business, but external markets for which they may offer their services.

Indeed, everything in today’s business environment seems to be moving towards an “on demand” business structure, wherein service providers are compelled to react to events from within the environment.

In order to do well in a competitive market, a high level of autonomy must be maintained. This should include the freedom to select the right supporting IT systems. There is an increasing degree of separation that creates a vital need for loose coupling to take place among application components. This enables the supported business processes to bend with the continuously changing nature of the business structure.

As a means of attaining such agility, the supporting applications have to be agnostic to organizational changes such as the reshuffling of roles and responsibilities, in sourcing and outsourcing, the division of the departments or the entire company, fusions and all sorts of other reorganizations.

Business processes should not be limited buy supporting Information Technology systems. The business processes should smoothly follow all business changes. If, for example, part of the process is outsourced to an external partner, then part of the supporting Information Technology system winds up getting cut off. The system’s remaining parts should start then communicating with the outside partner. The system should not be allowed to collapse. It is also undesirable for an adaptation to a new situation to cost a lot of time and money. This should be prevented at all costs.

Can Service Oriented Architecture live up to the hype?

Loosely coupled application parts should be able to readily put the scissors right in to the structure of the business without disrupting supporting Information Technology systems. At the same time, the synchronous command and control nature of Service Oriented Architecture is one method of tightly coupling application components that do not allow for such a wide degree of flexibility.

Service Oriented Architecture can be loosely coupled in the technical domain, where common web services technology is utilized, but it is not really in the functional domain where Service Oriented Architecture may be associate with calling foreign services and thus eliminating the redundancies of data.

The availability of stored data and services might be made to disappear after an act of outsourcing, which might lead to costly consequences and major risks. All this has to do with the creation of dependencies via Service Oriented Architecture. So in a way, Service Oriented Architecture’s promise of delivering loose coupling, which tends to be asynchronous, can at the functional level be regarded as hype.

Information Technology Flexibility vs. Organizational Flexibility.

Of course the utilization of Service Oriented Architecture does have its benefits. The restructuring of an application in following the business process of redesign can be very beneficial. The Information Technology department can also benefit from this. It will lead, in the end, to lower Information Technology costs for the business side, as well as delivery at a faster rate.

Right now, Service Oriented Architecture’s position in the market is that of a mainly command and control type architecture at the highest granularity levels of functional decomposition. In order to attain both loose coupling and autonomy within the context of the previously mentioned organizational evolutions, event driven architecture can be regarded as a more apt style of architecture at the current level of granularity.

Event Driven Architecture provides flexibility directly to the business itself. With Event Driven Architecture, a business is able to reorganize without affection the construction of an application. Event Driven Architecture assures that a change can be made to the structure of a business without altering the applications.

Granularity

Why, then, is Service Oriented Architecture promoted at such a level of granularity? In charge is the causality of four aspects. First off, Service Oriented Architecture tends to be considered in terms of web services. Secondly, web services technology on the performance level is currently inappropriate at the lower levels of granularity. Third, web services come from request and reply patterns; thus, they tend to be associated with command and control solutions. Finally, event driven models are not well known – people only look for solutions in more commonly known domains.

It is an unfortunate fact that the command and control pattern is inappropriate at this level. Service Oriented Architecture can be a good idea in the middle layers of functional composition when it is based on synchronous web services. In those situations, the command and control type of interaction will typically be required, and may in fact be in good balance with the performance of web services.

TrackBack URI for this entry

Comments (1)

Subscribe to this comment's feed

Show/Hide comments

Show/Hide comment form