When I started working as in architecture rather than development roles 8 years ago it was rare for Architects to have development IDEs such as Visual Studio or Eclipse on their laptops. Not only were architects barred from accessing live and production systems but they also didn’t have access to test and development environments. Complex design concepts and ideas were communicated through Visio, PowerPoint or tools such as Sparx Enterprise Architect and the primary audience for these deliverables were the client and not the development team building the solution. The architecture and design of a system was a static set of documents.
So as an architect I was being actively discouraged from rolling up my sleeves and getting into the detail. I had 10 years of development experience behind me so it seemed counter intuitive to actively limit my ability to bring these skills to bear.
As an architect I am a technical leader. A key skill of this role is the ability to communicate a solution to all stakeholders regardless of their technical background. Whilst a hands off approach works well with business stakeholders, but it is not sufficient to lead a technical team.
In my story I went with the hands off approach. This enabled me to develop my client facing skills whilst neglecting my technical skills. This was encouraged through a development plan that focused on architectural certification and leadership programmes rather than technical training and conferences.
However my inner technie would not be silenced and it often jumped to the forefront when fires needed extinguishing or when technical finger pointing erupted between suppliers. A couple of years of this left a bad taste in my mouth – how much stress had been caused because I was not proactively dealing with technical risks at source, how much of the client’s budget had been burnt (or how much profit was lost by my employer) when projects over ran due to “unforeseen technical issues” which in hindsight would have been uncovered much earlier if prototyping had been done earlier in the project.
The recent resurgence of Agile on my career radar has cemented my belief that the classic hands off, BUFD (Big Up Front Design) architect is a problem rather and a solution. I have come to this conclusion because the classic Architect role is not a producer, it is a management role.
Large corporations have huge numbers of managers whose job is to guide producers rather than be producers. But companies that have applied the principles of agile to management favor products over process, and therefore favor software engineers over managers.
Architecture is still important in modern software development but it is clearly becoming a role rather than a person. People with architectural experience and aspirations can only be credible in modern software development if they are producers. Therefore they need to be able to code.
I’m not going to let my technical skills lose their relevance. It will be a challenge that I’m dealing with my listening to technical podcasts such as DotNetRocks and SE Radio on my commute and I have a Pluralsight playlist I’m working through. Most importantly I have Visual Studio and Eclipse installed on my work laptop and they are not going anywhere.