Today I’m thinking about how important data design really is to solution design. I often wonder if our roots in Information Technology will always take over our thoughts – I used to work exclusively with data and moved on to Architecture. Now, when I work in the System Architecture space, particularly on design or solution, I revert to data – and often first.
We need to understand what the data will look like and what is needed before we can design. After all – information technology is about information and always about moving it around. We manipulate, massage, analyze and display it – what impact does it have?
Today I am trying to help clients come up with a new way to allocate files based on a bunch of business parameters. Over the years, they have bandaided the process, and morphed it based on many business needs that have nothing to do with the allocation itself. It was almost mind numbing to walk through the paths and rules that had been added over the years. I’d get
frustrated and start over and over going back through the data.
Eventually I thought “this is crazy – what are we really trying to do here, and what is the bare minimum of information we need?”. Simplifying things brought clarity. After I weeded out all of the special cases, I found that the solution was rather simple – there were two basic methods, with a third method that could be applied to one of the first two based on a third parameter. Voila – done. Add a bit of history logging to enable lots of great reports on performance, volumes, etc and we have a great solution that everyone understands.
There – that’s it – my first thought of the day – this is going to be addictive to be able to organize all of these Architecture thoughts in short bits, as I have them.