There is this rumour going around that good architects need to write (production) code. I think the term was coined by Scott Ambler of agilemodeling.com, or was it ThoughtWorks? Anyway, I don't care, because I disagree.
See, I did write code, a lot of it. I was good at it, and I still like to write code for my own pleasure, but my current, full-time role as an enterprise architect does not involve much coding. As a result, I have become slightly detached from the way code is written in our company (tools, processes, etc.) and when I do, it is laborious and frustrating. In fact, I would respectfully suggest that letting me near production code might: a) not be the best use of my time, b) be dangerous.
It's not because I'm older, or wiser, or slower, or too important to code. It's because I spend my time thinking about different abstractions: higher-level ones. The principles are the same, but the moving parts are larger.
See, I write enterprise code.
My IDE is Powerpoint ... or Word, if I'm feeling adventurous.
I am like the town planner. Sure, I could have a go at building a house, but would you really want to live in it?
I know I wouldn't.
But what do you think?
Latest comments (24)
Very well said. I love the comparison to a building architect actually building a building. It doesn't happen.
However, I think part of the problem is the "throw it over the wall" architecture. As architects we need to employ governance to make sure the developers have adhered to the architectural design. Just like a building architect would do.
Architecture without governance is useless, in my estimation. The "enterprise code" and the source code should be parallel. Where we run into problems is without governance our "enterprise code" becomes useless.
In my current company developers are transforming requirements into architecture. So, this is part of the job description of us developers all, smaller features to juniors, bigger ones to seniors. Challenging requirements are going to be discussed by the team, and decisions are made in consensus, weighing arguments. Naturally, senior developers with a lot of experience have way more influence.
We don't miss dedicated architects.
I'd say on this site the overwhelming answer will be: "Yes".
The overwhelming answer in industry is: "No". Their perspective is architects get paid multiples of what they pay a software developer, so they should get much more out of them.
I don't think there's a simple cookie-cutter answer. You have to do what's most effective both in the short and long term.
Short Term
In the short term, as an EA, you have to do whatever it takes to get the project moved along. Sometimes you're doing prototyping, project management, daily war rooms, bug bashes, integration work. And yes, much of it is being a great communicator and "force multiplier," getting dozens or hundreds of people on the same page.
Let's further acknowledge: That is both thankless and it eventually makes you useless. How do I know? I was that guy.
Long Term
Longer term, you need to rotate yourself back through development, whether that's a new assignment with your company, or a new gig entirely. Own something. Take it to production. Sustain it. This is how "architects" stay relevant.
Call it a "sabbatical" if you must, but do it.
System Architect here, I have found I am most effective when I know not just the high level, but also most of the deeper level of capabilities of the code, coding methods, systems, etc. What I don't do anymore is do the repetition necessary to go from amateur to pro. I give a wide berth for my engineers to be the professional coders/operators to solve the details and give me feedback when my knowledge pool isn't deep enough. Only some of my code is production quality and used, the rest is used to make me a better translator/listener.
So, it's about "Powerpoint architects"
You, know, 5yo kid can draw squares and arrows in Powerpoint, you don't need all this CS background and programming experience at all.
I see architect as a person, who, has a vision of connection between "what the system should do" (requirements) and "what the system is" (actual implementation). And it's important to keep this vision real - be able to sit next to developer and make it real, by capturing it into code (also this implementation sample will be priceless for less experienced dev team). Otherwise, there won't be guarantee that it even possible to implement all requirement with required quality and within required time.
I'm ok, that there may be person, who draw diagrams and doesn't code, but don't call this person architect - this is "product owner" - someone who provide requirement for implementation.
"Enterprise Security Architect" might be perfectly fine without writing any code.
Software architect should code because software architecture mostly expressed in code, somewhat in diagrams but never in Word or PowerPoint.
PowerPoint software architecture is dead at the moment it is created. Software architecture evolves with software, it is a progressive development in time and is never fixed. Only by keeping up with the product itself, how it is written, modularised, what tools, libraries and frameworks are used, what infrastructure components are good now and will probably not be as good in a month time - all this evolves continuously together with code.
If you don't program you have no business doing architecture. It's a fallacy to believe you can be in tuned with the needs of software without being involved in it's writing and deployment .
There's no way you can understand the needs of a database without being strongly aware of how the database is used. There's no way you can understand the needs of a load-balancer without being acutely aware of how the backend software works.
Architecture designed absent the programming element will inevitbly be the wrong architecture. This applies to any kind of administration and deployment. These are all under the same hood of software development.
Now, you might think that you're well enough informed that you can make appropriate decisions. The truth is that if a programming time can summarize and communicate the requirements clearly enough to an architect, they simply don't need the architect, somebody on the team can do it themselves. Architecture is not a role that requires excessive specialization.
If you still don't think this applies, then perhaps your role is more of a product manager and not an architect at all.
It is great that you work for such a large organization that they can afford a person who attends meetings as their primary contribution. Also your organization is large enough that they can afford the technology choice mistakes you make because over time the technical environment changes dramatically and you slowly become completely out of touch and start making decisions based on what you knew first hand 5-10 years ago. I do know architects that don't code - they were super good coders and decided to become "developers of talent" instead of "developers of code". A key to this pattern of individual is that they dip back in from time to time to stay abreast of the latest technology changes. Also for someone to do the architect job well without regular coding they need to be super quick learners of new technology.
Perhaps the biggest problem is that you think you can be a good architect and avoid coding. Sounds like you are rationalizing a six-figure salary+administrative assistant just to go to meetings all day long while letting the skills that got you there fade away. "Enterprise Security Architect" = "The person who can't really protect the company but can be conveniently fired if something goes wrong". A similar argument can be made for non-technical CIOs or CSOs. Nice to have, easy to fire as a symbolic gesture when something goes wrong. No actual talent loss because all they did was sling PowerPoint at meetings. Nice work if you can get it.
As an old-school architect (you know, buildings and stuff) who also writes code this topic really confuses me whenever it pops up 😂
A developer's effectiveness, particularly in the security problem domain, is dependent on familiarity with low-level details only coding can provide. Beware the architect who isn't at one with the languages that comprise his/her system.