Sunsetting Book

Bret Davidson

Jason Ronallo

2018

Introduction

There are only two ways for your organization to get more done:

Hire more people.

Do less.

This is a short book about how to do less.

Work in Progress

This booklet is a work in progress. We think there are some useful content here already, but we’ll be adding and changing this over time as we gain more experience and learn more.

Site Updated: 2018-07-03

Who

We work in an academic library in a technology department. While we think a lot of what we write applies outside of academic libraries and technology work, that’s our background.

Working on the context of an academic library these days means managing lots of change. Academic libraries also have particular challenges like actually running multiple “businesses” at once.

Working in technology means managing both technology change as well as making those shifts into new areas of work.

Sunsetting is one reaction we have had to dealing with the context we work within.

What's in a Name?

Why do we use the word “sunsetting”? What other words could we have used?

Decommissioning: We could write about decommissioning. Decommissioning captures some of what we mean. It is a process. But it sounds sterile and formal. Are we docking a naval vessel into port and filling it with mothballs?

Shut down: We could say we’re talking about shutting things down, but that’s just a technical piece to the work. “Shut down” is about the mechanics involved but misses too much of the human. Sunsetting something isn’t as easy as flipping a switch.

Winding down: Gives the impression that projects and services are just wind up toys and then just continue to walk under their own power until they wind down. This one minimizes the ongoing, often hidden, work that happens in order to maintain something.

Killing off: We could say we’re killing off projects, but that sounds too brutal and bloody. In some cases this

Pulling the plug: Continuing on with the gruesome theme. This one is too traumatic. Such a difficult choice to make.

Death: In some ways we are writing about the death of projects and services.

Socio-Technical

A lot of the options for naming this kind of activity are insensitive to the social aspects of the work. We want to recognize that this can be uncomfortable and emotional work. In some cases you’ll be considering sunsetting a product that was someone’s successful idea or that they put months of effort into. It is difficult to consider killing off someone’s “baby”.

For these reasons we prefer the term sunsetting. Sunsets can be beautiful. We’ll cover more later about how to soften the blow. They can be gradual–you’re not just pulling the plug but making the necessary plans. Sometimes there’s a twilight period for a project before its day is over.

Preservation

By trying to pick our terminology carefully we hope to break through some other barriers in our thinking. We work in libraries and archives, so our natural inclination as librarians is to preserve. Pulling the plug on something isn’t an option without considering preserving it in some way. Preservation can certainly factor into approaches selected, but we need to modify our expectations on what can be preserved and to what extent.

Why Sunset?

Sunsetting is simply a means to an end, not the goal itself, so what are we really trying to achieve? There are lots of reasons to consider sunsetting but the ones we want to focus on are about how it addresses a particular set of challenges in academic libraries. As we’ll likely repeat throughout we think these can apply to other areas as well. Sunsetting can be an effective way of managing some of these challenges.

Our best summary we currently have of these challenges and how sunsetting helps address them is in our CNI presentation.

Definitions

Portfolio: We refer to all of the projects, products, committees, and service of an individual or organization as their portfolio. We like the term portfolio as it needs to be organized. We’ll give tips for how to organize portfolios.

Trigger Points

Consider what may trigger a sunsetting.

You’ll need to pick your own, but following are some suggestions for trigger points from the kinds of technology work we do.

While only some of the following will end in a sunsetting, they’re useful moments to pause and consider the option.

Frequency

Sometimes you might choose a sub-optimal direction so that you can move forward with something. Or maybe rather than continue to think so deeply about a particular area you accept something less than ideal in order to move on. So the same is true with considering sunsetting.

Organizations often have a product or project which is constantly under scrutiny if not assault. Are we still doing that? Do we still have to do this? If there’s a constant stream questioning the value of a product or project it can take a lot of time as well as being demoralizing for the staff involved.

