"If Architects Had To Work Like Web Designers..."

25 Oct 2004 - 1:10am
9 years ago
5 replies
855 reads
Listera
2004

For your amusement, and perhaps for client/boss education.:-)

<http://twasink.net/blog/archives/2004/10/if_architects_h.html>

Ziya
Nullius in Verba

Comments

25 Oct 2004 - 4:43am
Alex Bainbridge
2003

Hey,

I wrote an article as to why building a website is like building a house!

http://www.travelucd.com/consult/4stages.php

In it I suggest that it would be much better if web designers did work like
architects! (rather than the other way around!)

alex

Alex Bainbridge
www.travelucd.com

25 Oct 2004 - 11:31am
Petteri Hiisilä
2004

Alex Bainbridge wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> Hey,
>
> I wrote an article as to why building a website is like building a house!
>
> http://www.travelucd.com/consult/4stages.php
>
> In it I suggest that it would be much better if web designers did work like
> architects! (rather than the other way around!)

You're almost right.

http://www.ftponline.com/vsm/2003_09_14th/magazine/departments/softwarearchitect/default_pf.aspx
"Today, Web designers are called programmers, programmers are called
engineers, engineers are called architects, and architects never get
called. Not only are our titles mixed up, but our community of software
practitioners is also deeply confused about the roles we play. The
confusion is even worse in the minds of the businesspeople who hire us
and set our budgets and schedules."

http://www.infoworld.com/article/03/02/12/HNproject_1.html
"The act of constructing software is, in fact, not an engineering
process," Cooper said. "Engineering to me is problem-solving, which is
very different from solution implementations, which is what programmers
[do]." Title inflation is endemic to the industry, he said. "Web
designers are called programmers, programmers are called engineers, and
engineers are called architects, and architects don't seem to ever get
called," Cooper exclaimed.

This is OK, almost:

http://www.travelucd.com/consult/4stages.php
"Project manager / architect - drives the production of the business
requirements. This document covers how the business plan is put into
practice - including all the detail on how the company and processes
will operate - but no technical details."

- First, architects aren't the best project managers and vice versa.
They are two different roles. You might find those two roles in the same
person, but even that person should choose just one role per project.

- Second, real architects always create drawings and blueprints.
Software architects almost never. Requirements aren't useful to anyone:
not the manager, not the client, not the architect, not the engineer,
not the programmer. If you have 1. blueprints AND 2. requirements,
you're much better off.

***

We interaction designers are the architects, and we should not work like
the web designer in the first article. We should solve human problems.
We translate the human problems into (feasible) technical problems.

Engineers solve the technical problems and create the engineering
blueprints. This problem solving role requires people who can and want
to improvise (with technical solutions).

Programmers construct the product for shipment. This construction role
requires people don't want to improvise, but create quality code and
effective algorithms.

As a result: there really is no such thing as "software architect". If
there was, he would be the programmer-engineer-architect multibrain
wannabe, who's responsible for most of the digital crap that the digital
world produces.

"Engineers don't build bridges - ironworkers do", said Cooper in his
keynote last summer.

"Software architect" is as silly idea as an ironworker, who has also
engineered the bridge and planned five other bridges around the town.

I mean, if this guy can create brilliant traffic architecture (less
traffic jams etc.), why the hell is he still engineering bridges? Or if
he can engineer those bridges, why would he bother actually constructing
them with ironworkers? Even if he can construct them, why should he? And
if someone ironworker is good at constructing bridges, what makes him
good at reducing traffic jams?

Sounds provocative, but really, think about it. Software architect is a
silly term. Even it such person exists, he would be terribly ineffective
doing those three roles at the same time. As they are. The evidence is
overwhelming.

