A hobbit's ring and walls of Mordor: A journey through IT
The walls of Mordor
My 6 year old daughter was fascinated watching me watch this little guy taking a ring somewhere. As I have watched all the three films it was kind of a deja vu for her. Her question was where is this guy taking this ring to. And she wanted to see where he is going to drop it. She was not really concerned about the emotion in the middle. She just wanted to see the scene where he would drop the ring. I told her taht he had to cross these really thick fortified walls of Mordor to get there not to mention the countless mountains and forests.
My little ring
Recently where I work I had a request to create a web page that displays some data from a database. Well I figured I could do that. This reminded me of Leonardo Da Vinci writing to a prospective employer that he could architect war machines while only on the last line of that long letter that he would mention that he could paint as well if an occasion arises. Any way back to the ring analogy where this web page is my "ring" and the database is my "drop point". I thought how hard can it be.
So I have talked to the team that already developed a substantial application using Struts and Websphere. The architecture they are adapting is pretty straight forward containing domain objects, and service interfaces with a possible session bean implementations for the near future.
For me to add code to this solution required that I install WSAD, DB2 Client, and QuestCentral for DB2. It somewhat disappointed me that I can't immediately take a look at the database and check its data to plan a strategy for the web page. I said, that's OK, I have patience I get to install all these nice tools and perhaps I will be super productive.
Being a large corporation, the installs are handled by a different department. So I have asked them to install WSAD. It took a week to install WSAD because it conflicted with 10 other applications that are on my box all seemingly requiring a different JVM. I had to uninstall all applications that are evenly remotely connected with Java and then proceed to install WSAD. At 2.1 Giga bytes WSAD certainly needed the respect that it demanded.
Well my luck seem to follow me. I have asked the help desk subsequently to install "db2client" and "quest central". Mistake. I should have asked to install them one after the other. Well the result is I have found after reboot that DB2 is a flurry of error messages. But the good news is "Quest central" seem to come up (Whether it will actually connect to a database is another question).
So I call back and have DB2client reinstalled.
Well Quest central won't work now and complains about not finding "DB2CLI.DLL".
On some investigation the "PATH" variable in the environment for "System" is pointing to "Path" as opposed to "PATH". That's an easy guess. So I had to change this to "PATH" and QuestCentral seem to come up OK now.
You would think WSAD the flagship of IBM would come with a db2client built in. Well I guess IBM ran out of room as they already take 2.1 Gigabytes on the hard drive. Either that or IBM figured most programmers use SQLServer anyway (Just kidding).
Even after installing all this, you would think I can click some button somewhere and I would be able to SEE the data. Well now I have to configure the Quest with whatever settings it needed to see the data. And all the manuals tell you to install tools to connect to the data but they are quite silent about where the data is. It is like finding those fires to drop the ring in. It seems the target is ever alluding.
Data is secondary
In fact it is not uncommon for projects of this nature to expect to go through the java architecture first and then walk through the service apis to see how to retrieve the data instead of looking at the rich set of SQL calls to explore the data to eventually come back to the service interfaces.
Walls of Mordor revisited
It is as if data in IT corporations is guarded and locked behind the walls of Mordor. I always wondered why these walls are so thick. Almost 3 Giga bytes of code to put a simple web page. Don't get me wrong, the architecture IS important and the service layers ARE important in a multi developer environemnts, but I suspect that it is possible to make this process a bit less austere and more experimental to arrive at the final solution.
Apparently Quest central knows its databases by reading the db2client.ini file. Well this itself is configured using yet another tool in the db2client installation. Comparing to all this, setting up a JDBC connection seem like a breeze. After this is done quest central seem to recognize the data base and opens the database.
You would think I have seen my data now. It is as if realizing that one would get here eventually, the data modellers seem to have another wall around data. This is the obscure abbreviated table and column names. They look more like mangled names. No data dictionary to figure out what these abbreviations might mean and what the significance of these fields. You are expected to know these by spending time with the database and mostly by osmosis.
The story is not that uncommon. This seem to negate one of the laws of XP that says a programmer has the RIGHT to be productive. These walls are some of the reasons why such a right can be undermined.
Familiarity and innovation
When data is so remote to the programmer, it is hard for the programmer to be innovative and come up with new ideas for viewing or manipulating the data in new ways. Because programmer is only exposed to the service APIs that may or may not allow experimentation of the data. This unfamiliarity and remoteness with data why some of the IT systems look so stiff.