A Visible Viewpoint

Are You Solving Your Real "Year 2000" Problems?

Printable PDF Version

By Alan Perkins
Vice President, Consulting Services

Copyright © 1997, Visible Systems Corporation

Contents

Are You Solving your Real "Year 2000" Problems?

• The Real Problems
• About the Author
• More Information

Are you Solving your Real "Year 2000" Problems?

• Will your information systems meet the twenty-first century information needs of your organization? Do you know what those needs are?

• Can you change your information systems quickly and easily in response to changing needs and requirements?

• Do your information systems developers have the skills and experience with state-of-the-art tools and technologies that will allow them to be effective in the next century?

• Do your developers consistently develop quality information systems on time and on budget?

If you can answer "Yes" to these questions, congratulations. You are among the minority of Americans who are truly prepared for the millennium. However, if you are spending your resources fixing date management problems in old code, then you are wasting your money!

Fixing the two-position date processing problem will, at best, solve only a relatively isolated and short-term problem. The problem exists only in software modules that compare one date with another or that use the date in computations. That much is obvious. What is not obvious is that for many systems the problem will solve itself in a matter of weeks or months. The duration of a system’s date problem is the same as the length of its date processing cycle. As soon as the system passes the point in time when the date computations and comparisons produce erroneous results, the systems will work again (at least until the year 3000). In light of this, spending the estimated $2-3 per line of code to find and fix all the date processing modules in existing systems seems excessive. It might be better to simply intervene manually for the limited amount of time the problem exists.

Nevertheless, even though you may be able to suffer through a few weeks or months of increased work and reduced service, you will still have old software and its inherent problems. If you have classic systems, they most likely have many of the following characteristics. They are written in unstructured first and second-generation languages. They are poorly documented if they are documented at all. They were designed to reflect what the developers interpreted your business requirements to be ten, twenty, or thirty years ago. Since they were first implemented, they have been patched and modified over and over to fix errors and respond to changing requirements until your staff is likely fearful of making any changes because they cannot predict the results. The characteristic of classic systems that is most disturbing is that they do not actually provide the information your organization needs now, much less what it will need in the future.

Fixing a twenty or thirty-year old system is like fixing an antique car. No matter how much money you pour into it, it is still an old car with no radio and no air-conditioning, and it still needs perpetual maintenance. For the same amount of money, and often considerably less, you can get a brand-new, state-of-the-art, low maintenance automobile that will provide years of superior service and performance. While one may argue that there is both intrinsic and sentimental value for a classic car, there is absolutely no value in "classic" software. Further, the skills necessary to maintain classic software (programming in COBOL, PL1, Assembler, etc.) are not the skills that will be valuable in the coming years.

It is counterproductive and actually wastes resources to keep your old systems, even if they still work after the turn of the century. Rather, you should determine your twenty-first century information needs and acquire or develop replacement systems that meet those needs. At the same time, you should improve your internal skills, practices, and infrastructure in order to survive and succeed in the next few years.

If you have not already done so, you need to determine your future business requirements and information needs, and you need to document them in a way that is useful to both developers and users of your information systems. One of the most effective tools for documenting strategic requirements is an Enterprise Information Architecture. An enterprise architecture links your organization’s strategic plan, data architecture, application architecture, and technical architecture. An enterprise information architecture is a logical organization of the following corporate-level, enterprise-wide elements:

• Strategic goals, objectives, and strategies
• Business rules and measures
• Information requirements
• Application system descriptions
• Relationships between applications and data elements
• Technology infrastructure definition

An enterprise information architecture also establishes guidelines, standards, and services that define your systems development environment. If any of these elements do not exist in your organization, they must be developed. Even if they do exist, they must be validated. All of the elements must be documented.

When an enterprise’s architecture is so documented, it can be used to accomplish the following:

• Facilitate change management by linking your strategic requirements to systems that support them and by linking your business model to application designs
• Develop an information warehouse and executive information system that enable strategic information to be consistently and accurately derived from operational data
• Promote data sharing, thus reducing data redundancy and maintenance costs
• Improve productivity through component development, management and reuse
• Reduce software development cycle time
• Choose and implement commercial off-the-shelf systems that most closely match your business and information needs.

While you are developing and documenting your enterprise information architecture, you also need to improve your software development processes and procedures until your developers are able to consistently develop quality information systems that meet your organization’s information needs.

Your software process improvement efforts should focus on:

• Improving staff skills
• Establishing and enforcing standards
• Identifying and using metrics
• Acquiring and implementing appropriate tool sets

A critical success factor for Software Development Process Improvement is developing, documenting, and assimilating your own strategically-driven, customer-focused, model-based, software component development methodology customized to meet your organization’s unique needs and corporate culture.

Unless you have considerable in-house expertise, you will need outside consultants to serve as methodology experts, as trainers, as coaches to your staff, as skilled facilitators, and, when appropriate, as members of your project teams, in order to develop and assimilate your own methodology.

As a result of developing your enterprise information architecture and improving your system development processes:

• Productivity will improve so that better software will be developed faster
• Changing requirements will be met rapidly and well.
• Maintenance costs (typically, 70 to 80 percent of software development budgets) will be reduced significantly.
• You will be able to achieve progressively better levels of the Software Engineering Institute’s (SEI) Capability Maturity Model (CMM). The CMM is today’s most widely used benchmark for software process improvement.

Can you do this before December 31, 1999? Yes. It’s not too late. You have time to solve your real Year 2000 problems if you start now. The longer you wait to begin, the harder (and more expensive) it will be. In any case, it won’t be easy. It will take resources and hard work, but it will be worth it. Being able to determine and document your future information needs -- and armed with improved processes, skills and infrastructure -- you will be ready meet the challenges of the next century.

Back to Contents.

More Information

For more information concerning this Visible Solution, please contact: