I have to tell someone.
At work, we use Oracle relational databases. Oracle databases, if you aren't familiar, are geared for very large, very complex operations, suited for massive companies storing decades worth of information. Oracle is at once revered for its reliability and reviled for its complexity and capability for obfuscation. It hails from the late 80's to early 90's, when computers were just coming out of their monolithic, batch processing days, where COBOL scripts ruled the world, and data management was very, very hard. It serves its purpose, but it takes an incredible amount of resources, both human and computer, to keep them running.
Oracle's proponents and experts are... consistently interesting people. In my experience, they are either older folks, having been elbows deep in Oracle's guts for decades, now cynical and war-worn, or younger people who are seeking professional legitimacy by putting "Oracle" on their resume.
Oracle veterans have the opinion that if something can be done on the database, it should be done on the database, given the performance gains from calculating things on the database rather than having to wait for network transfer, parsing, etc. Often, this is a reasonable policy, as the database can more easily and succinctly perform common types of calculations better than you would if you were to reinvent such a wheel. Oracle newbies adopt this premise wholesale with the promise of Oracle's superior performance and limited scope to make up for their lack of knowledge of the computing world. I know, because I have been the Oracle newbie.
However, I have the benefit of having seen the other sides of the fence. Database technology, or rather, "data persistence layers," have come a long way since Oracle was new. Forward thinking companies big enough to warrant the use of Oracle (like Google) now rarely use products like Oracle not only for their exorbitant licensing feeds and cost of operation, but also because data storage is an entirely different game now. Disk storage is cheap, computation is cheap, and large, monolithic hardware is expensive to maintain. Reliability and scalability are critical, and small, repeatable, easy to create and then throw away data fabrics are all the rage because the Internet demands it. It's no longer reasonable to have a single database server. There are just too many people. Too many smart phones.
The IT industry has been moving away from Oracle for a while now. However, much like the bank industry's dependence on COBOL programming, Oracle is still widely, pervasively used in older businesses, governments, and utilities, or really any place with money to burn, no necessity to expose themselves to the Internet at large, and a reluctance towards change. Which is where my current employers come in.
Oracle is culturally entrenched where I work. In a very early-90's setup, we have groups dedicated separately to project management, PC desktop support, network and server administration, applications programming (my group), and database administrators. For a 300+ person company, we're a relatively large IT shop, but we also support a fairly wide range of things. We're the IT department you wish you had when you call somebody at your corporate IT hotline and you get somebody a few thousand miles away. As such, people in our company are used to getting what they want from IT (much to my dismay), and frequently, the expensive, ridiculous, utility-geared software requires an Oracle database backend in order to lend some credibility to their otherwise janky and outdated programming sensibilities.
Additionally, when I say Oracle is "culturally entrenched," I mean figurative-nigh-literal trenches. Applications programmers and database administrators, while cut from the same cloth, continually compete for intellectual ownership of projects and intellectual superiority over one another. It comes part from our egos, but also due to Oracle's presence. It is a continual pain to configure, manage, and troubleshoot from a programming perspective, but it's too useful and reliable to give up. Many alternatives exists, but when you've already paid for the licenses, it's hard to let them go unused. Plus, Oracle's architecture and toolset promote a "everything goes into Oracle... and stays forever" mentality, given that the more effort that goes into writing things that interact with Oracle, the more effort one signs up for in the future to get more things to interact with Oracle. It's a vicious cycle.
That said, once things reach a working state, it tends to be that you can leave them alone for a long time.
Which is where the problem starts.
One of our engineers has been with the utility for a long, long time, a very smart guy with a dangerous level of knowledge when it comes to programming and databases. He has ownership of a number of pieces of software, some critical to managing equipment failures and doing analysis of those failures over time.
The product we started with was merely a "collector" application. It collected data, and provided rudimentary reporting and analysis tools to see how pieces of equipment were performing (or ultimately failing). We'll call this system Alpha.
A second product came along, which was another "collector," whose job was to aggregate data from multiple sources, including those from Alpha. It offered a number of nice analysis features that Alpha didn't, as well as provided the ability to "join" disparate data sources together. We'll call this system Beta.
System Alpha and system Beta needed to talk to each other. Beta knew how to talk to and get information out of Alpha, but Alpha didn't know anything about Beta. Alpha was already home to a number of interesting reporting features, but couldn't talk to Beta to make use of its additional capabilities.
This is when our engineer started making development requests to the IT department.
The requests were for additional reporting features that took information from both Alpha and Beta, and made it available in Alpha. However, inevitably, these features would then need to be made available back in Beta in order to do the same kind of analysis for the folks who only had access to Beta.
This process repeated for at least a decade.
As the requests, and implementation of them became increasingly complicated, the less people understood the full breadth of the system that was being put into place. Additionally, the requests would be handled differently between the applications programmers and the database administrators, and implemented by a different person each time. At least two generations of database administrators cycled through, and all but one of the application programmers remain (who had only worked on cursory modifications, and wasn't part of the original development).
Then I came along. And they dropped a binder on my desk. And told me to "start upgrading."
The best way to demonstrate this accreted clusterfuck is through an example of a pattern I've been discovering with some of the reports:
It is fucking nuts. Things to take away:
The example above is just one case among potentially dozens. This spaghetti mess is something that, rather than revisiting or redoing, they would just tweak to solve their immediate problem, and then walk away for as long as possible. Or as long as it took for them to find another job, or retire.
What bothers me is that among numerous IT professionals, knowing full well the ramifications of their inaction, have chosen to pass the buck for as long as possible without acknowledging the depth of the problem. It is only now that I'm being forced to upgrade one of the dependent systems has the inevitable come to pass. My choices are now limited to breaking business-critical functionality as a result of the upgrade and hindering our engineering departments, or somehow continuing the cycle of abuse.
I have to tell someone. Because it's a goddamn mess. And so that perhaps, if ever you have the ability to make such a decision, stray away from Oracle: the thing that allows great power, but also unspeakable evil.
