Task: Review and Test Asset
One or more of the asset review processes are executed to evaluate and approve an asset.
Disciplines: Asset-Based Development
Purpose
To maintain control, quality, and management of the content into the Repository.
Relationships
RolesPrimary Performer: Additional Performers:
InputsMandatory:
    Optional:
      Outputs
        Main Description

        As assets are submitted to the Repository the relevant parties are notified of their role in the review process. Some may be in the role of Reviewers whereas others are in the role of the Review Board. There are many possible review processes given the variety of asset types, cultures, and other restrictions.

        The review processes are defined per Community. There are three kinds of review processes:

        • AS-IS
        • Built-in
        • Extensible

        The Built-in and Extensible review processes can use a Review Board. The Review Board provides oversight to the review process, they can modify the set of reviewers, initiate the review process, and cast final votes on the asset. Without a Review Board the Reviewers are notified and the assets are approved/rejected based on the votes cast by the Reviewers.

         Review Process with and without Review Board.

        • As-Is: this really means there is no review process, meaning that assets submitted using AS-IS are automatically approved. Administrators normally have to approve this.
        • Built-in: in this case the Asset Repository provides fundamental asset review capabilities which can be configured by the Administrator. Review Board members and reviewers can be identified to review assets of a particular type, owner, or classification. The Asset Repository notifies participants when an asset comes in for a review process.
        • Extensible: this kind of review process is customizable to reflect the workflow the enterprise needs. This review process is specified by a process language or by a change management system.

        There are many possible review processes given the variety of asset types, cultures, and other restrictions. The review process can be netted to two major groups, the Review Board and the Reviewers. The review process was specified in the Task: Configure Repository. If the Review Board is enabled then for each asset that is submitted the Review Board should be notified and they begin their activities. The Review Board will plan the review, select reviewers, initiate the review, evaluate the submitted reviews, and cast the final, deciding vote on the asset. In the image below a built-in review process has been specified called "Service Implementation Review" for assets of type "Service Implementation". A Review Board has been enabled, this means they will cast the final vote on the asset. Also one review has been identified, by name, rather than by role.

        Once the Reviewers are notified of the review they can claim the review request and conduct the review and submit the review with vote to the Repository. Reviewers may also suggest other Reviewers to the Review Board. If the Review Board is not enabled for the review, then the votes from the Reviewers determine if the asset is accepted or rejected.

        The actual set of reviewers, the steps of the review process, and the parties involved generally requires customization for each organization.

        Steps
        Submit Asset for Review

        The Asset Owner or Producer has completed their refinements of the asset and now submits the asset to the review and approval process. The Asset Owner or Producer may have suggestions on subject matter experts who could fill the role of Reviewers.

        Setting up the Reviewers in the Repository is helpful, but should be extensible for specific assets.

        Notify Parties
        The Repository should handle the activities of notifying Reviewers of the asset to be reviewed. However, in practice, the Asset Owner or the Review Board may need to provide reminders.
        Conduct Review

        There are many kinds of reviews to be performed on assets. Some types of reviews include:

        • Asset name review: the proposed asset name is compared with understanding of the target Asset Consumers.
        • Classification review: the classification aligns with the manner in which target Asset Consumers will search for the asset.
        • Functional compliance review: the asset goes through typical functional testing, executing test cases and using testing tools to validate the asset.
        • Non-functional compliance review: the asset goes through non-functional testing to verifies the asset's performance, scalability, security, and so forth.
        • Packaging review: verify the asset contains necessary support material, making it easy for the Asset Consumer to use, and also support contact information is present and accurate and the support team is ready to support the asset.
        • Similar asset review: The asset is evaluated compared to other assets to determine if the implementation overlaps or is similar to other assets in the Repository.
        • Subject Matter expert review: A fit for purpose evaluation is conducted, examining of the asset fulfills the purpose properly and aligns with the Asset Specification.

        When a Reviewer completes a review they submit the review files (if any) and cast a vote.

        Browse Review

        If the Review Board is enabled they cast their vote on approving or rejecting the asset. If the asset is rejected then it returns to an early submission state, such as Draft, otherwise it transitions to a state such as Approved.

        An asset that is Approved is made visible to the anticipated Asset Consumer audience through the Repository. An asset may transition to other states as well after it has been approved. For example, if the asset is a service, then it may be published to a service registry, which may change the state to Published.

        Review Board Vote

        If the Review Board is enabled, they cast their vote on approving or rejecting the asset. If the asset is rejected, then it returns to an early submission state, such as Draft, otherwise it transitions to a state such as Approved.

        An asset that is Approved is made visible to the anticipated Asset Consumer audience through the Repository. An asset may transition to other states as well after it has been approved. For example, if the asset is a service, then it may be published to a service registry, which may change the state to Published.

        More Information