Introduction
With this series of posts, bite-sized in length, I intend to help folks who want to make the transition from IT Engineer to IT Architect. I’m using the generic “IT” to represent server, security, networking, etc. I can speak specifically from the perspective of a network engineer moving into network architecture, but the very high level concepts should apply across the board. I called out “IT” because I did not want to confuse it with actual construction architects. I know precisely less than nothing about being that kind of architect.
These posts won’t be very long at all and can probably be absorbed in five to ten minutes max.
What This Isn’t
I’m not going to write a prescriptive document on becoming an architect. I can’t offer any books to read, online reference materials to absorb, or other such exercises you can follow to get to that next step. Nor will I be offering a step by step guide. Influence and guidance: yes. Checklist to follow: no.
Let’s get into the first chapter.
Chapter 1 – New Tools
The engineer has access to all sorts of tools that he or she uses on a day to day basis. From the networking perspective, it’s the ever present router or switch CLI:
Systems administrators, security engineers, etc all have their same set of tools. You’re down in the device or host configuration daily, and you’re probably pretty damned good at what you do. With any luck, you’ve started moving past that and into the whole automation of those devices. If so: fantastic. If not: why? We’ll get to that in a later chapter.
Instead of staring at a CLI with a blinking cursor, architects will generally find themselves interacting with a completely different tool set. Need a hint?
Big enough hint? An architect is spending far more time writing, diagraming, and presenting than he or she is configuring things. In fact, I’d go so far as to say 90-95% of the time they’re interacting with their computer, it’s in one of those tools.
Don’t Lose The Edge
Once you’ve spent some years in an architecture role, it’s very temping, and quite easy in fact, to lose one’s technical edge. Becoming complacent and comfortable just doing diagrams, designs, and presentations because that’s your job. But don’t lose that technical edge you spent all those years as an engineer honing. That lab you suggest engineers test stuff out in? Go play in that yourself, too. Make use of virtual environments to prove out your design where possible. Make sure that if you have to fall back into that old role, you can.
Next: Strategic vs Tactical Mindsets
The next micro chapter will focus on the difference between how an architect looks at some and how an engineer does.
