Tough to find a good place for these comments. There are some interesting
observations to make on the mentality of IT people, business management,
etc..
First, on the concept of "if we're going to add a GUI we might as well get
an entirely new app": The business rules and UI should be considered as
entirely separate entities. Getting a new app with a GUI does not imply
that you're going to get equal or better business rules. This concept is
exemplified by Mark's GP client and dozens more like them. Management must
be educated to separate the idea of the UI from the business rules.
Second, I wince in pain at the concept of IT people looking at a Character
UI and deciding it's deficient, based solely on the asthetic value. How can
someone decide by the UI whether an app suits business needs? How does the
simple fact that an app has a Graphical UI make it any more functional than
a Character UI? What is the trigger in the mind of IT people that leads
from "I see a GUI" to "it must be capable of running our business" or "all
we need to do is add a couple business rules to this GUI and it will work
for us"? I really think this GUI mentality comes in part from the video
game generation where graphical games are perceived as better than the old
Pong, StarTrek, Zork, Wumpus, and Adventure games ("plugh" or "xyzzy" ring
any bells here?) In all of the rhetoric about separating the UI from the
business rules, somewhere in the minds of IT people is the idea that a
Graphical UI implies better business rules - and graphical database
management tools somehow imply a more sophisticated database. So while
people sing the praises of Object Orientation and n-tier architectures, in
the big picture they still don't really "get it".
Third, and all of this is really related, what confuses me about all of
these failed migrations is that intelligent professionals keep missing
obvious factors of migration, like feature comparisions, business needs
assessments, training, and documentation. And why do we seldom see basic
auditing to identify problems and keep a project on track - or to put a halt
to migration when critical (and I really mean critical) issues are
identified? In every one of these failed migrations there is one or more
persons in management pushing forward with some underlying business agenda,
no one wants to openly state that the plans aren't sound, the systems aren't
ready, or that the whole idea is foolhardy - and somehow hundreds of
thousands of dollars get thrown into projects like this with no one in IT to
pull in the reins and say "enough is enough, this is FUBAR".
There are answers:
- Upper management should openly listen, if not directly or immediately
heed, the advice of everyone affected by a migration, from end-users to IT
to trading partners and perhaps even stockholders.
- Upper management must insist on detailed advance planning from IT, and get
everyone to try to poke holes in the plan. Hire a consultant to poke holes
in the plan (similar to hiring a hacker to test your network security). If
the plan doesn't work, at least everyone had their input. This is far
better than post-failure finger pointing and "I coulda told them it was a
stupid plan" comments. (Yes, that will happen anyway if people ignore the
opportunity to speak up. Small people love to bask in the failure of
others.)
- Someone needs to be accountable. It seems the people who drive projects
like this into the ground have the least to lose and many people under them
to blame.
Finally, and back to the topic, about Results and the magic silver bullet
which will lead from CUI to GUI: It seems we have years to add
functionality to these CUI applications, but no time to prepare them for the
almost inevitable GUI challenge. A key factor that makes CUI non-portable
to GUI is the embedded Input and Print statements in the code. Don't wait
for tools to go GUI, prepare your app properly and you'll find many tools
that can then be used to add the GUI. If developers would take some time to
modularize their code, then migration to GUI using any number of tools can
be a relatively simple, painless, and inexpensive process, compared to
migration from linear/procedural/non-event-oriented "spaghetti" code.
Pre-emptive modularization may eliminate the need for migration, saving
months to years of aggravation and tens to hundreds of thousands of dollars
in non-recoverable expenses. And IF migration is to occur, modularization
now can facilitate the process later, allowing a company a smoother exit
strategy rather than a cold-turkey cutoff. Unfortunately these concepts
have been well known for over a decade but we continue to hear stories where
the code can't be GUItized so management decides to toss the app.
Getting management to buy-in on the time/cost of modularizing an app is
tough. The value is only perceived when the expense of a GUI or migration
is considered, and that's usually too late. I think it's important for IT
people to have these discussions with upper management, combined with
pro-active discussion of proper migration planning, _before_ those
underlying agendas start making people forget the lessons we've learned from
all of these other migrations.
Thanks for your time. Hope it helps someone.
Tony, Nebula R&D
[EMAIL PROTECTED]
--
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users
