An essential step in a mature data warehousing development and code promotion process, peer review can be included in many data warehouse development phases, including data model development and ETL process creation. Incorporating a peer review into your data warehouse development process not only ensures the end deliverable is up to snuff, it also helps to train the developer and set of peers on best practices. The questions that you may have are ‘what is a peer review?' and ‘how do I perform one?' Let's answer both of these questions.

What is a peer review?

A peer review is when one of your ‘peers' reviews a deliverable that you are working on prior to moving the deliverable into the next environment. Let's break that definition down into its separate pieces:

  • Peer: Someone with at least the level of expertise that you have with creating the deliverable that you are working on. For example, if you are creating a data model, you should not choose someone that does not have any data modeling expertise to perform a peer review.
  • Review: A check of all aspects of the deliverable to ensure that it is ready to move to the next environment. For example, if you are creating an ETL process, once it has been developed, reviewed, and approved, it can get deployed to the Quality Assurance environment.
  • Deliverable: An artifact that must follow a set of standards to move through environments. For example, deliverables in an ETL process would include the process, configuration information, and documentation on the process.

How to perform a peer review?

A peer review should be led by the main developer of the deliverable. Before the peer review date, the peer review lead should send the completed deliverable to his peers. All peers should look at the deliverable before the peer review meeting to bring questions to the meeting.

During the peer review meeting, assign a scribe to take notes on all aspects of the review: questions that arose, changes that need to be made, and action items to follow up on. It is important that the peers performing the review use constructive criticism at all times. For example, peers can say ‘what do you think about changing the primary key of the table' instead of saying ‘your primary keys do not make any sense'. We have to keep in mind that the end goal of a peer review is not to personally attack someone, but to make sure that the highest quality deliverable is being provided to the client.

Then, several critical items should be checked.

-Compare the deliverable against any available organizational standards. When creating a deliverable for an organization, we must be certain that any standards in place are followed. Organizations will not view deliverables highly if the organization's standards are not followed. If standards do not exist, the developer can assure that his work is standardized by following the formats and conventions of similar deliverables. For example, within a data model, all dimension tables should have the same prefix or suffix. Even when organizational standards do not exist, it is critical for items across deliverables to be standardized.

-Ensure the deliverable's processes are performed efficiently. For example, during an ETL peer review, someone may notice that the most efficient method of moving data from a source to a target table is not being used. In another example, during a data model peer review, someone may notice that data is being stored multiple places within the data model, creating the possibility for inconsistencies within the data, and also causing the ETL processes used to populate the data to execute longer than needed.

-Ensure the deliverable is completed correctly. If the peer review is of an ETL process, the developer that created the ETL process should walk through the various components of the ETL process, and allow visibility into the details of the process. This will allow his peers to see any errors. If the peer review is of a data model, the developer should explain the various tables in the data model, allowing his peers to ask questions about the data model.

CapTech performs peer reviews

CapTech uses peer reviews in its projects to ensure all deliverables are accurate and follow the client standards. These sessions are also a great way to impart knowledge to the client. In addition to consulting projects, it is also recommended that peer reviews be included during the development lifecycle, to allow the developer to receive feedback on his work just after initial development. This will allow the developer ample time to make any required changes. CapTech also uses and recommends that a developer uses a peer review checklist. This will help the people performing peer reviews from overlooking essential items and ensure a final, complete product. When done correctly, peer reviews are a great addition to the development and code promotion process.