Taking control of your application development – pit of success

This series of posts was long in coming and today seems like a good day to start it.
Over the last few years I’ve had a few conversations about structuring an application and found that while there’s a solid body of knowledge and proven practices available people don’t care much about it or misinterpret it. From what I’ve seen, coming up with the structure as you go or creating a superficial one leads to fast take off, but slow progress, the pace that gets slower all the time.
I’m not talking about heavy investment in infrastructure or design upfront. You will make adjustments, but having a good start is like digging a Pit of Success. Your developers can’t help, but fall into one.
In most abstract terms what it comes down to is planning the tiers and… here it comes… layers, if any, your application will have.
The most obvious practical aspects are:
– What processes you’ll run,
– Where will they run,
– What your dependency graph for each process should look like.
Obviously all of it highly depends on the requirements; however the software industry in general through trial and error seems to have settled on certain ways of dealing with certain class of problems. Fowler calls those Patterns of Enterprise Application Architecture.
Here’s the default layered architecture according to Fowler:




Provision of services, display of information (e.g., in Windows or HTML, handling of user request (mouse clicks, keyboard hits), HTTP requests, command-line invocations, batch API)


Logic that is the real point of the system

Data Source

Communication with databases, messaging systems, transaction managers, other packages

He makes a distinction between layers and tiers here, because a lot of people confuse the two. Essentially, by Data Source we mean a bunch of our abstractions (classes, interfaces, etc) that talk to the database and other systems. It does not include the database itself. That’s another tier – one that might or may not happen to be running on the same machine, but we consider it separate.
The distinction is important because we’re defining the application boundaries. For example in a client-server application, what we really have is 2 applications with their own boundaries and the choices of layering should be made separately for the two.
There might be a sharp learning curve in learning the concepts, but all the tools to implement the infrastructure for common set of problems already exists and available in a number of flavours.
Traditionally tools drove the approach to the solution, but I believe the tools are just means to an end. Let’s start with “What do we want our solution to look like?” this time around. Read about the quality attributes I quote from Patterns of Software by Richard P Gabriel. I think everyone would like to see those quality attributes in their application. What can we do from the start?
Tune in later for the second part, where I’ll go over the language (abstractions) the layers might want to talk in and what my preferred dependency graph looks like.
Taking control of your application development – pit of success

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s