What came first – the solution or the data?
I’ve spent years in IT and no matter what I do, it keeps coming down to the data. As an Enterprise Architect, selecting a portal for a large financial company was an exercise to plan for technology that would support data in many areas.
As the years go by, Data Architects have become responsible for Web Site Content. Sadly, there are many folks out there on the Web who actually think this is Information Architect – yikes. (see my related article at Architect Boot Camp in the Information Architecture Section It is so much more than just content, although the Data Architect’s job has become so big when they have to figure out how this stuff is going to be stored and organized as well as designing custom databases for inhouse applications.
So when you are called upon to create a Solution Architecture – where do you start? The requirements is usually the first place, but often the requirements come out in the form of Data. Someone says “we have this sales information and we need to make it viewable and include the ability to create custom reports for our marketing managers.” So what do you do first? Do you create a data model? Do you pick technology to run it on? Do you choose the application technology you will use to create it?
Architecture is both a means of doing an inventory, linking and creating new stuff. The inventory in this case includes finding out if this data all lives in a database you can access directly, or whether or not you need to create a new one. It also includes an inventory check of the custom development and data warehousing technologies you have, as well as the interface technologies you have to bring them to the users.
What about security? Do you have that in place to present this information to the marketing team over the net in distant places? Or do you need to protect this stuff so Walmart can’t get it (just kidding – they are the favorite commercial villain, right next to Microsoft!).
How about resources – do you have anyone in your company who has done this before? Can you borrow someone who’s done it, or better yet, some application and resource who have done it and simply tweak it to get new data?
The longer you’ve been around as an IT Architect, the better you’ll get at recognizing patterns, inventorying them and picking them back up and dusting them off for a new solution. Ain’t life great? The best employees might also be the ones who try to do as little new work as possible!
Monday, September 26, 2005
Monday, September 19, 2005
First Blog
Welcome to the Architect Abstract Blog Edition 1
The Start of ASolution - is it Data Architecture first?
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.
The Start of ASolution - is it Data Architecture first?
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.
Subscribe to:
Posts (Atom)
