Software Architect
Software Architect
A SoftwareArchitect is the bottom line on ConceptualIntegrity. S/He leans towards high-level design while a programmer leans towards low-level design.
See also ChiefArchitect, ArchitectAsKeeperOfTheFlame
Wally: I'd like to change my job title to something with "architect" in it. My dream is to do less work while being allegedly more valuable.
Catbert: The best I can do is "CodeMonkey"
Wally: How about "SoftwareSimian"?
I have yet to hear a person who worked as JustaProgrammer under the direction of a SoftwareArchitect speak kindly of that experience. [InAllMyYearsIveNever.]
Others in the team have architectural input, however, the SoftwareArchitect has the final say when there is no consensus or if she feels ConceptualIntegrity may be compromised. I've heard plenty of people speak kindly of this experience.
I've seen three possibilities for SoftwareArchitect's:
The three kinda grim possibilities you mention all sound to me more like unfortunate consequences of managerial style or corporate culture. None of them acknowledge what a good SoftwareArchitect actually contributes. Modulo social skills and people who are just plain ornery (yes that's a significant modulo), if you know what you're talking about your team will listen to you, and if you don't they won't, regardless of what your job title is.
Ideally you don't need a SoftwareArchitect at all, but if you do they should be JustAnEngineer (or better yet JustaProgrammer, since "engineering" doesn't mean what it used to) who happens to have enough experience to anticipate the likely direction of the project (and maybe some social skills too). Basically someone who can DoTheSimplestThingThatCouldPossiblyWork at a very abstract level, especially when the team as a whole can't or won't agree, and maybe even before the team is fully assembled.
The idea of an "architect" comes from the "software development is construction" metaphor. It is assumed that an architect is required to first design the thing, and to oversee construction of the thing to ensure that the design is followed and to work out any discovered flaws in the design. Not everyone considers this to be a good model for software development.
Not everyone considers this to be a good model for construction, either. Most buildings have no architect. Many people in the construction business prefer it that way.
Oy! As long as they aren't "constructing" (read, hacking) any building I plan to enter. And by the way, where to you get the data for "most buildings have no architect?" What, the plans for these buildings just pop into existence fully formed?
I got the data from StewartBrand's book "HowBuildingsLearn". He claims only 5% of buildings have architects. The rest are designed by non-architects.
Okay, that's one source. Got any other backup for that? I realize this isn't journalism, but if you are going to make a claim like that...And anyway, how does that have to do with building software?
Fred knows what he's talking about. It's not so much about authority. It's not that one member of the team wants conceptual integrity while everyone else doesn't. It's a bit more compliated than that, but not rocket science. The project manager is going to be the center of scheduling activity and schedule pressure. Someone else needs a significant voice on the project. You could call that person architect if the title suits you. It's someone to say "let's have an excellent design here, while someone else is minding the schedule." Without that person, a team may very well do work that is well below their ability, integrity-wise. When everyone is trying to optimize schedule (a game I see played too often) design quality slides. Enter the architect; let's hope she knows how to inspire. -- WaldenMathews
Another way of saying this is that people meet schedules for a living; they do elegant design out of love. Architecture is about optimizing for love. -- wm
Yet a third way of saying this is that the person under pressure to come up with a workable schedule should not also be the person who is under pressure to come up with an efficient design. It is far too likely that the schedule pressure will compromise the design.
I agree with wm. The architect is the only person that can be responsible for Quality. The Project Manager, team lead (or whatever you want to call them) is responsible for getting it out-the-door. They don't care about Quality. The day-to-day developers can't see the big pictures. So, it comes down to the Architect. But, they HAVE to have authority to keep the quality high. If they don't, its time to start PrepareResume? :-) -- David Lanouette
It's worth pointing out that, in the UK, it is illegal to call yourself an architect if you do not have the appropriate qualifications in architecture. See http://www.arb.org.uk/regs/prot.html
Section 20(1) of the Architects Act 1997, states that "a person shall not practise or carry on a business under any name, style or title containing the word "architect" unless he is a person registered under this Act". -- DonaldFisk
In which case there are a lot of criminals working in the UK IT industry.
I got the data from StewartBrand's book "HowBuildingsLearn". He claims only 5% of buildings have architects. The rest are designed by non-architects.
It's likely that 5% is made up of the most complex buildings? Then that would jibe with experience. Simple things can be made to work. The more complex something becomes the more it needs a guiding hand.
That 5% are what Brand calls "high road" buildings. Complexity isn't the discriminating factor; fashion is. Modern architects focus more on design aesthetics than complexity or functionality. The implementation details are often neglected or poorly modeled in their designs. He includes comments from builders about how blueprints from architects often ignore details for basic services, which have to be retrofitted into the design. It's a fascinating book. I highly recommend it. -- EricHodges
SoftwareArchitect the MicrosoftWay
It is not finalized yet by late 2005, but the future of a MicroSoft SoftwareArchitect (certified) will involve appearance before a review board. See http://www.microsoft.com/architecture/default.aspx?pid=share.certification&abver=FEEB2E89-4412-4C58-A7F8-9B2CA0E0BDAC
In my experience the term SoftwareArchitect is too limited. Because of the complexity of systems development today, you must have someone who is really a SystemsArchitect? - someone versed in network, hardware, databases and directories, in addition to software development at a high level. This person should be able to understand the implications (bandwidth, scalability, overall system performance) of various design choices for complex systems spanning multiple machines - as well as integration with legacy/outside systems. The days of building a system, and then throwing it over the wall for the operations team to deploy without understanding of overall scalability and performance - and more importantly being able to provide some reasonable data/testing to that effect - outside of a given machine are over (or should be). I estimate 6 out of 10 projects that I've dealt with were delivered with defects that caused the performance of the overall system (network utilization, storage utilization, or general scalability calculations) to fall outside of predefined specifications - causing failures of ancillary systems in some cases and requiring refactoring which drove the costs above the original budget. -- MalcolmCampbell
If you read the top lines, you will find the term SystemsArchitect? there already. :-) I agree that SoftwareArchitect often means experienced developer or framework developer. I also see that the role of a SystemsArchitect? might be profitable (depending on the development process though). I worked with SystemsArchitect?s that saw their job as overlapping with quality management (which we didn't have). So where do you see the upper border of a SystemsArchitect??
See: ArchitectsDontCode, JobTitles
EditText of this page
(last edited March 14, 2008)
or FindPage with title or text search