As I mentioned in the last The diary of a BW 7.3 Ramp-Up project (Part 1), we started with a complete new system, so with a green field, just knowing what applications to move from the old to the new system. There were different naming conventions for objects, no coding standardization, different architectures for different applications.... So the first discussions we had was about the new architecture. Here we followed the guidelines of the newest lsa concept and adjusted it to our specific needs.
So we have a corporate memory that contains all data delivered by the source system without any changes in write optimized DSOs. Here you find almost everything a datasource delivers (--> following the 'support the unknown' concept). This Layer should move to a NLS in future. The second layer will be the quality and harmonization layer. No data is stored here(well of course there might be exceptions) but the transformations from datasource to the propagation layer objects will be found in this layer. In the propagation layer the data will be stored in a consolidated view in standard DSOs and ready to use for the applications. These levels build the EDW, the Enterprise DataWarehouse.
Now, the ADM, the Archtected DataMarts, come on top. Here you find the business and transformation layer. Basically we have only transformations here to the reporting layer objects, but again, exceptions might be possible. The reporting layer contains our InfoCubes and SPOs and on top, we have the virtualization layer where we have the MultiCubes on which the reports are created.
After being sure about our architecture, we had to define new naming conventions. Well I will not stress this too much, as it will be different in each project, and not that relevant for standardization. But surely the naming conventions should follow one rule all over the system, maybe slightly different for the different layers, so that others who join the project can easily adopt them. The only thing we had to take care of was about the new SPOs as the technical name for a SPO is 2 characters less than a normal Cube or DSO.
The nicest thing we did was about the coding for start/end/infoobject routines. We created just a few methods which have to be added to each and every transformation we have in the system. There is one method in the endroutine of all corporate memory objects. There is one method in the startroutine of all propagation layer objects.... And there are some customizing tables to enable the functionality in these methods. The so to enable functions are e.g. conversion to upper case, conversion to lower case, switch alpha on/off, select data from other objects and map correctly.... And for really specific functions we also implemented the call of 'Exit-Methods'.
At the end we decided to document everything in a wiki, with links to the metadata repository, the online help and ofcourse with more detailed information for the users.
I will talk about the rampup process and some technical details in the next blogs.
