A key part of the software architect’s job is producing an architectural description of the system that defines the architecture’s key functions, features, and characteristics for its stakeholders. Where do you start? What do you need to know? Nick Rozanski and Eóin Woods provide detailed answers to these questions, with useful suggestions on how to attack this fundamental document that underpins any development project.
So Now I’m A Software Architect. What Do I Actually Do?
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Another approach: you’ve been made a software architect because you exhibited the behaviors that were needed from a software architect. Keep doing what you were doing.
Seriously: think ahead, and communicate. Those two qualities are what distinguishes an architect from an engineer. That’s what I’ve been told when I was promoted from senior software engineer to software architect; actually, a year before I got promoted, I was told that I needed to work on those two as my management believed that I’d make a good architect, i.e. when I was officially made an architect I had already been working like one for over a year.
your job is now to dictate how a system should work even though you don’t have the responsiblity of coding it. This gives you the freedom to put any sort of shit together on a page, be it implementable or not, and programmers have to struggle to make your ambiguious crap into a working program. When you then complain that the programmers went “off course” and demand that they follow your “achitecture” don’t be surprised if you find a little surprise on the hood of your car at the end of the day.
Depends of the environment. You are now responsible for that architecture that cannot be implemented. I think most of the architects are carefully thinking about this. Only if you are a consultant architect you can do such a lousy job in my experience.
Nah, you can have “architects” who are so full of themselves that they convince the management that the programmers just don’t know what they are talking about. I’ve quit projects before that had such dickwads in control.
That’s exactly what I’m talking about. Programmers flee and if other come instead they will flee too. In the end the “architect” will get the kick in the butt if he’s not aware of the timing (flee himself just in time).
Well, QuantumG, you’ve just been fscked over repeatedly by bad management. I’m sorry, but it happens to all employees, no matter how competent or capable (or the reverse). That’s right, management, because once the architect has drawn up the “most glorious and perfect spec” with perspectives and viewpoints for all the pretty little stakeholders, she or he has to roll up the sleeves and get dirty doing WORK.
A good software architect is basically a TEAM LEADER. “Team” as in all players are WORKING TOGETHER. The architect is a regular engineer with additional roles (making the specs, FIXING the specs *g*, communication, long-term planning/lifecycle, etc. [see article]).
“Leader” as in she or he is responsible for the thing, doesn’t waffle out if things go wrong, and tries to keep the team motivated and focused on target.
This is called “managing a sufficiently large project”.
In smaller shops, the manager and the software architect are often the same person. In bigger shops, where the org-chart is a complex and multi-layered beast, the architect is abstracted away from management. But, like a building architect, she or he is present and in communication with the actual construction (dev team and its manager[s]) at all stages. S/He must be willing and flexible enough to roll with the punches and admit his/her mistakes, as the Real World (TM) renders all models flawed. BUT s/he must not be a doormat to the dev team to do whatever THEY want either because they will, for the sake of meeting THEIR goals, throw out the baby with the bathwater (EX: the parts of the design needed for future expansion or long-term maintainabilty but are costly and difficult to do NOW).
Problem is, again, your management either didn’t know or care. Hope I wasn’t too cynical or mean-spirited. Rant over.
–JM
Nah, you can have “architects” who are so full of themselves that they convince the management that the programmers just don’t know what they are talking about. I’ve quit projects before that had such dickwads in control.
Well, I guess I’m lucky I’ve always worked in small shops because what you describe sounds like what you would find in large shops where actual code involvement for an “architect” gets further removed.
Our architect is also our manager and head software engineer. He’s always involved with the code. And luckily any architectural decisions are always a team meeting and not dictated by anyone.
Definitely. I worked on one project, where the ‘architects’ were bureaucrats two states away, who apparently were driven to make sure the system was as expensive and useless as possible. They chose only the most expensive name-brand databases and application servers (thus being even more annoying as ‘architects’), and worked to change the system requirements and interfaces just frequently enough to ensure nothing ever got accomplished. Even not working on that project, I saw it spin its wheels for two years, getting much more expensive and complex and still not solving the problem any better than the first prototype. Yuck.
I guess it depends. Yeah, if the architect works by throwing a document “over the wall” to the engineers, I can see how it can go very wrong.
In my case, I’m personally responsible for the screwups that are related to the architecture, period. My cube is pretty much in the middle of the cubes of people for whom I architect code, so when something goes wrong I get screamed at. And whenever a bug looks like it’s related to the way two or more modules communicate, I very often have to actually debug it, or at least diagnose it.
Just copy Bill Gates! He’s the Chief Software Architect at the largest software company in the world, after all.
Sharpen up your Visio and Word skills because that’s all an “architect” does…create Visio and long-winded Word documents that only other architects pretend to read.
As an SA I agree with JBQ, communication is one of the most important tools. It both gives the chance to get everyone working as a team and also to know what’s wrong. Developers usally have no problem telling you where the problems are, it’s your responsability to act on them. The earlier you act on them the faster things will work.
Another important thing is to see and solve the problems, you don’t have to do it alone but you should lead the way.
Btw, I don’t only use Visio and Word, I use Outlook and MS Project as well
/TQH
1) Let your coding skills slide.
2) Stop really learning how any technology works beyond the surface level.
Why? Well, being an architect, you really only need to deal with high level concepts, and those concepts are, in general, language and technology agnostic.
HA! I jest, but unfortunately, most of the architects I know fall into the above mold. So sad.
Me again.. I forgot to add that I have worked with one or two really great architects. What made them great is a combination of what has been stated already AND that they didn’t do what is in my previous post. Staying passionate about the technology is sure way to inspire those working under you. Another great quality is someone who can mentor the developers under them.
Oh, if you follow those two points you sure arn’t a good SA.
/TQH