[Sigia-l] IAs vs BAs

[Alexander Johannesen]

On 6/20/07, Andrew Boyd <facibus at gmail.com> wrote:
> That said, if they [BA's]  are worth their salt, they can produce a
> plain language use case at need to illustrate their understanding
> of as-is or to-be processes.

It's a sad thing that the price of salt ain't what it used to be, but
perhaps that does explain a few things.

> Agreed entirely, no argument there. Some people take this to the
> extreme (again, using the circular argument, "some bad use of tools"
> does not equal "the tools are evil and should not be used by anyone").
> The tool is a tool, and can be used for good or for acts of stupidity,
> in much the same way that a hammer can be used to bang in a nail, hit
> your thumb, or commit a murder.

As with *anything*, it comes down to how good the person who use the
tool is, and I think we all agree on this. it seems to me that the big
problem here is that the tools are getting better at hiding crap
workmanship to the unknowing.

As an example, how a nimwit down the hall gets his pet project
approved because it *looked* good even if the idea itself is bad, not
because the managers all all stupid, but because something that looks
look will always win over useful when neither is critical to anything.

> > The advancement of prototyping tools is certainly making bureaucratic
> > documentation and deliverables culture look sillier by the day, so I can't
> > possibly be unhappy about that. :-)
>
> I'll keep going out on this particular limb - what if the deliverables
> are tools in and of themselves, and can be used for good or evil in
> the same manner as prototyping tools?

As a toolmaker myself I think I understand the pitfalls you're
referring to. Tools, just like a nice smile or a firm handshake, is
part of how people communicate their solutions or suggestions. Tools
are there to help you, but it is very easy for people to think that
*they* are good just because the tools they use are good, and I
seriously think that knowing this difference is the real difference
between someone you want to hire and someone you don't.

This has implications in all sorts of directions, from the fact that
tool-huggers usually don't know why the tools make them look better
than they really are (which is alright as long as all they do in their
job is what the tool can do well, and the future never changes, at
least not until the next version of the tool...), it pushes the end of
the will to learn deep knowledge about subject matters (why learn
about the psychology of open card sorting when my tool does it for
me?), makes people replace quality for efficency (mostly; knowledge
does breeds quality, while efficency mostly breeds workflows, even
*quality* workflows), and - my favourite pet peeve - makes people
unaware of the theory and knowledge that sits behind the tool (or
helped create it).

Now, all of this is just off my head and based on repeated
observations (and I might be terribly wrong), but every time the
electricity goes in a major city, people die. Ok, a bit over the top,
but a lot of people rely so heavily on their tools to the point of
forgetting the tools knowledge, the history of the tool, why it's
there, and slowly, forgetting what the original problem was.

Of course, all that could lead us to use PowerPoint to design
interfaces, Word to do spreadsheets and Excel to write reports, but
maybe that's a clever excercise in that whole "experiences" category
and builds character. I dunno. :-)


Alex
-- 
 ---------------------------------------------------------------------------
 Project Wrangler, SOA, Information Alchymist, UX, RESTafarian, Topic Maps
------------------------------------------ http://shelter.nu/blog/ --------