O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

How to Build, When to Buy: Scalable Tactics for Digital Projects and Services

62 visualizações

Publicada em

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?

Publicada em: Tecnologia
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

How to Build, When to Buy: Scalable Tactics for Digital Projects and Services

  1. 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. 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. 3. “Build or Buy” A swift way to summarize a range of options among two obvious and opposing points.
  4. 4. Scalable Tactics scalable: usable or adaptable with changes to scope or size. tactics: specific actions to reach an objective.
  5. 5. Common Building Blocks
  6. 6. Specific Building Blocks
  7. 7. Software Economics “Economics is the study of how people make decisions in resource- limited situations.” Barry Boehm “Software Engineering Economics" 1984
  8. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 24. Use Case + Parameters
  25. 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. 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).
  27. 27. 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.
  28. 28. 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.
  29. 29. 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.
  30. 30. 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

×