Home > Service-Orientation
in the Real World > Life Before Service-Orientation (Part II)
|
...continued from previous page
The aforementioned characteristics of traditional solution delivery provide a good indication as to why this approach has been so popular. Despite its acceptance, though, it has become evident that there is still lots of room for improvement.
It Can be Highly Wasteful
The creation of new solution logic in a given enterprise commonly results in a significant amount of redundant functionality. The effort and expense required to construct this logic is therefore also redundant.
It’s Not as Efficient as it Appears
Because of the tactical focus on delivering solutions for specific process requirements, the scope of development projects is highly targeted. Therefore, there is the constant perception that business requirements will be fulfilled at the earliest possible time. However, by continually building and rebuilding logic that already exists elsewhere, the process is not as efficient as it could be if the creation of redundant logic could be avoided.
It Bloats an Enterprise
Each new or extended application adds to the bulk of an IT environment’s system inventory. The ever-expanding hosting, maintenance, and administration demands can inflate an IT department in budget, resources, and size to the extent that IT becomes a significant drain on the overall organization.
Figure: This simple diagram portrays an enterprise environment containing applications with redundant functionality. The net effect is a larger enterprise.
It Can Result in Complex Infrastructures and Convoluted Enterprise Architectures
Having to host numerous applications built from different generations of technologies and perhaps even different technology platforms often requires that each will impose unique architectural requirements. The disparity across these “siloed” applications can lead to a counter-federated environment, making it challenging to plan the evolution of an enterprise and scale its infrastructure in response to that evolution.
Figure: Different application environments within the same enterprise can introduce incompatible runtime platforms as indicated by the shaded zones.
Integration Becomes a Constant Challenge.
Applications built only with the automation of specific business processes in mind are generally not designed to accommodate other interoperability requirements. Making these types of applications share data at some later point results in a jungle of convoluted integration architectures held together mostly through point-to-point patchwork or requiring the introduction of large middleware layers.
Figure: A vendor diverse enterprise can introduce a variety of integration challenges, as expressed by the little lightning bolts that highlight points of concern when trying to bridge proprietary environments.
|
