Yon were the days when the term “architect” was a much proscribed and well defined career.  Gaunt, squinty individuals hunched over drafting tables with t-squares and compasses crafted the great works of art found in today’s building infrastructure.  Today, as with many terms, the trade is watered down with the advent of electronic media, computing and other technologies.  Each self proclaimed thought leader or innovator in their field becomes an “architect” of their trade or practice.  But there are few trades that are more similar than that of software architecture and building architecture.  The kinship of Frank Lloyd Wright and Martin Fowler can be seen in the timeless designs embodied in structure and software solutions.  And it is that metaphor that I would like to explore in some detail.

As with many youth, during my college years I had the chance to be employed in a number of fields.  To this day, one of my all time favorite trades was that of a foreman on a construction crew.  We built custom homes in the Rocky Mountain area, they were beautiful.  I loved doing the work, fresh air, sun, exercise and in the end a lovely structure.  Several years later I moved to the other side of architecture and design.  It was very fascinating to see both sides of the equation firsthand and realize the liberties and constraints that each role was allowed in the process of construction.  As I look back now as an architect in software, I can see the same role distinctions and implementations.

Abstraction is a wonderful tool for an architect.  To an architect, many of the implementation details are not something they concern themselves with.  Positioning of nails and brands of power tools are something left to the skilled laborers and tradesman.  The architect rises above this.  To them, they see a design, a vision, and communicate that through specifications, drawings and other artifacts.  In fact, these very artifacts range from high level vision reminiscent of artwork all the way down to detailed exploded views of sections of the structure.  And in each levels of these specifications are detailed the measurements, materials, and relationships to other segments of the architecture.  From these, abstraction provides the flexibility to the tradesman to determine the type of tools and sometimes the brand of material to use in order to accomplish the job.  And most importantly it allows the general contractor and financier the flexibility to make pricing decisions based on cost of materials fitting the plan.  Abstraction provides the architect the ability to separate from these implementation concerns in order to accomplish a pure and robust design.

Software architecture as we will see is identical in form and function to structural architecture.  Software architects will use the same abstracted separation to create plans that are not bound to specific tools or technologies.  This allows them to create architectures unfettered by manufactured constraints not core to the architecture.  To them the details of method calls and programming languages are not essential to the architecture.  What is essential is the system as a whole, the overall functions needed and the criteria under which the system can be called complete.  The software architect also uses plans to communicate.  These, unfortunately are not in a canonical or standardized form.  They may range from a single piece of paper or whiteboard sketch to a grand vision laid out in books.  In the end, the architect must take the requirements from the customer and with the project manager and development leads optimize resources to provide what is expected.  Between all parties there is symbiosis and conflict as each level participates in the implementation.  But above petty details the architect rises and is able to give real time adjustments to the software system in design to accommodate the issues brought to bear by the developers.  These planning steps and relationships are a key part of the architectural experience.

Planning with boundaries

A common misconception says that wide open space and no constraints are architects friends and that somehow out of a completely blank canvas the architect will create something fantastic.  This is not the case.  The architect deals with what the world knows as definite boundaries.  Those boundaries are things like price constraints, area, elevations, environmental concerns and function.  These boundaries drive the end result by imposing on the design and forcing the architect to either work around or incorporate the boundaries into the design.  A rather whimsical example of this is a tree house.  The architect of the tree house uses the boundary of the tree to enrich the design and function through incorporation.  On the other hand, the lack of acreage in inner cities causes architects to design vertically, being constrained by the hard boundary of square footage by mandate.

Architects use boundaries to plan and optimize.  Architects start with a finite almost raw space, a fixed area with other constraints like easements, utilities, curbs, public ordinances and zoning restrictions largely unseen to the naked eye.  Taking all of these factors into consideration the architect creates the base platform from which to operate.  At the same time, he will consult with the owners of the space to determine form and function.  The platform may or may not be affected by the decision in this process, but these discussions do assist in the overall planning of the structure.  Throughout, the architect is able to maintain an amazing job of using all this information to communicate a grand vision of the project. 

One of the greatest skills that an architect has is to be able to think in four dimensions.  He is able to visualize the structure from the raw foundation to the final shingle, as well as see these items coming together along a logical timeline.  Using this four dimensional viewpoint the architect creates plans for every tradesman that takes part in the construction process.  The architect can communicate from the high level vision of the structure as well as decouple the parts of the structure into usable diagrams and plans as a part of the whole.  Throughout this process, the boundaries constraint the measurements, materials and time required to complete the steps.  And lastly, one of the most important things that boundaries provide is predictability.  While not directly involved in all of these decisions, the architect’s output definitely influences costs.  With appropriate boundaries these costs can be estimated and controlled at macro and micro levels.  From an engineering perspective boundaries provide predictable scale up and scale out points and allow the structure to be engineered correctly with the right materials and placement of structural elements.

