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:

Jon Skeet [C# MVP] wrote:

On Oct 25, 2:19 am, Arne Vajhøj <a...@vajhoej.d kwrote:

not_a_commie wrote:
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?
Yes. Unless standards don't mean anything in your organization.

UML is the standard for diagrams in the industry.

That doesn't mean it's the only - or even the most effective - way to
communicate.

Personally, I've never been a fan of UML.

What you did not quote was:

#He/she may not like UML. He/she may not want to use UML for
#this project. But he/she should know UML.

UML is the standard.

As Radek says, according to who? It's widely used, but that's not quite
the same thing.

There may be reasons not to use the standard.

But now knowing the standard is a very poor reason.

If your organization happens to use UML extensively, that *might* be a
reason - although it's simple enough to learn UML when necessary.

If your organization doesn't use UML, or doesn't use it very much, why
should it be a job requirement?

--
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

[Chris Mullins [MVP - C#]]

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote

UML is the standard for diagrams in the industry.

That doesn't mean it's the only - or even the most effective - way to
communicate.

Certainly true. But for the same reason I'm unlikey to write this message
out in Hmong, I'm unlikey to go with a Software Diagraming language nobody
has ever heard of.

The reason we write is (often) to be understood by as wide a range of people
as possible. If we each created a new diagraming language for each problem
we came across, the results would be a complete lack of ability to
communicate with each other.

Every professional field has a set of language tools they use to communicate
with each other. In some professions, these languages and tools have evolved
over a very long people of time and are very mature. Civil Engineers, for
example, can reasonably expect to read a set of plans put together by just
about any other Civil Engineer the world over. Electrical Engineers and
Architects as well can expect this.

In Software Engineering this is now possible through UML. This langauge
allows engineers well versed in Java, C++, .Net, Basic, and other langauges
to communicate with each other.

--
Chris Mullins

[Jon Skeet [C# MVP]]

Chris Mullins [MVP - C#] <cm******@yahoo .comwrote:

<snip>

In Software Engineering this is now possible through UML. This langauge
allows engineers well versed in Java, C++, .Net, Basic, and other langauges
to communicate with each other.

I find that UML on its own is rarely good enough to communicate
effectively - whereas a diagram and suitable explanation is good enough
*whether or not the diagram is in proper "formal" UML*.

Usually the system architecture shouldn't be on the level of "this
class and this interface" - just drawing deployment boxes is good
enough. When I *do* want to look at the class level design, I can
understand non-UML boxes with description perfectly easily - or looking
at the source itself.

--
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?=]

Radek Cerny wrote:

[snip]

>UML is the standard.

Says Who again? Maybe in some organisations, but not any global body that
matters.

Try google for the term "defacto standard".

Arne

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

Jon Skeet [C# MVP] wrote:

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

>UML is the standard.

As Radek says, according to who? It's widely used, but that's not quite
the same thing.

It is called a defacto standard.

>There may be reasons not to use the standard.

But now knowing the standard is a very poor reason.

If your organization happens to use UML extensively, that *might* be a
reason - although it's simple enough to learn UML when necessary.

If your organization doesn't use UML, or doesn't use it very much, why
should it be a job requirement?

Because an architect that does not know UML is complete out of
touch what is going on in the industry.

And that is a pretty bad characteristic for an architect.

Arne

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

Jon Skeet [C# MVP] wrote:

Chris Mullins [MVP - C#] <cm******@yahoo .comwrote:

>In Software Engineering this is now possible through UML. This langauge
allows engineers well versed in Java, C++, .Net, Basic, and other langauges
to communicate with each other.

I find that UML on its own is rarely good enough to communicate
effectively - whereas a diagram and suitable explanation is good enough
*whether or not the diagram is in proper "formal" UML*.

Usually the system architecture shouldn't be on the level of "this
class and this interface" - just drawing deployment boxes is good
enough. When I *do* want to look at the class level design, I can
understand non-UML boxes with description perfectly easily - or looking
at the source itself.

Hmm.

Are you talking about UML in general or specifically about UML
class diagrams ?

UML has a deployment diagram !

Arne

PS: The usefulness of class diagrams if often higher if they only
show what is important not everything.

[Jon Skeet [C# MVP]]

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

Usually the system architecture shouldn't be on the level of "this
class and this interface" - just drawing deployment boxes is good
enough. When I *do* want to look at the class level design, I can
understand non-UML boxes with description perfectly easily - or looking
at the source itself.

Hmm.

Are you talking about UML in general or specifically about UML
class diagrams ?

UML has a deployment diagram !

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.

PS: The usefulness of class diagrams if often higher if they only
show what is important not everything.

And again, that's just as easy to do (IMO) in an ad hoc manner as with
fully UML-compliant diagrams.

--
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:

>>Usually the system architecture shouldn't be on the level of "this
class and this interface" - just drawing deployment boxes is good
enough. When I *do* want to look at the class level design, I can
understand non-UML boxes with description perfectly easily - or looking
at the source itself.

Hmm.

Are you talking about UML in general or specifically about UML
class diagrams ?

UML has a deployment diagram !

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.

Arne

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

Jon Skeet [C# MVP] wrote:

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

>Because an architect that does not know UML is complete out of
touch what is going on in the industry.

And that is a pretty bad characteristic for an architect.

I wouldn't claim to "know" UML. I know enough to understand other
people's diagrams, and I'm perfectly capable of communicating with
other people through ad hoc diagrams with enough UML-ness where
necessary.

Am I completely out of touch with the industry? Would you throw my CV
out because it doesn't list UML as one of my core skills?

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.

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 ?

Arne

[jehugaleahsa]

On Oct 23, 7:55 pm, not_a_commie <notacom...@gma il.comwrote:

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?

UML is a standard, not something required. I find that being able to
express your ideas in the form of drawing is important, but the means
that you do it should reflect what your group best understands. Even
the inventors say it should only be used if the people you work with
can benefit from it.

This really comes down to whether you company communicates via UML. If
no one does, then it is not very important. Remember, there have been
ERDs for decades and they still aren't totally agreed upon. Does you
company need someone to know UML (it doesn't take long to learn it).