Five Challenges for a Maturing Discipline

[At the opening for SATURN 2014 I presented five challenges for the software architecture community as a means of kick starting our brains for the conference, but also a serious reflection on the state of software architecture practice.  My hope is that these challenges are something we can work on together as a community and are my attempt at capturing something actionable that we can do to accelerate software architecture's maturation.  On the surface these five challenges are pretty simple. Of course if it truly were simple then it wouldn't be much of a challenge. Think about them. Give some of them a try. Let me know what you think.]

A little less than 20 years ago, Mary Shaw and David Garlan published a book reflecting on trends they noticed were emerging in software development.  The book's subtitle was extremely fitting: Perspectives on an Emerging Discipline. My reaction to the book, having read it for the first time for a software architecture class in 2008, was that it was grand in scope yet unassuming.  Having had the opportunity to meet and work with both David and Mary while a student at Carnegie Mellon, I found that the tone of this landmark book is more a reflection of who they are than anything else.  Essentially they proposed to the software engineering community, "Here are some interesting ideas and trends we've noticed and we think they are worth taking seriously, but these ideas need some further thought."

While Perspectives was certainly intended to be a unifying, landmark work, Mary and David had the wisdom to recognize that this was only the beginning, that this emerging discipline of software architecture must continue to mature, and that others must be responsible for the growth of the practice.

Fast forward to today, and the success of conferences such as SATURN show that software architecture as a discipline is maturing, that we are continuing to improve the state of practice with every new software system shipped.  But while we are learning more and getting better and better as a community every year, it is also becoming apparent that we still have a long way to go.

Software architects are expected to be a very different kind of leader than what is commonly required of folks in a leadership role.  Software architects need to maintain a focus on business, technology, and people simultaneously.  Software architects are expected to be experts at the largest granularities of abstraction while at the same time fully comprehending the implications of the tiniest technical details.

This is a problem for us because mastering both of these worlds – coding in the large and coding in the small – is extremely difficult.  In the past decade or so we've become really good at coding in the small as evident in the thousands of flowers blooming on Github and other code depots.  As an industry though we also seem to lack a general self-awareness and discipline when it comes to understanding why we make the decisions we make. To me this seems like a problem in how we educate software architects.

While it's great that we can force success through brute force and raw smarts, if we as an industry ever hope to reach a point where someone can master software design basics before becoming a grey haired master, we need to continue working to mature our discipline.  Currently it takes 10 - 15 years of experience for someone to really master software design.  The prevailing wisdom is that a person is not even ready to learn software architecture - coding in the large - until they've practiced software development for at least 2 – 5 years - coding in the small.  At the same time, elementary school students are practicing geometry, calculus, and trigonometry -- mathematics that took some of the greatest minds in the history of the world years to figure out.  Certainly we can do better with software architecture than we are currently doing.  I'm not suggesting that education is a substitute for experience. I am suggesting that we can improve our software architecture education and make software architecture more accessible and easier to learn.

As an emerging discipline, that we have problems like this is actually a good thing.  Software architecture is growing up.  The discipline has emerged and as a discipline software architecture still has a lot of growing and maturing to do.  My hope is that these challenges will not only get you thinking about where we are going with software architecture, but also that you will accept some of these challenges and at the same time help continue to improve the maturity of the software architecture discipline.

Five Challenges for the Maturing Discipline of Software Architecture

1. Increase diversity – technology, age, gender, cultures, everything.  Having diverse perspectives on a team is a force multiplier for success.  Every team should strive to have rich diversity.  Men and women. Young people and older people.  Different cultures and backgrounds.  Different universities.  And perhaps most importantly, different technical and work experiences.
   
   Ecologists often refer to biodiversity as one of the most important traits for determining the success or failure of a species.  Drawing an allusion to evolution is not an accident here.  As your system evolves, the more diversity that is available in the ecosystem the better fitness that system is likely to have.  Learn a new programming language.  Learn a new framework.  Every once in a while, get out of your comfort zone and seek out people and communities with opinions or practices different from your own.  You will learn something new and the results will be surprising and good.
   
   
2. Write more code.  There is this nasty rumor that software architects don't write code.  Plain and simple, anyone who calls themselves an architect without dirty hands is not an architect.  I know many agree with this, but to overcome this negative perception we need to write even more code.
   
   I am not suggesting that we should write more software, but rather software architects need to remember their roots.  Writing more code does not mean you should be writing production code – in fact it's probably best that some (most?) team leads and architects stay off the critical path for a project.  Non-production code is still extremely important.  Direct observation through experiments is one of the most powerful tools we have in software architecture.  Learn by doing.
   
   
3. Put humans first.  As software architects we are very much focused on software systems.  So much so that it seems we sometimes forget that the whole point of the software and the documentation and the models that we build is so we can provide value to people.  Human centered design is an extremely important trend in software development right now and the software architecture community is completely missing out.
   
   Who are the humans software architects care about?  Downstream programmers, maintainers, testers, customers, managers, fellow teammates – the user too, but as software architects we are responsible for the experience of everyone who interacts with the systems we build, not just the users.  Put humans first in the documents you write and the systems you design.  Empathize with the developers, the testers, the managers, the integrators, and not only the users.
   
   
4. Create a sense of craftsmanship.  We've all seen it.  That diagram that was created just so someone could check off a box on a process.  The font is too tiny to read.  There are innumerable lines and boxes.  Nobody really uses the diagram because nobody wants to take the time to understand it.  The person who created a diagram like this straight up did not give a shit.  Design is as much about results and process as it is about aesthetic.
   
   Part of putting humans first is caring about what you build.  Embracing craftsmanship means only creating software, models, documentation, plans, and so on that you would be proud of.  Craftsmen strive to produce work that they would proudly declare as theirs, and would be willing to stake their reputation on what they produce.
   
   
5. Share what you know.  As software architects, our job is just as much about teaching as it is about programming and technology.  A software architect who can't share their ideas is neither a useful leader nor an effective designer.  Conferences such as SATURN are critical to creating great software architects and offering platforms for sharing.  So too are less formal self-publishing platforms such as blogs, YouTube, LeanPub, Hangouts, Stack Exchange and so many others.  Collaborate, share, teach others – this is the only way software architecture can continue to grow and mature.

These are the challenges of a maturing discipline.  These are my challenges to the software architecture community.  Are you up to the task?