Gods and Mortals, Part 1

Zeus on his throne

I first witnessed this early in my career when “the architect” would fly into town for two days every few weeks and diagram the architecture for the upcoming application on a whiteboard. Then the architect would fly out of town and developers would fire up IDEs to implement the architecture.
(K. Scott Allen, from “Whiteboard Architecture”)

The discussion I wish to provoke is: Is it the sole responsibility of the software architect to provide the architecture?
Or is it that the architect is best competent, skilled, verbal, and positioned to help the team (or organization) to produce the most appropriate architecture?
(Ilan Kirschenbaum, commenting on “Architecture versus Design”)

It’s easy to accumulate a backlog of ideas for posts, particularly when you write in your spare time. This one has been waiting in the wings for a while, to be forced out onto the stage by Ilan’s comment on my last post. It’s one I should have addressed a long time ago, because it touches on one of the biggest threats to software architecture: some of those who call themselves architects.

“Ivory Tower Architects” are a long standing embarrassment to the discipline. Likewise, “Architecture Astronauts” and those in love with patterns for patterns’ sake are frequently used to justify the opinion that architects provide no value. Worst, in my opinion, are the Olympians, descending to the mortal realm to dictate to the lower beings. Alone, or in combination with the above types, the “God of Architecture” is particularly adept at alienating the rest of the development team. This alienation leads to ignoring the need for architectural design, or hoping that it will emerge in some coherent form, to the detriment of the product and its users.

In “Agile Architect – What is it?”, Ilan outlined a more collaborative role for the architect:

Instead, the architect should work with the product manager, defining a solid Definition of Done, in order to create the requirements with solution in mind (thank you Eshed)

The architect should work with designers, developers and testers, to talk in their native language, in relevant engineering terms, describing the business needs of the customers, so they can produce the right software.

The architect should view the software, in various stages of being produced, in order to highlight quality issues, refine requirements, adjust the architecture – in other words, respond to feedback early.

In order to achieve the above, the software architect could be the one writing the high level design, creating solution overviews and diagrams, etc. Could be, but does not have to be. The organization might gain more if the architect assists the above mentioned to product all these documents.

I strongly agree. Leadership (paired with responsibility) is necessary, but a more inclusive approach makes sense from several perspectives:

  • Understanding – When the other members of the team are involved in the design process, they should gain a deeper understanding of the architecture (knowing both the “whats” and the “whys”) than would be the case if the finished product were deposited in their laps.
  • Ownership – Participating in the design should also engender ownership on the part of the team as a whole. People tend to be less resistant to that which they own as opposed to that which is imposed on them.
  • Evaluation – The architect gets the opportunity to gauge the skills of the rest of the team and they get a better appreciation of the architect’s abilities as well. This should foster mutual trust.
  • Training – Involving the team in the design of the architecture is valuable training. Team growth should be seen as a positive.
  • Quality – This applies in two ways. First, a fresh set of eyes is likely to spot issues regardless of the item being tested. Ideas that survive the team approach are likely to be durable ones. At the same time, you gain the advantage of multiple skill sets. It’s unlikely that any given architect (or anyone else for that matter) is universally skillful. Working collaboratively allows you to leverage the strengths of the entire team.

The last bullet point cannot be over-emphasized. Although he was discussing enterprise architecture, Tom Graves made an important point in “Analyst, anarchist, architect” regarding the applicability of the Hegelian triad of thesis, antithesis, and synthesis to architecture:

…the antithesis is not a negation of the thesis, but a challenge to the assumptions on which the thesis is based – which then leads to a synthesis that makes real practical sense.

It’s not impossible to achieve that challenge to your assumptions when working solo, but it’s far from easy. I’d argue that one characteristic of a good architect is making efficient use of available resources. In my opinion, using the team to improve the quality of the architectural design as well as their understanding of it sounds like an efficient use of those resources. In the words of Roman philosopher Seneca the Younger: “Even while they teach, men learn”.

Advertisements

21 thoughts on “Gods and Mortals, Part 1

  1. Thank you for the warm reference, Gene.
    I must shamefully admit that I have been ‘stuck’ on my own Olympus at times in the past. But with experience comes also insight. Maybe some of us must go through this process, in order to help others avoid or correct such mistakes.
    I am glad you liked my post, and responded with this excellent article.
    Looking forward to part II!

    Like

    • Ilan,

      Thanks for taking the time to respond. I think the interaction is just as valuable here as it is in the design process.

      You’re very correct that experience brings insight. I was put in a position a few years back where I was the team lead for a group of architects, each having anywhere from one enterprise application to 3-4 smaller applications that they were responsible for. I had to learn very quickly to let go (“not the way I’d do it” does not necessarily equal “wrong”) and work with them (as well as the teams they served) rather than try to dictate. It’s a balancing act, though, as it runs contrary to another trait that’s equally important – having confidence in your own abilities.

      Like

  2. Pingback: Gods and Mortals, Part 2 « Form Follows Function

  3. Hi Gene,

    i find your article really refreshing and it does have some interesting points to reflect in.

    In my experience I’ve been in both sides, I’ve been mart of the Olympians and has changed the way I work with time and experience. I totally Agree with Gene, experience is a plus…

    In my case, it is actually a paradigm in the department where they tend to thing that the important Architectural definitions should be made by Architects and never with the development team.

    But things are changing and I can say that by proof in the field we are becoming less the Gods each day and more the semi-gods…

    Would you mind if I refer to your article and most it?

    Like

  4. Pingback: Getting there from here « Form Follows Function

  5. Pingback: Who’s Your Predator? | Form Follows Function

  6. Pingback: Design by Committee | Form Follows Function

  7. Pingback: Your Code is not Enough | Form Follows Function

  8. Pingback: Risky Assumptions and the Assumption of Risk | Form Follows Function

  9. Pingback: Why does software development have to be so hard? | Form Follows Function

  10. Pingback: Lord of the Repository | Form Follows Function

  11. Pingback: Shut up, salute & soldier on? | Form Follows Function

  12. Pingback: Who’s your predator? | Iasa Global

  13. Pingback: Design By Committee | Iasa Global

  14. Pingback: Who’s your predator? | IasaGlobal

  15. Pingback: Who Needs Architects? Who’s Minding the Architecture? | Form Follows Function

  16. Pingback: Who Needs Architects? – Are You Committed to Reaching Your Goals? | Form Follows Function

  17. Pingback: Who Needs Architects? Well, Nobody Needs this Kind | Form Follows Function

  18. Pingback: Leadership Anti-Patterns – The Great Pretender | Form Follows Function

  19. Pingback: Babies, Bathwater, and Software Architects | Form Follows Function

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s