While initially the meaning of ‘architect’ was restricted to those who built physical objects like buildings (as it still means today), the word can be applied much more generically. For example, James Madison is often referred to as “the architect of the U.S. Constitution” for his crucial role in bringing about the Constitutional Convention in 1787, preparing the delegates with a compilation of the defects of the Articles of Confederation, creating the first outline draft of the eventual Constitution, and shepherding the whole process as it progressed. He also contributed to the Constitution’s ratification as one of the triumvirate of authors known as ‘Publius’ who wrote the 85 essays which became known as The Federalist or The Federalist Papers. (For an excellent exposition of Madison as architect, see James Madison and the Role of the Architect by Dana Bredemeyer.)
As I stated in the post Build Different. Build Victory., “As computer systems and software became increasingly more complex, global, and interconnected in the latter half of the twentieth century, the need for an architecture-type role became obvious, and the field of systems architecture was born.” There is often confusion between the role of the architect and the traditional role of the engineer. This is not hard to understand, since in many organizations architecture work is performed by engineers (and by people in other roles).
In their book The Art of Systems Architecting, Mark Maier and Eberhardt Rechtin describe some of the key differences between architecting and engineering:
- “Generally speaking, engineering deals almost entirely with measurables using analytic tools derived from mathematics and the hard sciences; that is, engineering is a deductive process. Architecting deals largely with unmeasurables using nonquantitative tools and guidelines based on practical lessons learned; that is, architecting is an inductive process.”
- “[A]rchitecting is characterized by dealing with ill-structured situations, situations where neither goals nor means are known with much certainty…. The architect engages in a joint exploration of requirements and design, in contrast to the classic engineering approach of seeking an optimal design solution to a clearly defined set of objectives.”
- “At a more detailed level, engineering is concerned with quantifiable costs, architecting with qualitative worth.”
- “Engineering aims for technical optimization, architecting for client satisfaction.”
- “Clearly, both processes can and do involve elements of the other.”
In one organization, we spoke of architecture and engineering in the context of a continuum from strategy on one end to implementation on the other.
The architects focused more of their efforts on the strategy end of the spectrum, while the engineers focused more time on the implementation end. There was much overlap in the middle, particularly around system design. We found that this was best done collaboratively, leveraging the strengths of both architects (with deep knowledge of the markets and business strategy) and engineers (with deep knowledge of the technology and technical staff capabilities) to produce compelling yet feasible designs.
Even though the lines between architecture and engineering roles may blur at times, a collaborative culture will have little trouble finding the balance which works best. Nevertheless, there is a real benefit in separating the two roles. In my experience, the engineers are almost always allocated to a current project, working toward specific product release deadlines. This reality often means that meeting the schedule takes precedence over long-term consideration of system qualities. Separating an architect role from the day-to-day grind of meeting the release schedule allows some person or team to escape the tyrrany of the urgent, to think about and champion a broader perspective, and to ensure that the products or system will fulfill the business strategy and marketplace needs beyond the immediate release.