Technical architects have long understood the benefits of architectural laying within an application to reduce coupling, increase modularity and maintainability, etc. Typically, that layering looks something like:
However, as IT strategists we must also recognize the benefits of layering when it comes to looking across applications. After all, most organizations (including Storeroom Solutions) rely upon a large number of applications to perform its responsibilities. Most of these applications were assembled over the years based upon the requirements and business strategy at that time. Rarely do enterprises have the opportunity to build everything at once (oh my, how I miss the dot-com days when it seemed everything was green field). The same way layering within an application can improve modularity and maintainability, layering of applications can increase business flexibility without spiraling increases in complexity and cost.
Say, for example, a service provider offers an application that it has developed over the years to perform procurement and inventory management functions for clients. It has proven to be a real competitive advantage, especially for those seeking a turn-key solution. The application has also proven to be relatively low maintenance and trouble free. It looks like this:
Alas, times change and the number of new clients seeking a turn-key solution starts to dwindle. Fortunately, the company has developed some real expertise in its procurement capabilities that are attractive to an entirely new segment of the market. This segment already owns an inventory management application but wishes to tap into the advanced procurement features offered in this application. The company is faced with a challenge. Because application layering wasn’t considered in the original design, separating the functionality is a problem. In order to overcome these challenges, the company must aggressively re-factor its procurement/purchasing functions to allow inputs from a source other than its embedded inventory application. In fact, it may be easier to re-write the procurement application, leveraging the existing business rules. The new application topology may look something like this:
What is this advantage of this approach? In this case, this application layering approach allows for new business opportunities that would have otherwise been difficult to serve. Furthermore, by employing SOA concepts and maintaining a disciplined API in its procurement application, the company can keep maintenance manageable. After all, its internal inventory application could use the same API as the external inventory application to communicate!
Downsides? It is is easy to gloss over the downsides but they are rarely greater than the benefits of moving to this layered application approach. One practical downside is the complexity that could be introduced to some users due to the new architecture. For example, if users were accustomed to a single application with an identical look and feel they may be exposed to a little more variation due to the new modular approach. However, even this can be managed through Single Sign On technology and common libraries and standards between the teams responsible for maintain their respective applications.
While this approach may seem to be a “no-brainer”, I continue to encounter architectures where little, if any, emphasis is placed on “application layering”. Hopefully, more architects and CIO/CTO’s will start to place greater value on the benefits of this approach.
