Fog Creek Software
Discussion Board




Becoming a highly competent Architect

The "Hiring coders versus architects" thread brought out a lot of interesting issues.

What I would like to know is what makes a great Architect? (Please don't include things about being a decent coder - we have already covered that).

What are the skills possessed by such a person?

If a developer has around 1-3 years of experience, what are the things he/she should be looking at, in order to make the transition from developer to architect?

Prakash S
Monday, February 17, 2003

Define what an architect and developer are?
I have never seen an architect or anyone who called themselves an architect. Hypothetically, you have 10 person projects done by 2 people. Those 2 people then try to give specific things to do to the other 8 but still end up doing 99% of the work. Are those 2 people architects? Is a rational UML guy an architect? 

PRC 
Monday, February 17, 2003

An architect is somene who takes at least 15 minutes to think what he's doing before starting to code:-)

Daniel Shchyokin
Monday, February 17, 2003

Im with Daniel all the way here....

At my current place the have workshops to no end, spending a whackload of money....at least as much as prototyping the ting. The one who gets there quickest wins :)

Patrik
Monday, February 17, 2003

Oh geez, here we go again …

So you wanna be an Software Architect, eh? 

1) Design a complex software system by yourself and lead a group of developers to see it through to complete implementation.  This involves thorough use-case, sequence, and component documentation. This also involves implementing key proof-of-concept applications and being able to revise your design in accordance to functional and performance requirements. 
2) Put down Software Architect on your resume. 

Note that in this industry, step 1 is optional.  Just put down “Software Architect” on your resume and be able to spout forth a wide variety of industry buzzwords and acronyms in a seemingly coherent manner.    Know all the UML buzzwords and be able to crank out out pretty looking UML documents.  Presto, you are a high and mighty software architect.  If you take this approach, make sure you refer to any kind of coding activity as “trivial implementational detail”. 

From my experience with successful large-scale projects, the high-level architecture was arrived at by consensus via an iterative process that fleshed out requirements and revealed architectural necessities throughout. 

I have also had the misfortune of working with incompetent “software architects” who regarded coding as a lowly activity that was beneath them.  Needless to say, the projects were not successful.

Even Dave Cutler (the architect of Windows NT) is a tremendously skilled coder by all accounts who wrote much of the NT kernel himself.

Be warned that more mature, effective software development groups are wary of architecture-only elitist freaks and avoid them like the plague.  In reality, software design/architecture is a specific task within the development of a large-scale project.  Software architecture really isn’t a profession that’s separate from software engineering. 

Well anyways, good luck in your quest to become a Software Architect.  And make sure to keep those lowly grunt-coders in line when you do :)     

No offense ...
Monday, February 17, 2003

If the coder has 1-3 years of experience then he or she should gain more experience. You need to understand that this is practically nothing. I understand that architect sounds kind of cool and so on, but are you really able to design large complex systems after 1-3 years of development experience ... I don't think so.

FooBar
Tuesday, February 18, 2003

As stated a few times before on this forum:

Source code = Architectural design

So by definition any coder is an architect. Some code/design at a higher level laying the blue print and defining the api's for complex projects and some fill in the details, but all coders are architects. There is no difference.

Anyone or any organization still thinking that coders are merely builders implementing an architectural design are doomed to mediocrity at best.


Now about that question how to become a highly competent coder ;)

The best top level software developers are the ones that keep things simple. Modularity is the trick. As long as you keep your system in sizable modular chunks it will be easy to implement, easy to maintain and will remain scalable. You can come to such a design by refactoring. Do it any time, all the time. Don't wait 3 months. Great software is not designed, it evolves.

Where refactoring hits a brick wall is in the backup compatibility department. As long as you are in control of everything no problem. But imagine that you created an api or a database structure that is used by millions. Changing the database structure and changing the api interface is not going to increase your popularity.

Here's a (dangerous) example: Compare Linux with Windows. Linux focuses on refactoring a lot. As a result it is highly modular and clean OS, but it often breaks (binary) compatibility. Linus stated that the design is more important than binary compatibility. That's a choice. Windows is still binary compatible with older versions, but is therefore harder to refactor. Arguably, Linux is the more modular and cleaner OS, but Windows still runs those 15 year old applications. Which one is better?

A great software designer is the one that oversees all the higher issues.

Jan Derk
Tuesday, February 18, 2003

I'd agree, software architecture is a process not a job title even if, at times, I've been called one.

I've designed systems where I haven't written a line of code for them, but I've never designed something I couldn't write.  If someone can't understand the implementation of a design then they can't really be said to be designers or architects or whatever buzz word is current.

