Sean Boots

Technology, public services, and people. But mostly people.

Three suggestions for the next President of SSC

Version history

Update: Last week the prime minister announced new senior leadership at SSC. All the best to the incoming team!

In early 2022, the President of Shared Services Canada (SSC) announced that he was retiring. In what has accidentally become a tradition, below are some suggestions for the next president to take on the role.

SSC was created in 2011 and is the centralized IT infrastructure department of the Canadian federal government. A lot has been written on SSC and its creation and evolution; I won’t recap it here but it’s a fascinating public administration and tech case study. For most of its history, SSC has struggled with both morale and technical capability; that’s started to improve in part under the most recent president. A few friends and public servants that I look up to highly work at SSC; from their stories, there are a lot of really great people who work there, but they often spend a lot of time fighting uphill battles against the organization’s long-established workplace culture and processes. Nowadays about 8,000 people work at SSC, making it the largest IT-focused organization in the federal government (in comparison, about 400 people work at the Office of the CIO, and about 110 people work at the Canadian Digital Service).

The suggestions below are some quick thoughts on where SSC could go from here. If you have ideas to add, give me a shout anytime.

1. Start moving to zero trust networking and away from perimeter defence

  • Network infrastructure and security has been a big part of SSC’s DNA since it was created. Like other traditional corporate networks, the government’s networks are heavily focused on perimeter defence and monitoring (what my friend Mike once called the “crunchy outside / gooey inside” model of IT security).
  • Other governments around the world, particularly the United States, United Kingdom, and other allies, are moving away from perimeter defence and towards a “zero trust” cybersecurity model (something I’ve written about before here).
  • Particularly as the Canadian government adopts cloud services at scale (a key enabler that kept the public service operating throughout the pandemic, and something SSC deserves a lot of credit for), perimeter defence makes less and less sense.
    • In practice, this can often mean piping internet connections from (very fast, very scalable) cloud providers back into (much, much slower) corporate networks in Ottawa before piping it back out to employees across the country connected over VPN.
    • Given the extensive security controls and monitoring tools that large-scale cloud providers have built into their own infrastructure, the added (perceived) security of traditional network monitoring tools isn’t worth the heavy cost in employee speed, reliability, and productivity. This includes “secure cloud to ground” systems that likewise aren’t worth the cost and complication.
    • Traditional network monitoring tools are also a great way to create a single point of failure for attackers.
  • The United States’ recently-announced approach is a great model to follow; I’d love to see SSC take the lead on implementing something similar in Canada.

2. Enable the rapid, secure adoption of third-party software-as-a-service tools at scale

  • Despite a 2018 OCIO directive encouraging public servants to use online collaboration tools, and the GC Cloud Adoption Strategy recommending software-as-a-service (SaaS) solutions as the government’s primary cloud approach, there are still a wide range of barriers to adopting, paying for, and scaling up their use.
    • These online tools – like Slack, Trello, Miro, and more – helped public servants continue to work, collaborate, and communicate throughout the pandemic. Departments that enable and encourage their use are going to continue to have more effective and more motivated employees than ones that don’t.
    • To SSC’s credit, its own employees have access to a wide range of online tools; this is great to see and something other departments should strive to emulate.
  • In collaboration with OCIO, SSC runs the government-wide employee login system (MyKey, which is somewhat ancient). This system is currently limited to on-premise networks.
  • SSC could play a major role in at-scale adoption of third-party SaaS tools by providing a government-wide employee login that is compatible with third-party single sign-on (SSO) connections. Enterprise-grade SaaS solutions often provide an option for external SSO logins, handing off account management to companies’ directory management systems and reducing the need to manage separate sets of users. For this to work, the government-wide SSO login needs to be available to cloud services (and to use modern, extensible protocols).
  • SSC could also work with the Canadian Centre for Cyber Security and Public Services and Procurement Canada to pre-emptively approve a large range of SaaS software for Protected B information. (It’s worth noting: departments can approve this themselves under the Directive on Security Management, but having a centralized list of pre-cleared SaaS tools would significantly help with uptake). To avoid concerns about favouritism for specific tools (or vendor lock-in), SSC could publish regular updates on what tools public servants across government are asking for, and prioritize security reviews accordingly.
    • Doing this continuously, rather than as a one-off exercise, would be critical to ensure that the list of reviewed software is up-to-date and relevant.
    • OCIO could publish complementary guidance and standards instructing that if a tool is approved for Protected B information in one department, it wouldn’t need to be reviewed separately by other departments (to avoid redundant security review efforts).
    • As much security documentation as possible should be publicly disclosed, for transparency and to support SaaS adoption efforts by other governments and jurisdictions who could reuse and build off this work.

