Prizes & Awards
My Profile
Active Members
TodayLast 7 Days
more...
|
Resources » Articles » General »
Analyzing Legacy Databases for redesign
|
Introduction
The term Legacy, as defined by the Webster’s dictionary, is something that is handed down from an ancestor or from the past.
This definition commonly describes old databases that were one developed using third-generation languages and early RDBMS
versions. The term Legacy implies that a database has been around for quite some time. In information technology, generally
anything that is old is out-of-date or obsolete.
Legacy databases usually share common functional issues such as the following:
(O) Unnecessary manual operation and maintenance administration
(O) Multiple inappropriate interfaces
(O) Performance degradation over time with the growth
(O) Difficult and costly upgrades or migrations
(O) Unsupported or discontinued software
(O) Undesirable interface appearance
(O) Incompatibilities with the new hardware and software
(O) Inadequate and deficient business process
There are just few of the issues that can trigger a proposal to redesign the legacy database.
Other scenarios prompting redesign might include these:
(O) An organization changes the way it does business, which changes process, data storage, and data access.
(O) An organization that is successful usually grows, which means more customers and more data, as an organization grows new
business process might surface along with the requirements for new data.
(O) New ways are discovered to use data to streamline business functionality.
Is it Worth the Effort?
“Is it worth is?” is the big question when considering redesign of a legacy database. This is a question that can only be
answered with careful contemplation. Is it worth the time, money, effort, and sacrifice?
A proposal to redesign a legacy database involves some of the very same questions and the same need for common sense, but
involving more technically inclined issues, of course.
There are many considerations that must be weighed before concluding whether to invest in a legacy redesign effort, or to
continue working with the current database.
Some of these include
(O) How important is it to stay with the Current Technology?
(O) What ate the hardware and software requirements?
(O) What costs are involved?
(O) What business interruptions might be encountered?
(O) Will training be required?
(O) Must the database be synchronized with another database, perhaps as a result of an acquisition or merger?
(O) What are the performance implications?
Hardware and software requirements
With any proposal to redesign a legacy database comes with the possible need to upgrade hardware and software. Besides, if
you are speeding the effort to redesign the database, why not invest a little bit more to improve the hardware components and
software that let you use that database? Keep in mind that though that investment in new hardware and software will yield
only temporary improvements as compared to a quality database design. Many organizations are becoming more willing to rely on
the new hardware and software to solve their design and performance problems because of the plummeting costs of hardware and
the increasing costs of consulting and training.
Database design might prompt you to consider these modifications of hardware components:
(O) Replace the host sever
(O) Replace the end-user workstation
(O) Increase host server disk space for growing data
(O) Increase host server memory
(O) Increase the number of CPUs on the host server
(O) Upgrade network components
Software to consider replacing with upgraded models includes:
(O) Operating system software
(O) Database software
(O) Database design tools
(O) Database administration software
(O) Application development software
Business Interruptions
Anytime a database is begin redesigned, business interruptions can occur. Interruptions in daily business can inconvenience
the customer and user of the existing system. Interruptions are generally caused during the conversion of the old system to
the new system. Some organizations are considered 24x7 shops, meaning the database must be available 24 Hours a day, 7 days a
week. There is typically no schedule downtime. Obviously there will be a degree of downtime during the implementation of a
new system. An organization is considered a 24x7 shop because of the requirements its customers have placed on data
availability and service. In a situation such as this, some downtime must be expected, accepted by the customer and carefully
scheduled.
If an online product-ordering system experiences a business interruption during the attempted implementation of a new
database, the business could experience the following:
(O) An Old database is taken offline.
(O) Customers cannot place product orders.
(O) Company attempts to place new database online.
(O) Problem arise with implementation
(O) Customers still cannot place orders.
(O) Customers become frustrated.
(O) Customers shop elsewhere.
(O) Implementation problems are resolved.
(O) The new database is brought online.
(O) Customers can now order products.
The end results for this sample business interruption might include
(O) Loss of customers, which leads to
(O) Loss of potential revenue, which leads to
(O) Loss of repeat sales to customers lost, which leads to
(O) Loss of customer referrals, which leads to
(O) Loss of more revenue
The chance of business interruptions should not be a factor in deciding whether or not to redesign a database.
Performance Issues
Poor performance is an excellent reason to consider redesigning the current system, or developing entirely new system. Most
non design related performance issues can be handled by tuning at the following levels:
(O) Operating system
(O) Database
(O) Application SQL
(O) Database de-normalization
A poorly designed database is a fundamental cause of poor performance. Even tuning at the previously mentioned levels cannot
fully optimize database performance if the database structure itself is not sound. Modifying the database structure through
de-normalization should be the last resort when attempting to tune a database.
How does the current performance measure up to use expectations? Answering this question will determine if performance is
currently a factor. If performance is acceptable, then a redesign effort is not justified using this consideration. If
performance is not acceptable then redesign might be considered. If a redesign effort is proposed, how is performance
expected to improve with the new database?
Assessment of the Existing Database
Legacy database redesign can be compared to rebuilding or remodeling an older home. The design and condition of the home’s
interior and exterior structure will determine how much work is necessary to make it livable. Any good assessment of legacy
database will provide much information regarding its strengths and weaknesses. A legacy database can be assessed by
interviewing the end users, and by the development team mining for information in database. Assessment questions to consider
are
(O) What is the type of Database – OLAP or OLTP?
(O) Is the database secure?
(O) Is the database performance acceptable to the end user?
(O) From an overall perspective, is the data relatively easy to manage?
(O) What is current size of the database?
The Effects of the Business Process Re-engineering
Re-engineering a legacy database can fundamentally alter the database structure. New SQL features such as Object Relation
Models and any Database language gives developers more flexibility within the database. 3GL programs will no longer be
required to handle common procedures, integrity rules, and other mundane tasks. The structures within the new database will
be more organized and defined. During the redesign of a legacy database, it is generally necessary to re-engineer the
existing business processes. Technology advancements are major factors in business processing re-engineering.
Migrating Legacy Data
Migrating legacy data is a major issue when redesigning a legacy database. Sometimes, developers forget during redesign that
data exists. When redesigning a legacy database, it is just as important to care for the existing data as it is to design the
new database structures. The migration of data is major part of legacy redesign. Adequate time and resources must be
allocated for data migration. Individuals can be assigned the responsibility to begin planning data migration from the
beginning of the redesign effort.
The migration of legacy data consists of these three steps:
(O) Back up the legacy data.
(O) Convert the legacy data into new format.
(O) Load the data into the new database.
As implied, the conversion of legacy data might involve combining or splitting data because of normalization and
de-normalization steps taken during the design.
Documentation
Documentation provides an overall picture of the database as a whole it must be updated as well. Redesigning brings new
business rules & architecture that should be thoroughly documented. Generally a thoroughly documented database is a well
designed database. Thorough documentation is always a complement to a database. It is an essential part of the initial
analysis and redesign strategy.
The two most important type of documentation are:
(O) System documentation
(O) End-User documentation
System documentation contains the information about the system itself. It also contains design plans, diagrams, and other
information associated with the structure of the system. The system is made up of both the back-end database and the
front-end application. So, it should contain information about the interaction between the database and the application as
the proposed hardware and software configuration. This document is used mainly by the technical team in understanding the
system.
End-User documentation should be brought up-to-date as well. End use documentation contains information about the application
interface to the database. This documentation describes the features and uses of the application, as related to the database.
|
Responses
|
No responses found. Be the first to respond and make money from revenue sharing program.
|
|