A number of articles have been written on software architects; two of my favorites are:
- Joel Spolsky on Architecture Astronauts
- Martin Fowler's Who needs an Architect?
Both underscore the importance of architects making software and systems more simple. Spolsky targets the idea of not getting too abstract, and Fowler suggests architects are really guides, which resonates with me.
I want to focus on an aspect I haven't seen discussed, and that's good coaching. Or, at least, I want to focus on a different aspect of coaching: setting good success criteria.
My style tends to be the astronaut style - abstract everything to the extent possible. This creates maximum flexibility, but does so at the expense of simplicity; or, in project management terms, does so at the expense of productivity. Concrete concepts are easy for developers, especially inexperienced ones, to understand; as such, systems get done based on concrete concepts.
At times I've been very successful with the astronaut approach; but I've watched enough systems delayed and downright fail that I've evolved my thinking and approach in this space. I am not nearly as zealous about astronaut architecture as I once was.
Root cause of these failures? The inability of developers to execute the architectural vision. This is not a negative relection of those developers! Rather, it's expecting too much of them to see what architects see. The tale of Flatland seems apropos here. Expecting someone who's still learning the intracacies of basic programming to resonate with the challenges of concurrency or the power of reflection is asking too much. Clearly the risk is proportional to the number of "newbie" developers you have as part of your team (where I've had success with the astronaut style is with, you guessed it... other astronauts).
So how can guides bridge this gap?
Actually, it was working with external partners that pushed me into a new area (to me) of thinking. I was tasked with creating standards for a industry trade organization; unfortunately, the partners I was to work with did not have the experience I did in the software space - they were electrical engineers who were well versed in embedded software. The standards to be defined were external to the microprocessors for which they were responsible. This was about setting system integration standards (service discovery, communications, location transparency, etc), and the route the team was headed would have been limiting in the short and long term and did not leverage the state of the art in these spaces. Challenging these decisions required a set of agreed upon criteria, independent of the standard. This was the best decision made in the standards process - what are the success criteria that the standard should meet? By defining the success criteria up front (not in vague, abstract terms, but in lower level details), future discussions on the merits of different approaches went smoothly.
(Interesting enough, the success criteria mirrored standard architectural characteristics: security, communications, location transparency, discovery, etc.)
At about the same time, one of the developers I lead was wrapping up an ambitious project. The project would allow easy discovery and communication of services on a network. The developer did very well with the design and implementation, with one miss: new services and functions required new code to be developed. The avoidance of manual code generation was fundamental to the business case of the project! But in the architecture we put together, nowhere did it specify such criteria. Ah ha! Success criteria isn't just about architectural characteristics. But that particular criteria was critical to the success of the project, and critical to the design of the system. If it's critical to the design, it should be part of the "architecture."
I will go so far as to argue developers don't need architects. What is needed, are guides. Guides provide the same level of constraint as architects, while still providing the maximum amount of design and implementation freedom.
I've found inexperienced team members will drive to sound architectural decisions (one of my fears of XP was the lack of arch vision... over time I am less concerned about this aspect of XP) if they are clear on the success criteria. Developers are smart - they know whether they are meeting the criteria or not. I would much rather have a developer using SOAP out of location transparency and language-agnostic reasons than using it "because the architecture mandates it." I've seen some creative designs and thinking because developers had the freedom.
To be sure, as an architect, there are times I slam my fist on the table. Usually it's around important interfaces in the system and the protocols those interfaces need to support. That said, more and more I remove myself from architectural specs and focus on success criteria. In the end, success criteria generally point the developer to a design solution that I hope for in the first place. Still, it's a great learning experience for the developers to have a higher degree of freedom, and you never know when they come up with something better than you were thinking. In the end, that's the real measure of success.
No comments:
Post a Comment