3. Incrementally make SSC services optional instead of mandatory

  • This would begin the most significant change in SSC’s operating model since it was created. As I’ve written about before, making enterprise services optional instead of mandatory is a way of creating essential feedback loops and organizational incentives. Other organizations do this deliberately in order to raise the quality and competitiveness of their in-house tools and solutions.
  • In the Canadian government (and SSC is not the only example of this), we have a habit of making enterprise systems mandatory before we make them good. That eliminates feedback loops and makes it harder to make the case for continued improvements, because users and clients can’t choose to go elsewhere or use other options.
  • SSC provides a huge range of important services to departments; for many of these, a single provider really is the best approach (network cabling between office buildings, for example, is a natural monopoly that a single organization is best suited to handle).
    • For specialized services, however – from satellite monitoring to high-performance computing to field or offshore radio equipment to robotics – departments and teams have needs that consistently aren’t well-met through a single provider.
    • Likewise for emerging technology needs, public service teams need the ability to experiment with non-standard systems and devices. Requesting these through processes that are designed for highly-standardized devices and equipment adds delays and administrative burdens. It’s easy to forget how diverse the operations and services of the entire public service are; diverse technology is an important way of enabling these activities.
  • SSC’s intake process for requests from departments (via business requirements documents and months- or years-long timeframes) reinforces waterfall IT project management approaches that are decades out of date.
    • Switching to a catalogue model (where services are available instantly through automated processes, pre-approved without needing additional human approvals) would substantially improve SSC’s efficiency and reputation.
    • For bespoke or highly-specialized services that can’t be integrated into a standard catalogue (and where departments are currently dependent on SSC), these should be a high priority to migrate staff, expertise, and responsibility back from SSC to the department that needs them.
  • For areas where SSC acts as a contract holder and reseller – for cloud infrastructure, for example – it should be just as fast to acquire these services through SSC than to get them directly from the original vendor.
  • Given SSC’s size and responsibilities, making its services optional “overnight” would introduce a lot of uncertainty and confusion. SSC should create a 1-3 year roadmap with incremental timelines for making each of its service areas optional (with any remaining exceptions, like physical network cabling, clearly laid out). An update to SSC’s enabling legislation or Order-in-Council directions would help support this approach.

The technology world has changed a lot in the past 11 years. For teams that deliver software and build online services, one of the biggest shifts has been bringing together software development and system administration responsibilities into the same roles. DevOps (as this is called) is how the world’s leading tech companies build and operate services used by millions of people. This includes using automated systems (particularly infrastructure as code) and SRE techniques that help ensure that services are reliable, secure, and scalable. In the Canadian public service, genuine DevOps approaches are used by a vanishingly small number of teams, because our organizational structures don’t allow it.

As SSC moves towards making services optional instead of mandatory, it should also plan for the gradual migration of (some, but not all) SSC staff back into departments. This shouldn’t necessarily be a migration into departmental IT groups; embedding tech expertise and capabilities and responsibilities directly into program teams is where the future is going. DevOps with the “Ops” part in a separate team isn’t genuine DevOps (much like the case today, where it lives in a separate department at SSC). SSC’s sysadmins and IT professionals have a tremendous amount of expertise and institutional memory that departmental teams would benefit from.

Joining an organization and scaling it down, in part, might not be the most exciting goal for new leadership. But in SSC’s case, it’s a rare opportunity to reinvigorate the broader public service’s technology capabilities. Switching to modern zero trust networks, enabling at-scale use of software-as-a-service tools, and creating feedback loops and incentives by switching to an optional service delivery model – it’s the beginning of creating the tech-equipped overall public service that Canada needs.