1. The ability to create ERD diagrams or at least a facsimile thereof using UML class diagrams. Extra points awarded if it does both or if the UML class diagrams can be customized for ERD type diagrams
2. The ability to generate web-sites from the final diagrams and/or any other supplementary information that can be added to the diagram objects
3. Speaking of which, extra points awarded for being able to attach significant amounts of meta-data and/or reference external files
4. Naturally, ease-of-use will be a priority
5. As will a short learning curve
6. Ease of implementation is a bonus as will be the ability to install the tool on multiple platforms (in my case, I will test some version of windows, Snow Leopard (Macs) and Linux (likely Ubuntu).

I will also include whatever pains I went through during the installation as well, if there was any. Since I run mainly Snow Leopard and will need to virtualize environments for Windows (probably running Wine under OS X) and Linux, I am guessing there might be some. I will keep the pain of installing in the virtual environments separate from the pain of installing the tool itself (which there really shouldn’t be any).

If you have any particular data modelling tool that you would like me to test, please leave a comment below. Also, soon, I will present a compiled list of contenders, so speak up quickly .

But is that really true? In my experience, the only thing holding back a data warehouse from being able to provide near realtime data was not the data warehouse itself, but all the heavy software development processes around it, and a lack of communication with the business about the efforts put in to maintain good data quality. Both of these things are correctable, not just to provide near realtime BI, but to provide better BI in general.

Heavy Software Development Processes

This is almost always the result of doing software development using the waterfall approach. There are better ways (see: Enough Projects Drowned Under the Waterfall). By employing a software development methodology that doesn’t bury itself in hand-crafted documentation (which always requires a lot of time), and takes a multi-streaming approach to getting things done (like implementing Data Governance or taking advantage of it if it already exists), the development cycle can be shortened and more reactive to change. It also helps to have this coupled to an architecture that can support change and extension easily.

Communication with the Business

Often, in an attempt to get around the lack of communication with the development group, business users will build their own solutions to generate the BI they need quicker. This, of course, works because they are able to side-step all the (historically) heavy processes the data warehouse team has in place. What happens though, is that the solutions they build don’t take into account an enterprise view of the data, and always end up duplicating data transformation logic that already is or at least should be done somewhere else. This results from a lack of communication between the groups, and the lack of understanding between the business and the data warehouse team about the what is really needed and how what his really needed can be produced.

We Need to Talk and We Need to Act, at the Same Time

As mentioned above, the way out is to talk together, often and purposefully, and to act together, often and purposefully. But don’t wait for the talking to be done before you act, and don’t wait for the actions to be completed before talking again. Multi-streaming these activities makes them both go faster and results in a better solution through improved collaboration. Now that’s Agile Development!

Extending the Benefits

As I said, there are a few things that could have been done with CAST and its features that we did not take advantage of. For instance, I would have included the quality metrics in the vendor’s statements of work. That is, putting into the contract a section that said, “If you deliver software, these are the metrics we will use to measure the quality of that software, and if it doesn’t meet the criteria, you will either fix it, or explain the reason why not to our satisfaction.” That alone would solve a lot of commercial arguments and out-of-warrantee charges. Another thing I would do is include CAST into source project lifecycle, making its impact-analysis feature a part of the feasibility study. This would help to ensure that we caught all the platform changes the project would need to manage. This would have significantly reduced the number of extra charges brought by the vendors due to otherwise unforeseen impacts. I also would have promoted the CAST Dashboard to the rest of the business to prove to them that we had a good handle on our data warehouse. The dashboard provides a great overview of the state of your platform from a technical components point of view. Showing the other business areas that you are improving the quality of the data warehouse now and how you will improve it in the future allows you to maintain a cooperative dialog with the other business areas and helps keep you honest and open.

Again, to know more about CAST, contact the vendor. As well, you can always ask me questions in the comments below.