If that sounds like, 'if you don't know what it is, then you can't do it', its not intended to.  I don't know how 'architects' evolve these days, hopefully they come out of designing locally and then in collaboration with others understanding how systems hang together, how they have a tendency to be self similar, that the structure of interfaces should be consistent and make sense.

Simon Lucy
Tuesday, February 18, 2003

The biggest difference I've seen between tech leads and architects is that architects spend 60% of thier time looking outward - dealing with marketing, mgmt. or customers. Both do architecture. Most of a architects coding is non-production code (prototyping or first pass at some core libraries).

Sometimes architects are split off from the team and spend all thier time either talking to customers or going to meetings instead (usually not by choice). Be carefull what you wish for, you might not like it :)

With 1 - 3 years of experience the odds are you are just a coder - that you haven't even made the mental transition to becoming a developer yet.

I would suggest you get as varied as experience as possible, and try to get tasks that force you to think of the system, rather than just your component. 

Eric Moore
Tuesday, February 18, 2003

"Source code = Architectural design"

I don't think anyone here really believes that if you think it true. If anything, it should read:

Source code = lowest level of design

That implies that there are different levels of design, but it does not explain just how many.

One thing that should be obvious, is that the equation merely says you design your code to achieve some specific goals, but that the level of design depends on the language you code it in.
In other words, assembly requires you to solve more specific problems than Smalltalk.

So if the lowest level design depends on the language, what can be said about the highest level of design?

Practical Geezer
Tuesday, February 18, 2003

Thanks for the replies so far guys. Things are a lot clearer now.

PRC, Daniel, Patrik, Simon, Eric: Thanks for sharing the knowledge.

-----------------------------------------------------------
No offense:

What do you mean when you say: " This also involves implementing key proof-of-concept applications"

-----------------------------------------------------------
Jan:

"Some code/design at a higher level laying the blue print and defining the api's for complex projects and some fill in the details,"

This is excatly what I want to do, laying the blue print, think of the trade-offs, etc.

"A great software designer is the one that oversees all the higher issues. "

I know this purely comes from experience. Will looking at all those sample applications on MSDN be of help? How do you learn-about/ identify these higher issues?

Prakash S
Tuesday, February 18, 2003

As far as design goes I don't think anyone disagrees with the following:
- There are too many different technologies and languages for one person to be an expert in all of them. So specialism is a good thing.
- You need one body to effectively make decisions of any kind, including design decisions. That body should be small to be decisive, but not too small to be effective.
- Even if you need one body to make decisions, that does not mean that that one body also needs to be a specialist in all the aspects that a design decision might involve. So such a body needs to be supported by whatever specialists it needs and it should be able and willing to rely on those specialists.

I also think that everyone here agrees that before you don't just make design decisions for the fun of it, but because you are actually trying to solve (someone's) problems.
So you also needs to capture the problem and analyse it.

This too isn't an isolated process, because it makes no sense to try to capture a problem (define a new product for instance) if there will be no way to solve it anyhow.

So in any development effort you need to be able to understand the problem space with enough understanding of technology to realise when things might become unfeasible.
But you also need enough technical expertise to not only be able to determine feasibility, but to actually make the final product.

Some development efforts are too small to afford separate specialists for all of the fields involved.
Some development efforts are too big to affort one person to even comprehend everything at once.
But problem analysis and technical solution are also too different in some respects to expect people to have all traits or even interests to do them well at the same time. With emphasis especially on "at the same time".

Practical Geezer
Tuesday, February 18, 2003

Prakash,

You seem to be more interested in negotiating design trade offs than in actually working out the non-essential consequences of these design decitions, right?

You should realise that not all development efforts are big enough to support that kind of division of responsibilities, so it might limit your future prospects.

Not that any of this is bad in itself, but you do realise that of course?

But now I wonder, who will give you the frame of reference in which your design trade offs make sense? I mean, besides the technical reference frame, that limits your options to what is feasible?
Or more specifically, you will be trying to provide a good solution for some problem, but who defines the problem? And what will be your role in that process?
There is not one right answer of course, but it is an aspect of development that you can't ignore given your ambition...and it should further shape your knowledge and skills.

Practical Geezer
Tuesday, February 18, 2003

Practical,

Thanks for those interesting comments.

Prakash S
Tuesday, February 18, 2003

"design trade offs than in actually working out the non-essential consequences of these design decitions, right?"

- trade-offs was just an example. I am interested in all aspects of the design process/ decisons.

Prakash S
Tuesday, February 18, 2003

Hope they make sense, because I realise that without direct communication and practical examples to clarify things, it is all rather difficult to explain.

