Goal-Directed Design and Legacy Systems

27 Oct 2004 - 6:37am
9 years ago
2 replies
536 reads
Narey, Kevin
2004

I'm interested in experiences where IxDers have employed GDD on an upgrade
of a large enterprise legacy system, where the implementation model
necessarily (because of the complexity of infrastructure and mammoth costs
to change it) dictates system rules to the user and therefore counters some
of their potential goals.

I understand that there needs to be compromise. I guess it's always going to
be a damage limitations exercise? Comment appreciated.

Rgds

Kevin

**********************************************************************
gedas united kingdom limited
Registered in England no. 1371338

This email and any files transmitted with it are confidential
and it may be privileged.

It is intended solely for the use of the individual or entity to
whom it is addressed.

If you have received this in error, please contact the sender
and delete the material immediately.
**********************************************************************

Comments

27 Oct 2004 - 8:57am
Petteri Hiisilä
2004

Narey, Kevin wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> I'm interested in experiences where IxDers have employed GDD on an upgrade
> of a large enterprise legacy system, where the implementation model
> necessarily (because of the complexity of infrastructure and mammoth costs
> to change it) dictates system rules to the user and therefore counters some
> of their potential goals.

Those are called constraints. In this case they are narrow, but don't
let that limit your ability to think. Thinking is cheap. So think.

> I understand that there needs to be compromise. I guess it's always going to
> be a damage limitations exercise? Comment appreciated.

To make it short:

1. First pillage, then burn. Not the technology, but the old functional
specs. "Destroy, erase, improve."

2. Do your Research, Modeling, Requirements, even early Framework. Do it
just like you would, if you could start from a blank slate.

Now you see what the _real_ functional requirements are. You can show
those to managers engineers and they can note themselves, what's the
difference between the old solution and the right solution. Find your
limits: get the constraints for your work.

Remember, for the customers and users, the user interface *IS* the app.
If you see that the old technical architecture and code base is elastic
enough, use it. If not, well, then it's up to management. It's not an
easy decision to make, but at least now it's not based on guesswork, but
facts. Hurts less :)

We DID rewrite a big enterprise application from scratch two years ago,
because the old (expensive) implementation just wasn't OK for our
client's real future needs. We knew that the new house was going to be
built on frozen lake, unless we did something about it.

3. Do the final Framework and Design within those constraints.

4. Development support

That's it.

Goal-Directed project (from scratch):
OPTIMAL--x----------------------------------------------CURRENT

With Goal-Directed upgrade: (what it should be like, if we try hard)
OPTIMAL-----------------x-------------------------------CURRENT

Without Goal-Directed upgrade: (what can we improve easily)
OPTIMAL-----------------------------------x-------------CURRENT

The important debate is in the framework phase. Try to get as close to
the "optimal" as possible, using as much "old" technology as possible.
Find pigholes. Replace rotten parts. Put the old legos in a new order.
Avoid scar tissue.

This might help:
http://www.cooper.com/content/insights/newsletters/2004_issue04/Ten_ways_to_kill_design.asp

Best,
Petteri

--
Petteri Hiisilä
Palveluarkkitehti / Interaction Designer /
Alma Media Interactive Oy / NWS /
+358505050123 / petteri.hiisila at almamedia.fi

"The unbroken spirit
Obscured and disquiet
Finds clearness this trial demands"
- Dream Theater

5 Nov 2004 - 10:25am
John Vaughan - ...
2004

Kevin:
> I'm interested in experiences where IxDers have employed GDD on an upgrade
> of a large enterprise legacy system, where the implementation model
> necessarily (because of the complexity of infrastructure and mammoth costs
> to change it) dictates system rules to the user and therefore counters
> some
> of their potential goals.
>
> I understand that there needs to be compromise. I guess it's always going
> to
> be a damage limitations exercise? Comment appreciated.

Yup.Yup. Yup.
This scenario (legacy upgrade in an environment that has lots of inertia)
pretty well describes the "standard" corporate IT engagement, as I 've
experienced it. And - as noted - that means that the tail wags the dog.

IxD rarely has a power base in such a situation (Bless you, if you do):
Very few corporate IT departments have an established UX practice. Nor is
IxD a well-integrated (well-established or well-respected) role in the
conventional IT process. So it really comes down to social skills: i.e.
leveraging your credibility

Which is to say that it's done by small steps and alliances.

* The usual First Step is to slap a fresh coat of paint on the same old bag
of shit. New Stylesheet. Implement Consistency. Reconcile Terminology.
Maybe even re-route some Navigation. Yes, it's superficial, but it provides
a basis of general good will upon which to build.

* Make the coder's life easier. Come up with techniques that really service
the implementation guys. CSS. Templates. Quicker turnaround. More efficient
management. Standards that remove the distracting task UI design from the
shoulders of programmers.

* Tech metrics help you make your argument. Work with the tech architects
to show how the new design will improve performance.

* Integrate with QA & documentation folks. They're natural allies and
they're a great resource for identifying problem areas (i.e.
"opportunities") Once you get your solutions on paper, it's (sort of)
real...

* Make the Business Analysts look good. The BA is the quickest path to
direct contact w/ the client and is presumed to be an advocate for the
client perspective.

* "Tis far better to beg forgiveness than to ask permission." Be proactive
in offering up The Better Way.

Even so, it's often a rocky road.

Syndicate content Get the feed