保持联合运行宣言的第7条原则说，在你具备战略能力之前，你必须首先能够胜任这项工作。
IT的流程和实践就是IT完成工作的方式。而那里就是你体现能力所在的地方。
本系列的前一篇文章谈到了“改进”IT流程和实践的重要意义。现在的问题是，作为首席信息官，你究竟需要将个人注意力集中在其中的哪一个上。
答案就从这个基本原则开始：管理者个人发起的变革倡议不应该同时超过三项。超过这个神奇的数字，你就会失去专注的能力，并进而失去领导的能力。
但是首席信息官应该选择哪三个呢?
不应关注的内容：IT运营
组织流程改进计划最明显的候选方案就是著名的ITIL框架。但那可能是一个错误。
采用ITIL框架本身并不是一个错误。这是一个完美的框架，它背后是几十年的成熟经验。ITIL的重点是IT运营。而IT运营只有在出现问题时才会被注意到。作为首席信息官，当事情进展顺利时，你也会希望被注意到。
因此，如果你的IT组织需要更好地进行可用性管理、容量管理、性能管理、基础架构生命周期管理、系统管理，尤其是变更管理时，请确保你有合适的人员来负责IT运营，并明确表示你将通过唯一重要的IT运营指标(不可见性指数)来衡量他们的成功，也就是说，当IT运营没有被注意到时，你必须是唯一一个能够注意到的人。
作为首席信息官，你应该认识到，虽然IT运营非常重要，但它一点也不具有战略性，而且，如前所述，如果它做得不好，你也就不能具有战略性。
委派它，并确保你委派给它的经理拥有他们所需的所有工具和支持。
流程优先事项1：服务台
如果IT的声誉(这也是IT的全部声誉)不太好，修复服务台就应该是你的首要任务。
服务台是IT的红发继子，这是不幸的，因为IT与业务其他部分成功集成的一个关键因素往往是业务/IT关系的质量。
IT与其他业务的关系在服务台总是时好时坏。因此，如果你听到它被称为“无助的服务台”，或者如果你的业务伙伴问你，为什么在他们打电话给服务台让他们知道之前，IT不知道系统已经关闭，或者如果你听到了服务台工作人员在交换愚蠢的用户故事，或者如果有人在打电话给服务台寻求快速简单的帮助时，服务台只是给了他们一个号码--请选择你的故障，而不是给他们立即需要的10秒钟的答案，如果服务台表现出了这些症状，就请将你的个人注意力放在修复服务台上。
让IT组织的其他部分发光所需要的业务支持也依赖于此。
流程优先事项2：应用支持
规则1：如果你的应用程序支持团队仍然沉浸在瀑布式的方法当中，你还在等什么?立即让他们开始转向敏捷吧，并亲自监督敏捷采用战略及其执行。
规则2：敏捷不仅仅是Scrum。为IT实际做的工作选择合适的敏捷变体，而不是因为“每个人都在使用它”而选择Scrum。
规则3：大多数敏捷变体都是为了管理应用程序开发而设计的。大多数人都是“在可以的时候进行购买，只有在必要的时候才进行构建。”如果你也是这样，就请完全忽略Scrum。相反的，可以让你的应用程序团队采用CRP(会议室模拟)或是其近亲ATDD(验收测试驱动开发)。
规则4：大多数敏捷变体专注于将软件作为产品来进行交付。多数企业都需要IT的合作来实现有目的的业务变革。修改你所采用的任何敏捷变体，然后使之成为现实。
流程优先事项3：IT架构管理
我们将在本系列的下一篇文章中介绍如何评估IT架构本身的质量和卓越性。如果它很糟糕，那当然是IT架构管理实践失败的征兆。
你的IT架构管理实践需要帮助的其他迹象是什么?
“我们不知道我们的架构有多好，”这是一个令人惊讶和沮丧的常见症状。就这一点而言，“我们不知道我们拥有什么”其实并不罕见。
还有什么?它没有：
- 发布并公布了一份简短的--简短的意思是不超过十几条--指导其他一切的架构原则列表。除了简短之外，这些原则还必须用简单、无术语的语言编写。
- 出版和公布一份标准清单，其内容如下：基于原则;根据记录良好的实践保持最新;并定期进行更新--每季度更新一次是有意义的。
- 将生命周期管理确立为标准实践，将其集成到IT规划和预算当中。
- 围绕体系结构原则和标准制定一个云战略，围绕着云是一种体系结构，而不是存储和处理中心这一认识。
这并不意味着，如果IT架构没有这些缺陷，那么实践就可以安全地进行了。
IT体系结构实践——以及它的业务集成，企业体系结构实践——一直都面临着从增加和维护价值到变成官僚主义泥潭的持续风险。
顺便说一句，这种危险并不是架构所独有的。任何被授权审查和评论其他团队创造性工作的企业和组织都有着同样的风险。
顶尖的架构需要一种反官僚主义的心态。并且它还需要资金，因为交付一个具有令人满意特性和功能的应用程序项目比交付一个符合架构标准的具有令人满意特性和功能的应用程序成本更低。
由于你的一般执行发起人不太可能愿意承担差额，因此提供或修改应用程序功能的项目将需要架构来弥补这一差异。
IT架构管理职能部门必须找到一个能够实现健康架构的方法，同时最大程度地减少使用强制执行来作为其主要策略。它还必须能够说服行政领导，一个好的架构也是一项明智的商业投资。由于这两个至关重要的问题，你将很难逃避这样的结论：即使在最好的情况下，作为首席信息官，你也应该亲自去监督IT架构团队。
但是信息安全呢?
在当今这个时代，与IT相关的业务威胁正越来越多地受到有组织犯罪和恶意国家行为者的支持，入侵的潜在损害在很久以前就从“恶化”发展到了“巨大”，信息安全必须成为IT的首要任务之一。但是，与IT运营类似，信息安全的有效性也是通过其自身的不可见性指数来衡量的。
更糟糕的是，要想变的有效，信息安全必须是侵入性的，所以一定程度上的不可接受的可见性会随着地域而变化。
还有一点：没有与高质量的IT架构紧密结合的信息安全也是有漏洞的信息安全。
因此，需要将信息安全纳入到你的IT架构实践中，作为首席信息官，你可以关注信息安全，但它不会进一步的分散你的注意力。
解决IT创新问题(又称“数字化”)
看看创新的商业机会是在哪里发生的，你会发现IT即使不是头号竞争者，也肯定是前三名之一。
作为首席信息官，你在这里的选择要么是负责IT创新，要么是接受在执行领导团队中增加一名首席数字官的想法。
但那将是你的一种不称职的宣告。此外，这会把IT领导层一分为二，CDO将成为创新者，而你则总是会成为那个否定者。所以“首席信息官”将成为你退休计划的一个陈述(“职业生涯结束了”)。
我们不会想要那样做。
相反的，要将IT创新也纳入到IT架构实践当中。这样做不仅为创新提供了一个组织的家，使其不会分散你的注意力，还将创新的责任放在了与将IT创新集成到IT体系结构其余部分的长期需求的相同位置之上。毕竟，你不会希望IT创新成为未来的自动化孤岛。
如何处理“DIY IT”
自己动手的IT，也叫“影子IT”、“流氓IT”和“停止吧!你在给我一个头痛的IT!”这是太多首席信息官竭尽阻止的事情。
这就类似于国王Canute在命令潮水不要进来。
不管怎么说，DIY IT更多的是机遇而不是问题，因为它在不增加IT支出的情况下大幅增加了公司的IT带宽--或者至少增加了可见IT的支出。
DIY IT的缺点在很大程度上是可以避免的。大多数情况下，它需要IT在技术咨询方面提供一点点支持，以确保它符合IT的架构标准，而作为交换，IT架构的职能部门将获得所需的文档，以防止DIY IT变的隐蔽。
这使得对DIY IT的支持将成为又一个能够舒适地融入IT架构功能的IT实践。
最后
为了使IT能够胜任，它必须使用精心设计、定义和记录的流程和实践来完成其工作。首席信息官应对所有的这些问题负责，但在实践上，一个人是无法同时指导三个以上的转型的。
在大多数的IT组织中，最需要首席信息官个人领导的三个流程领域是服务台、应用程序支持和IT架构管理。把它们打磨得闪闪发光，IT就会成功--而且会获得明显的成功。
但这只有在IT运营同样出色的情况下才能实现，这就是为什么，有一点自相矛盾的，首席信息官们应该确保将这一责任委派给其他人的原因。因为如果你做不到这一点，你也就没有足够的精力来打磨这三件大事。
