The 4 Aspects of Every Application: Part - I

Application Point of View

I think nearly every software application project can be thought of as having the following 4 aspects: Business, Process, Maintenance, and Infrastructure. How you design your application has a lot to do with your point of view and which aspect you think should get the most emphasis. A common mistake is to view every application from the same point of view and thus one aspect gets the most emphasis every time. The aspect you give the most emphasis to will obviously affect every facet of your design including your object designs.

Business: This is code concerned with applying business rules and logic to determine what needs to happen in a given situation.

The result is a business-oriented application, one where the most effort is in making sure the business is correctly modeled and understood. This emphasis is valid for the common business application where a developer is trying to mimic a business as described by a business expert. A telltale sign of a design effort that is focusing on the business is that the main artifacts of design are business object models. Often the first thing designed is a rough sketch of the business entities represented as classes.

Process: This is code that implements a process which when completed accomplishes a required goal.

The result is often, as the name implies, procedural code. Or at best, the result is an object-based design where objects are used to hold data, but all the "thinking" code is in the process routines, not the objects.

Maintenance: This is code for the direct creation, changing and deleting of things in the application.

The result is generally a data-centric application where the business is viewed as just adding, removing and changing data in a system. A telltale sign of a maintenance application is when the design effort begins with designing database tables. From the very beginning the emphasis is off the business and geared towards the data instead. This kind of emphasis is valid for applications where truly the creating and changing of data is the primary focus. For example, something like a contact management application or some sort of activity logging application lends itself to a maintenance-focused application.

Infrastructure: This is code that is a result of the simple fact that we are writing software. Examples include code that maps objects to data and vice versa, security and logging for auditing purposes.

The result is often an application that does not model a business but rather reflects the implementation of the requirements. Often the goal of the developers in this case is to achieve something technically difficult. This kind of focus is valid for something like grid computing tools, framework libraries, etc. The business of the application is often technical in nature.

So what’s the point exactly?

A common mistake is to approach every application with the same emphasis in mind. I have found the most common mistake when designing the common business application is to design the application like it is a database-babysitting application.  In other words, the whole application is approached as if the business is all about Maintenance. The actual business logic is lost in the shuffle between inserts and updates. Furthermore, I think because business applications lose their business focus, developers who are intrigued with an object-oriented solution can't figure out exactly how to apply those OO principles to the multifaceted world of the common business application.