We want to avoid every question always being open. One solution to this is setting particular trigger points for considering doing something as extreme as shutting down a service or making other changes. We avoid constantly revisiting every commitment by setting trigger points for when to ask those questions.

Staff Changes

A lot of our work on sunsetting developed when a well established, successful librarian developer who was responsible for many of our successful projects left. We had to take this large portfolio of successful projects covering a wide variety of types of projects and technologies and distribute them across the department. It really hit home how we needed to take these kinds of events much more seriously if we were going to keep moving forward. We want to be proactive in identifying opportunities to address questions before someone leaves. Besides the obvious staff departure scenario consider the opportunity in redistributing portfolios to identify other changes that could be made.

Migrations

If you have to touch or change a large codebase in a significant way, then consider other options like sunsetting. Is it worth it to put in the work needed to keep the project working?

There’s a lot more to say about the importance of maintenance and the need to better valorize this necessary work, but in the life cycle of technology projects, maintenance often exposes a particular organizational challenge. The true cost of maintenance is often hidden. And why is that?

Technology projects can start with an even distribution of effort between various stakeholders and technical staff. Once a product is in maintenance mode it can sometimes lead to an uneven distribution of effort.

There’s a long tail to these costs and they can often be most heavily borne by our most productive, successful, creative technical colleagues. Even if the percent of time for each one might be low over time, they still take up head space and can lead to more anxiety and context switching. So surfacing these costs at times like a major migration, can help us do the cost benefit analysis.

Changing Skills

We’ve found that we’ve made better choices over time on sustainable software stacks and development practices. We’ve consolidated more around some foundational, even boring, technologies that get the exciting work of meeting user needs done just as effectively. This has meant that we are no longer developing and updating skills with some of the older technologies we used in the past.

When should you deprecate or change software stacks? When should you adopt new technologies?

We can’t answer those questions, but once your answer is “now”, then consider how you’re going to stop using those technologies.

With as many services as your organization provides, do you have the depth and redundancy you’d like in the technologies and skills you need? It is a real challenge. Skills in the market change. For instance, maybe you were a PHP shop and you’re finding that you are hiring more python developers. When you’re noticing that you’re shallow in technologies you’ve used in the past, consider sunsetting when you don’t want to continue to maintain services in which you’re no longer actively building skills.

Commercial Options

Since the time you’ve developed an application or service, have commercial options become available or matured? In my department we’re often creating novel services that then eventually become more mainstream. At that point there’s often no longer a compelling a reason to maintain what we’ve done. There is sometimes the hurdle of having to accept something that’s not bespoke, but the availability of commercial options is certainly a trigger point for considering a migration.

Whether commercial or an in-house developed bespoke application, if you’re the last user of the application then it might be time to sunset it. We get lots of benefits from being involved with communities. If the community is gone are you still getting all the benefits you want? Don’t just assume you’ll want to make a migration in these cases. Is the reason you’re the last user because the general value has been proven to be low?

Organizational Change

Lots of reasons why organizational change might trigger sunsetting. One is when you see the strategic direction and goals of your university changing. You get an explicit statement of a pending change. How can you quickly re-align? Does your current service in an area still meet the emerging needs? Consider how you’ll clear the space to begin working in new areas.

Anticipation

Sunsetting can be an effective way of clearing out enough space in anticipation of new work. To really be strategic in your vision. Besides explicit organizational change when you get external signals of a change in the field, in new technologies, you and your colleagues may have a hunch about new opportunities. Consider how you’ll make space rather than just adding on top of already busy staff.

Team

The same way you need a team to start a project you need a team for sunsetting.

The team for a sunsetting can be different than the team that developed the product or service. In some cases you’ll need different skills. In others mobilizing folks who have worked on similar sunsetting projects before or have the connections or relationship needed can be beneficial. Changing up the team in this way can also make it easier on someone who doesn’t have to be responsible for killing off the thing they spent so much time on. Having someone who was on the product team step away once it will be sunset can also have a more immediate benefit of clearing space for that staff person while not also adding a sunsetting project. Sunsettings often have different schedules and timelines from other project work so considering who will be in the best position at different stages helps.

