does a software architect need UML skills?

[not_a_commie]

If you were going to hire a software architect / functional lead for
your project (written exclusively in C# including WPF, WCF) would you
require that they have UML skills?

Is being able to draw the standard UML diagrams in a notebook
sufficient, or would you require that they have some experience with
some UML program or another? Which program?

[Jon Skeet [C# MVP]]

Arne Vajhøj <ar**@vajhoej.d kwrote:

But what advantage does UML have in deployment terms over ad hoc
diagrams? Yes, I'll use the appropriate symbol for a database etc - but
very few of my diagrams are strictly UML conformant, and I don't think
it hurts communication at all.

A common symbol set requires less explanation.

But to fully know UML there's an awful lot of symbols that aren't
really necessary. For instance, when drawing a web service as part of a
deployment diagram, I'm perfectly happy to use a plain rectangle and
put "Authentica tion WS" in the box. From the context, it's always been
absolutely obvious to *everyone* (whether or not they know UML) what
"WS" means. Why learn a special symbol for it?

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Arne Vajhøj <ar**@vajhoej.d kwrote:

Personally, I think it's most important that architects are able to
come up with appropriate solutions and communicate them effectively to
their teams and managers. The nature of that communications is
relatively unimportant, IMO.

You place your UML skills a bit in the gray zone, so I don't know
if I would throw your CV out of it, but I would be worried and
probably want to check industry standard knowledge rather detailed.

Architects produce diagrams. UML is the standard (or if you prefer
another wording: the most widely used) for that.

Architects produce architecture, designs. That's the most important
thing - how reasonable their designs are, and whether or not they can
communicate them. Given the choice of someone who communicates well in
the interview but doesn't know UML, or someone who can draw UML but not
actually *talk* about it, I know I'd always go for the former.

An applicant for an architect position that does not know UML
would be handicapped in the race for the job compared with those
that do. Why has he/she not bothered to learn UML ? What else
standard concepts/technologies/tools does he/she not know about ?

I look at it a different way: there are *so* many technologies,
methodologies etc that one might spend their time learning, that by the
time you can communicate effectively without precise UML, your time is
better spent on other things.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Jon Skeet [C# MVP] wrote:

Arne Vajhøj <ar**@vajhoej.d kwrote:

>>But what advantage does UML have in deployment terms over ad hoc
diagrams? Yes, I'll use the appropriate symbol for a database etc - but
very few of my diagrams are strictly UML conformant, and I don't think
it hurts communication at all.

A common symbol set requires less explanation.

But to fully know UML there's an awful lot of symbols that aren't
really necessary. For instance, when drawing a web service as part of a
deployment diagram, I'm perfectly happy to use a plain rectangle and
put "Authentica tion WS" in the box. From the context, it's always been
absolutely obvious to *everyone* (whether or not they know UML) what
"WS" means. Why learn a special symbol for it?

There are no special symbol. You would use a stereotype.

If you used standard deployment diagram you would communicate
what is deployable units.

Boxes are much more fuzzy than a UML component symbol.

Arne

PS: I am neither super good in UML or super strict in the way I use
UML, but I use it if possible.

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Jon Skeet [C# MVP] wrote:

Arne Vajhøj <ar**@vajhoej.d kwrote:

>Architects produce diagrams. UML is the standard (or if you prefer
another wording: the most widely used) for that.

Architects produce architecture, designs.

Diagrams is the concrete incarnation (artifact) of that.

That's the most important
thing - how reasonable their designs are, and whether or not they can
communicate them. Given the choice of someone who communicates well in
the interview but doesn't know UML, or someone who can draw UML but not
actually *talk* about it, I know I'd always go for the former.

The ability to communicate verbally is absolutely a plus as well.

But that does not make UML skills less valuable.

Besides most companies prefer to have their architecture in
writing.

>An applicant for an architect position that does not know UML
would be handicapped in the race for the job compared with those
that do. Why has he/she not bothered to learn UML ? What else
standard concepts/technologies/tools does he/she not know about ?

I look at it a different way: there are *so* many technologies,
methodologies etc that one might spend their time learning, that by the
time you can communicate effectively without precise UML, your time is
better spent on other things.

Somehow I don't quite understand the last part.

It takes some time to follow what is going on in the IT industry, but
it is part of an architects job to know something about what is out
there that could be useful.

Arne

[Jon Skeet [C# MVP]]

Arne Vajhøj <ar**@vajhoej.d kwrote:

<snip>

I think we're going to have to agree to differ.

While I certainly wouldn't say that having UML is a negative attribute,
I would prefer to work with someone who was just a bit better at
talking about designs (and writing about them in plain words) than
someone who could do better UML. In other words, its value is pretty
low to me.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk