Rob Kraft's Software Development Blog

Software Development Insights

The Way of the Software Architect – the first allegory

Posted by robkraft on April 9, 2012

The CEO came to me and said he would like a new web site.  I replied that I am a client/server software architect, but that I could learn to become a web architect and build his site for him.  I went to the masters of Ruby on Rails and in just two weeks I learned to create a site and I learned the power of convention over configuration.  Then I went to the masters of ASP.Net and in another two weeks I learned the many benefits custom controls and the Microsoft Way.  Then I went to the masters of PHP and I learned the simplicity and elegance of the PHP way.  Then I went to the masters of MVC and learned the testability and power of the MVC way.  I went to the masters of Silverlight and learned the power of .Net in the browser using the C# way.  Finally I went to the masters of HTML5 and javascript and learned the breadth and reach of the HTML way.  I learned each of these technologies in two weeks each.  I returned to the CEO and said, “I have learned many of the best web development frameworks.  I have developed web sites in each and I know the strengths and weaknesses of each.  I am now ready to build your web site for you using the very best approach.”  The CEO looked at me and said, “You are too late.  I told my 17 year old niece about the web site I desired and she created it using Google sites in two days.  The site she created is perfectly satisfactory to my needs.”


— The architect’s way


This story illustrates the necessity of the architect to understand more than technology.  Indeed, for every person involved in a software development project, the goal of your tasks is not to provide an esoteric best answer.  In the role of a software architect, your goal is to recommend the best architecture.  But every person in an organization has many roles, and one role shared by every person is to help solve business problems quickly and efficiently.  Often, the business goals trump the goals of the software architecture.  Business goals include:  getting to market early, pleasing a specific client, pleasing a specific CEO, developing a secure solution, developing a prototype solution; development a solution inexpensively that is good enough; allowing a junior developer to learn through trial and error by developing a solution; developing a solution merely to learn a new technology; developing a solution to test out a new technology before using it in more important projects.  All this and more.  A software architect needs to help a business solve business problems first, and worry about purity of architecture second.

2 Responses to “The Way of the Software Architect – the first allegory”

  1. housecor said

    Great story Rob. It really emphasizes the point of focusing too much on technology and not enough on the business need. I recently read a post by an independent contractor who is now billing for far more money by avoiding mentioning the technology at all to the client. This focus made him more relatable and more focused on solving the business problem. By listening better and forging stronger relationships he created a competitive advantage.

    Great post!

  2. housecor said

    Great story Rob. It really emphasizes the importance of focusing on business needs rather than the technology. I recently read a post by an independent consultant who found he was able to great increase his rates by not mentioning the technology at all. It’s a competitive advantage to not be another “x technology” developer and instead be someone focused on the business problem.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: