ANALYSIS: The Root of the Problem
By Mark Buchner
Because of the increasing urgency of the Year 2000 problem, it is highly likely that your organization imposed a moratorium or slow-down on new development in part of 1998 and possibly all of 1999.
Maintenance efforts continue to keep the enterprise applications running. Perhaps other unavoidable development work tied to government regulations or other non-negotiable demands on your company continue, but most likely, very little else.
During the later part of 1999 and early part of 2000, many organizations will impose a total freeze on change in their IT applications and systems. One obvious rationale for this moratorium is the issue of re-synchronization of Y2K related changes to the production systems. The freeze is simply prudent management to avoid multiple simultaneous problems and to make problem identification easier.
So even before the business starts to move aggressively forward into the 21st century and identifies lots of new opportunities to be supported by IT, there will be a backlog of previously justified new development projects, some of which may even have already been started. In addition, a backlog of infrastructure or application upgrades that were deemed non-essential for Year 2000 and, a further backlog of deferred minor enhancement projects will all need to be dealt with.
Many projects were deferred. Perhaps it was the sexy new Java/Internet/Web project. Perhaps the deployment of Windows NT or Windows 98. Perhaps the replacement of legacy systems with new versions of in-house developed applications or with enterprise resource planning (ERP) packages that still required significant customization and user training. These projects may have made sense in 1996 or 1997 but do they still make sense now, as we enter into the new millennium?
Imagine the growing frustration of end users and line-of-business managers as a result of IT inaction. After all, IT has this dismal track record of finishing projects on time and wasn't it IT that got us into this Year 2000 mess in the first place? The idea of putting appropriate information tools into the hands of the end user, is a central tenet behind and principal advantage of e-business and business intelligence.
The thing we have to do first and foremost is understand this application backlog. What still makes sense and what is highest priority? But when all is said and done, if we're not relying on packages and we're still in the in-house development business, the most important IT strategy may be to rethink or reconfirm your information systems architecture, and to specifically establish or reconfirm your application software architecture.
While clearly we have evidence that Y2K has affected application backlogs, it is not the root cause, and surely its effect is only fleeting. Backlogs have always existed. Underneath the Y2K shock lie the real reasons for application backlog.
1. Lack of an architectural model. A well designed OLTP application utilizes a normalized data design, SQL-based middleware, DBMS integration of constraints, transaction management, and data synchronization. Furthermore it externalizes the I/O design and modularizes its process logic (triggers, stored procedures.) Object oriented programming furthers code re-usability. Application openness through incorporation of client server and e-business standards eliminates hardware (client or server) dependencies. An application designed to a true OLTP model would see a Y2K challenge as no different or no more difficult than any other requirement change or addition. A well-architected solution will always deliver higher flexibility, productivity, and responsiveness to users and developers.
2. Lack of development productivity. While many customers often feel this is #1, it takes a back seat to architecture. Nonetheless, development tools have improved dramatically and what was once accomplished in months now takes days, what once took years can now be done in months. A strong combination of RDBMS features (AS/400 developers: learn about DB2 UDB!) coupled with visual programming (which eliminates coding) and object orientation (which promotes re-use) impact productivity dramatically. RPG programmers may revel in their market demand and price, but this is for maintenance of legacy code, not for new development.
3. Immature technology. Certain types of applications were not even possible fifteen, ten or even five years ago because the state-of-the-art in computer technology did not provide the power required at the price point users were willing to pay. Advances in communications through TCP/IP and the World Wide Web have enabled the masses of the world to leverage the infrastructure of the Internet. E-business, Business Intelligence (BI) and other new buzz-word technologies are only enabled today because the hardware can match it. Look no further than the massive capabilities of the new AS/400e systems for evidence. It's not just the raw hardware, its also the collaborative abilities which allow us to share requirements and facilitate joint design. Best to build the applications the business actually wants! So why consider e-business and BI? Because now you can!
The millennium challenge will come and go, it will have a visible, one-time impact on application backlogs. But the root cause of application backlogs and the basic solutions lie somewhere completely different.
Mark Buchner is president and founder of Astech Solutions Inc. (Aurora, Ontario), which applies technology to the practical needs of the AS/400 market. mbuchner@astech.com.