Architecture

When and why do you need an architecture?

If you are going to build something small or even medium in size, you can just wing it. Small stuff requires little architecture and medium systems most often crystallize along some crude architectural lines without much intervention. If you are going to build something large and you start without an architecture, what you will wind up with is a large series of disconnected and/or overlapping pieces that are impossible to stabilize. The project will die.

So what is an architecture?

In its most simplest explanation it is the overall organization of the underlying sections of code. For something to be ‘organized’ that means that there are a series of rules which categorize a specific layer to a ‘reasonable’ number of sub-pieces. Most often I prefer to refer to these as ‘lines’ and to leave the number of layers to be relative to the problem. An unreasonable number of categories is somewhat dependant, but lower numbers like 3 or 5 are nice, while larger ones like 20 or 30 are problematic.

How does one describe an architecture?

Like any good blueprint, an architectural description is a top-down listing of the lines and the layers. But since there are essentially two dimensions to an architecture there need to be two main roots to the design. The first is the underlying data in the system, while the second is the way the code is constructed to manipulate this data.

A top-down view of the data is essentially a hierarchical structure, starting with the major entities and gradually breaking them down into the details. The overall organization however needs be contained within a reasonable number of categories at each layer, so the major entities are most likely collected into a smaller set of categories at an abstract layer. That ‘organizational’ constraint flows all of the way down to the details. The data itself often cross-references other entities, but it does so internally (as data), thus it often be arranged in a hierarchy.

For the code the situation is similar. A hierarchical structure of categorizations forms the basis, however code is a little more difficult. To avoid redundancies many well-defined parts of the system will be shared at many layers, so here a hierarchy really fails to capture the expressive requirements of a well-designed system. Thus, although there is a root (a place to start), the lines in the code form a graph of categorizations, although these should still be presented as well-organized layers (unwinding this is part of the challenge).

So overall a well-documented architecture has two main sections that each descend down into the details. At each layer, there are a reasonable number of sub-pieces that are either specific or abstract (if necessary to be reasonable). A group of programmers should be able to walk their way through both parts of the document and use all of the contained information to solve all of the final coding-level problems.

If all is going according to plan, they still have significant problems to work on but all of the external decisions have been resolved and they understand how their individual pieces will interact with each other.

How does one create an architecture?

A software system needs a well-defined problem to solve. The underlying details, driven by this problem, come from analysis of the solution, which identifies the required data and the algorithms to operate on the data. There may also be analysis into the operation environment for the system and possibly the development environment as well. All of these details need to be sorted and arranged, then finally organized into layers. Although the final architecture is top-down, assembling the pieces in a bottom-up manner is often simpler and produces less redundancies. Generalization and abstraction are key to reducing the effort and getting it presentable. The architecture is ready when it’s depth matches the programming team’s capabilities.

Five Years

It seemed so long ago when I first starting blogging. A number of other writers had reached the five-year mark in their blogs and I can remember being very impressed. “There is no way I’ll be blogging for that long,” I thought to myself. Five years is both a very long time and a brief instance in one’s life, it is funny how time can seem so contradictory.

Five years actually came last year -- I had blogged a full year at another site before I switched over to Blogger and renamed the blog. At that time I was contemplating the type of post I should write. Should it be funny? I’ve never been able to get my sense of humor to come out correctly in writing (I am actually funny, it just doesn’t translate well). Should I write another of those rants on the ills of the software industry? We’re an immature industry, which drives me nuts, but there doesn’t seem to be much on the near horizon to be able to change that. Perhaps I should reflect on the sorry state of discussions on the Internet? Rude, stupid and mean often combine to interrupt the necessary flow of communication, but I do have a sense that slowly that is breaking; that once all of the newness diminishes, we may actually get down to sorting out the mess our world has become. So what then?

I took up writing because I tried to write a book but then soon realized that I had no real understanding of how to communicate my thoughts in ways that were readable. I had managed to get well into my late thirties without writing anything more than a few pages. I had always known that you don’t really understand something until you can explain it to others, and that verbal conversations doesn’t really allow for you to go deep into a body of knowledge. After a rather productive period back then, I had acquired a new sense of how to build things, but still lacked the ability to share that knowledge. So off I went, continuously stumbling, in the hopes that I could somehow make a difference.

These days I’m no longer so keen on changing our industry. I tend to write for myself, to clarify my own perspectives and to help me tie together the vast stream of loose ends I’ve accumulated over a long, and sometimes painful career. That leads me towards my interests, whether or not they are popular or desired, but I am happier now with what I am saying and slowly I think I’ve managed to improve the way I am saying it. Writing in this fashion is an excellent way to learn to clarify one’s knowledge and I’d easily recommend that more people pursue it. Fame and fortune won’t be yours, but there is a tremendous amount of growth and satisfaction that come from being able to see how you are progressing in your pursuit of wisdom. We only get better as when we acquire more knowledge, and it is far tougher to turn a stream of facts into really deep understanding than most people realize. Maybe when I get to my ten-year post I’ll have something more enlightening to share ...