A RACI is a matrix that summarises who is responsible for what on a project. It also defines who approves a deliverable, who is involved in the production and who is the target audience of the deliverable.
The matrix is constructed by placing the project roles in columns and the tasks and deliverables in rows and then in the intersect the letters R, A, C and I are used to indicate the involvement of the role on the deliverable.
An important consideration when producing project documentation is to know who the target audience is and therefore who should approve the document. For example, consider a report functional specification produced by a business analyst. The specification should be read, understood and approved by the Business Representative as they need to be sure that the report meets their requirements. In addition it should also be read, understood and approved by the report developer as they need to make sure that the functional specification doesn’t contain any features that cannot be implemented.
Having worked on and delivered many BI projects I have realised that one of the factors of a successful project is to have clearly defined roles and responsibilities for the project team members. This ensures that everyone knows what they and everyone else is responsible for and are required to do – no more “that’s not my job”.
This article describes a set of key roles for a BI project that is building a data warehouse and providing a set of reports and analytical capabilities to an organisation.
This article lists some of the deliverables that are produced as part of a BI project. It is not a fully comprehensive list and the descriptions of the deliverables are brief but the aim is to give an overview the main deliverables so that you have a starting point for your BI project.
One of the key drivers of this article is that although there are many articles on unit testing in general on internet there are hardly any on unit testing with SAP DataServices. Unit testing has been accepted as a key part of the software development lifecycle for projects building applications in languages such as Java or C++ however I have rarely come across a SAP DataServices project where unit testing is treated as a fundamental part of the software development life cycle. As a result projects without rigorous unit testing spend longer than planned in system testing, identifying trivial defects, and as a result suffer from delays and cost overruns.
This article first explains what is unit testing and what benefits it brings to a project and then looks at how to implementing automated unit testing in a SAP DataServices project.
In software programming it is widely held that using global variables or other constructs to maintain global state is a poor programming practice and many of those reasons can also be applied to development of jobs in SAP Data Services.
The following is my list of 10 reasons for why you should never use global variables,
Tight coupling between separate parts of a Data Services job
Hidden dependencies between separate parts of a job
Lack of isolation for unit testing components of a job
No access control – everything in a job has full access to a global variable
Global variable values can be set at runtime
Lazy reuse of global variables
Global variables depend on the context in which they are being used
Local variables can have same name as global variables
Global variables discourage code reuse
Global variables restrict configuration management
These are further explained below and since I’m a never-say-never type I’ve also included one situation where you can use a global variable.