Some vendors are beginning to refer to Pick applications as "Legacy" applications. I'm not totally sure what the sales guys (you do recognize it's a sales term don't you?) mean when they say "Legacy" in that derogatory tone of voice, but these are clearly the large, proprietary mission critical applications which business's depend on. Without them, there would be no . . .? No what? No business as we know it, perhaps no company, certainly no job.
The other implication of the word (or at least the tone of voice its used in) is that these applications belong in an earlier era. They no longer fit in today's world. I get the strong impression that legacy applications are assumed to be the dinosaurs of our day, still stomping around and making a lot of noise, but dying out fast.
Is this really true? Should you put your Pick applications on a morphine drip and mark them "do not resuscitate" while you migrate at twice the speed of sound and faster than your finances will allow to the new holy grail? Are the descriptions above for legacy applications even mutually compatible? My answer to these questions is a resounding NO!
The reasons for this answer are complex. First, Legacy applications are by definition critical to your business. This means you need to continue to care for and feed them or you're in Big trouble. Pick has historically been a stable, high performance platform to build and maintain these applications. While there is some consolidation going on in the MultiValue community, there is certainly no short term risk to staying with Pick. Pick still has a number of strengths. It's fast and it's hardware portable. It's intuitive and easy to learn. It's fast. It is well matched to the real world data needs of most businesses. It's fast. It has a large base of sophisticated, mature applications.
Of course, Pick also has some significant weaknesses. The more important ones seem to be: It is not Open in today's bigger sense. It is not as formal and robust as some of the newer players. It is not truly relational and lacks true data definition dictionaries. It is seriously lacking in current application development tools.
The most commonly proposed alternative, a generic Client/Server solution, seems to offer solutions for many of these problems. Client/Server solutions are getting stronger and more capable every year, particularly in graphical application development tools. Today they are cost effective solutions for departmental tasks and to off load decision support systems from the primary database. Every data processing shop should definitely be exploring them in these roles, but I feel client/server is not yet ready for the mission critical enterprise OLTP functions.
I stressed Pick's performance not simply to reiterate one of Pick's historical strengths, but to highlight the fact that today's client/server standards are fairly weak middleware standards. Since vendors can't seem to reach agreement on the implementation of openness, they fake it with a large quantity of middleware glue. Vendor A takes the data request in his proprietary protocol, and by jamming it through many layers of stacks and conversion code, ends up at some common middle ground. Then this gets passed to the back-end vendor B who jams it through the many layers of his stacks and conversion code to make it become his proprietary protocol. Then the response data gets pushed back through these layers the other direction. Openness of a kind results, but huge quantities of memory and CPU time get consumed in the process. The point is performance still matters, especially as the terminal count goes up.
Today's path to a formal relational database with true data definition dictionaries is to use (proprietary) SQL based tools. Client/server requires one or more network operating systems, each with one or more sets of protocol stacks (often from another set of vendors) for the communications issues. Next, you would need to add transaction protection tools in the form of separate transaction processing monitors such as TUXEDO or TransArc to control transaction integrity, but even they can't deal with parts of the network or database being down. As the number of servers goes up for performance, the reliability and maintainability of the network decreases and support costs mushroom.
Additionally, and this one's really tough to swallow, You are not ready for it. Pick may have a few warts, but over the years it has done its job so well that very few shops are ready to tackle a major effort such as this. I mean no disrespect, but 99% of you don't have the staff or the expertise even think about it.
Rather than attempting to immediately abandon/migrate/replace the primary
Pick application to/with something else, my recommendations would be the
following:
First and foremost, take whatever steps needed to ensure you get the
maximum advantage and return from your current hardware and software investment.
For most of us this clearly means continuing to develop and maintain our
Pick applications.
Next, begin to explore the application of new client/server technology. It may not be ready for your main application, but it is maturing and can handle some parts of serious business applications. Recognize the Open Sever paradigm is a totally different design and programming approach. Begin immediately to invest in training yourself and your staff to understand these new technologies. Invest in the tools to learn and work in this environment. PC's, SQL engines, Network OS's, repositories, GUI development tools, etc. Each piece comes separate and each has half a dozen alternatives to evaluate.
Most large Pick applications are 10 to 20 years old. It's impossible to imagine they still accurately reflect your business needs (if they did, you wouldn't be looking at alternatives). Look at re-engineering your process work flow and data processing instead of just porting your current application to whatever's hot today. The premise of business re-engineering is basically that simply throwing technology into poorly performing processes won't work. Putting a turbo charger in a VW beetle doesn't make it a Porsche. It doesn't make sense to automate or soup-up a process that shouldn't be there in the first place. One of the best kept secrets in the industry is that most of the saving or improvements achieved during a conversion don't come from the new technology at all – they come from the "stealth re-engineering" that happens as a result of having to reexamine the process and fit it into the new environment.
Don't go into any of these projects expecting huge cost savings or a quick fix. The commonly projected savings are illusionary at best. The per seat software costs are much larger than you think, and vendors commonly ignore peripheral issues such as retraining and additional support costs. Training costs alone are estimated to be as much as one to two thousand dollars per user to become familiar with a new GUI interface. Not too surprisingly, the low end is for formal training and the high end is for self taught users. Programmers and analysts typically require six to nine months each to become proficient with these new tools and techniques, and a few may not be able to make the transition.
Avoid starting with business critical applications. Instead use new systems implementations to break-in this new knowledge while using the developing Pick open database tools to keep the corporate database up to date. Don't look at these projects from a purely technical viewpoint – instead, try to approach them from a business value or service standpoint. Will you be better able to handle today's business needs by using newer technology? Perhaps in some cases the answer is yes – but only after the painful learning curves are absorbed. Will you be better positioned to deal with tomorrow's needs? Certainly!
In summary then, I believe the following to be a reasonable outlook.