How many of your software projects do you consider truly beautiful? How often does your customer feel the same way? Are you, the architect, ultimately responsible for those feelings?

I ponder these issues often, particularly when reviewing and analyzing the successes and failures of my own career path. Then there is that agonizing question: just what is a software architect? We all often fall back on the traditional “building designer” metaphor. While it is a tried and true description, I find it lacking for one reason or another. Other models must exist that better describe the numerous challenges and responsibilities of our software profession. Even our customers, the ultimate benefactors of our work, need a better way to understand the value of our contribution. Other careers inspire similar passion, enjoyment, frustration and challenge, and offer meaningful parallels that enhance our work and crystallize our ambitions.

Beauty is in the eye of the beholder. This is often the case for subjective work with intangible or non-existent requirements. It is the responsibility of the person charged with creating the work to ensure that the multitude of details that do not exist on paper, that can not be quantitatively tested once complete, are present in a real enough form as to enter the awareness of the consumer. Software, while theoretically tangible, is often viewed by users with a mixture of awe, suspicion, expectation, frustration, and sometimes even gratitude. The software architect bears the brunt of the responsibility for ensuring that the user experience fall on the positive side of those reactions.

It is not enough to have a vision for the solution; we must persistently nudge our team to successfully achieve that vision. Our challenges are immense. Frequently our team membership represents varying skills, personalities and experiences. They must work within the boundaries of the available or chosen technologies; deal with the whim of fashion and style; and conform to arbitrary expectations that often compete against the best solution to a problem.

Art is a powerful force in my life. I have been a musician since I was very young.. In high school and college, I spent time in technical theater. My wife is a stained glass artist, and herself spent 12 years in technology. Today I play several instruments, but have turned my creative focus to glassblowing. Yet while art is important, maybe even a passion, I am a software architect by profession. I get much of the same satisfaction out of participating in software projects as I do from my involvement in music, theater and art. I notice too that many of my peers and mentors share a similar connection to the arts. I find interesting parallels between software architects artists that offer to improve our careers and enhance our professional enjoyment. In these comparisons, I will draw on parallels in team arts, such as glassblowing and music ensemble, which share many characteristics with software projects.

The following comparisons make these assumptions:

-          The architect has experience in what is proposed

-          The architect influences substance, manner and motivation of the team’s work

-          The architect is a part of the entire project lifecycle, and touches pieces of the project as it progresses

-          Becoming a good architect takes time

-          Not everyone can be a good architect

In the creative arts, especially those that have both individual and team dynamics, there are very established and effective learning processes. These combine a focus on individual skill with real time performance assessment and team collaboration and feedback.

For musicians, regardless of their instrument, there are certain standards that are learned. For example, there are certain basic techniques that must be mastered to be proficient as a glass artist. These are important foundations to the emerging artist. For the musician or glassworker who wants to become the visionary, the composer, they can not bypass these steps. It is a shared set of experiences and fundamental knowledge that will connect them to their “teams” as they progress.

Music is not just about “making music;” it is about the performance. For visual artists, the performance is seldom live; nevertheless, the critical peer and teacher review remains a close analogy and an important part of the learning process. These real-time, candid, ego-pressuring experiences refine vision, focusing attention on details that others see or hear. When teaching software architecture, this technique would be a valuable addition to standard modeling and documentation tasks. In the real world, the vision of the architect must encompass many other views.

Many of the best artists, the most visionary composers and conductors, worked for those who came before them. In participating in another’s efforts to realize a particular vision, they are freed to experience the process, and at the same time required to continue to hone their own sense of what will be “right” in a particular work. To become a great architect, apprenticing with a more experienced mentor provides countless opportunities for first-hand experience –– close to the material at hand. In fact, just like in the creative world, this apprenticeship often leads to the student becoming the master, as the master moves on to greater and or different things.

Once in the architect’s chair, there are many facets of the process that await the architect’s inspiration. Their sphere of influence includes the selection of technologies to how those technologies are implemented to how well the team knows how to implement them.

In art and music, as in software, there is a fine line between breaking new ground, and digging one’s grave. In many cases, even ideas that seem radical are based in fundamental patterns and techniques. Whatever the case at hand, it is the architect’s responsibility to carve away any unnecessary innovation, only breaking the mold for the most necessary and justifiable reasons.

A symphony orchestra has many components, all of which must work in concert. Likewise, teams on large glass art projects have scientific, artistic, safety, environmental and commercial challenges, requiring individual expertise to be focused in different areas. In the end, these group leaders are responsible for the end result, know everyone’s role, and can demand refinement based their knowledge of the substance, manner and motivation of the work at hand. In essence, the leader knows how to do it. In software, the architect without direct understanding of what needs to be done AND how it is going to be done will never get the best work out of the team.

The end result is measured not only by the architect, composer or visionary artist. It is measured by all those who experience it, who use it, those who make it a part of their lives. However, those same people know how they feel about it when it is done often can not articulate beforehand when it should be done. The vision for the end must take into account the needs and wants of these consumers, but also must be advocated by the architect.

In my world, the software architect is like the artist. Those artists who depend on their own inner vision for a solution, but who also rely on the skills of those around them to achieve that vision. Artists are as good at doing as they are at proposing. Artists that have a powerful impact on those who come in contact with their work, work which is made that much greater by all who are involved.

Further reading: Several months ago, I had a long conversation with Ward Cunningham, who had recently joined Microsoft. Our discussion turned to linkages between art and software. He pointed me to work by, Richard P. Gabriel, a Distinguished Engineer at Sun. Gabriel has been working, with others, on a proposal for a Masters in Fine Arts in Software. You can read more about it here, and read some of Cunningham’s (and others) comments here.