Friday, April 30, 2010

The Architecture Team

The architecture group is responsible for ensuring that no work is duplicated, that the company aligns with the standards and that the best technology practices are followed.
Think of the architecture team as the “special forces” team made up of senior technical advisors who maintain a holistic picture of the entire technical environment, both present and future.
When empowering the architecture team it wise to keep an eye out for those headstrong individuals who, in their quest for architecture purity, or because of ego, tend to push their own point of view or technical religion, rather than addressing customer needs.  A good architect should be an expert and, by definition, an expert is someone who can solve any given problem in multiple ways. If you encounter an architect continuously hammering home the same solution to every problem; all the while blindly refusing to consider any other alternative, then it’s time for you provide some serious direction. 
While the architecture team should enforce the standards, it should also demonstrate flexibility in adjusting and enhancing these standards on an on-going basis. The way to do so is by staying in tune with the business requirements and with the system analysts, engineers, and developers who are responsible for delivering the solution.
This is what happens.  You form a small group of bright, technical people with the objective of having them develop the framework, tenets and standards needed by the organization. However, if this group is not given the responsibility to actually deliver specific components, it becomes very easy for them to move to the realm of platonic but impractical beauty. In this realm, all architecture constructs are conceptually beautiful and theoretically comprehensive, but essentially non-workable and non-functional (the original Open System Interconnection developed in the eighties comes to mind).  Should the situation be allowed to fester, you will soon hear your programmers mocking these “fools on the hill” whose only ability is to produce extremely abstract architecture papers that will never be followed through. Meanwhile, the very talented architecture team will grow increasingly frustrated as they watch the fruit of their work ignored by these “spaghetti-code hackers”.  I don’t have to tell you that this is not a healthy and productive state of affairs.
Giving architects a degree of development responsibility sends them a message that they will not be able to get by simply by publishing a series of holistically irrefutable, enterprise architecture bibles. Instead, the architecture group should be tasked with delivering something, as in actually coding stuff!. This approach is to prevent the emergence of what author Joel Spolsky calls, “Architecture Astronauts”[1], or what they were called in my day, “Blue Sky Architects”.
Accordingly, while the architecture group should have clear governance in defining and directing the standards, they should also be tasked with delivering code. To keep this team well grounded, a good assignment would be to give them responsibility for the development of system framework services, libraries, and toolkits.
Alternatively, line development functions should have a seat at the table in the development of technology standards. The architecture team has the overall responsibility of organizing and running technology forums that ensure that the technical team has a say in the process. These forums should allow everyone in the development community to speak their mind and to give their personal viewpoints regarding standards and tenets.
Still, at times, some line developers will need to be reigned over simply because it is not feasible to pursue the whims and wishes of those whose motivation might be to pursue “cool-hacks” rather than to ensure the long-lasting services of his or her deliverable. In the end, however, it is always more advantageous to bring these discussions to the forefront and to address them openly rather than behaving in a “dictatorial” manner.
I have found that when the architecture group does their work correctly and involves the entire development team, they will emerge as the natural leaders. The best case is when line programmers actually seek the advice and help from the architecture group. When you see this happening, you’ll know you are on the right track.

[1] “Joel on Software” by Joel Spolsky, 2004 Apress.