Object Blues

One of the key differentiators between Mac OSX and Windows, according to quotes attributed to Steve Jobs, is that Mac OSX is Object Orientated. He places this fact at the heart of a key productivity advantage allowing Apple to turn a major release every 18 month or so. Redmond seems to take a lot longer than that for Windows. It's also enabled them to turn out the respective iPhone and iPad OS's relatively quickly.

That's fine as far as it goes but I personally have always had a bit of an issue with OOP (Object Orientated Programming) in the real world in the fact that it isn't exactly consistent with the RDBMS view of the world.

- OOP is Function Centric whereas Relational is Data Centric

IMHO OOP works well when you're writing things that are function centric (like operating systems, flashy web sites, computer games, graphics packages) but is less successful when writing large data handling systems (like data warehouses etl's, high volume transaction systems).

When we have to merge the object and relational world together we have three options. The first is to use an Object Relational Bridge technology or secondly we store Object datatypes inside an RDBMS. Both of the represent the RDBMS is an OO friendly format.

Then of course there's the third way which is to use a OOP language (like Java) and write code that doesn't conform to OOP basics negating all the benefits of Object Orientation. Guess which option I've mainly seen in my travels.

Congestion Blues

My average work commute speed is about 8mph*, which is just better than the average London rushour car journey at 7mph - worse than the horse and cart achieved at the start of the 20th Century.

Cars are great so what's went wrong? Well the problem is the tarmac and the fact that we all want to use the same bit at the same time. So if that's the problem then what are the possible answers?

- Build more roads - yet studies have shown that new roads encourage people off public transport and into cars with no net benefit to congestion.
- Build great public transport - yet most governments are too bankrupt to fund the sort of public works programs required to make major infrastructure improvements here.
- Work from home - the best commute is the one you don't have to take. With boadband and mobile technology we have the infrastructure and tools that enables us to really embrace this solution, but so far it's only a minority solution.

So what's this got to do with IT? The answer is below:

- Build more roads - is the equivalent of building more interfaces between our systems. Except that in our case each road is made from different materials, using different construction techniques, different traffic lights and different road signs.
- Better public transport - is the equivalent of building an enterise bus architecture. A great potential solution but still very costly and complex.
- Work from home - back in my earlier post "Redundancy Blues" I lamented the lack of the single corporate database. Imagine if all the data our company held was in one database. We would ensure that it ran on the best hardware, backup and recovery would be easy, we wouldn't need to build data warehouses to try to discover a single version of the truth. In short,if we had realised the potential benefits offered to us by Open Systems we'd be in a far better place than we are today.

Oh, well, must go and get my pick axe. I'm building a new road today.

*Please note that I consider myself very lucky that my commute is only half an hour. Across the world many, many people spend about 2+ hours per day commuting to work and back - that's about 25% of the time that they are actually there!

7x24

If you've been around in IT for a while you've probably come across the term 7x24 meaning 100% system uptime.

I was once employed in London by a Investment Bank as a DBA where we were developing a mission critical global options trading system. Luckily the data volumes were small, the servers and environments stable and I'd had plenty of time to work through a reliable hot standby failover solution with an excellent UNIX Sysadm. All was good in my world.

Then during the preparations for go-live the topic of Availability arose. The Project Manager threw into the mix that we had to guarantee 7x24 availability.

My response was that we could aim for 100% uptime excluding planned outages but that we couldn't guarantee it. This resulted in a bit of table-thumping, as was quite often in IT projects in an Investment Bank.

Suffice it to say that when I explained the costs and complexities involved in guaranteeing high that availability from a solutions side and the human side it the PM became a bit more reasonable, especially when I threw in the fact that neither Scott McNealy nor Larry Ellison could guarantee 100% uptime on the configuration of Solaris and Oracle that the solution was constructed.

So the lesson is that before you start discussing High Availability the metric that needs to be understood is the actual cost, either in dollars or reputation, to your business of the mission critical app being unavailable. Until you have that there's really no point in discussing the HA requirements of the system. The funny thing is that when I was consulting I designed lots of Technical Architectures and never once could I get that fact out of the client.

Where did my Open Systems go?

Early in my career I bought into the concept of 'Open Systems' in a big way. I'd been working on proprietary mainframe systems for a couple of years and figured that 'Open' had to be the way to go.

For those unitiated in the world of Open Sytsems it effectively was a euphamism for UNIX and RDBMS technology. The 'Open' basically mean that systems could be developed on one platform (say Sun) and ported to another (i.e HP or IBM) without much effort. Portability was the key to keeping your vendors sweet and it was also ensure that cross skilling your staff was easier. The same was theoretically possible with SQL based databases.

So did this happen? Not really. I used to work in a software porting team for a UNIX/RDBMS based product and because we applied strict standards to keep our code open we managed the transition without too much effort. This was not typical though. Most IT guys out there will tell you that porting from one server or database to another is a major undertaking.

That has resulted in the vast majority of IT shops out there often selecting a particular flavour of UNIX or RDBMS as its system of choice and that kind of defeats the whole argument of Open Systems if you think about it.

Redundancy Blues ....

No not that sort of redundancy ....

I used to work with files and hierarchical databases on mainframes before I saw the light and chose to focus on relational databases. I was an early adopter and technology convert/evangelist. I can hardly believe that I used to voluntarily read UNIX and RDBMS books as I'm just not that much of a nerd.

Which leads me to the point of this post. One of the big concepts at the heart of RDBMS is the adoption of third normal form (3NF), and one of the key fundamentals of 3NF is that a piece of data should only be stored once and once only (i.e. with zero redundancy).

So I'm happy to report that 20 years down the line we're happily working away with our single 'corporate database' reporting on our 'single version of the truth' becuase it would be mad if we'd just swapped technologies and repeated all the issues we used to have with the legacy technology. Just mad.