07.07.11
The SQL Crime Scene
[Cartoon]
How many SQL crime scenes has IT covered up? When was the incorrect use of SQL the major cause of a business incident and the senior management was not made aware? It happens so often, it is almost common place.
An organization I once worked with was having a major problem. Their customers were having significant delays in accessing a primary application. The application functionality had recently been extended and more customers were coming on board. The assumption was that the addition of the new customers had pushed the resources supporting the application beyond its limits.
The problem was immediate so a solution needed to come quickly. New servers were ordered to double the processing capacity. Delivery and installation were rushed and a premium was paid.
Just before the new equipment went online, one of the SQL experts accidently found a change made that he had not approved. The change was causing a single request to make multiple accesses to the database. This had an exponential effect upon the server resources. With only a minor change, the single request could be satisfied with a single database access.
The SQL was repaired and the millions of dollars of new servers were installed. Customer requests were no longer being delayed. IT had responded quickly and the business senior management was once again satisfied. However, senior management was never made aware that the hardware expenses were not actually necessary.
As an Enterprise Architect I have witnessed multiple occurrences of the misapplication of technology by aggressive and not as well trained developers. Many are not aware that relational databases must be tuned appropriately for proper SQL usage by experienced database administrators. I have witnessed developers who demanded that a different relational database be used on their project because it was better suited to their application needs. This is their defense when their application performs poorly.
Some of the worst cases I have seen occurred from developers attempting to write elaborate stored procedures. I have seen procedures with hundreds of lines of code. These types of procedures are questionable even when written by seasoned veterans. In these cases, when performance became an issue, the hardware was blamed.
Using relational databases along with SQL is complex in large organizations. To avoid crime scenes, it would be best to have all SQL written or reviewed by experts. It would also be best if all applications were reviewed during the design stage by an Enterprise Architect. Having Enterprise Architect reviews might just prevent a crime from ever happening. All data does not need to be stored in a relational database.
The Enterprise Architects can see what is coming and are already preparing. They know that this will be their time. Corporations will be able to completely focus on their business, and automation will be viewed as an agile enabler. Automation will finally become the self-service contributor that the Corporate Office has always wanted it to be. –Enterprise Architects Masters of the Unseen City
Closing the Business / IT gap.
