| Page Tree | ||||
|---|---|---|---|---|
|
On this page:
| Table of Contents |
|---|
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
reduces costs
accelerates development
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
Accelerate Development
tbd
Promote Consistency and Supportability
tbd
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 building blocks that enable core capabilities within services. A single definition is not the goal because it can be many different things.
A core capability or service that can be utilized by public and private service delivery teams
A common component is platform agnostic for the user, well documented and regularly updated by a dedicated team that enables self-serve and quick onboarding
A common component is cataloged in a central repository with an interactive dashboard that provides information on active users and teams (maybe a GitHub repo link) and abides by well-defined standards of software maturity
The objective of a common component is to solve a frequently occurring problem faced by multiple teams for once and for all
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.
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? Understand who the user is not well understood, but I want to point out 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:
Staff who are non-technical and have no funding to acquire them
Product/Project Teams with technical resources who need to integrate their system with common components
How do we build Solutions to help both groups? (more to come in this section)
Start with the simplest user journey
Add new capabilities that have only a minimal increase in complexity
Hide the complexity from those who don’t need it or want to see it
Market Awareness
Are customers satisfied that their problems are solved by the product you offer? 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