As many of you know, I’ve been doing a great deal of consulting with various businesses, often in the modernization arena, but also some work with databases in IBM i, Linux, and Microsoft based systems.
I am noticing a sad trend in what I see when I begin an engagement and begin to looking at existing systems.
First I see a vast range of different technologies in use with folks trying out the latest and greatest tool or web enablement language on the web, but most importantly, I see a horrible trend that takes me back to the 1970’s when I first started working with computer systems.
Over my career, I designed integrated enterprise wide database systems that used a single central enterprise database and used a form of Object Oriented design to implement components of Enterprise systems.
Today, while I see tons of new technology, systems design has become a thing of the past. Databases while using modern DBMS software have reverted to files in a file system. This has been particularly prevalent in Microsoft environments were a database represents a collection of files supporting a single application. I have noticed tremendous duplication and redundancy of data resulting in vastly different results and conflicts in data between applications.
Today we see a focus on “Data Wareheouse” where some poor analysts have to attempt to resolve conflicts between redundant data in the production applications. The bulk of an analyst’s time is spent trying to resolve differences between data collected in different applications.
When we look at application design, we see a lack of enterprise architecture and design. We see projects handed to developers who take a weak set of requirements who interpret them and implement what they think the requirement states and build systems that they believe meet the requirements with no verification of the design.
This takes me back to one of my first jobs where I was hired as a systems analyst who worked for the systems department which was separate from the programmers who worked for the data processing department. I was supposed to write a requirements document, send it via inter office mail to data processing where a programmer would interpret and implement what he or she thought I wrote. I wouldn’t see anything until I saw the result which was usually wrong.
Thee programmer would create files based on what they thought was needed. Today, we are right back to this horrible environment with no analysis, modeling, prototyping, or design.
There is no concept of Data Administration in these shops, but rather just one or two “Database Administrators” who manage the physical attributes of the DBMS Software where data is stored.
We have lost the lessons learned during the 1980’s and 1990’s and are back to the 1970’s!
Pathetic!
