Flexible, Scalable Software Amid Constant Change

Chris HolmokIn the ever changing landscape of product requirements, infrastructure changes, and good old bug squashing, developers can be caught in the trap of maintaining software rather than improving it. As most developers know, it is hard to design and implement software against a moving target. For quite some time larger applications have been built on the n-tier, or multitier, design (see figure-1).

Figure 1

Multi-Tier design diagram.

This approach solved many problems and made software more scalable and flexible. It makes small changes in different tiers or layers easier to manage.

Multi-tier design works well until a sweeping change becomes necessary. By sweeping changes I mean when a company switches from SQL Server to Oracle, or a partner completely drops its WebService API and replaces it with a RESTful API. These changes happen, and can be traumatic experiences for developers working in the middle tier. The entire – or at least a good portion – of the business layer has to be rewritten. Ugh!

Enter the “Provider Pattern” (a.k.a. Abstract Factory Pattern). The provider pattern allows a layer of abstraction between the business logic and storage/integration points (see figure-2).

Figure 1

Abstract Factory Pattern diagram.

Think of them in the following analogy: device drivers are for hardware what providers are for software.

As developers deal with changing requirements and growing business needs, we may not be able to write one, perfect system that answers every issue and requirement every time. But, we can create a multilayer collection of systems that work together and can adapt and scale as changes and requirements arise, sometimes even before they even happen.


Get every new post delivered to your Inbox.

%d bloggers like this: