2020年是前所未有的一年，当数据高管们反思公司所经历的技术加速发展时，他们可能会发现，在琳琅满目的技术宝库中，确定2021年及以后的技术优先级很有挑战。
2021年有很多值得期待的事情。
根据SiliconAngle和企业技术研究(ETR)的数据，预计2021年CIO预算将至少增加4%。
根据最新的大数据和人工智能高管调查，近92%的企业表示，在数据和AI方面的投资步伐将继续加快。
不过，仍有很多问题需要解决：超过3/4的高管承认，他们没有成功建立一个数据驱动的组织，虽然99%的高管对大数据和人工智能的投资仍然很高，但结果并没有那么理想。
在这篇文章中，我研究了两个可能决定CIO未来的问题。一个是有利的，另一个比较令人担心。
组织洗牌
在数据、人工智能和分析领域，数据团队的组织效率问题一直是一个争议点。一些公司更倾向于集中式模式，由一个团队作为“卓越中心”，协助业务部门解决分析需求。这种方法的好处是基于这样一个前提，即通过集中的资源、技术和流程，组织可以获得规模经济，出自一个团队的数据更能保持其标准和规范。
另一些企业则将数据工作分散化，部门负责人能够采购分析软件和基础设施，以及雇用直接分析师和科学家向其汇报。这种方法基于这样一个前提，即在帮助组织进一步走向数据驱动时，商业敏锐性和协调性与技术知识同样重要。
当然，也有一些公司尝试了两者的混合，他们建立了提供“数据即服务”的集中式团队，也拥有针对“特定业务”需求的业务分析人员。
无论你的公司采用何种模式，似乎还没有解决在组织里向谁报告的问题：数据、AI和分析团队应该在“技术部门”(CIO/CTO)、“财务部门”(CFO)还是其他业务职能部门下报告?
这个问题是最近LinkedIn调查的主题，结果CFO的优势非常微弱。如果你读过评论，你会注意到仍然没有明确的共识：许多人建议数据、AI与分析团队应该向CEO办公室报告。另一些人则担心，向CFO报告可能会使得组织运行集中到降低成本上，而不是集中在创新上。
2021年或许能帮助CIO们解决这个问题。对许多人来说，2020年“技术加速 ”将数字化转型变成了业务的必选项。对一些人和企业来说，更是生死攸关，CIO们和其团队首当其冲，被委以重任。
因此，在Gartner的2021年CIO议程调查中，Gartner建议CIO们“抓住这个数字业务加速的机会”就不足为奇了。最重要的是，在2021年，CIO们有机会成为“代理首席运营官”，在全公司范围内进行数据驱动的业务转型。
技术融合
人们相信，最好的突破发生在最糟糕的年份之后。
2021年其中一个突破就是 "融合 "的概念，这种现象指的是某些技术市场相互接近，以至于它们可能会重叠并成为一个整体。
“融合”并不是一个新概念，它可以追溯到上世纪90年代，麻省理工学院实验室创始人尼古拉斯-尼葛洛庞帝，在其1995年出版的《Being Digital》一书中对其进行了最精彩的描述，大量技术在后来被得到验证，尼葛洛庞帝也被誉为技术预测之父。
他的思想是正确的，就是数字化加速了技术的融合，技术为我们的生活带来了便利，技术的融合使得设备的功能越来越强大，如果你不相信，可以回顾一下过去的十年：我们的手机变成了手表，也变成了我们的电视......哦，还有电话。
这种趋势在企业领域也有很多：比如很多人预测人工智能和商业智能的融合，数据仓库和数据湖将来也会融合。虽然在不同的技术之间有共同的用例比较常见，但CIO们需要小心 "供应商说辞(VendorSpeak)"。
“VendorSpeak”是指当技术供应商将技术趋势描绘成被广泛接受的现实，以支持他们所构建的解决方案时所说的话。VendorSpeak通常不是恶意的，它源于技术创始人希望将他们打造的解决方案解决更多的问题。
我在供应商已经工作了很多年，亲身经历，深有体会。不妨把 "VendorSpeak "想象成技术专家的 "确认偏差"。
事情是这样的：技术专家为他们所熟悉的问题(甚至有实践经验的问题)构建了一个解决方案。他们的产品得到了广泛的市场认可：客户和合作伙伴扩大了解决方案的使用范围。当他们发现其技术被应用到许多方面时，他们会感到兴奋。他们的愿景超越了他们建立原始产品的目标，这时，技术专家们要经受考验，区分其解决方案的核心用例与角落用例之间的差异。
当“角落用例”被定位为“核心用例”时，技术专家就有可能将CIO引向错误的业务塑造(有时甚至是改变职业生涯)决策之路。
最好的补救措施是所谓的 "设计中心"。 对于2021年接触的每一个供应商，通过将“每个产品的最佳应用”归零来对其评估，评估一个解决方案的“设计中心”的最佳方式是将其与 “用户、数据和流程”三者关联。
以数据仓库与数据湖为例。该解决方案最适合什么数据?结构化数据还是非结构化数据?它针对什么用户角色进行优化?分析师还是数据科学家?它最适合什么类型的用例?分析还是建模?
如果供应商告诉你，他们有一个工具可以“解决所有问题”，那就要小心了。退一步问：你的需求是否适合重叠的领域，或者所提出的“一刀切”的方法是否会使你的解决方案超出其真正的设计中心?
"角落用例 "VS "核心用例"
回到我们智能手机的例子，可能更容易思考核心和角落用例的区别：智能手机之所以能够吸收这么多设备的功能，是因为那些设备只覆盖了狭窄的用例：一个时钟只能报时，一个有线电话只能打电话。
技术产品和解决方案是尺有所短寸有所长，不能太过听信供应商的一家之言，结合自身业务需求博采众长不失为上策。
比较特斯拉和吉普车。它们都是伟大的汽车。它们都可以运输货物、物资和人员。但你会带哪一辆去参加越野赛呢?
这同样适用于数据仓库和数据湖。应用解决方案时，要从其核心用例出发，而不是从角落用例出发。换句话说，避免开错车参加错误的比赛。
