When a decision is made to replace a module, or an entire application I have found it IMPOSSIBLE to get a Green Screen Ap even through the door for a demo. Business Rules are extremely important, but the wealth of GUI or GUI like applications on the market make it easy to find one that fits the bill, or very close to it. Forget about just plain GUI, browser based is more often on the hit list. Oftentimes management and users have become so ingrained in their thinking as to how the business process flow must be, that they are blind to see an alternate route to the same end result. How often have you heard that an application is to be replaced, but they want the same exact reports that they have been receiving for the past 10 years? Change to the process flow is many times the impetus to replace a module or application in the first place. Change is not always terrible, although feared. In truth I have found the fear to be more in the hearts of the IT person who has tweaked the system over the past 15+ years and is insulted that their masterpiece is being considered a dinosaur ready for replacement. How dare they! You don't think that way when you replace your car now do you? You generally move into a newer improved model that outperforms the car you left behind. It may react a little differently, but overall the performance is better.
The one thing about GUI that management often overlooks is speed entry and the need for many areas of repetitious to be designed for speed and utilizing keyboard rather than mouse entry. Clerical staff on the other hand accustomed to green screen entry are often afraid that GUI MUST be slower. It all depends on the design. You can hit the bottom line by making it efficient, making it fast, eliminate keystrokes, and address the business issues. It's up to a creative techie to find the warm and fuzzy comfortable spot with whatever tools, not be afraid to spread their wings a bit to learn something new, and expand the horizons of a company by taking them to another level. Afterall, management may move ahead without the programmer who insists that green screen is where a system should stay... -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tony Gravagno Sent: Saturday, April 17, 2004 7:15 PM To: 'U2 Users Discussion List' Subject: RE: GUI from Mv code Re: Crystal Reports 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 -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
