SIGIA-L Mail Archives: RE: [Sigia-l] Bridging the gap
RE: [Sigia-l] Bridging the gap
From: David Bishop (bishop_at_maya.com)
Date: Wed Sep 03 2003 - 10:03:38 EDT
> I have been told that one of my roles as an information
> architect includes bridging the gap (or chasm) between the
> design and technical teams.
> 1. Have you any project or process specific evidence that the
> IA is indeed the missing link?
At the risk of being trite, just about every project we've worked on as
consultants. At MAYA, we view the Information Architecture as the bridge
between the System Architecture (the mechanism that makes the thing work)
and the User Interface (the part that transduces information to and from the
I'm not super-happy with the language, but read what we say here on our
...I think the important notion to understand is our point about the IA
being the only part of a system that you "really own." A better way to say
this is that it is one of the longest-lasting and slowest-changing things,
and that the UI and the system internals can change around it. Consider a
bank -- the IA can describe how money flows and the services the bank
provides and what benefits a customer gets. This is the crux of what it is
to be a bank: it provides security, it lends money, it compensates you in
the form of interest, and so on. One can imagine an entity-relationship
diagram that explains all this: customers store money; banks provide
security to customers; customers borrow money; borrowers pay interest;
interest is passed on to customers who are storing their money, and so on.
The user interface can change -- tellers versus drive-throughs; ATMs,
on-line banking; checks versus money orders, etc. The system architecture
can change, too -- trucks of cash versus wire transfers; individual banks
versus chains versus consortiums.
So having the folks responsible for the UI understand the IA is *critical*.
And having the folks responsible for the system, the mechanism, understand
the IA is *critical*.
IA is the bridge. It is the glue.
> 2. What types of deliverables have the potential for
> communicating to both audiences?
We've used all sorts of deliverables. Usually diagrams of some kind. Often
entity-relationship diagrams or a variant. Often navigation maps (like site
maps). But don't get too hung up on the "right answer," here. It requires
user-centered design -- consider the people you are trying to get to
communicate. To what would they respond best?
Consider some of these examples:
A few diagrams for a client developing a digital library:
(click the Information Architecture link at the right for a larger picture)
Here's an "old school" diagram we created a number of years ago using some
posterboard, scissors, and some sticky circles. You can't really tell at the
scale of this image, but it's an IA diagram that charts the relationship
between many of the elements of a shipping system
(click the little picture at the right for a larger view)
MAYA Design, Inc.
When replying, please *trim your post* as much as possible.
*Plain text, please; NO Attachments
Searchable list archive: http://www.info-arch.org/lists/sigia-l/
Sigia-l mailing list -- post to: Sigia-l_at_asis.org
Changes to subscription: http://mail.asis.org/mailman/listinfo/sigia-l
This archive was generated by hypermail 2.1.2
: Sun Nov 23 2003 - 22:55:54 EST