Initial steps in application design

One of the keys to building large-scale, high-volume applications is to apply the concepts of scalability and extensibility at every level within its design. Determining where and how these concepts apply - where they make sense and where they are overkill - is an inexact exercise. The approach I use is to imagine the best-case deployment scenario for a given application - what would the application look like technically if my grandest hopes of success were realized? With that picture in mind, then look for areas within that design that can be sized down in terms of cost, effort and development time in ways that are “forward compatible” with the ultimate business goals for the application.

The term “forward compatibility” became a short-lived buzzword a few years ago, but it is one that I continue to use regularly. To me, it means, “can I build an abbreviated version of my grandest design in a way that allows it to be progressively enhanced (not rewritten) until it finally evolves into what I wanted it to be from the beginning?”

In large scale applications, a few fundamental concerns are always present; security, volume, stability, performance, maintainability, availability, scalability, enhanceability, data integrity, to name a few. When we think about forward compatibility, each of these elements becomes a lens through which we can begin to visualize what a fully idealized system must look like.

Various techniques can be leveraged to isolate components within a system, allowing a loosely coupled, distributed solution to be created from relatively free-standing modules that are very tolerant of changes that may occur within other modules, with added benefits in terms of reuse, maintainability and availability. This approach is broadly categorized as SOA, or a Service Oriented Architecture.

Part of this involves defining a business object model that is shared across multiple components (maybe all) within a system, which becomes the common language of that system. In other words, each object within the model is a "noun" that, when taken together, constitutes a common vocabulary that is shared and understood by all components. These include things like customer, or order, or product.

Once this model is defined, it becomes the virtual heart of the system. All other aspects of the application are then simply mechanisms that support the ability to pose and answer questions expressed in terms of that model. From a logical standpoint, everything from persistence to presentation are expressions of the model in various forms.

It is important to note that just as a given model object may be represented in vastly different ways depending on context, the database model is not the truest representation of a “business” model object. The database model is simply an expression of the business model in persisted form, usually including attributes that are relevant only in terms of persistence. For this reason, I recommend attempting to capture the complete business model in technology-agnostic terms before attempting to visualize it in the form of a relational database schema, or even a NoSql schema. This is important because, thinking again of the idealized system, it is likely that much of this data - especially if the system has social underpinnings -  will not be well suited to relational persistence.

Another reason this point is more than academic is that a properly defined system also allows data to be shared in technology-agnostic ways. This allows potential consumers of application data to “think” of model data without concern for the inner workings of the system that hosts it. Given the likelihood that a completed solution will include mobile applications (iPhone, iPad, Android, Windows Surface, etc), a pure business model is even more desirable. It is a step towards an open, fluid system that becomes more characterized by the concepts it embodies than the specific features it may support at any point in time.

New Blog

Thanks for visiting. I've just started this blog, which will focus primarily on enterprise software technology. I have been an enterprise Java developer and architect for many years, and have decided to begin sharing some of the useful information I've found, for what I hope to be the general benefit of other developers.

I do keep another blog as well, which is more general and personal in nature; meaning, it contains rants of debatable value on a range of topics.