The phrase “Think global, act local” may be a bit overused but it encapsulates one of the biggest issues in software architecture – do you go for a local or global architecture?

At this point you may be a little vague as to what local or global architecture is, but don’t worry – everyone is in the same position. Most of the time you can tell which direction a decision moves your design – more local or more global – but the point at which it deserves the label “local” or “global” remains ill-defined.

Let’s try to be a little more concrete. As projects become more complicated increasingly there are decision points where you can select between a local or global design.

We can ignore any simple programs that are self-contained and just take in some data, do some sums and terminate. After all such programs are so simple they don’t really need a grand design - they hardly need a design at all!

The sort of projects that are interesting are the ones that work with multiple, possibly complex, data sources interacting with multiple entities and presenting fresh data to yet more entities. To be even more concrete let’s consider a simple case study.

Collecting the garbage

Suppose you need to implement a document garbage collection scheme.

Each document can be either ready to be deleted or not and the condition that determines it can either change with time or be fixed.

For example, some documents might be marked for deletion by the user; others might need to satisfy a complex condition such as five new versions exist and the document is six months old.

Think about how you might implement the garbage collector.

I hope you can see at once that your first major architectural decision is one of those critical decision points that select for either a local or global design. This is a critical decision because once made, even if made by accident, the decision is very difficult to un-make.

In this sense the decision determines the overall architecture and there rest comes down to decoration and furnishings!

I hope you noticed, before you started to refine your design, that you really do have a choice.

You can opt to use a central database to record the details of the documents or you can record the details along with the documents as metadata.

At the current state of technology it is worth observing that local versus global often does reduce to database or central "silo" versus distributed metadata.

To be clear, you could set up a database that records the file’s location and an indicator of its state or you could store the state information about the file as part of its metadata, i.e. store the state either in or “alongside” the file in some way. Exactly how this is done is important because the association between the metadata and file should make them effectively a single entity.

What is local and what is global does depend on where you draw the system boundaries and is one of the reason why the problem doesn’t arise if you consider only small projects. For example, in the storing of the state of a single file the global/local issue hardly arises - you simply get on with the job and do it.

In this case, however, the example serves to highlight a slightly different point and a better usage of the terminology. You really shouldn’t think of a solution as being just global or local.

You should, returning to the well worn expression, always think global and, wherever possible, act local. 

You need to implement a database of global garbage collection status but you should store the data locally in each file rather than collect it together into a single database. What could be a better example of global thinking and local action.

In this sense the metadata solution is a local action implementing a global objective and the database is a global action doing the same job.

Pros and cons

So what are the advantages and disadvantages of each approach?

The database storage solution has the apparently huge advantage that it is efficient. You don’t have to search for the documents that are potential candidates for garbage collection.

All you have to do is scan the list of documents, evaluate their associated conditions and, if appropriate, delete the document.

Compare this to the global-thinking/local-action approach. In this case you have to search the entire file system to locate documents that have garbage collection conditions in their metadata, evaluate the conditions and delete the document if appropriate.

This sounds terrible!

<ASIN:0470167742>

<ASIN:0321112296>

<ASIN:0321357485>

<ASIN:0321154959>

<ASIN:059652269X>

<ASIN:0321127420>

<ASIN:0201775948>