Friday, April 25, 2008

Why are you rebuilding the wheel?

One of my product managers, Jason Tiret did a great interview with the B-EYE Network on the topic of 'Data Model Patterns'. As always, he did a fantastic job but again reminds me after listening to Jason's positioning on how much time is WASTED day in and day out in the (database) development life cycle.

All of us have a CONSTANT stream of inputs coming at us distracting us from our work. I think you can all empathize with me when I say that I feel my job some weeks feels like it has become a constant stream of meetings! Beyond that I usually have no less than six IM bubbles pop up at once every hour, cell phone calls, CrackBerry texts...you name it. It all yields distraction from the focus to find solutions.

Certain jobs more than others require absolute focus. I think this is most obvious in the development community where studying a software/code problem in all its dimensions to come out the other side with an elegant, scalable and abstract solution is what separates the masters from the punters. This said, business does not have time for software developers to sit in their cubes, head phones affixed blaring "...music I can focus with..." and wait for the uber-solution to bake and be presented. Cost centers like development have profitability to focus on, not to mention time to market and driving revenue from product innovations that need to be generally available in acceptable time frames with high quality.

Everyone in this day and age is looking for a productivity advantage. At its core, Google Desktop Search is precisely that for every Tom, Dick and Harry with crappy file management practices for their PC. Not everyone came from a Unix background which at its core is about elegance in how you create and traverse file paths...more often than not through key strokes which demand simple and memorable file paths than silly places in the nether regions of your C: root your fandangled mouse dragged and dropped your file...and in doing so, forgetting where the hell you put it! So while Windows has essentially enabled computing for the masses via simple GUI (e.g. mouse et al), it has essentially turned all PC's into virtual garbage dumps. This is what is happening to corporate Wiki's as well in addition to why enterprise storage needs are going the ROOF! We have become our grandmothers: 'Collectors' of digital nick-knacks we just CAN NOT purge from our proverbial virtual shelves.

But productivity 'enhancers' is not just about PC file management obviously. To make their jobs easier, clothiers leverage stencils every day to create general patterns for clothes which are then customized for the wearer. Architects leverage stencils to ensure exactness and repetition of their designs every time. Even we as a worldwide collection of business weenies download and use Visio Stencils so we can quickly mock up that perfect diagram time after time. The software world for eons has had design patterns such as the "GOF" or "Gang of Four" to ensure the exactness and more importantly the productive reuse of software architecture. Rebuilding the wheel as it were is a galactic time waster. And speed and accuracy is king.

In the data management world, this is no different. Tons of time is wasted in the areas of managing data within, to and from relational databases. Take for example ETL jobs. There's a specific reason why companies like Informatica grew to multi billion dollar market caps and why IBM gobbled up Ascential for a cool 1.1 billion. It relates to predictable, reliable and repeatable data delivery needs combined with the dramatic cost reduction in doing so which in large companies measures in the terabytes of data delivered on a weekly (if not shorter time frame) basis. COTS ETL as another example reduces the need for custom coding jobs, often written in C or Cobol for 'one off' data delivery needs and often legacy code written by folks who if hit by the proverbial bus, could threaten a company's operations.

But lest we forget, databases are software too! While the database is often protected from the itchy and curious fingers of software developers who'd love to have direct access to the databases by legions of DBAs with the worlds fastest 'access denied' routines and procedures, data architects, data modelers and database designers for some reason have traditionally been outside the progressive software development process growth. curve. On the design front, data model patterns are seeing a rise in popularity within the data architecture communities through affect they have on productivity of those responsible for thinking through data storage and management problems. The implementation of standard data management structures like Universal Data Models is the equivalent of GOF for the database sect. Obtaining a set of stencils to provide the basis of various 'core' business functions (e.g. Accounting, Orders, Shipments) in addition to specific patterns on industry-specific data problems (e.g. Insurance, Healthcare, Telco, etc) solve the following:
  • Standardization: Effectively it can establish a baseline for specific core data and teh rules that surround and are expected to be enforced on that data.
  • Reuse: Deriving from a standard template will begin to help with meta data management issues. Specifically as it relates to the data managers plight to reduce the amount of varied 'instantiations' of a business concept (e.g. "Customer") and the varieties of ways the data storage object has been implemented with wildly ranging data types, column sets, indexes, constraints, etc.
  • Raw productivity. The think-time for a highly paid data architect to 'invent' a model pattern measures in the weeks...with likely many more to perfect, review and communicate. Having a library of standard patterns to pull from to leverage quickly that are known to be 'approved' and furthermore available for new hires to leverage and accelerate their work is what any manager would consider a great use of time to establish in their quiver of 'tools'.
So, data managers, start thinking about the repetitiveness of your day to day functions and what you can be doing to eliminate some. Modelers in particular, start thinking about how your re-invention of the wheel vis-a-vis creating the same damn patterns over and over is nuking your cycles that could be focused on driving the business forward.

Thanks for reading,
Greg

0 comments: