Recently there was a post on the BI forums on what constituted functional and technical roles in BI.. on further discussions with colleagues in the same field .. I got to delve more deeply into the basis for such a What is difference between Technical & Functional skills of BW….
Traditional R/3 and other transactional systems like CRM etc have a strong demarcation between technical and functional , this is especially evident in R/3 where you will come across technical consultants across functions but will find function specific consultants like SD functional consultant etc…
Is such a classification valid for BW as well ?
good question , but then one more reason why this has arisen is due to the fact that BI is seen as a front end system where a person may get away by just typing in descriptions and utilizing the three buttons of the mouse…!!! Weird but true…
Now coming to the crux of the discussion … are there technical and functional roles in BI and if so what are they expected to do ?
Attacking the issue from another angle .. some of the role that are typical of a end to end BW project would be : BW Architect BW functional consultant BW Technical consultant…
This would lead people to ask .. is it for the sake of the project that we come across such roles or is there something that these people are specifically meant to do ??
From what I have seen .. correct me if I am wrong…
BW Architect : Similar roles – Data Architect / Data Modeler / Systems Architect The BW architect understands high level design and would typically be involved right from blueprinting to end of the design stage… where the primary responsibilities could be :
1. Crafting the EDW layer
2. High level data model
3. Designing the high level data flows
4. Corporate data model
5. Well versed with basic DW concepts relating to cubes / ODS / performance / DB
These would mean that : The architect owns the data model for the BW system Understands the system landscape of the client / source systems Understands and is conversant with the processes currently defined and knows in full the various data points captured at various intervals of the process Is aware as to how the current design fits into the larger scheme of things .
What an architect is not expected to do :
Any coding of any sort Actual physicalization of the model Any development if required Debug / write any code..
BW Functional consultant
Synonyms : Data Modeler / Business Analyst / Systems Analyst The BW functional consultant is one who can understand the high level design and break it into smaller functions and the functional consultant may be well versed in the processes of particular modules like PP / MM / SD so that h/she may look at : 1.Documentation
2.Data sources
3.Data models ( detailed fully attributed ) ones to suit the same
4.Estimate the level of customization required
5.Convert the requirements into specifications that someone else could develop / off shored…
6.Understand modeling concepts like cubes / ODS etc…
What a Functional consultant is not expected to do :
Do any development of code / code snippets Data loading / monitoring Can be involved in physicalization of the EDW layer depending on available skill sets and comfort levels doing development Here the line dividing the functional consultant and technical consultant starts to blur… and expectedly so….
BW Technical consultant
Synonyms : ABAP-BW Consultant / Systems Analyst … The BW technical consultant is essentially seen as a person who either leads the technical team or is part of the development team involved in converting the specifications into actual objects.. Basic expectations would be :
1.Understand the technical specifications
2.Physicalize the layers
3.Develop ABAP code if required ( Usually done by ABAP consultants )
4.Monitor the data model and support it into UAT
What a technical consultant is not expected to do :
1.Documentation
2.Requirements
3.Architecture And now coming to the next facet …
What the above roles are not expected to do but would be great if they did!!!
1.In depth understanding of performance tuning
2.Look at an EDW as a storehouse of related data instead of a report bank
3.Look at how an EDW serves the business by way of providing business critical information
4.How the business benefits from the reports delivered Technical aspects
1.Understand the coding being done – not essentially do the same but even basic understanding is good – the reason being that further down the line the reason for many of the modifications is lost by way of missing documentations etc…
2.Understand the data model from the perspective as to why it has been done this way and what is the particular requirement driving this particular design 3.Look at requirements from the perspective of effort versus simplicity and achieve a balance between the same and not to deliver a bare bones system or a completely complex system with all bells and whistles..
Most of these are observations from being a Business analyst / SAP BI consultant / SAP BI architect on various projects and often having to deal with multiple hats at the same time , along with having the task of analyzing what has been done already and evaluating others work and also constantly asking the question
“ This could be done in these ways .. supposing someone comes along a year later – are we leaving any option unturned which could be a lifesaver later on??”
Another role which would be very useful to have is : Netweaver Architect : More than often customizations demanded are outside the purview of the BI system but could be done using the web application server like BSP Pages / Web Dynpros etc ..
which is given to the client – would give the view that there is a very good level understanding of the processes and consolidation of sources is also happening .. which would be very heartening for the client to see as well…interfaces that ease day to day business needs…
Till then have a nice day and a lot of food for thought....
Arun