Practical Geezer
Tuesday, February 18, 2003

it is A-Ok, thanks

Prakash S
Tuesday, February 18, 2003

"- trade-offs was just an example. I am interested in all aspects of the design process/ decisons."

Can't have it all though :-)

But if you will be trying to, you might want to take a look at the human aspects of development. Or rather, the usage aspects of a product, which in the end are usually driven by human goals and objectives.
It might put technology in a different perspective if you realise that we invent technology to create solutions for real life human problems, to make our lifes easier.
Lately technology itself, and making life of machines easier seems to have become more of a goal, at the expense of our convenience and (emotional) well being.

Practical Geezer
Tuesday, February 18, 2003

" the usage aspects of a product"

- it is interesting that you bring it up, Wouldn't HCI/ Usability be more in line with "The Joel Test".

Prakash S
Tuesday, February 18, 2003

"- it is interesting that you bring it up, Wouldn't HCI/ Usability be more in line with "The Joel Test"."

I am not sure why you say that, but let me explain what I mean.
Most of the tools we build are built to fit a need.
So to build the best tool, or even decide that you actually need a tool, you will have to learn about the purpose.

You have to ask questions like:
- What are you trying to achieve?
- Under which circumstances?
- What are practical limitations?
- Or technical?
- What information is available?
- What is needed?
- Who or what uses it?
- What do you do now?
- What goes wrong?
- Or what are you missing?
- Et cetera?

Your intention is to determine what goals one is trying to achieve, in order to determine how you can best achieve those goals under the circumstances, with the means available.
Usability is one aspect of this, as is the human interface, but these are not the only ones.
All of this is intended to tell you at least the following:
- what features are needed
- what (externally visible) behaviour is needed
- what kind of information must be provided
- when, how, to whom or what
- how the information can be created

As soon as you get a firm grip on this, you can start worrying about how you are going to fill these needs with technology or without it, whatever best fits the circumstances.

My test would be, does this solution help me get my job done with more convenience and reliability? And safety if that matters.
Or does it allow me to get a job done I could not before, with as much convenience and reliability, and safety, and et cetera, as can be expected from the current state of technology.

Practical Geezer
Tuesday, February 18, 2003

You might want to checkout the Worldwide Institute of Software Architects (www.wwisa.org).  Members of this group have published a couple of books on software architecture and what it means to be a software architect.  The first one is calle "The Software Architect's Profession" and the second one is titled "Software Architect Bootcamp".  Also, Alan Cooper (book author and the father of VB) is trying to market himself as a software architect.

Engineer, scientist, builder, architect — most people seem to have a clear mental image of these roles. But put the word "software" or "computer" before any of them and the clarity turns to a dense fog. Unfortunately, that fog exists not only for the clients of software construction projects, but for the end users, and even the software professionals themselves. All these groups have trouble defining computer software related job titles, responsibilities, and roles.

It hasn't always been this way. Back when mainframe computers ruled the world and only large corporations could afford to buy and use one -- computer programmers had a clear career growth path they could follow. The technical path usually went like this:

* Programmer (0-3 years)
* Programmer/Analyst or Senior Programmer
* Systems Analyst (6 or more years)

Of course, some people took the project management route after they had put in at least a good four or five years worth of solid software development work.

Chaos and confusion reign today primarily because there are no barriers of entry into this field whatsoever (except those imposed by an individual employer).

One Programmer's Opinion
Tuesday, February 18, 2003

Why the hell haven't we EVER seen a statement in this industry such as the following:


"Design several really large and complex software systems from user requirements to deployment, and do a substantial amount of their implementation as well, and you will be deemed a software architect."


It seems to be consistently assumed in this industry that UML diagrams and being plugged into the high faluting language of CS researchers and academics qualifies one for the "architect" role. Everyone else with poorer pedigrees and less identifiable academic ties is consigned to moulder as a maintenance programmer and low ranked developer, until they burst a blood vessel out of sheer frustration and re-enter the workforce as a Metabolife distributor. Or so it seems to me.


Personally, I would *ONLY* trust a software architect who had successfully built large, complex things in the past that actually saw production. But this one practical attribute seems to be little understood or respected when it comes to hiring practices.


The college degree in some hard science or engineering would be nice but not essential, to assure that the person somewhat understood the process of invention and learning how to learn, but even that is negotiable for the right person.


All else is vanity.

Bored Bystander
Tuesday, February 18, 2003

Thanks, will check out the WWISA website.

----------

Bored,

"I would *ONLY* trust a software architect who had successfully built large, complex things in the past that actually saw production."

