Some software architects tend to think a lot about our place in the software world. In a recent conversation with a colleague, I found myself in agreement with his description of the clear separation between software engineer and software architect. His argument wasn’t that the two roles couldn’t be fulfilled by the same person, simply that they are separate disciplines. I fully agreed, yet as I thought about it, I grew somewhat uncomfortable with my own conviction about the extent of this separation. I felt a need to try to establish what the relationship is, and perhaps what it should be.

I began as a programmer, and grew to a developer, a software engineer, then finally into a software architect. For me the relationship between these roles is clearly and linearly connected. Yet others come to the role from other paths, primarily along the analyst lines. Somewhere these paths converge.

Still I question whether I could have become an excellent architect, if I had not first learned to be an excellent software engineer. Of course, I am not making a personal claim of excellence, or lack thereof; I was merely making a point of the relationship in the progression. Yet, my roles meandered broadly as I worked toward my professional goals, and I believe that I learned about aspects of architecture from each. From verification, to project management, to software quality assurance; each new role revealed new insights about architecture as well as the lack of attention it is given in most projects.

As recently as February 2004, the IEEE-Computer Society completed the first edition of the “Guide to the Software Engineering Body of Knowledge”. In section 12, this guide enumerates the fields which share a common boundary with Software Engineering. The list is comprised of: Computer Engineering, Computer Science, Management, Mathematics, Project Management, Quality Management, Software Ergonomics, and Systems Engineering. Of note here is that just 2 years ago, one of the most respected computer societies in the world, did not recognize software architecture as a discipline independent of software engineering. In fact, software architecture falls within a single subarea of the Software Design KA. This fits well with my internal beliefs about architects and architecture, though it’s sure to raise hackles for many. This doesn’t mean that I believe that the Software Architect does not deserve a distinct occupational role; quite to the contrary. Just as Software Engineering is a subspecialty in the broader field of Computer Science, a Software Architect is a specialist, who concentrates on a single aspect of Software Engineering; an aspect that has not traditionally been well addressed by the rank and file Software Engineering generalist. But why is it that this particular software engineering specialty is so well filled by so many who would not ordinarily be called software engineers?

I once hired a consultant to deliver a training class for a predecessor of MDA technology. Like MDA, it was a model translation approach that I will generically term model-driven development. In passing, he spoke about the three skills of software development: analysis, design, and implementation. He said that it had been his experience that it is unusual to find a single individual who is above average in any two of the skills; and exceedingly rare to find an individual who excels in all three. As a program manager rolling out this technology to his group, this had been a problem for him, because the natural order suggested that the product would be created by the implementors; the programmers. By and large, programmers were less effective in the use of the tools.

Model-driven development, according to its pioneers, employs an analysis-centric approach. The design evolves from the analysis, and the implementation is transformed and translated from the design. In this methodology, the lines between analysis and design can be quite fuzzy, but the distinction from implementation and anything else is clear-cut. Implementation is a very limited activity in MDD; but analysis and architecture play major roles. In fact, that is somewhat of an understatement. In reality, the process of model driven design is the process of elaborating an architecture, and one can view the implementation and translation portions as necessary steps to validate the architecture.

The point I’m making is that architectural design is heavily dependent on analysis, and the two activities do not separate cleanly. Yes, I believe my qualifications as an architect rely heavily on my experiences as a software engineer, but I think they rely even more heavily on my specific experiences in the role of analyst. Analysis is the foundation for all good design; and this, I suspect, is why many architects are not from a traditional software engineering background; and why a good many software engineers will never be, or even wish to be software architects.

Synthesis of a solid architecture can only follow a thorough analysis of the problem space. Analysis and Synthesis are both needed. Synthesis is the core skill of engineers across all domains; while analysis is the primary domain of theoreticians. As they say, “In theory, there is no difference between theory and practice. But, in practice, there is.”

Many software engineers are very uncomfortable with analysis, yet it is a skill that is quite heavily relied on in many non-engineering endeavors; and herein lies the opportunity for cross-over. It may be that an analyst from any field can become a competent software architect, despite a complete lack of comprehension of the technical mechanisms underlying the implementation. It simply requires that they gain an understanding of component connection and communication, interface design, and synthesis of a system from these components. This architect may understand almost nothing about “pass-by-value” .vs. “pass-by-reference”, or files .vs. named-pipes. Some consider issues such as this to be design details, and perhaps this is a correct assessment. Personally, I have a bias against this view. My belief is that an architect who cannot address the mechanisms of implementation, lacks the ability to assess the robustness and efficiency of the architecture. In the domains where I typically operate, this would be an intolerable handicap; in other domains it may be perfectly reasonable.

Creating a software architecture is an exercise in problem analysis and solution synthesis. Above all, the software architect must be able to create and assess a solution comprised of top-level components and interactions in response to a specific problem or problem set. This goes beyond the skills of the typical software engineer; though many senior engineers find themselves thrust into the role. It goes beyond the skills of a typical analyst, but this profession also provides a viable path.

Whatever their background or origins, the need for software architects is a pressing one for all non-trivial software-based projects. Industry has begun to recognize the need for enterprise architects, but architects at other levels still struggle for credibility. There is a general lack of understanding about what value we provide; and how our skill sets differ. Bringing this understanding to industry will be our challenge over the coming years.

About Max H:
Max is a father, a husband, and a man of many interests. He is also a consulting software architect with over 3 decades experience in the design and implementation of complex software. View his Linked-In profile at