The downside to software is that it is just that…soft.  The biggest risk to any software structure during the build process is what is called feature or scope creep.  This is analogous to the blank canvas vs. the constrained environment.  A common fallacy by those not familiar with software is that because it is soft that there are no boundaries and that they only constraints are time and development resources, and that simple application of those resources will yield correct results.   This is not the case in enterprise software systems.  Like physical structures, enterprise systems start with the same constrained platform.  These include database sizes, disk space, servers, bandwidth and transaction throughput.  These raw boundaries, not tied to any product implementation, are taken into account by the architect and are usually communicated to him by the owners of the business and IT infrastructure.  This doesn’t change his vision of the overall system, but may alter the design nuances to accomplish them.  But make no mistake; many of these are hard boundaries, just like concrete and acreage.  The software architect turns these boundaries into advantages by leveraging across them to service multiple solutions as well as optimize usage of common patterns to reduce redundancy.  In the end, software boundaries need respect just like walls and foundations.  Once a piece of software is built, if there is additional need the architect can start anew by planning properly engineered additions or additional applications. 

Through this iterative development and delivery process the boundaries not only help control cost and features, but also help solidify delivery dates and allow management to declare completion through reduced ambiguity.  Without boundaries, these things could not be accomplished.  The features would change or grow at the whim of users, managers and development.  The budget would be unfixed and hard to manage and just like in construction because the finished product was so poorly defined, there would not be a chance for a certificate of occupancy.

From Design to Done

Once the proper boundaries and constraints are identified and established, the design process can begin in earnest.  For the architect, this is where the real artwork lies.  The architect begins with a high level abstract or vision of the structure.  This vision will drive certain designs and patterns into the architecture.  For instance, a residential construction will be classified by a style of home like Southwestern which will then dictate certain features, like tile roofs and stucco.  The high level functions of the structure dictates not only look at feel, but structural concerns as well.  A somewhat tragic example of this correlation is found in the library at the United States Naval Academy in Annapolis, Maryland.  When designed and built it was a grand structure, with the space to house classrooms, labs and millions of publications.  However, the architects failed to take into account the full weight of the books when designing the structure and as a result the occupied library began sinking slowly into the soft sediments of the river lowlands.  Mistakes like those are avoidable by incorporating functional concerns into the design process.

From the high level vision the architect drops down to the creating the platform serving as the foundation.  The foundation serves as the basis for the structure.  The entire load bears on the structures found therein.  This includes beam structures, cement footings, steel and slabs.  These foundational elements may be aesthetically designed, but more often than not, they are solely structural. 

Enterprise infrastructure behaves in very much the same manner.  The system is likely constrained by the hosting environment.  It is made up of a number of different things, but all based on the premise that it costs resources for hardware and platform software.  This constrains what can be done on top of this platform.  The richness of the platform software and hardware will also determine in some respects the load that the system can handle or specific guarantees of reliability in very much the same way the structural elements of a building will.  The software architect takes all these things into consideration when designing a system.  Full disclosure of the known elements of the architecture, functions and boundaries to the architect is important at this point.

At each level of structural design, there are details given about overall dimensions as well as details about methods or patterns for segments of the structure.  The architect will typically detail exploded views of things like footings, headers, beams, windows, eaves, siding and rooflines.  So in addition to the broad floor plan which helps lay out the entire floor in a cohesive manner, the tradesman is given instruction on special ways to construct the features of the house that are non-standard or subject to interpretation.  These details may also be required by special building codes unique to the locale or type of structure.  Often these special features or focused sections of the plan call for specialized skills or materials.  This also assists in planning resources and scheduling.

Following a logical sequence the architect moves from bottom to top of the structure detailing everything from foundation detail to soffit trim.  The plan implies a schedule and sequence of events; however some of these items are left to the tradesman as we shall see.  During the construction phase, the architect stays involved in the event that there are changes in the plan or complications encountered.  One such structure where I was leading a crew found just such a change.  We had just finished framing the first floor of a large custom home and were getting ready to start rolling joists on the second floor.  At this point the home buyer decided to change from a smaller bathtub on the second floor to a large Jacuzzi style bath with intricate tile work.  The plan had not called for any reinforcement in the floor joists on the second floor to handle the load of that much water.  So the architect was engaged to make the changes and we found that we were then had to use laminated beams and doubled joists to reinforce the second floor.  This also impacted the already done first floor walls as those beams needed bearing points down to the foundation.  So the changes were made in the walls in order to handle that load.  In this example, the architect was needed to fix and adjust the plan and working with the tradesmen made the changes in the appropriate point in the construction.

It is fair to say that the software architect is a little more hands on during development than the structural architect.  But throughout the process, he is just as engaged in the design process.  Starting with the high level vision, the software architect communicates the goals, vision and function of the solution or enterprise that is being built.  These guiding principles will not typically change.  What may more frequently change are the avenues and implementations used to accomplish that vision.  Software has the added luxury of being a fair bit more pliable allowing some flexibility in the design and implementation in more real time.  This is one reason why the architect stays more engaged throughout the project.  While building a purchasing card management system for the United States government, the architecture was geared towards transaction processing and transaction monitoring.  However, the initial architect had failed to accurately predict the sheer volume of data that would be needed to roll up into reports for the government.  When testing determined that the transactional database system would not handle the load adequately, I found myself devising a new architecture for analysis and reporting to fit with the current system design.  Many of these decisions are made real time, and the software architect uses the same exploded views of segments of the systems in order to detail special circumstances in applications and systems. 

