The project planning ability of Data Vault 2.0 method comes from PMP. Unlike the agile Scrum method, it emphasizes formal project planning in sprint. Each project has a project plan: it includes the tasks to be completed, the expected results as the output of the tasks, and the roles that will perform the tasks. Depending on the type of project, there are different types of roles to execute the project:
Business sponsor: consistency should be established between the project, business and vision.
Technical business analyst: an advanced user who reports to the business department but has certain technical skills, including understanding the data model and the ability to directly use or write SQL.
Project manager: responsible for ensuring that the project team completes the project.
IT Manager: Ensure business continuity and business success.
ETL developer: The developer responsible for the extraction, transformation and loading (ETL) process.
Report developers: realize business-driven reports based on information marts, business warehouse tables or (in rare cases) directly on the original data warehouse.
Data Architect/Information Architect: Responsible for information architecture and data integration.
Metadata administrator: responsible for the construction of metadata.
Change management personnel: ensure that new functions will not interfere with other IT or business services when they are launched, and also be responsible for ensuring that new releases can be carried out in the environment and will not be hindered by other projects.
Many organizations mistakenly assign responsibilities to people instead of defining roles. The advantage of defining a role in a team is that people in this role can be replaced by another skilled person-for example, if the current person leaves the organization or changes the project. Role definitions are helpful to organizations in many ways: these role definitions help human resources departments find suitable people for jobs in the free market; It is possible for new employees to quickly determine their responsibilities and complete the work they should complete; Finally, clear responsibilities can help the team decide who will do what when dealing with problems that naturally arise in development projects.
In the data warehouse, the project team already knows most of the roles presented. Technical business analysts are an exception. This role acts as an intermediate function between business and IT. Figure 3.2 gives more information about the characteristics and responsibilities of this role.
Because this role is between business and IT, the job of technical business analysts is to ease the relationship between the two sides and prevent the mentality of "climbing over the wall" between them. This mentality of mutual understanding, mutual support and joint efforts is often the root cause of project failure. This kind of project is characterized by unclear business requirements, technical artifacts that do not meet business requirements, requirements that IT understands, and software unreliability caused by untested or incomplete testing (from a business perspective). Usually both sides will blame each other, and both sides are very sure that the other side has made a mistake.
This is why the Data Vault 2.0 team does not recommend separating business roles from IT roles. On the contrary, the two groups should cooperate, and each role should pay attention to its own responsibilities. If possible, teams should work in the same place to improve efficiency. IT is important to establish a certain degree of collaboration and mutual understanding between business and IT, and between each role, so as to prevent the situation outlined in the previous paragraph. This is the responsibility of the project manager. If teams start to separate during the project, they need to keep moving.
Part of the understanding that needs to be established from the business aspect is that during the two-week sprint, I need a way of working that is relatively unaffected by daily problems. Problems in operation must be arranged in the next sprint. In order to achieve this, IT departments must also change their minds: their job should be to let the business departments solve some (if not most) problems themselves without the participation of IT departments. This is where "managed" self-service business intelligence (BI) comes into play. The Data Vault 2.0 standard provides IT departments with guidelines on how to provide data in a way that business users can use themselves. This requires shifting the responsibility to the enterprise. For example, it should not be responsible for repairing the data in the enterprise data warehouse to make up for the errors in the business system. IT is the business department's responsibility to fix these errors so that the IT department can send the data back to the business department through the data warehouse, where they can apply business rules to convert the data into information. It will use this knowledge to standardize commonly used information marts.
In order to prevent any interruption, the change of system requirements requires an established process. Figure 3.3 shows the communication process of this DataVault2.0 requirement change.
Figure 3.3 Communication Flow 3.3 DataVault2.0 Requirements Change
New change requests usually come from the business aspects of the project. It needs to assess the risks and impacts on the current production system. This is why change requests are passed from business users to IT managers and project managers in charge of scheduling through sponsors (who decide the priority of requirements change) and technical business analysts (who help turn business requirements into technical projects). When it completes the risk assessment, it returns this information to the business department, so that they can make a final decision on whether to realize the demand change according to the risk and impact assessment. If the business department decides to continue to handle the demand change, the IT department will arrange the demand change in the next sprint stage according to the previous priorities of the business department. Then, they are responsible for the development and subsequent delivery of new artifacts. After the business personnel have tested the change (except the development test) and accepted the change, the formal signing will release the IT department from more responsibility for the change of requirements.
When developing a new version of the data warehouse system, the development team uses the same method as the traditional software development team. They used the Alpha (Beta) version to test the new version in the early stage of the development process. The beta (beta) version is easy to test for a limited business audience, and made a Gamma (candidate) version. The Alpha (beta) version should only affect technical team members until technical business analysts.
In addition to the technical IT team, there are usually 3 to 5 technical business analysts in the Alpha version. When IT departments release new reports to analysts, it should be clearly pointed out that these reports are not intended to be distributed to business departments, because the information in the reports or cubes (data sets) may be wrong or even bad. However, technical business analysts will receive these reports to help them find these errors or identify miscalculations. After the first two or three sprints of a data warehouse project, the Alpha version is usually distributed to technical business analysts.
Once the new version reaches the test state, it will be displayed to more technical business analysts, business sponsors, selected business managers and other users who have vested interests in the new version's functions.
The beta version has been thoroughly tested by IT and business representatives, and no longer contains any obvious or known errors. However, due to the nature of publishing status, the generated report is still not suitable for circulation. Instead, limited teams use these reports to identify problems that development and technical business analysts have not identified so far. If the limited team agrees to the preparation for product release, the data warehouse system will enter the Gamma (candidate) state.
Gamma or production version has been deployed and provided to all business users. This method strictly follows CMMI, which is a part of Data Vault 2.0 method. Subsequent articles introduce the CMMI method of Data Vault 2.0.