By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,376 Members | 1,115 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,376 IT Pros & Developers. It's quick & easy.

does a software architect need UML skills?

P: n/a
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?

Oct 24 '07 #1
Share this Question
Share on Google+
24 Replies


P: n/a
I certainly would not require it. Having direct UML skills implies that you
understand process models and object oriented methodology etc, but one can
have expert knowledge in these and not have UML skills.

Experience and a proven track record in the things you deem important for
your project are crucial, not UML skills.
"not_a_commie" <no********@gmail.comwrote in message
news:11**********************@v29g2000prd.googlegr oups.com...
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?

Oct 24 '07 #2

P: n/a
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?
Unless the job has some specific requirement to work with UML as the
basic architectural paradigm (for example, the team already depends
heavily on UML), I would not consider it at all. Even with such a
requirement, I would keep in mind that it's much more important to hire
a smart, adaptable person who can learn UML or other techniques as
needed than to focus on specific skill sets.

Obviously there has to be some fundamental basic skills, but those
aren't going to involve specific design techniques, or even specific
languages for that matter. I would much rather hire a smart guy who has
never seen C#, Java or C++ than to hire a dumb guy who claims to know
all three.

Of course, I may be a little biased, given that I think I have a clue
when it comes to software architecture, but had to Google UML to find
out what the heck you're talking about. :)

Pete
Oct 24 '07 #3

P: n/a
If a candidate is smart enough to consider hiring, he/she is certainly
smart enough to pick up UML quickly.

--
Andrew Faust
andrew[at]andrewfaust.com
http://www.andrewfaust.com
"not_a_commie" <no********@gmail.comwrote in message
news:11**********************@v29g2000prd.googlegr oups.com...
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?
Oct 24 '07 #4

P: n/a
On Oct 24, 12:55 am, not_a_commie <notacom...@gmail.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?
yes, and he should also be skilled in XML, BS and WTF...

Oct 24 '07 #5

P: n/a
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.

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

You would not hire a C# programmer that had never heard
about for loops no matter how smart he/she appeared to be.
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?
Tools does not matter much.

There are plenty of them. And if he knows 3 tools, then your
are probably using tool #4.

Arne
Oct 25 '07 #6

P: n/a
On Oct 25, 2:19 am, Arne Vajh°j <a...@vajhoej.dkwrote:
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. I use it where it's
absolutely required, but I wouldn't claim to know it well at all. The
important thing is that whether I'm using UML or not, with a diagram
and some explanatory words I can make myself understood.

I'd rather be able to whip up a quick picture on a whiteboard which
just has blocks showing what's going on, without worrying about
getting all the UML symbols etc correct, and talk someone through the
picture (or use written text if necessary) than spend hours on a UML
diagram.

Just MHO. And yes, I've been to job interviews where people have been
surprised and disappointed in a lack of UML. That doesn't mean they're
right though ;)

Jon

Oct 25 '07 #7

P: n/a
They should also have skills in BOX and ARRO.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

namekuseijin wrote:
On Oct 24, 12:55 am, not_a_commie <notacom...@gmail.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?

yes, and he should also be skilled in XML, BS and WTF...
Oct 25 '07 #8

P: n/a
Jon Skeet [C# MVP] wrote:
On Oct 25, 2:19 am, Arne Vajh°j <a...@vajhoej.dkwrote:
>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.

There may be reasons not to use the standard.

But now knowing the standard is a very poor reason.

Arne

Nov 5 '07 #9

P: n/a
[snip]
>
UML is the standard.
Says Who again? Maybe in some organisations, but not any global body that
matters.
Nov 5 '07 #10

P: n/a
Arne Vajh°j <ar**@vajhoej.dkwrote:
Jon Skeet [C# MVP] wrote:
On Oct 25, 2:19 am, Arne Vajh°j <a...@vajhoej.dkwrote:
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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 5 '07 #11

P: n/a
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote
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
Nov 5 '07 #12

P: n/a
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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 5 '07 #13

P: n/a
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
Nov 6 '07 #14

P: n/a
Jon Skeet [C# MVP] wrote:
Arne Vajh°j <ar**@vajhoej.dkwrote:
>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

Nov 6 '07 #15

P: n/a
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.


Nov 6 '07 #16

P: n/a
Arne Vajh°j <ar**@vajhoej.dkwrote:
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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 6 '07 #17

P: n/a
Jon Skeet [C# MVP] wrote:
Arne Vajh°j <ar**@vajhoej.dkwrote:
>>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
Nov 7 '07 #18

P: n/a
Jon Skeet [C# MVP] wrote:
Arne Vajh°j <ar**@vajhoej.dkwrote:
>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

Nov 7 '07 #19

P: n/a
On Oct 23, 7:55 pm, not_a_commie <notacom...@gmail.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).

Nov 7 '07 #20

P: n/a
Arne Vajh°j <ar**@vajhoej.dkwrote:
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 "Authentication 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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 7 '07 #21

P: n/a
Arne Vajh°j <ar**@vajhoej.dkwrote:
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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 7 '07 #22

P: n/a
Jon Skeet [C# MVP] wrote:
Arne Vajh°j <ar**@vajhoej.dkwrote:
>>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 "Authentication 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.
Nov 19 '07 #23

P: n/a
Jon Skeet [C# MVP] wrote:
Arne Vajh°j <ar**@vajhoej.dkwrote:
>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
Nov 19 '07 #24

P: n/a
Arne Vajh°j <ar**@vajhoej.dkwrote:

<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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk
Nov 19 '07 #25

This discussion thread is closed

Replies have been disabled for this discussion.