While usually not covered by code mandates or regulations, software architects derive design from the same patterns and standards that are commonly used in the industry.  Some things like security, database design and message exchange can be found to be canonical and fungible between enterprise structures.  Since these are generally accepted in the industry, it is simpler to find skilled technical staff to develop to those standards. 

In both structural and software architecture, the process of design is similar.  It begins with a vision of the system or structure.  This vision maintains state throughout the creation of macro to micro plans for the creation of the structure or software.  Critical to the architectures are the detailed views of segments of the system drawing on standards and elucidating details needed for compliance to codes or accepted patterns.  And at the end of the day, the architect relies on the ability of the tradesman, the developers and engineers to interpret the plans to build a robust system or structure.

The Architect and the Tradesman

Hammers, screwdrivers, nail guns and drills...some of the tools of the skilled tradesmen in construction.  Legion is the variety of hammers available both for varying functions as well as personal preference.  My first day on a snowy jobsite at the base of the Rocky Mountains involved breaking in a 32 ounce framing hammer.  I remember being the envy of almost everyone on the crew, everyone except the general contractor.  His preference was to carry a roofing axe, and after watching him at work I understood why.  And after building many custom homes, I came to understand the relationship between the architect the tradesman and tools.

Remember the principles of abstraction that make the architect so effective.  The ability to rise above specific details of implementation allows him to purify the implementation of his vision.  The tradesman on the other hand has a mixture of constraints and freedoms when implementing the architectural vision.  On the one hand, the tradesman is generally free to choose any number of tools needed to get the job done.  Skilled tradesmen will use the correct tool for the job, but at the same time will definitely have a favorite tool or tools for certain functions.  I still use the Hitachi pneumatic framing gun over all others because of the way it feels and operates.  And of course for most intensive nailing operations I prefer that over my two pound hammer.  On the other hand, the tradesman is not always given the freedom of choice as to the types of materials to use.  These are usually a combination of decisions made by the architect, like in the case of types of floor joists, structural elements or lumber dimensions or they are made by the contractor and financier of the structure for budgetary or code reasons.  The tradesman doesn’t have the luxury, except in extreme cases to question the types of material chosen; they are just expected to follow the specification on the use of the material.  In this sense, the tradesman is very much subservient to the vision of the architect.  They even may not agree with the look and feel of the structure or even the function, but they know how to implement the detailed plan. 

The architect and tradesman do not interact all that much.  This is one of the benefits of the detailed plans, is that the architect can move on to the next project and the tradesman can construct to the specification.  Without this detailed specification the architect would need to be onsite directing the work effort on a daily basis.  This is slightly different from the relationships between architects and developers in software.  By contrast these players will often sit side by side and flesh out details of the implementation from the architectural plan.  Due to the “soft” nature of software architecture things can be this fluid, but may not need to be as more rigid specifications and more importantly patterns emerge for software design.  Both of these items will bring the software architecture to implementation cycle much closer to that of structural architecture and development.

Architects are not tradesmen and vice versa.  Very rarely will you find an architect instructing a skilled framing contractor on how to nail one piece of wood to another.  There is an inherent trust placed in that skilled laborer that they can perform the function needed to complete the project.  That same trust should exist between software architect and skilled programmer.  In fact the architect may not even know exactly how something will be coded, just that it will and it will deliver on the specification.  The tools that the programmer uses may not be apparent or known to the architect either.  They may range from full development suites to simple text editors, and are determined both by personal preference as well as mandate by a project manager or IT infrastructure.

The loosely coupled relationship between the architect and the tradesman or programmer exists to fill a purpose.  It optimizes the work that both can perform and allows them to deliver without constraints on their ability.  It also decouples the architect from the pedantic details of implementation as well as allowing the programmer/tradesman to accelerate their work by using the predicable and repeatable patterns detailed in the plan, with tools they have familiarity with.

So Why Architecture?

The metaphor I have used has been building to answer this question.  Why is architecture important?  Why do we have architects?  I hope that some of those answers are obviously demonstrated herein.  It all boils down to delivery.  If there were no architects, there would be no delivery.  Through the use of proper boundaries, the project success criteria can be determined.  Those boundaries provide structure to the development, and signal completion.  Many software application development projects fail due to improper planning and boundaries.  This is typically seen when small prototypes move directly into production.  The prototype will perform well for its function, and incorrectly assumed to be able to just scale right up.  This is analogous to a contractor building a one story single family home and then deciding to just add floors with no additional structural modifications.  Correct architecture avoids these issues through planning, proper design, and coordinated execution with skilled developers and tradesmen.