DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for So you want to be an Enterprise Architect?
Robert Morschel
Robert Morschel

Posted on

So you want to be an Enterprise Architect?

It's the guy who sits in the meeting room with the CTO, wearing a posh pink shirt and gold cufflinks. He used to be a developer, long ago, but now he is an enterprise architect who most likely earns well over 100K and can Powerpoint with the gods.

You, however, sit there with your IDE, wondering why the dependencies are screwed again and nothing will compile. Your product owner is breathing down your neck, and nobody understands how gifted a developer you are. You dream of writing the next Facebook, but you wonder what it must be like to be an enterprise architect, or any sort of architect, for that matter.

Well, fear not. I'm about to tell you.

You're probably one already. An architect, I mean.

Certainly you are if you're any sort of decent developer. You understand that everything needs structure. That everything lives in an ecosystem it doesn't control. That your apps need to play nice with other apps. That people matter. That the software exists for the business, not the other way around.

The only difference between you and the cufflink guy is scope. You operate at a low level (for now), whereas he doesn't.

The enterprise architect is like the town planner. His job is to see the bigger picture, to help the mayor make informed decisions about the community, and to ensure the town grows in a sustainable manner.

The thinking skills are the same, even if the tools are perhaps different; and your boss is still an idiot.

Top comments (1)

Collapse
 
ben profile image
Ben Halpern

Yeah, if you aren't treating your own part of the job with the care same care as the lead "architect", you should probably start. I expect everyone to care about the structure and purpose of their code regardless of where they sit on the org chart.

Timeless DEV post...

How to write a kickass README

Arguably the single most important piece of documentation for any open source project is the README. A good README not only informs people what the project does and who it is for but also how they use and contribute to it.

If you write a README without sufficient explanation of what your project does or how people can use it then it pretty much defeats the purpose of being open source as other developers are less likely to engage with or contribute towards it.