Versions Compared

Version Old Version 12 New Version Current
Changes made by

Matthew Hall

Matthew Hall

Saved on

Key

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

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 you should outline for your product how to implement the pillars of success.

You may need to consider various delivery methods, both for your team to utilize the things you build, and for how you plan to allow others to use them.

Each reusable software building block will fit into a category related to where it sits in its proximity to a user. Make sure you have a good understanding of where your product sits and how it supports the broader ecosystem of common components.

Expand
titlePillars of success for achieving reuse

  • Self Service

  • Showcase Capabilities

  • Implement Examples

Self Service

While it is good to work in the open and be transparent, all too often it is left up to the team that is looking at a open sourced product to sift through the code to find the pieces that they can reuse. A product that has enabled self service allows for product onboarding without any involvement from their team. This may mean you have a to build a self service registration tool so people can be guiding through the process that is required for each new user.

Showcase Capabilities

The effort to find the reusable code and repurpose it to fit with your product offsets the value obtained for developers who typically prefer to make it from scratch themselves anyways. If you have built with reuse in mind then you will have in place a way for people to try it out. Seeing a product in action is superior to documentation or a list of features.

Implement Examples

Even a small barrier in this space will be enough to prevent success towards the goal of avoiding duplication and achieving the ecosystem approach. Once a potential client or user has decided they want to use your product, the still have to figure out how. Provide them will all the information they need to get it working including a specific example of how to plug it in. Depending on what sort of product you are building this could be done in many different ways.

Expand
titleDelivery 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. These delivery methods are built on the pillars of success for achieving reuse.

Hosted Service

This means your team is running the digital service and providing a location online that people can go to for accessing the product. Typically this is a website or web application but it could also just be an API that would be used by another web application. Your team in this case is doing to hard work of keeping it running, taking care of the data it stores, ensuring privacy and security, and other digital custodianship accountabilities. One hosted service might be using multiple other hosted services in order to deliver value to its users.

Reusable Component

Certain products make sense to be shared, but may often have valid reasons for not running a single hosted service. It those cases the product should still have a dedicated team that is responsible for the continuous improvement of the product. This is typical performed by a team that is using this reusable component as part of another digital service they are delivering. An example of this is when software teams will publish pre-built images of software to dockerhub. From DockerHub a software team can reference one of these pre-built images, to be installed along side their product to add its capabilities to their digital service.

Teams that use one of these images benefit from all the work done to build it, but maintain the responsibility for hosting it. It fact a hosted service may consist of nothing more than a team running something from dockerhub. With this approach you benefit from having a black box that with the correct inputs will give you the output it promises.

Shared Code

This is similar to a reusable component except it allows the team that is implementing it to add in their own customizations which they would then build and deploy. So shared code means it is no longer a black box. Doing this approach also adds in the responsibility to conduct all the testing of any changes or configuration that the team conducted.

Tested Instructions

This is a set of documentation that can be followed and once completed will result in something of value being created. This could be a set of scripts to run in a command prompt or it could simply be a numbered list of steps to take to make something work. Not everything will justify creating a web application, but if in an hour you can create a quick step by step set of instructions to help save 10 minutes, for 1000 people, then it would be time well spent. One example where this approach is very common is in writing a very clear readme for your github repository.

Documentation itself is a product that needs to be tested, collected feedback for, and iteratively improved. Each time a new team member joins your team, they should be required to use only the documentation to get the application setup in their local development environment, and then for their first pull request to the repo submit some improvements to make the documentation more clear.

Expand
titleCapability level

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.

Core

Core capabilities are the ones that users will ask for by name.

Supporting

Supporting capabilities are the ones that service providers need to implement for the core ones to work.

Service Management

Service management capabilities are the ones that help you operate the administrative work back stage.

Service Quality

Service quality capabilities are the ones that help you have a good reputation because your software is reliable, secure, privacy preserving and high performing.

Page Tree
root@self
startDepth1

On this page:

Table of Contents
maxLevel6minLevel1includeoutlinefalseindentexcludetypelistprintablefalseclass

Component Design Framework

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.

Capability Categorization Models

When thinking about what the list of all common components are, it might be helpful to consider that there are multiple ways to group things to create this list.

Expand
title1. Service Delivery Cycle

This model looks at the journey of a user:

A. discovering a service is available,
B. requesting or activating the service
C. the service being performed or the transaction being processed

Discovery

  • Products

  • Services

  • Careers

  • Procurements

  • Data

  • Subscriptions

Submission

  • 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

Processing (Operation)

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

  • Comments

  • History

  • Assignment

  • Notification

  • Automation

Expand
title2. Capability Enablement Level

Foundational

When you start your project focused on the foundational capabilities it will ensure there is demand and that you are solving problems for users.

  • collect/submit information

Enabler

Factor out the enabler capabilities as new common components.

  • design forms

  • store information

Additive

Looking at the user journey where there are system handoffs work to add connections to solutions for the next chunk of work in the user journey.

  • evaluate applicant’s submissions

  • send notifications

Multiplicative

As it will not be possible to scale with just additive approaches, we will need to implement event triggered messaging and subscription services that can enable many systems to connect with each other without those services being tightly coupled.

  • system A is subscribed to certain events that get posted by system B

  • a process for the evaluation of grant applications may start when a new grant application is received

  • example component: event streaming, or message queues

Expand
title3. Product Model

This model looks at the logical breakdown of the capabilities of a software product. Each of these capability areas may contain many functions:

Capabilities

Enablement Type(s)

Service Delivery Step(s)

Expand
titleForm Design and Submission

Form Builder Tool

Form Versioning

Form Publishing

Form Submission Lists and Details

Form Settings Management

Form Permissions and Security

Submission Status

Data Export and API Access

Event Triggered Service Extensions

Foundational, Enabler

Submission

Payment and Reconciliation

Login, Identity and Digital Trust

Template and File Mgmt

Subscription/Notification

Additive

Discovery

Workflow and Event Streaming

Multiplicative

Processing

API Access Management

Visualization Dashboards

Password Management & Automation

Registry Aggregation (Backstage)

Prototyping Kits

DevOps and Hosting

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

common Services

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

  • Add new capabilities that have only a minimal increase in complexity

    • Hide

    • 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?

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

    • internal adjustment based on user centric feedback

    • external adjustment based on industry factors

    Image Removed

    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.