Communication

For any sunsetting you’ll need a communication plan. Our background is in technical products and projects, but we’ve found that what needs the most lead time in sunsetting projects is the development of the communication plan.

Part of this is internal communication, for the affected teams, departments or the library as a whole. The projects that get sunset are often someone’s baby, and they reflect significant achievements in people’s careers. It can be difficult to let go of things that have been part of someone’s professional identity and sensitivity to that for internal communication plans is an important consideration.

Users, faculty, campus partners, etc. all may be impacted by sunsetting. What options exist for data export or migration to other services? What services do you provide for them going forward? Part of this work should be the exploration of alternative options, if any, for a user to have their remaining needs met. Before you communicate with your users you’ll need to develop some migration plans. How do we still direct our users to services that will meet their needs? We don’t want to abandon our users. We’ve ended up not needing these migration plans for some services, but they were a good safety net to ensure we avoided issues for our users.

You then may want to consider how to do external communication within your profession or domain. How do you communicate that some things you sunset were still successful projects? In some ways communicating with the external audience in this way also communicates clearly to internal colleagues the value of the work they’ve done. How do boost the good work of your colleagues even after the application or service is no longer live or being practiced?

In the technologies of sunsetting section we’ll mention some of the common approaches to support these kinds of communication including pickling and tombstoning.

Technologies

What are the technical aspects of sunsetting?

What are the technical tools that aid in sunsetting?

We’ll write here about topics like:

pickling

tombstones

project pages

virtualization

web archiving

migration paths (and ETL)

static sites

Pickling

We also need some way to capture the parts of the project that are essential for the organization, the internal part of the work.

This might be documentation about code repositories, database backups, project documents, etc.

Tombstones

First, we need some ways to capture the history and success of projects so that people can continue to be recognized for the great work they did.

We also need to preserve what we’ve learned from the work.

Project Pages

One way we do this is through project pages that capture who worked on the projects, describe what the project was about, and shares some of the impact of the project.

This also serves as a way for external folks to view historical projects.

Virtualization

Building on some of our development practices, we’ve experimented with using Vagrant development environments as a migration target.

These are isolated, disposable environments that can emulate a web server environment in every detail that are run on a local machine.

Web Archiving

We can also use some of our existing infrastructure to smooth the path to sunsetting, such as using web archiving to create a snapshot of a site.

We did just this with Learning Space Toolkit, a grant project deliverable that we migrated using web archiving tools. The web archiving/static site approach can extend the useful life of a project while also bringing closure to a major grant deliverable.

Migration Paths

Migrations can be a way for projects to live on but in different forms, especially ones that take less effort to maintain.

Some migration paths can be used to breathe a sustaining breath into old projects and some can be used to demonstrate that a project really is ready to be sunset.

We won’t cover the whole spectrum of alternatives, but here are some ways you can reduce the load of services even if you rule out sunsetting.

Static Sites

Static sites are another migration path and are one way to keep an application alive with lower effort and higher sustainability.

Often times, by the time a project reaches maturity we have a much better understanding of what features or capabilities are important. We can take just the most useful, important parts of an application to allow it to live on.

Not a sunsetting, but maybe a point you don’t get to without suggesting sunsetting.

It’s also worth noting that a static site migration can be completed by someone other than the original developer.

Case Studies

The story of some successful and unsuccessful sunsettings.

We’re looking for others to contribute case studies as well. Get in touch.

Presentations

DLF 2017

CNI Spring 2018

License

Creative Commons License
Sunsetting Book by Bret Davidson and Jason Ronallo is licensed under a Creative Commons Attribution 4.0 International License.

Credits

Contact

Contact Jason Ronallo at jronallo@gmail.com

We’re looking for others to contribute case studies as well. Get in touch.