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.

The Solutions

To address the challenge of maintaining up-to-date, complete and accurate technical documentation of the data warehouse platform, CAST was used to analyze the production platform after every deliverable. The Enlighten tool was made available to all the internal and external staff working on data warehouse projects, and the web-site created by CAST was made available to the entire organization.

And because we also had several on-going projects  (as everyone does), we would also analyze the UAT environments from time to time as well. This allowed the impact analysis to capture changes to a future version of the data warehouse platform as well as the current one.

The code quality analysis was reviewed on a periodic basis to keep track of the “hotspots”, as these problem areas would be included in projects that touched on those areas, so that the number of potential problem areas could be reduced over time.

The Benefits

By using CAST, we were able to reduce the costs of project affecting the data warehouse while increasing the quality of the deliverables. These cost saving were realized by having all the technical information of the platform in one place, always up-to-date, and easily available and navigatable. As well, by automating many of the otherwise manual tasks that never seem to get done, the cost of testing and doing impact analysis was signicantly reduced. Also, the abilty to set the expectations of quality and being able to measure those expectations objectively, let to better, more bug-free code being delivered on-time and under budget.

Recommendation

I highly recommend this product to anyone who has a large system or systems that they need to get under control or not lose control of. CAST helps to implement a layer of automated governance that can be otherwise far more expensive to implement, and, as mentioned above, can certainly reduce project costs through increased productivity and increased quality of deliverables. I haven’t worked on a project since where I didn’t wish CAST had been implemented there as well.

In the next post, I will look at some things that we could have done with CAST to further improve our business processes, and a couple of things to take into consideration when using CAST. If you have any questions, I urge you to contact them, and you can also leave questions in the comments below and I will answer the to the best of my ability.

I recently worked with an organization where we had looked at a tool that was able to analyze all the source code for the ETL jobs of their data warehouse and provide several benefits to the organization as a result. The tool is called CAST, and comes from a company called Cast Software.  I was hesitant to implement such a tool there because I felt that the data warehouse group didn’t operate at a sufficient level of maturity to be able to fully exploit the features of this software, and as a result, would be implementing a tool that would never get used. However, during the presentation of the tool and its features by the CAST team, I, for one, was so impressed by what the tool could do in terms of analyzing source code, and even more, what it does with the information gathered from that analysis, that we decided to implement the tool. In the end, the data warehouse group was able to take advantage of the tool, although not as completely as I would have liked. In the next few articles, then, I will examine in more detail, why we decided to implement the tool, what it could do out of the box, what it couldn’t do out of the box (but could do later, with a little customization), what we did with it, and what we didn’t do with it but probably should have.

The Challenges

Because our data warehouse had been built in bits and pieces over a number of years, there was a lack of cohesive technical documentation. It existed, of course, but in documents spread over hundreds of project directories, and in the heads of the internal staff and in the heads of the external staff, if they were still there. This was always a problem in that, a) they were not sure what they had, or how it was built, b) doing an impact analysis across all the ETL tools involved (unix shell scripts, DataStage, custom PL/SQL, and some java) was very labour intensive, and c) with all the ongoing projects for the data warehouse, it was impossible to properly evaluate the quality of the deliverables from the vendors (most importantly, the source code).

Getting More Done Better With Less

We originally looked at CAST to solve the above problems. The tool could analyse all the source code across all the ETL tools we had, and in doing so, could provide a) complete technical documentation of the production data warehouse platform, b) end-to-end impact analysis, and c) provide a quantitative analysis of the source code delivered by the vendors and provide industry-standard measures of the quality of the code. Having all this would, in turn, allow us to a) significantly reduce the learning curve for new internal staff and external vendors, b) significantly reduce the time and increase the quality of the impact analysis studies they carried out, and c) enable automated enforcement of the development standards and guidelines, reducing the number of errors in the deliverables whilst improving the overall code quality.

Code Analysis

CAST can parse just about all the source code you can throw at it, regardless of the language or tool it was written in. If they don’t already have a parser written for a specific tool, their universal parser can be tweaked very quickly. With our organization, we had some source code in Unix shell scripts, some ETL written using DataStage, and some just in PL/SQL. The reporting tool used was Business Objects. CAST had no trouble with anything we gave it. The one issue we did have was that the PL/SQL parser was not equipped to deal with dynamic SQL and PL/SQL that was data driven. Much to my surprise, though, it took the CAST Switzerland team only a handful of days to update their PL/SQL parser to handle this problem! When they were done, we had a tool that could analyze all the source code in our platform, along with the databases (mainly Oracle) so that we ended up with complete technical documentation (albeit using the included Enlighten tool, with a bit less on the generated web pages). To put it succinctly, they managed to do in 12 days, what we had not been able to do in almost 10 years!

Impact Analysis

With all the source code analyzed, and all the database objects analyzed, the CAST Enlighten tool could generate an automated impact analysis in the time it would take to get a coffee before starting to do the analysis manually. In the past, doing a thorough impact analysis required extensive reviews of document when you could find them, reading all the source-to-target documents if they were up-to-date, talking to the developer if they were still on-site, and in the end, reading all the source code line by line if you could get access to it. As you can imagine, this was not only time-consuming, but frought with errors and omissions. It could take weeks on a larger change, but with CAST, it could be done in an afternoon, with just a little digging inside the tool itself.

Code Quality

Another big issue we suffered with was that there were never the resources within the team to do a proper inspection and review of the source code deliverables from the vendors. In some cases, the projects were just too big to manage with our small internal staff size, in other cases just too small to worry about. This led to visicous, lengthly cycles of testing and re-developing, as new bugs were not found until user acceptance testing, or, even worse during the pre-production system testing, and in a few cases during use after production rollout. Not to mention the inevitable commercial disagreements between the vendors and us where one would blame the other for the delays and the errors. Since we didn’t have the internal resources to do this due-diligence of the vendor deliverables, a lot of problems like the ones mentioned above crept into every project, pushing back delivery schedules and blowing the budgets of the projects.

The CAST tool, because it comes with a huge number (>600 when we used it) of quality measures for source code, and because you can modify them to your taste or add new ones, all the delivered source code could be checked against these quality measures, even before they were manually tested. I didn’t pretend to understand all the types of measures they would calculate against the source code (things like Cyclomatic Complexity are the things of rocket scientists, I’m sure), but what I did understand was that they could tell you in an instant how well written the code was, how well it complied with your internal standards as well as industry standards, and where in the code you might have a trouble spot later on (if the complexity measure was too high). All these things could be used to do an automated reinforcement of the development standards and guidelines of the organization, and acted as an independant third-party to help in the decision to accept or not the source code being delivered by a vendor.

continued in the Part 2…