In his Agile Analytics book, Collier devotes his eighth chapter to the topic of “Version Control for Data Warehousing”. Clearly the IDT is not a Data Warehouse development tool but it certainly qualifies as one of the artefacts used in the delivery of Analytics solutions that Collier lists. The IDT’s purpose is to prepare and manage the semantic layer on top of Data Warehouses, Marts, etc… rather than actually design one but I think the core principles of that chapter are still applicable.
Collier writes that ‘Version control is mandatory on all Agile Analytics projects’ and provides five advantages to the delivery process.
1) It allows development rewind.
2) It allows controlled sharing of code.
3) It maintains an audit trail of development.
4) It provides release control.
5) It encourages ‘Fearlessness’ in development.
I particularly like that word ‘Fearlessness’ and the understanding that it allows developers to experiment with solutions without adversely affecting the project. This, as part of a collaborative development environment, is perhaps where the IDT can offer the most support over the traditional Universe Designer – always a nightmare-ish tool to promote code through – although, again, it’s far from complete in supporting all five of Collier’s version control advantages i.e. it doesn’t really support the rewind principle beyond one iteration or maintain an audit trail of development.
Let’s focus instead on what the IDT does deliver. I’ll cover how different developers can work on the same SAP Universe, applying a degree of version control to and sharing the code of, the different layers of the ‘exploded’ Universe. Throughout these developers will have to work within the principles of good communication and collaborative working (because the IDT won’t do it all – no tool would!).
I’ve set up two users who I’m sure, being the best of friends, will adhere to the best practices of collaborative developments.
Tom Sawyer is first to log into the IDT in the morning. He’s got a new measure to add to the Business Layer of our eFashion Universe so immediately also starts up a shared session which opens up the centralised Repository versions of all currently deployed models. Now, it’s not immediately obvious how to do this and, depending on your screen size and resolution, you might have to do a little resizing of the various IDT panes.
From the Window drop down menu, Tom selects the Project Synchronisation window which then opens up on right hand side of the workbench.
The session has to be opened by clicking on the session icon. If your project sync pane doesn’t have enough screen space, this icon will be hidden and you’ll have to expand the pane size.
Opening the session connects the user to the central repository of Shared IDT Projects. An IDT project consists of layers that can be used to create a Universe (.unx) i.e. connection layers, data foundations and business layers. Note that each project can consist of multiple versions of each i.e. it’s possible to build more than one Universe from a single project. They’re probably best organised through agreement within the development team. A prime place for the collaborative working practices and standards to start being developed.
Opening up a shared project then populates both sections of the Project Synchronisation pane – the Sync Status and Shared Project lists. From the Sync Status window we can see that the iteration of the Project uploaded on 28th February. This reflects the iterations developed locally from converting a traditional .unv Universe into the three layered .unx Project, and then shared with the central repository. We can see that, at the moment, all are fully synchronised with the local version.
In the Shared Project section of the Project Sync pane, Tom can then ‘lock’ individual layers of the project to prevent other developers changing them whilst he works – fearlessly – on them. An example of this is Tom wanting to lock the eFashion Business Layer so that he could add a new Measure object to it.
This will communicate to other users that this layer is currently being worked on. When Tom’s colleague, Huck Finn, logs in that morning and opens up the Project Sync pane in his IDT workspace he sees that the Business Layer is locked. By scrolling along the Shared Project section, Huck can see details as to which user has locked it, version number, last update date, locked date, etc… He can also simply unlock the layer if he wants to which does rather undermine the process. A charitable interpretation would suggest SAP are merely trying to encourage effective collaborative working through increased developer communication but, I’d suggest, this a clear candidate for project enhancement.
Anyway, Huck goes over to Tom’s desk and agrees that whilst Tom is creating this new measure, Huck will work instead on adding that new data source to the existing Data Foundation layer. Huck checks out the Data Foundation layer and they both have a productive morning working on the same project.
After lunch, Tom is happy that his changes have been tested successfully in his local sandpit environment. He can now see, as expected, from the Project Sync pane that the version of the Business Layer on the central repository is out of sync with the version in his local sandpit environment.
By clicking on the “Save Changes on Server” icon on the top left of the Sync Status section, Tom can now check in his changed layer to the central repository.
Tom calls over to Huck and lets him know that the new Business Layer is ready for him to work with so Huck refreshes his Sync Status section and sees that, yes indeed, there is a new version there ready for him to sync to his local area with the status “Changed on Server".
Huck clicks on the “Get Changes from Server” icon and a copy of the most recent version of the Business Layer is downloaded to his local sandpit. Huck can now test the changes he’s made to the Data Foundation that morning don’t impact on that Business Layer and proceed, fearlessly as ever, with his own development tasks.
You get the gist. There’s a clear and straightforward, check in/check out environment available in the IDT that supports an iterative, incremental and evolutionary – an agile – approach to Universe development. Similar functionality could be achieved in the pre-4.0 Universe Designer and a variety of CMS folders but always only for one developer at a time. With the ‘exploded’ Universe approach, developer productivity gains are clear. Releases can become more rapid.
There is, of course, room for improvement. In future releases of the IDT I’d like to see a further ‘unpacking’ of the Universe so that developers can work on individual components of each layer in the same check in/check out style e.g. a Dimension Class in a Business Layer could be developed by one, whilst another worked on Measures. It would also be nice to add some commentary to each iteration as, at the moment, Huck would have to manually check for the changes Tom had been made (assuming they weren’t working in a good collaborative fashion that is!). And, I guess, ultimately I’d like to see full integration with a third party version control system so that, as per Collier’s recommendation in Agile Analytics, all the artefacts associated with the BI environment can be stored in one place to ensure the potential requirement to completely rebuild the environment. Subversion would seem to be the obvious integration version control tool here given that SAP already ships it for the their BusinessObjects CMS Repository.
Not perfect then but a start at delivering the collaborative environment and version control required to support Agile Analytics. Next time I’ll be looking at a specific feature of the IDT Business Layer development –Queries – and how they could be used to help deliver continuous testing.
No comments:
Post a Comment