I like reading about software because often a writer will attach a descriptive name to a familiar concept or describe it in a new and interesting way. This week’s software engineering lectures and readings in Software Architecture in Practice brought up several such names and descriptions that stuck with me.
Architecture as Early Decisions
The early chapters in the book echoed the class discussion about the definition(s) of software architecture. Its main definition says the following:
The software architecture of a program or computing system is the structure of structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships between them.
This is as good a definition as any, but it did not ring as true in my mind as a passage that appeared several pages later in the book:
Software architecture represents a system’s earliest set of design decisions. These early decisions are the most difficult to get correct and the hardest to change later in the development process, and they have the most far-reaching effects.
The second definition emphasizes the thought process behind an architecture; the first describes any system whether or not any thought was put into building it. Granted, a bad architecture is still an architecture, but I prefer to focus on the good ones—those that made the right decisions early on.
Professor Johnson paraphrased this idea in class today when he said, “Architecture is the stuff you wished you did right in the beginning.”
Transaction Scripts
I am sure all programmers have encountered a particular style of programming that seems to willfully ignore object-oriented programming practices. Rather than encapsulate behavior in classes and split an application into well-defined modules or layers, a programmer will instead make many monolithic functions that probably contain SQL directly in the code. This style may work well on small applications—I am certainly guilty of using it—but it breaks down as common functionality is duplicated and bugs appear.
Tuesday’s lecture described these types of programs as “transaction scripts”. This term is much more descriptive than “procedural-style programs” and easier to say than “non-object-oriented programs”.
Software Business Cycle
A common theme in the early lectures and the first chapter of the book involved the interaction between the architecture of a system and the organization that develops the system. For example, an organization that implements a client-server architecture will probably have two teams: a client development team and a server development team. That is, the module divisions in an architecture will usually define the divisions in an organization.
Obviously, the influence can travel in the opposite direction as well. The people and expertise in an organization will affect the final architecture. For example, a group of PHP/MySQL experts will probably not design an architecture around .NET and Microsoft SQL (though a good architecture may not even specify the implementation language or database).
The book calls this interaction the “Software Business Cycle”. It is a good thing to keep in mind for when I eventually enter industry, and something that I have been insulated from in my previous programming jobs.
Unrelated
I found it interesting that with a quick search on Getty Images’ website I was able to find the original picture that the book publishers chose for the cover of the book. It seems like an odd, random choice. Why is a person standing alone in the entryway at night? Why did the publishers crop out the fountain, leaving what appears to be a strange discoloration in the sky?