Take an ecosystem approach

Use ecosystem thinking

Ecosystem thinking means taking a broad perspective in making decisions about your service. This includes:  

• Understanding your service end-to-end so it meets user needs in a predictable and cost-effective way 
• Knowing your service’s role in the ecosystem, including how it supports government priorities, provides a consistent user experience and impacts partners  
• Collaborating widely using platforms such as Communities of Practice, the DevHub, GitHub, Rocket.chat and Stack Overflow  
• Using smart data management practices that reduce duplication and enhance data quality  
• Being aware of compliance requirements in enterprise standards and core policies  

Understand build buy decisions

Digital products and services are composed of multiple technology choices, each of which must be considered independently. Sometimes these choices come down to deciding between building a custom solution or buying a commercial product. Commercial solutions can be cost-effective compared to custom-built ones, but choosing them without considering long-term effects on the ecosystem can create future issues and dependencies.  

A commercial product could be the best choice if:  

• It will meet government and user needs at a competitive price, both in up-front and long-term costs 
• It doesn’t need to be modified to suit your needs, which could make it expensive and difficult to maintain 
• It is actively supported and improved by its vendor 
• It can scale or adapt to meet your future needs without becoming too expensive 
• You can test it before you make a commitment to adopting it 
• There is evidence it will work, such as a track record of successful use by other organizations 

It may be better to develop a custom solution if commercial products: 

• Can’t offer the functionality you need or the market lacks maturity or diversity 
• Would need expensive modifications to meet your needs 
• Would prevent the government from owning or controlling the final system and its information 
• Are untested or can’t show evidence they’ve worked for other organizations  
• Can’t show that they will continue to be cost-effective and flexible if your context changes in the future 
• Would result in lock-in or reliance on the vendor that isn’t worth what they offer 

Whether you choose to build or buy, the key is to be consistent and thorough and consider the future impact of your choice on users and the ecosystem.

In either case, be certain you have the resources you need to support the solution throughout its lifecycle. Document your reasoning clearly and re-evaluate the solution regularly to make sure it continues to meet your needs.

Avoid lock-in 

Lock-in means being overly reliant on a certain technology or vendor so switching to a different option becomes impractical. This makes it difficult or impossible to pivot if your context changes. Avoiding lock-in means ensuring you have long-term flexibility to continue making choices that best meet your needs and those of your users. To help avoid lock-in: 

• Consider each technology choice independently. Something that worked in one context might not work in another 
• Don’t choose the same solutions just because it’s what you used last time 
• Avoid inflexible solutions unless they offer the best balance of functionality and long-term value  
• Maintain ownership and control of government data, source code and front-end interfaces 
• Right-size contracts by making sure they’re reasonable in length and value 
• Build internal capacity to develop and maintain systems and avoid options that we can’t maintain or educate our people about without vendor support 

Lock-in can be acceptable in some cases. Committing to a solution with high switching cost can still be the best option if it offers functionality or value we can’t find anywhere else.  

To make the right decision, consider the long-term impact of your choice on the ecosystem and your users. The best option is the one that meets government and user needs while minimizing expense, switching cost and technical rigidity through the service’s lifecycle. 

Focus on interoperability  

Use reusable technologies

Reusable technologies can make services more reliable and sustainable by providing teams with pre-built solutions to common problems, so they don’t need to build a solution themselves. When choosing the best solution for your product or service, the priority should always be to meet user needs and deliver value. The reusable technologies below can offer great flexibility and value to help you do that.  

Common Components 

Common components are reusable software building blocks that offer a pre-built solution to a common and well-defined problem, such as taking a payment. Well-designed common components are easy to adopt and integrate with other systems, reducing the investment of time and effort required to add functionality to your service.  

Shared services 

Shared services include shared software like government email, as well as shared infrastructure like government networks, servers and facilities. Using and improving these services helps our services provide better consistency and value to the community. 

Open solutions 

Open solutions are free, publicly-available standards and software. Using them can promote transparency and consistency, making it easier for the public to understand how our products work. Open solutions include: 

• Open-source software, which is often supported by a strong community of contributors 
• Open standards (file formats, protocols and interfaces), which can support interoperability and streamline development 

Cloud technologies

Cloud technologies provide services over the internet. They can make it easier for services to adapt and scale and can sometimes enable faster and cheaper development. The main types of cloud technologies are:    

• Software-as-a-service (SaaS) resources such as those found in the SaaS wayfinding guide and SaaS directory, which allow the use of applications over the internet 
• Platform-as-a-service (PaaS) resources such as our private cloud development platform and public cloud hosting services, which provide online environments to develop, test and deploy applications 
• Infrastructure-as-a-service (IaaS) resources, which allow for virtual hosting of products and services 

Cloud technologies should be implemented in a way that protects privacy and prevents lock-in by ensuring we have sufficient architecture flexibility and internal technical skills to pivot to other options if required.  

Alignment guide

The alignment guide is intended to be used with the supporting context of the related practice and resources. This guide provides examples of what the implementation of this practice may look like and defines a range of competence within the practice area.