要能胜任，或者为架构中的每个组件购置能胜任的解决计划。任何因特网办事或电子商务解决计划。为基本举措措施中的每个组件，标识出团队对它应负的义务以及应当具备的才能程度。对客户来说，每个问题都是你的问题。你你不克不及责怪供给商。你供给的是办事，不是软件。

不要把可否胜任与本身开辟照样外部购置或者与焦点决议计划照样高低文决议计划的问题相混杂。你可以购置解决计划，但仍然要能胜任去安排和保护它们。事实上，客户也请求你如斯做。

也许你以为这条原则是不问可知的:“对于我们所做的来说，我们当然是能胜任的，不然我们若何坚持营业?”为了解释这个原则，我们假设你有一个因特网产物，如某种SaS平台、电子商务产物或其他在因特网上交付的解决计划。

你的团队对你采取的负载平衡器真正懂得若干呢?你多久要求一次外部赞助来解决这些负载平衡器的问题或者实现新功效呢?你的数据库又若何呢?你的开辟人员或DBA知道若何断定哪些表须要索引，哪个查询运行得比梦愒四?你知道若何担表移到文件体系上，削减争用，进步整体临盆力吗?你的运用办事器又若何?谁是处置这些问题的专家?也许，你对所有这些问题的反响是，你并不须要亲自做这些工作。你可能从其他人写的书中读到过，应当发明本身具有不同凡响的才能的范畴，并专注于这些范畴。然而剖断一个组件是否“非焦点”或者该组件毕竟应当从外部购置照样本身开辟，这并不该该与断定团队是否有响应的才能来掌控所购技巧相混杂。应用第三方或开源数据库绝对没有问题，但这并不料味着你就不必懂得数据库，不必具备对它进行操作和故障检修的响应才能。

你的客户期望你交付给他们的是一个办事，而你开辟一个举世无双的软件来创立这个办事只是实现目标的手腕。归根结底你是在一个办事业，这一点不要懂得错了。这是一种必须的心态，假如缺少这种心态，事实证实这会造成公司退化甚至扑灭。Friendster过于存眷“同伙圈”(F-graph)，这是一种用来盘算社交收集中人际关系的庞杂解决计划，可能是它在小我社交收集竟争中败给Facebook的原因之一。这种存眷背后是一种立场，一种很多软件市肆都持有的立场，即“同伙圈”所提出出的难题必需获得解决。这种存眷会造成站点办事中止或者响应迟缓，因为体系在及时盘算人际关系时会变得迟缓甚至停滞运行。与之相反的是存眷办事，即可用性和响应时光比任何特别功效都主要。软件只不外是供给办事的一种手腕罢了。

但在我们的世界中，你所须要的不只是软件。基本举措措施对以高可用性的方法按时处置事务来说也很主要。就像我们可能会过于存眷解决计划中的一个问题一样，我们也可能会疏忽用来供给办事的架构中的其他组件。假如说，为了顺遂供给办事，我们必需在软件方面能胜任，同样我们必需在与此相干的其他方面也做到如斯。客户期望获得的是优良的中的组1件出了故障，他们不会谅解你并不是井友者也不是这方面的专家，并且也不会关怀这些。

是以，固然你不必开辟解决计划中的每一部门(事实上我们也不该该开辟每一部门)，但却要对每一部门都有所懂得。对于我们采取的任何器械，我们都要可以或许准确地加以应用和保护，并在它们产生故障时，可以或许敏捷地予以恢复。经由过程在本身的网站设计团队内成长这些技巧或者追求合作伙伴的支撑，可以赞助我们做到这一点。团队越年夜，对某个组件依附越多，我们就越应当具有本身的专家。而团队越小，响应组件的主要性越低，我们就越应当将工作交付给外包专家去做。但假如依附合作伙伴供给赞助，那么你们之间的关系就应当不止于年夜多半装备供给商所供给的。这些办事供给商必需与你共担风险。换句话说，他们须要在你的办事产生故障时，亲身感触感染到你和你的客户的苦楚。当客户因为办事涌现问题而对你年夜吼年夜叫时，你毫不能让本身陷入如许的地步，一方面要在这些供给商的期待队列中苦苦期待，另一方面最终比及的却不是高水准的支撑。