Versions Compared

Version Old Version 4 New Version Current
Changes made by

Matthew Hall

Matthew Hall

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Design Principles

Should we build it? How do we decide?

The following questions may help Product Owners to guide the effort of their team. These questions are not meant to be a checklist, rather they are tools to help you think critically about your roadmap and backlog and about the individual stories. These question may also help team members to make certain technical decisions and determine how to handle technical debt.

  • Will the feature make the product more useful to a larger audience of users?

  • Does the feature help to improve how the users trust the product?

  • Will more people choose to use it because of this feature?

  • Is the feature doing something that was previously hard work for someone to do in another way?

  • Is the planned work avoiding opinionated designs and instead allowing for configurable choice?

    • e.g. BCGov Theme can be selected, but if another province was using our product, could they easily select they own style library to use?

  • Does it increase the reputation of the team?

    • how we document

    • how we code

    • how we deploy

    • how we test

    • how we work (agile fluency)

  • Is there measurable value aligned to a user problem?

Context

Do you have an understanding of where your component fits? Who is it for?

If you are building something with the intention of it being used as a common component then consider the following:

Select a Delivery Method(s): Hosted Service, Reusable Component, Shared Code, or Tested Instructions

As you consider how users are wanting to consume your product to gain value from it, selecting the right delivery method will help you to maximize the value while limiting overhead.

Understand the Capability Level: Core, Supporting, Service Management, or Service Quality

Core capabilities are the ones that users will ask for. Supporting capabilities are the ones that service providers need to implement for the core ones to work. Service management capabilities are the ones that help you operate the administrative work back stage. Service quality capabilities are the ones that help you have a good reputation because your software is reliable, secure, privacy preserving and high performing. Understanding the capability level will help guide your work to identify user groups and help you determine the scope and boundary of the product you are building.

Ecosystem

Processing (Operation)

  • Status: recording, tracking and displaying the state of a users submission

  • Comments

  • History

  • Assignment

  • Notification

    • Automation

    Page Tree
    root@self
    startDepth1

    On this page:

    Table of Contents
    Image Added

    What makes a good common component?

    Introduction

    What general characteristics or ingredients does each component need to have for it to be considered “good”?

    The big three are to 

    1. reduces costs

    2. accelerates development

    3. promotes consistency and supportability

    If you think you have a "good" one and would like it added to the catalogue so that others can find it easier, you can request to add your common component on the common components page of digital.gov.bc.ca/common-components.

    Reducing Costs

    Cost Avoidance

    The following are a few examples of how a components can create cost avoidance savings:

    • Built by one team, but used by more than one team

    • Deployed and hosted by one team

    • Enterprise licenses versus many individuals licences

    • A generic capability built that eliminates the need for reimplementing that function in all applications

    • Adding a self-self onboarding process to a Common Service that didn’t have one previously

    Cost Savings

    • An innovation solution that allows for discontinuing an existing common business process or function entirely

    • Providing a free and open-source alternative to switch to from existing more expensive options

    • Openly accept contributions from other digital service teams

    Accelerate Development

    • Complete privacy and security compliance documentation that can simplify or eliminate the requirement for each person who uses the component

    • Eliminate approval processes and funding requests by providing the service for free

    • Create quickstart wizards and implementation examples

    Promote Consistency and Supportability

    • Use well documented APIs and allow access to them

    • Share data in supported formats that are interoperable with other components

    • Be aggressive in addressing technical debt

    • Monitor the value of everything you’ve built and are paying to maintain

    Policy

    Core Policy, Chapter [12.1.1] Lists the Digital Principles.

    Principles 5 and 6 (Work in the open, Take and ecosystem approach) specifically relate to Common Components, but they are all useful for any software teams to be very familiar with.

    Definition

    In a software context, common components are among the list of building blocks used to create digital services. Components specifically enable core capabilities within services.

    • A core capability or service that can be utilized by public and private service delivery teams

    • A common component should be the following

      • technology agnostic for the user

      • well documented

      • regularly updated by a dedicated team

      • quick to onboard to in a self-serve manner

    • Self service is achieved when components are cataloged in a central repository, where a service delivery team can easily see which components are best suited to solve their use case. This can be aided by sharing information on success stories, metrics, and data that can be used to evaluate product health.

    • Common components are built with the goal of providing one more tool that can be used in combination with other tools to solve any problem that may arise.

    • The objective of a common component team should be to solve a significantly complex and frequently occurring problem faced by multiple teams for once and for all.

    • A component requires reliable data sources and must strive to provide consistent outputs

    Ecosystems and Value Streams

    Identifying Commonality

    What are the other products or services that may be doing what I’m doing? Who can I collaborate with?

    Your product or service may operate within many categories of software capabilities. Start with looking at just one of those categories that you think might benefit most from using common components.

    High Level Categories

  • Discovery of

    • Products

    • Services

    • Careers

    • Procurements

    • Data

    • Subscriptions

  • Submission of

    • Enquiries for information: Asking for guidance

    • Requests to create, update or delete something: Asking for coordination

    • Applications for a decision to be made: Asking for support

    • Messaging to provide comments: Feedback elicited and voluntary

    • Find out what ecosystems you may be contributing to or consuming from.

    When you think about the service that your product delivers also consider what the larger value stream your service is a part of. Once you identify your value stream, take steps to connect with others who are there as well, and start examining the various points along the way where there are hand offs, and make plans to address them.

    Agile Approaches

    Where does the need for your Digital Service exist?

    Understanding who the user is can be hard to understood. Let’s look at two distinct groups that occur commonly with Common Components. These two groups are not easy to focus on at the same time.

    The Have’s and the Have Not’s:

    1. Staff who are non-technical and have no funding to acquire technical people to help them

    2. Product/Project Teams with technical resources who need to integrate their system with common components

    How do we build Solutions to help both groups?

    • Start with the simplest user journey and protect it as the product matures

    • When adding new capabilities, hide the complexity from those who don’t need it or want to see it

    Market Awareness

    Analytical Iterative Feedback, measuring the pulse on the three pillars and adjusting as necessary

    Are customers satisfied that their problems are solved by the product you offer?

    Regular evaluation and monitor of the problem you are solving for will give you the information necessary for doing internal adjustments based on user centric feedback

    What threats and opportunities are presenting themselves from the industry?

    Trends and new technologies may arise that introduce new ways to solve the problem you are solving. Conducting analysis of these external factors and making adjustments is just as important as listening to users.