Now, if everybody wants to be an architect (because it's cool :), here's
how:

- Service architect (interaction designer etc.)
- Technical architect (engineer)
- Software architect (programmer)

Labels change, but the roles are the same. Try to keep them separate.

Best,
Petteri

--
Petteri Hiisilä
Palveluarkkitehti / Interaction Designer /
Alma Media Interactive Oy / NWS /
+358505050123 / petteri.hiisila at almamedia.fi

"The unbroken spirit
Obscured and disquiet
Finds clearness this trial demands"
- Dream Theater

25 Oct 2004 - 12:26pm
Alex Bainbridge
2003

Hi Petteri,

Thanks for your thoughts.

>- First, architects aren't the best project managers and vice versa.
>They are two different roles. You might find those two roles in the same
>person, but even that person should choose just one role per project.

Yes - I agree. What I mean is that they are the same "level" - but not
neccessarily the same person.

>- Second, real architects always create drawings and blueprints.
>Software architects almost never. Requirements aren't useful to anyone:
>not the manager, not the client, not the architect, not the engineer,
>not the programmer. If you have 1. blueprints AND 2. requirements,
>you're much better off.

Business requirements ARE useful if a number of technology platforms are
under consideration. You can't give a technology company a business plan -
or a "solution" in the form of a functional specification (as this is over
specification and is often system dependent) - therefore the "business
requirements" are very useful, in my view. (Of course different projects
have different problems etc)

best wishes

alex

--
Alex Bainbridge
CEO / Senior Consultant

alex.bainbridge at travelucd.com
http://www.travelucd.com/

Travel UCD Limited : consultants in travel & hospitality online strategy &
website design

Switchboard : +44 (0)845 130 3917 Monday to Friday : 8am - 7pm
Saturday : 9am - 3pm

The information in this email is confidential. The contents may not be
disclosed or used by anyone other than the addressee. If you are not the
intended recipient, please notify us immediately at the above address. We
cannot accept any responsibility for the accuracy or completeness of this
message as it has been transmitted over a public network. Travel UCD Limited
has installed proprietary virus checking software on its system to check
that emails and attachments sent by it do not contain known viruses. However
Travel UCD Limited can give no warranty that this email is free from
infection by viruses or anything else that has contaminating or destructive
properties. Accordingly you should implement your own virus checking
procedures before opening this email and any attachments.

26 Oct 2004 - 7:54am
Petteri Hiisilä
2004

>>- Second, real architects always create drawings and blueprints.
>>Software architects almost never. Requirements aren't useful to anyone:
>>not the manager, not the client, not the architect, not the engineer,
>>not the programmer. If you have 1. blueprints AND 2. requirements,
>>you're much better off.
>
>
> Business requirements ARE useful if a number of technology platforms are
> under consideration. You can't give a technology company a business plan -
> or a "solution" in the form of a functional specification (as this is over
> specification and is often system dependent) - therefore the "business
> requirements" are very useful, in my view. (Of course different projects
> have different problems etc)

Hi, Alex.

Sorry for my sloppy articulation. I agree with you. Please let me reopen
the logic :)

1. Get the business requirements
2. Get the constraints: business, domain, technical
3. Design (this is the architect's job)
4. You now have blueprints and the technical requirements
5. Engineer
6. Program

The old way doesn't work:

1. Get the business requirements
2. Get the constraints: business, domain, technical
3. ???
4. You now have ??? and technical requirements
5. Engineer
6. Program

The question marks are filled in later, during the construction process,
by engineers and programmers.

The old way costs big time:

"The average project spends about 80 percent of its time on unplanned
rework--fixing mistakes that were made earlier in the project."

(Software Project Survival Guide, Steve McConnell)

Best,
Petteri

--
Petteri Hiisilä
Palveluarkkitehti / Interaction Designer /
Alma Media Interactive Oy / NWS /
+358505050123 / petteri.hiisila at almamedia.fi

"The unbroken spirit
Obscured and disquiet
Finds clearness this trial demands"
- Dream Theater

26 Oct 2004 - 8:25am
Elizabeth Buie
2004

My SO is an architect, and he says that *does* sound like how things are.

Elizabeth
--
Elizabeth Buie
Computer Sciences Corporation
Rockville, Maryland, USA
+1.301.921.3326

----------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
----------------------------------------------------------------------------------------

Syndicate content Get the feed