I belive to build such a successfully large, complex, system needs preparation, which is what I am trying to work on.

Prakash S
Tuesday, February 18, 2003

Bored,

So in the mean time, you are in limbo?

Maybe you didn't mean to give one, but your "definition" is hardly a definition. It is practical proof of competency, yes.

Practical Geezer
Wednesday, February 19, 2003

Prakash,

I am not sure what's up with you. i have this concern that you want to as quickly as possible jump into the position of 'architect' which you see as a sexy high level title. i hope this is not the case.

You have 13 years experience, but you are still working on your degree right? Is that 3 years programming assignments in school or 3 summer internships or three years you had some job designing apis at microsoft before you started school or what?

Look, you can skip the title of 'coder' and go straight to 'programmer' or 'developer' *maybe* because you have a degree, just like you get to enter the military as an officer if you do it through a ROTC program.

But you can't be a general unless you have substantial battlefield experience.

And you can't be an architect without at least 10 years of development experience.

It's not a word to slap on your resumo or business card, though there are fakers and posers that do that.

It really means that you can design at a high level and get it right.

Experience is the ONLY path there right now because this field has not come to a formal understanding of how to reliably design large systems predictably. Learning this takes a long time and don't let anyone tell you there are some easy shortcuts.

Spend 10 years as a developer working on medium and big systems. Take part in the development of industry standards. Become the lead guy on a number of projects and deliver them successfully. Mentor others in your successful ways and long history of projects delivered on time and under budget.

Then start thinking about calling yourself an architect.

Ed the Millwright
Wednesday, February 19, 2003

Ed:

>you want to as quickly as possible jump into the position >of 'architect'"

- yes, I do want to be an architect as quickly as possible, at the same time I want to make sure I learn everything related to being one/ or enough to start working as an architect and picking up other things while being one.

I do not want to be an architect because it sounds cool; with so many software projects failing/ being over budget/ not being delivered on time/ etc; it is really important to know/ understand all the details. According to me the, an architect knows most about all this (If he/ she is a good architect)

>You have 13 years experience, but you are still working >on your degree right? Is that 3 years programming >assignments in school or 3 summer internships or three >years you had some job designing apis at microsoft >before you started school or what?

I have under 2 years of internship, these 2 years include 3 internships and some consulting work that I am doing currently.

I classify projects from school as learning and do not consider or add it to my work experience.

>And you can't be an architect without at least 10 years of >development experience.

I have to disagree with you on this. You say 10 years, but more importantly what has been done in those 10 years is what I am trying to identify, learn, understand, question, etc.. and hence these questions.

>Experience is the ONLY path there right now because this >field has not come to a formal understanding of how to >reliably design large systems predictably. Learning this >takes a long time and don't let anyone tell you there are >some easy shortcuts.

I agree with you, experience is the key, and that there are no shortcuts. But if one is smart enough, starts early, and keeps preparing towards being an architect - it won't take 10 years.

>Spend 10 years as a developer working on medium and >big systems. Take part in the development of industry >standards. Become the lead guy on a number of projects >and deliver them successfully. Mentor others in your >successful ways and long history of projects delivered on >time and under budget.

Thanks.

Prakash S
Wednesday, February 19, 2003

I think my definition of architect is too soft to be of much use to you. I see an individual architect as being mostly worthless anyhow. The only real "architecture" that I've seen is where a group of senior people with different backgrounds get together and iron out the complete design of a system or product. Some team members might be hard core developers, some might be expert administrators, some might be senior product testers, and some might even be end users. However, no marketing people are needed :-)

This group then examines all of the customer requirements (often overlooked, as in: "let's just get started writing code!" :-), develops the use cases, the system architecture, and the requirements. They then work with development (who may already be part of the team or involved in iterative reviews) to ensure everything is understood and practical. They will hand off their work by reviewing the high level design of the code.

The reason I prefer groups is because most individuals, no matter how good they are, will invariably put their personality stamp on their work. In other words, it bears their unique style and may be hard for other, even senior, coders to follow.

