Framework

Prioritization Criteria

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.

Component Level Prioritization

Will a significant number of people care about this?
Is there someone who actually needs this?
Does this helps us solve something that is a high BC Government priority? (must know the list)
Does this help BC Gov teams other than yours to solve their problems?
Will this eliminate a duplication of effort that causing political concern?
Does this allow the automating of handoffs between consumers of your service?
Does this have tangible financial benefits? (lowers the amount of funding required to deliver, eliminates a business process, enable repurposing resources to higher value work
Is there business agility in the team who will support it?
Will this improve the trust, confidence, reliability, and stability in the support of the service?

Feature Level Prioritization

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 the contributed code increase the reputation of the team? (documentation, coding style, deployment and integration process, testing, accessibility, etc.)
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:

Pillars of success for achieving reuse

Self Service
Showcase Capabilities
Implement Examples

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. 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. Even a small barrier in this space will be enough to prevent success towards the goal of avoiding duplication and achieving the ecosystem approach.

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

Capability 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.

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.

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.

Capability Categorization Models

1. 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

Note that in the model one service may initiate the

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
Processing (Operation)
- Status: recording, tracking and displaying the state of a users submission
- Comments
- History
- Assignment
- Notification
- Automation

2. Capability Enablement Level

FOUNDATIONAL:

Starting with Foundational capabilities ensures there is demand and that you are solving problems for users.

collect/submit information

ENABLERS:

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

3. 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)
Form 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

Agile Approaches

Where does the need for common Services exist?

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?

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

Common Components Program Overview