Put simply, traditional warehouses take too long to plan, build and change. In many cases the warehouse NEVER meets the current requirements of the business, and that costs the business money. A release cycle is basically a full warehouse build in miniature. The plan is created through a set of rigid, detailed requirements of what the designers think is required. Then a series of reviews. And more changes. And more reviews and more changes. All before anything has been built and validated! Meanwhile, the clock is ticking and the business is changing. Because everything is hand built and follows a rigid, detailed process it takes TIME—and time is money to a warehouse release cycle. And by the time it is all done, the business has moved on. Another batch of changes have to be processed and more hand built code generated to try and make the warehouse meet the emerging requirements.
Once we have the design of our solution, we go off and start development. (build)Of course, since we are mostly writing code, there will be bugs in our development, which will require testing. (build)So we will spend a significant amount of time in a test/develop loop, gradually refining the code (DDL, ETL, BI semantics and report generation) until we are ready for production. (build)At this point we “productionize” the code (create automated execution scripts and schedules) and finally go into production…(build)And operate our BI infrastructure(build)In many cases, this is a roughly 18 month project.
Instead of the traditional waterfall methodology, where we iterate between build and test phases, agile development places the iterations earlier in the process: between analysis and design. But for this to work, we need a tool set that allows us to communicate with the business more effectively during the design phase. We also need a tool that will allow us to show results very quickly – ideally, it should allow the “build” process to be largely automatic.Traditional tools don’t support this..
However, methodology alone won’t solve the problem. Let’s look at some other important cost factors of a warehouse release cycle.
By clearly defined, I mean defined in a way that reduces confusion and fosters understanding.Fixed requirements is an artificial creation of warehouse development teams. The key ingredient of this creation is shutting the business out of the process once they sign off on the initial requirements document.Much like the business environment itself, agreement is subject to change. Things change, and early looks at what everyone thought was correct brings new ideas. Agreement, especially amongst the key stakeholders must be maintained. This isn’t an invitation to scope creep, it’s just ensuring that what we thought we were asking for is in-fact what we need. If it’s not what we need, it’s throw-away—and will have to be redone. Therefore, keeping consensus greatly reduces cost.
When people from France and Italy need to communicate what do they do? They learn English. English is the common language that they use to communicate effectively.IT and business need a common language in the form of a business information model that allows them to communicate and collaborate. The business information model is a representation, which both IT and the business can understand and agree upon, of how data is defined and should flow to support the information needs of the business.But that’s only the tip of the iceberg. The Business Information Model is actually a complete set of blue prints for all data management activities, such as validating data, managing the database schema, and producing reporting semantic layers.
The methodology, or the way the organization approaches iterations is also important.Keeping the iterations short, so you never go too far down a wrong path before the business can provide valuable feedback.Making sure that iterations are efficient, and that only steps which provide value are included in them, is key to controlling costs. Too many teams have tried to compress all the steps they used in a waterfall project into an agile sprint. The results are usually disastrous and lead to a burned out IT staff, dismayed business customers and greatly inflated costs.Make sure that each iteration provides real business value and not just IT value!
Have you taken off the chains (e.g. over documenting, too many meetings / not enough working)?Have you removed communications barriers (e.g. co-location)Is your team comfortable starting an iteration with incomplete or even semi-baked requirements?
Traditional data warehousing tools don’t adapt well to agile development. This is because each tool is dependent upon the completeness and accuracy of the previous step.Kalido, by contrast, is designed to support agile development. It virtually eliminates the need to write, test and debug code. The Kalido Business Information Model is much easier to understand and communicate to a business user. In addition, it drives extensive automation that allows changes in the model to nearly instantly reflected in changes in the BI layer. By using a single tool from data warehouse design through BI semantic definition documentation is simpler, and largely automatic. The smaller team size, and the ability to iterate quickly, delivers results FAR more quickly, and much more accurately aligned to the business needs.
And, as Nik Green pointed out in the preceding session, an automated tool provides real savings that translates into both reduced costs and increased capabilities. Here is more detail about what Kalido customers have reported in terms of savings by using our automated data warehouse application.
All the automation Kalido provides means that we still do all the steps that are needed for a scalable robust production environment. We can just do them faster and more accurately, which makes for a lower cost per release cycle. The faster , shorter, and less expensive release cycles also provide more benefit per release cycle by allowing business can start to make decisions sooner.
Thanks for tuning in today. If you would like to learn more about how you can reduce the cost of your iterations while generated improved business value from them, you can start by taking Kalido’s on-line business agility assessment.If you are planning on attending the TDWI BI Summit this August, you should register for the sessions from Ralph Hughes that explain the agile tools behind these shorter release cycles.Finally you can see this in action by calling or e-mailing Kalido to request a demonstration.Thanks and I’ll turn it back over to Ben.
