Common Components for #DigitalBC
Habemus common components! Check out our new catalogue of components for digital services.
I’d like to share an update on the tools that we have in government for building digital services. This is a slightly technical read, so if you work in digital government or IT, read on! And if not, my TLDR is: governments can and should be smart about how we build modern services, and we have a growing suite of tools to do that well. Exciting stuff.
The challenge of enlightened digital services
In digital government, we talk about government as a platform (check out Richard Pope’s article if this is a new concept for you). We support an approach to government where distributed, mission-driven teams can contribute to the common goal of providing brilliant, inclusive, user-centric services to people. We get excited about using modern tools to deliver on the promise of government: service to people.
Delivering great digital services is thrilling work, but it’s often difficult. Governments are large, complicated organizations. Digital teams like mine, and like many across government, have to navigate between diverse priorities and stakeholders. And because of all these priorities and competing imperatives, sometimes governments deliver on our service commitments in ways that are less than ideal.
We all know the stories of big IT projects that fail, or at least stumble: HealthCare.gov, the Phoenix Pay System in Canada, and so many others that have been quietly written off. But we think and talk less about the more subtle but collectively pernicious flaws in our digital practices. Apps that are released without a product owner and that sit untended, collecting technical debt and creating risks for their users. Apps that cost the taxpayer precious dollars in development and hosting, but that have very few actual users or benefits. Apps that were built for a unique and valid reason, but for which teams created unique and duplicative functionality.
Build once, use often
Applications — the software that enables digital service delivery — are made up of a suite of composite parts. These parts can do things like transfer files, collect information, issue payments or notify people. The parts are rarely unique, and it makes sense to reuse them often across governments.
In tech, we talk about moving up the stack. Amongst the layers of hardware and software that enable our digital services in government, it usually makes sense to customize things as little as possible. It’s cheaper and less risky. That said, governments have to do things that other organizations don’t, and there isn’t always commercial software available that meets our needs.
And so, like many big organizations, governments build lots of software. In the government I serve, we try to do that in the open: we use open source licensing to buy and build, we release our code (here’s our GitHub), and we work to align with our wonderful digital principles. And increasingly, we look for opportunities to reuse the code that we buy or build. And those bits of code that we can reuse? We call them common components.
Common components for the people
At its core, having mature common components is about making it easier for teams to deliver great digital services. Without doubt, our most important users are the people we serve (for me, the people of British Columbia). But if we’re smart, we should also recognize that the digital leaders within our governments are also our users. And we can empower them to be more efficient and more user-centric when we provide them with mature components that are ready to use across the enterprise. For a lovely and hilarious description of common components, I wholeheartedly recommend this cheerful British video.
The work of building common components is about applying a service approach to digital enablers. Over the past few months, we asked digital teams why they weren’t using common components. Reasons why teams don’t use common components:
- Lack of awareness
- Lack of incentives
- Difficulty onboarding
- Challenging funding model
Each of those barriers could trigger a diatribe on their own, but suffice to say that, as noble as our goal may be of efficiently delivering brilliant digital services, there’s a fair deal of grit in our wheels.
What makes a good common component?
Sometimes I ask my friends and co-conspirators to imagine a world where we can use fairy dust to build our ideal systems and products, barriers be damned. We did this thought experiment for common components. So here’s what we thought would make for a great common component (or “coco”, because we’re cute that way):
- Quality product — Good cocos need clear and ongoing product ownership, ideally aligned with the mandate of the organization providing the service.
- Funded — Cocos should have predictable and ongoing funding provided centrally (or via cost recovery, partial or complete, if customization is required).
- Discoverable — They should be easy to find through some kind of public catalogue that is written in words that non-developers can understand.
- Easy to use — Adoption and onboarding should be easy! In fact, it should be so easy that teams don’t want to use anything else.
- Standardized — There should be some solid documentation around the use of the tools, likely reinforced through clear standards or policies.
- Predictable — Cocos should have appropriate governance supported by a product roadmap, documented service levels and generous change management.
Easier said than done! Often, components have some of these attributes but not all. And if we’re being judicious in our use of resources, that’s probably okay. But for components that teams need and actively use, it’s likely worth pursuing an enterprise-ready level of maturity. That maturity would mean that components are beautifully governed, implementation is seamless and dedicated teams provide continuous improvement.
Common components for #DigitalBC
I hope that by this point in my story, you are fully convinced of the joys of enterprise-ready common components. My thesis: governments can and should be smart about how we build modern services, and we have a growing suite of tools to do that well.
So now, the climax:
The good news: we have some common components! They’re documented here, and many of them are available for you to use. For me, this catalogue represents a thrilling step towards a coherent approach to effectively building digital services across government, prioritizing user experience while respecting the taxpayer. We even included one that we use, Notify, from the Government of Canada!
The less good news: not all of our components are as mature as we might like. But honestly, that’s likely good news too! It means our teams have been judicious in our investments. We’ve tried to be honest in describing the functionality of the components. And if there’s demand for them to improve, I think we’d all be delighted to take an ecosystem approach to maturing them.
Tell us what you think
We invite you to click around the catalogue. Like all good releases, we’re planning to take an iterative approach and improve the documentation as our tools improve. We’d welcome your feedback.
There’s contact information on the site for each component. Get in touch. We’d be thrilled to work with you to strengthen digital government, #DigitalBC and frankly, the promise of government providing brilliant services to our communities.
Onwards.
