如何在应用交付上发布应用
使用订阅模型在云中交付的应用程序组件市场正在爆炸式增长，它跨越了软件供应链，并且还在不断增长 。
鉴于这些组件服务的高质量，可能很难确定如何采购零件-您应该使用供应商还是自己建造？ 解决此问题的方法有很多，但是可以帮助您做出决定的有价值的思维模型是将代码视为一种责任。
自然的想法是将代码视为企业的资产。 这是您投入资源进行构建的要素，它可以推动业务的增长。 但是，另一种思路将编写代码视为创造风险，将其视为创造业务价值的必要手段。
类似于金融债务，想法是这样的：您借出抵押贷款购买房屋，您只想要房子，而不想要抵押贷款。 因此，您要尽可能减少抵押贷款，仅将抵押贷款保留足够长的时间以获取价值（房屋）。 而且，如果您要搬到新房子，则不要随身携带抵押贷款。 债务（负债）是价值的一种手段。
您可以用相同的方式来思考代码：您实际上并不需要代码，而是想要它创建的值。 代码需要不断的成本来理解，维护和适应它。 这些费用与支付房屋利息相同。 Scrum主管，两个比萨饼团队以及敏捷的仪式—都是必需的，但是所有人都只是在付清利息。 不幸的是，当您移至应用程序的版本3时，版本1的债务仍将徘徊-您无法摆脱委托人！
如果您是来自开发或技术领导者的背景，而您的角色偏向于构建自己的软件和系统，那么将代码视为责任是从业务角度查看决策并制定良好战略决策的绝佳方法。 将模型应用于构建与购买问题，出现了四个需要考虑的关键领域。
1.技术债务
良好的技术规范可作为资产（客户价值）的保险，确保资产不会随意消失在意大利面条代码，损坏的工作流程和错误的用户界面中。 如果您拥有良好的产品管理和敏捷的开发工作流程，那么您将使用一个在技术债务产生时对其进行标记的系统，并为其分配时间来连续重构代码库。 同样，强大的应用程序交付管道大量使用了代码审查，测试自动化，CI / CD和扫描工具，使您可以规避沉重的债务 。 如果您的流程不清楚，您的应用程序仍处于早期阶段，或者您打算在应用程序交付系统中进行重大更改，则添加更多代码很可能会带来坏账。
2.文化债务
当您将其作为服务购买时，是否值得伤害您的团队来构建新模块？ 要考虑的第二项责任是文化债务 -当您的决策收益对组织的文化产生长期影响时，就会发生这种情况。 如果问题出现在您最宝贵的资源：人身上，那么有必要考虑是否会损害您的创造价值的能力。 当您将人们与数据，信息，流程或彼此隔离开来时，断开连接，不满和不确定性将比比皆是。 把您的人民放在第一位！ 确保您不会因技术决策而承担文化债务。
3.知识不足
第三个考虑因素是您要构建的组件是否需要高度专业的知识。 这里的主要示例是涉及安全性的模块：文件处理，身份验证，加密和用户管理。 除非您拥有强大的内部专业知识来安全地构建这些知识，否则最好将风险转移给第三方。 其他示例包括分析和集成。 这些特色很容易陷入Dunning-Kruger效应 。 它们似乎是可以解决的问题，但现实情况是分析非常复杂，并且集成设置起来很棘手，并且随着时间的推移很难维护。
4.供应商波动
最后要考虑的是供应商本身。 您的供应商需要仔细评估，以确保其服务的可靠性以及您自己的法律和合同义务。 一些关键点包括：
像ISO 27001或SOC2这样的认证提供了一个简单的捷径，可让您决定是否信任供应商的技术印章。 但是，如果供应商没有它们，您可以自己做事以提供保证。 对于小型公司或新公司，您应要求与您位于同一细分市场的其他客户提供参考。 询问当地客户，带他们出去吃午餐，并了解与供应商合作的感觉。 理想情况下，选择有机会合作的供应商，推动他们的产品路线图并与他们一起开发功能。 查看您是否能够与其产品经理保持联系，以透明地了解其服务的工作方式。
与您的供应商合作并支持他们的成长是值得的—它降低了在软件供应链中建立新依赖性的风险。
结论
“代码即责任”的思想增加了战略价值，并为规划组织的决策提供了更大的深度。 这意味着在将工作交给开发团队之前，您需要三思。 与随时间进行维护的成本相比，使用服务来交付不需要管理的组件实际上看起来很合理。 第三方代码和应用程序交付服务的市场反映了这一点，因此，请走出去看看如何利用市场机会。
翻译自: /article/3292600/the-new-build-vs-buy-problem-in-application-delivery.html
如何在应用交付上发布应用
如果觉得《如何在应用交付上发布应用_面对应用交付中的新建与购买问题》对你有帮助，请点赞、收藏，并留下你的观点哦！
