Creating an Architecture

A software architecture begins as the result of the collective set of design choices made by the team that created the very first version of a system. These early beginnings, which might be sketches on a whiteboard or diagrams created in a notebook (or on a napkin), represent the intentions of this first development team. When the system is finished, these sketches may not represent reality, and often the only way the architecture can be explained is through a retrospective analysis that updates these initial designs to the delivered reality.

The initial version of a software architecture can be like a young child: whole and complete but immature and perhaps a bit unsteady. Over time, and through continued use and multiple release cycles, the architecture matures and solidifies, as both its users and its creators gain confidence in its capabilities while they understand and manage its limitations. The process is characterized by a commitment to obtaining honest feedback and responding to it by making the changes necessary for success. Of course, an immature architecture can remain immature and/or stagnate altogether without feedback. The biggest determinant is usually the market.

I've been fortunate to have been part of creating several new product architectures from scratch, and I've learned that the way architecture is actually created is a bit different from the recommendations of many books. These books tell us that when the system is completely new and the problem terrain is somewhat unfamiliar, designers should, for example, "explore alternative architectures to see what works best." This is sensible advice. It is also virtually useless.

There are many reasons that this advice is useless, but three of them dominate. Any one can be strong enough to prevent the exploration of alternatives, but all three are usually present at the same time, each working in its own way, sometimes in conjunction with the others, to motivate a different and more pragmatic approach to creating a software architecture. These forces are not "bad"they just are.

The first force is the lack of time in a commercial endeavor to truly explore alternatives. Time really is money, and unless the first version is an utter disaster, the team will almost certainly need to ship the result. They won't be able to wait! The strength of this force usually results in hiring practices that demand that the "architect" of the initial system have sufficient experience to make the right decisions without having to explore alternatives. In other words, hire someone who has already explored alternatives in a different job.

The second force, and one that is considerably stronger than the first, is the nature of the problem and its surrounding context, which dictate a relatively small set of sensible architectural choices. A high-volume, high-speed, Web site is going to have a relatively standard architecture. An operating system will have a slightly different but no less "standard" architecture. There probably isn't a lot of value in exploring radically different high-level architectures, although there is often some use in exploring alternatives for smaller, more focused, portions of it. These explorations should be guided by the true risks facing the project, and should be carefully designed to resolve them.

When You Know It's Going to Fail

As you gain experience with different architectures, you can sometimes spot disastrous architectural choices before they are implemented. Then you can either kill the proposed architecture and send the design team back to the drawing board or kill the project. Killing the project may seem a bit drastic, but sometimes this is required, especially when poor choices substantially change the new system's economic projections.

In one assignment, the engineering team decided that a full J2EE implementation was needed for a problem that a few dozen Perl scripts could have easily handledif another part of the application was also modified. In a classic case of " resum -driven design," the technical lead, who fancied himself an architect, managed to convince several key people in both development and product management that the J2EE implementation was the best choice. The architecture was also beset with a number of tragically flawed assumptions. My personal favorite was that CD-ROM images of up to 600Mb of data were expected to be e-mailed as attachments! In the end I became convinced that there was nothing to salvage and ultimately killed both the architecture and the project. We simply could not create and release the desired product within the necessary market window (that period of time when a product is most likely to find a receptive customer).

The third, and strongest force, is architectural "goodness," which can only be explored through actual use of the system. Until you put the architecture into the situation it was nominally designed to handle, you don't really know if it is the right one or even if it is a good one. This process takes time, usually many years .

Beyond Software Architecture[c] Creating and Sustaining Winning Solutions
Beyond Software Architecture[c] Creating and Sustaining Winning Solutions
ISBN: 201775948
Year: 2005
Pages: 202 © 2008-2017.
If you may any questions please contact us: