My official title at my day job is System Architect. Simple, straight forward, theoretically well defined. The wikipedia definition of a system architect makes it seem like the world is made of butterflies and honey and everyone is in love. It couldn't be less true.
Admittedly, at my place of business - a tech-saavy company with a development team of about forty very smart people - the idea of what an architect is and what he or she does is still forming. The position didn't exist up until recently. It's a little less like the wikipedia definition cited above, and quite honestly, thank God. My position is definitely more technical than it is business oriented (i.e. I still write code, et al). I tend to focus on (and possibly obsess over) design, system structure, subsystem integration and communication, and other seemingly opaque and lofty topics. Luckily, I still have to eat my own dog food and practice what I preach, so it can't all be about purity and pie in the sky conceptual cruft. If there isn't any meat on the bone, I could easily get eaten alive by my peers. (My apologies for the list of inappropriately used cliches above.)
Sometimes, the responsibilities can get hazy, though. Given that I am in a consultative rather than authoritative position, the onus is on me to prove that the solution offered is the best there is. There's no guru hat here; it's put up or shut up.
Not often, but almost with certainty, there are situations where time constraints around a project force a sense of impending doom and severely limit the time people are willing to put into discussion of a system. It happens. It can be even worse than that, though. The time it takes to have these discussions, not to mention the emotional energy when everyone in the room actually cares, is immense. People can get their egos bruised, or worse. I'm certainly not above such things, at times.
So what is a System Architect, really? Specifically, how do we prove the value of things like design patterns, integration patterns, and the like to other developers?
Posts
4 comments:
I've worked as "programmer", "developer", "coder" and other jobs , all software-related.
But then I worked for a year as a system architect for one of the largest oil majors, and would recommend the experience to any software professional. When your domain is only software, all the other issues around putting a system in place and (which normally gets forgotten) keeping it running over its lifetime are often conveniently ignored.
But when it is ones job to work out things like sizing, security, integration (internal & external), backup & restore, maintenance schedules & access, UAT, OAT, disaster recovery, support, user training & documentation, and all the other squillion and 1 things that make business-critical systems far more than just the software, it becomes clear that a good System Architect is vital to the success of any significantly sized project.
I have to agree. Seeing a slightly larger picture of what needs to happen for everything to work properly, I believe, makes one a better developer, as well. More than anything else, the design and integration aspects of the role have been the most interesting to me, personally. Thanks for your comments!
PS: Double points for using squilion in a sentence. ;)
This is what I do and I love it but if your idea of software is sitting in your cube with Eclipse all day this is -not- the job for you.
Pluses: you do a lot of different stuff - integration, design, technologist work, working with customers, working with delivery leads, often designing and coding prototypes so other people know what you're talking about.
Minuses: you do a lot of different things. That means you have to be able to context-switch bang-bang-bang, you're always going to feel 10 steps behind and you'd better know what's important and be able to focus on it unless you want consistent 15-hour work days as opposed to the normal 10.
Couldn't agree more. Thanks!
Post a Comment