Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

On this page:

Component Design Framework

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.

Pillars for Reuse

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

Software Packaging and Digital Service Delivery

 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.

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.

Packaged Business Capability (PBC)

PBCs vs. Microservices

PBCs and microservices are often thought of as the same thing, but there is a difference. 
Microservices are small, autonomous services that can be used together to create an application. PBCs are pre-built, standardized business functions that can be deployed and integrated without requiring extensive development effort. PBCs are custom combinations of certain microservices that work together to carry out a specific business function.

Microservices, while valuable, can be difficult to orchestrate, particularly for the average business user, as they are complex and difficult to maintain. PBCs remove this complexity and streamline things for business users as they are easier to manage in different environments and use cases. 

https://www.gartner.com/document/4008929?ref=solrAll&refval=381245319&

 Granularity Levels

PBCs of Innovation

This type will necessitate smaller PBCs promoting the need for flexibility, speed and rapid change

PBCs of Differentiation

This is the idea that your PBC provides a clear unique value proposition. It is more granular than a PBC of Record, but not as granular as PBCs of Innovation need to be.

PBCs of Record

For systems that manage data that has a long term need for stability, the PBCs can remain less granular due to the consistency of requirements over time. e.g. Land Titles

Component Visibility Levels

 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. This typical shows up when you are plotting your services on a value chain with the one that are closer to a user at the top and the ones farthest away as the bottom.

Core

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

Supporting

Supporting capabilities provide the necessary features that help in achieving the core outcome, but the user will not typically go in search of a digital service based on any of the supporting capabilities. Getting a receipt for a transaction is important but they came to buy a pair of pants.

Service Management

Service management capabilities are administrative and occur out of site of your clients and users. These are the capabilities that assist those who deliver the digital service to operate it efficiently. These capabilities are valuable to users, because it means the service operates smoothly, and if they are working well, users may not know they are even happening.

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. These capabilities protect data, makes sure people only see what they are allowed to see, and monitor the service to evaluate its health, or provide channels to report errors and suggest improvements.

Future section on Digital Public Goods

  • No labels