Knowing when to build or buy software is an ongoing topic that has existed for decades, but answers evolve alongside trends in museum staffing and software business models. How do you respond when vendors and agencies are filling your inbox with listicles on why you should buy their solutions? What if an energetic developer wants to build sharable and open solutions that will require maintainers? How can museums with very different resources and personnel share tactics in a meaningful way?

1. How to Build, When to Buy
Scalable Tactics for Digital Projects and Services
Chad Curtis
Head of Digital Platforms
MuseWeb
April 4, 2020

2. Possibilities
How do you respond when vendors and
agencies are filling your inbox with
listicles on why you should buy their
solutions?
What if an enthusiastic developer wants
to build sharable solutions that will
require maintainers?

3. “Build or Buy”
A swift way to summarize a range of
options among two obvious and
opposing points.

4. Scalable Tactics
scalable: usable or adaptable with
changes to scope or size.
tactics: specific actions to reach an
objective.

5. Common Building Blocks

6. Specific Building Blocks

7. Software Economics
“Economics is the study of how
people make decisions in resource-
limited situations.”
Barry Boehm
“Software Engineering Economics"
1984

8. Software Economics
How much is this going cost?
How long is this going to take?
Will it provide all the features we
requested?

9. Competitive Advantage
The highest-ranking factor for a
decision to build or buy software in
the private sector is competitive
advantage.
What does that mean for cultural
institutions?

10. Digital Teams
Within the frame of competition:
digital teams at cultural institutions,
regardless of size or structure, have
to decide when to build or buy
solutions based on a variety of
parameters.

11. Digital Teams
Based on findings of Kati Price and
Dafydd James (2018) it can be presumed
that the majority of cultural institutions
employ five or fewer people dedicated
to digital activities and that software
development is underrepresented and
likely outsourced.

12. Digital Teams
Connecting Bohem’s software
economics and the context of
competitive advantage: most cultural
institutions are likely constrained to
buy solutions and a smaller segment
possess the ability to build solutions.

13. “Build or Buy” Parameters
• Strategic Importance
• Direct Impact to Cultural Objects or Knowledge
• Availability and Sufficiency of
Commercial Off-the-Shelf (COTS)
• Cost of Labor
• Cost and Type of License
• Time to Public
• Scope and Complexity
• Staff Capability
• Staff Capacity
• Language / Architecture / Platform

14. “Build or Buy” Parameters
Strategic Importance
• The higher the strategic value, the more likely building or contracting to
build should be considered. The lower the strategic value, the more likely
buying should be considered.

15. “Build or Buy” Parameters
Direct Impact to Cultural Objects or Knowledge
• Much like strategic importance, the more direct impact a project or service
will have on objects or knowledge, the more likely building or contracting
to build should be considered. The lower the impact, the more likely
buying should be considered.

16. “Build or Buy” Parameters
Availability and Sufficiency of Commercial Off-the-Shelf
• An environmental scan of available software should always be conducted,
followed by a comparison of functional requirements. The need to build or
buy will be guided by whether COTS solutions are an exact fit, under-
deliver, or over-deliver for cost.

17. “Build or Buy” Parameters
Cost of Labor
• Whether building software internally or contracting an external partner to
build a solution, a calculation of labor compared to the value of
commercially available software must be evaluated.
• In the case of “contract to build” the difference between the time to
complete a project and the amount of labor required has to be calculated,
then a comparison needs to be made between labor rates of staff and
contractors.

18. “Build or Buy” Parameters
Cost and Type of License
• Maximize the use of open-source software licenses (commercial services
and support can be offered alongside open licenses.)
• Closed-source software licenses will be necessary at various levels and
should not be dismissed, however scrutinize closed-source solutions to
avoid vendor lock-in, vague roadmaps, unclear pricing, or any issue that
creates unnecessary dependencies between a provider and client.

19. “Build or Buy” Parameters
Time to Public
• The private sector uses the term “time to market,” so it seems fitting to
adapt the term for cultural institutions. The shorter the deadline, the more
likely the need to buy, while a longer and more flexible timeline allows for
building.

20. “Build or Buy” Parameters
Scope and Complexity
• The features provided by software, number of stakeholders, and
dependent services are just some factors that make the difference between
a small feature request and a discrete project or service.
• A larger scope and complexity, compounded by a short timeline, means
buying is more likely. However, with enough time and staff capability even
large scopes can be addressed in-house.

21. “Build or Buy” Parameters
Staff Capability
• Capability is a team’s theoretical potential to complete a project. If a team
has unlimited time to apply current skills and knowledge, this is a team’s
capability.
• Capability is often summarized and conveyed through rank and roles,
such as comparing a junior developer and senior developer.

22. “Build or Buy” Parameters
Staff Capacity
• Capacity is a quantifiable output, discoverable when staff capability is
placed within time restrictions. Staff capacity can be applied in software
cost estimation.
• An institution can be in a position of having a highly capable and skilled
team, but if they are not available they simply do not have the capacity to
build software.

23. “Build or Buy” Parameters
Language / Architecture / Platform
• The more accumulated experience a team possess the more likely they can
build across languages and adapt to frameworks. Limited experience
across fewer languages means buying is more likely when a project or
service requires an unfamiliar language or platform.

24. Use Case + Parameters

25. Use Case + Parameters
• SLAM launched a new website in December 2018 in partnership with
Cuberis, an agency that focuses on museums and galleries.
• The decision to engage with an external partner was based on a short
timeline (Time to Public) and current availability of the small internal team,
despite existing experience (Staff Capacity).
• The global decision was classified as a “contract to build” (Cost of Labor) in
which SLAM would take over development after the foundation was
established by Cuberis.

26. Use Case + Parameters
Adopting a CMS
• SLAM needed a CMS that would be a flexible development platform, easy
for content managers to use, and provide a large global community which
SLAM could leverage for long-term sustainability.
• We did not want to build a CMS, adopt a proprietary system, or join a small
community for support and development (Availability and Sufficiency of
Commercial Off-the-Shelf + Cost and Type of License).

28. Use Case + Parameters
Building the Online Collection
• Content with the highest complexity and top priority: art objects that comprise
our encyclopedic collection (Direct Impact to Cultural Objects or
Knowledge). SLAM’s Digital Strategy emphasizes the creation of content
around the collection (Strategic Importance).
• A review of existing commercial solutions revealed features that were not
needed and requirements that were not addressed (Availability and
Sufficiency of Commercial Off-the-Shelf). Investing in a new abstraction
layer was the best path forward.

30. Use Case + Parameters
Buying an Events Calendar
• Original scope included an integration layer with commercial event
management software already deployed internally at SLAM. The scope of the
integration had to be reduced to allow more time to adjust internal
procedures (Scope and Complexity).
• SLAM and Cuberis decided to license a commercially available calendar
plugin for launch (Time to Public) and let SLAM handle further event
integration as a separate project.

32. Conclusion
• Faced with competition among peer institutions and the private sector, digital teams are faced
with the challenge of pushing their own capabilities and capacity while knowing when to ask
for help from external partners.
• Implicit competition amplifies the importance of how cultural institutions provide and
maintain digital projects and services.
• Tactics are the primary method for digital teams to realize digital strategy and deploying them
through a combination of shared models and tools is vital to compete for time on user devices.
• By continuing to examine our decisions to build or buy software cultural institutions can gain
a greater awareness of how experiences are shaped by software and how to best utilize our
teams to serve our communities and collections.

33. How to Build, When to Buy
Scalable Tactics for Digital Projects and Services
Chad Curtis
Head of Digital Platforms
MuseWeb
April 4, 2020
chad.curtis@slam.org
@rampantprint