主张对IT组合进行现代化改造，就像主张给你的汽车换机油一样，支持的理由是：如果不换，最终发动机会烧坏。
但当下进行改造的投资回报率如何呢?这是个精算问题。今天推迟现代化改造，从统计学的角度来看，肯定会招致不良后果，但这种风险何时会成为现实，同样无法确定。
因此，根据你计划在CIO职位上坐多久，你可以确定是否关注接下来的内容。
第一步：梳理现有资源
现代化改造始于了解你目前拥有什么，这些信息本应妥善保存在一个经过精心维护和管理的配置管理数据库(CMDB，对非IT服务管理(ITSM)人士而言)中。多年来，我曾要求众多客户向我展示他们拥有的资源，到目前为止，我在寻找可靠、最新的CMDB的过程中，感觉自己就像一位硅基密码生物学家，徒劳地寻找着IT领域的尼斯湖水怪。
要避免成为我们这些IT密码生物学家中的一员，你首先需要一份IT所支持的应用程序清单，以及技术栈信息——即它所支持的业务架构，加上每个应用程序所依赖的存储库、集成、平台、基础设施和设施。
第二步：处置你的IT资产
处置涉及为你刚刚记录的每一项资产确定未来状态——即它的处置方式，首先，锁定一个存在严重缺陷的应用程序，这能带来商业利益，因为如果它没有缺陷，就不会被视为有问题。
你有八种处置方式可供选择：
• 扩展：对该资产进行投资，以提高其交付的价值。
• 保留：保留该资产，但仅进行维持其运行所必需的最小维护。
• 更新：对于商业应用程序，将其更新到供应商认为的当前版本的前一个版本。
• 替换：实施一个商业上可获得的替代品，至少提供相同的功能，或者理想情况下，提供相同甚至更多的功能，另外，你也可以决定定制编码一个替代品，但对于大多数IT部门来说，在大多数情况下，“能买则买，需建再建”是一个不可忽视的核心架构原则。
• 现代化：重构应用程序，使其符合现代架构和工程标准及实践。
• 平台迁移：重新编译到成本更低的环境中，这指的是保持COBOL应用程序使用COBOL语言，但运行在更理想的平台上，例如从Z/OS迁移到RHEL 10，但要注意平台迁移的局限性：许多IT部门将应用程序“直接迁移”到新平台，结果却发现迁移并未带来任何现代化改造。
• 整合：对于多个应用程序提供冗余业务功能的情况，将其中一个设为企业标准，并将其余的应用程序迁移到该标准上。
• 退役：对于不再需要的应用程序，归档其数据并停用，但要确保在无人监管时也没有人使用它。
第三步：警惕相互依赖和连锁反应
仅确定一个应用程序的处置方式往往是不够的，更改一个应用程序的处置方式可能会迫使其他应用程序及其技术栈(尤其是它所依赖的平台)也做出处置方式的改变。
而且，几乎可以肯定的是，对面向业务的应用程序所做的任何更改都会影响其他应用程序，并破坏一个或多个集成。
第四步：集成
集成是应用程序组合中的一个特例，它们通常是定制编码的，往往很脆弱，相对不稳定，而且一旦损坏并修复后，很难进行验证。
特别是，集成容易受到语义冲突的影响。例如，一个CRM软件包可能将“客户”定义为个人，第二个可能将其定义为家庭，第三个可能将其定义为企业，而第四个可能将其定义为客户企业的主要联系人，至少可以说，同步它们的数据库是很棘手的。
然后，业务战略会发生变化，从专注于向个人销售零售产品转变为批发业务模式。
第五步：执行计划——即使需要推翻大部分技术栈
我们本月和上月所讨论的只是一个框架——一种记录所有必要艰苦工作的方法，这些工作是为了使多层IT组合即使不能完全现代化，至少也能达到足够的现代化水平。
实际上，召集足够且合适的人员来对所有需要现代化的部分进行现代化改造，将是一项艰巨的任务，这就引出了这种情况中最不令人愉快的一个方面：一旦IT组合达到一定的过时程度，推倒重来可能比修复现有问题更具吸引力。
也许CIO会很幸运，现有的AI技术能发展到如此先进的程度，以至于可以逆向工程整个IT生产环境。
如果做不到这一点，那么用少数几个全面的企业应用套件(如ERP、CRM以及类似规模和范围的其他软件包，这将导致大多数应用程序的处置方式转变为整合)来替换整个组合，可能比试图零碎地修复问题更为实际和经济。