Unfortunately, although experience and education are necessary for being an architect (don't know if 10 years is a hard rule as mentioned above though), I think key parts of the job can't be learned. I think an architect has to have natural creativity and the drive to explore new ways of doing things as well as the patience to research and overcome the limitiations of existing ways. The best architects therefore have a high degree of intellect, experience, creativity, and maturity. The maturity is key because they have to convince upper management of the plan's inherent greatness while selling the technical specs to development all while educating everyone about what they've done. Without an efficient transfer of knowledge, they're worthless.

Tom Fairlie
Wednesday, February 19, 2003

Prakash,

the best way to become an architect is to serve under several good ones, and observe, learn try to be mentored as much as you can. I think you have the right interest profile, but you lack experience. There is no substitute.
If you were handed a true architect position tomorrow you either:
a> shit your pants, which shows you are aware of the responsibilities but not ready
b> not shit your pants, which shows you are not even realising the seriousness of the job, and certainly not ready

Just me (Sir to you)
Wednesday, February 19, 2003

I always thought architects are the people who have majored in architecture.

I hired one when I redid my living room.

I'm the man!
Wednesday, February 19, 2003

"The maturity is key because they have to convince upper management of the plan's inherent greatness while selling the technical specs to development all while educating everyone about what they've done. Without an efficient transfer of knowledge, they're worthless. "

Very vaild point, Tom.

----------------------------------------------------

Just me,

I agree with you, thought professional mentorship is too expensive.

Prakash S
Wednesday, February 19, 2003

>I always thought architects are the people who have >majored in architecture.
No


>I hired one when I redid my living room.
You mean an interior designer/decorator?

Prakash S
Wednesday, February 19, 2003

Becoming an architect requires you to learn to really appreciate the tasks an architect performs.  This means more than just book-learning the stuff, it means having suffered through projects with insufficient "architecture" and later learning what could have been done to save you from that pain.  You'll be much more likely to "make it your own" and not just be blindly chasing the methodology of the moment.

Large projects are a good way to gain this kind of experience, but I also think it becomes more personal and "real" to you on as small of a team as possible, and in a smaller company.  This means you will have fewer mentorship opportunities, but you will be put into positions of responsibility sooner.  You will be required to be more of a jack-of-all-trades, which means you can't get away with having your head in the clouds when you focus on architecture, because you're most likely going to have to implement it yourself.

Working in a larger company is a luxury in comparison, because you don't have to fight as hard to carve out a niche for an architect role.  The culture in a larger company may be so architecture-oriented that you see glaring waste of effort in the way they approach it.

A good book for understanding where architecture sits in the grander scheme of things is "Requirements Analysis: From Business Views to Architecture" by David C. Hay.  It covers the role of an architect in terms of the Zachman Framework, which is an excellent tool for understanding the different roles and perspectives necessary for creating large complex systems.

If you're looking for material that has a more hands-on feel, check out "Patterns of Enterprise Application Architecture" by Martin Fowler.

ODN
Wednesday, February 19, 2003

ODN,

thanks for the reccomendations.

Prakash S
Wednesday, February 19, 2003

Check out the (current) end of the "Hiring coders versus architects" thread for Bored Bystander's comments on the reality of being an architect.  Here's a quote:

"Basically, in order to "be" an architect in this industry, you *have* to operate in 'stealth' mode. Act "down and dirty" and blue collar proletarian as your masters demand with their checkbooks, but do what it takes behind the scenes to make things actually happen." - Bored Bystander

I think that's an accurate characterization, and one you wouldn't expect from the glamorous picture you get when looking on from the outside.

ODN
Wednesday, February 19, 2003

Software architect is a very misused title.

In my opinion the job of the software architect is to fill in the gap between what the customer and non-technical management want, and the information that the software team need to start implementing the thing.

Generally this is stuff like what language(s) to use, what database to use. How stuff will communicate with other stuff. General overview of the global arrangement of modules and files. What methodologies and standards are to be enforced across the project.

These are all things that individual developers *could* do themselves but when there is a team a single decision is necessary and the architect is the one who used their experience to make an "executive decisions" about these kind of things. It's their job to see the "bigger picture" and make sure that everything matches up with what's required

It's a job which overlaps with development manager, team leader, senior developer and project manager. Often the software architect is also a developer on the team but someone needs to have the final say on things like what technology to use to communicate between modules and the architect is the person who has that job.

I've had that job title before and didn't find it was a big job. I spend 95% of my time writting software the same as anyone else on the team but I got to make decisions like we should use XML-RPC rather than SOAP or whatever.

You need someone who has day to day knowledge of using all the technolgies that might be appropriate and also can see the big picture of how everything fits together. Generally you need someone who has no specialised too much on a single technology but who has a good knowledge of actually implementing a wide range of things. And plenty of experience of how software development works. I'd very much doubt that anyone who has less than five to ten years of experince of a number of different real world development projects would make a very good architect simply because there are too many technolgies and work process related issues that they will not have been exposed to.

John Burton
Friday, February 21, 2003

Thanks John.

Prakash S
Friday, February 21, 2003

*  Recent Topics

*  Fog Creek Home