下载掌阅APP，畅读海量书库
立即打开
当领导者被告知架构现代化将耗时数年、耗资巨大，并且在短期内可能会减少产品功能交付时，他们一定不满意。他们肯定希望有一种速度更快、成本更低、干扰更小的创新方式。不幸的是，在大多数情况下，并不存在这种快速解决方案。
我经常遇到的一种银弹风格的解决方案，是在未解决根本架构问题的前提下尝试进行系统的现代化改造。这种所谓的“附加式”现代化，实际上只是对系统的表面进行润色，改动那些较为容易的部分，给外界一种已经现代化的错觉，但实际上系统内部仍旧与落后系统和数据库紧密耦合。这实际上是在旧系统上打补丁，形象地说就像是给猪涂口红，虽然外观看似改观，但其本质并未变化。虽然这种方法无疑可以作为一种过渡步骤，但在很多情况下，那些根深蒂固的落后系统问题并没有得到真正解决，仍然制约着产品和技术的发展。
在21世纪10年代中期，当参与政府服务项目时，我曾亲身经历了附加式现代化问题。尽管我的团队开发了一个UX远胜于落后架构应用的新网站，但由于我们必须与不可修改的落后系统和数据库集成，所以无法实现用户期望的改进。这意味着我们无法在网页上添加新的输入框来收集信息，或提供落后系统API缺失的额外信息。
一个常见的误区是，组织认为通过购买如规则引擎这样的现成工具，可以让业务人员在不需要程序员帮助的情况下迅速进行更改。虽然规则引擎和低代码解决方案在很多情况下可能物有所值，并能提供足够好的质量，但如果仅仅是为了避免处理技术债务而购买这些工具，那么这种做法更多是一种理想化的期待，而不是基于深思熟虑的决策。
在为架构现代化旅程做准备时，重要的是要了解领导者们是不是在寻找附加式的架构方法或是寻求所谓的万能解决方案。这些迹象暴露了一个更深层次的问题：领导者在寻找快速解决方案，却没有意识到解决组织架构现代化核心挑战所必需的投资。如果存在这样的疑虑，那么与其寄希望于情况会自然好转，不如尽早建立沟通渠道，进行开放和真诚的对话更为有效。深入理解架构现代化的复杂挑战，并与决策层讨论，这有助于决策者明白所需的实质性投资的重要性。
一些领导者对组织持有机械式的看法，喜欢用工厂的比喻来描述。这种观念存在问题，因为它忽视了人的因素，从而错失了机会并产生了不切实际的期望。作为顾问，我遇到这种思维的具体例子是，有些组织请求我举办研讨会来确定他们的理想组织结构，随后通过一次性大规模重组以解决所有的问题。
这种做法属于组织结构和流程谬误（http://mng.bz/8rDW）。有些人错误地认为，仅仅通过改变组织结构或引入新流程（例如敏捷）而不实施更深入的变革就能显著提升绩效。如果解决问题真的这么简单，那么每家公司都已经做到了。实际上，组织需要的是一系列的全面改变，包括促进团队协作、赋予团队产品决策权、打破业务与IT之间的壁垒、调整资金分配模式，并且投资于技术质量来加快开发速度。尽管组织结构和开发流程极其重要，但这些变更本身只能带来有限的提升。在现代化旅程的早期阶段就开展这类讨论非常重要。
避免寻求仅仅改变表象的快速解决方案至关重要。相反，必须接受需要进行深入变革的现实。高质量的技术实践可以保持系统健康、避免进行大规模现代化改造。对这些技术实践的投资对实现目标至关重要。可持续的高效技术实践可以确保代码设计良好、易于理解且易于测试，从而使其在整个生命周期中更容易修改和维护，降低了维护成本。架构现代化之旅的开始阶段，正是引入这些新实践的理想时机。
我坚信测试驱动开发（Test-Driven Development，TDD）和结对或群体编程的价值。这些方法注重通过精细设计和持续重构来打造高质量且经过充分测试的软件。在寻找实现新功能的最简便和最可维护的方法时，这些步骤非常关键。虽然这些方法看似更耗时且成本更高，但是我发现，恰当地使用这些方法能在短期、中期，特别是长期带来显著的投资回报率（Return On Investment，ROI）。不过，像大多技术实践一样，它们有时也能引起争议。并不是所有团队都会倾向于TDD和群体编程，所以寻找适合自己组织的方法非常重要。我并不支持强制团队采纳他们反对的方法，但同时认为，有时候尝试新的、可能超出舒适区的做法是有益的。
如果组织在技术实践方面缺乏专长，那么在深入进行架构现代化改革之前首先解决这个问题至关重要。你肯定不希望在架构现代化旅程的开始阶段就产生落后架构问题。为此，你需要为团队提供培训和提升技能的机会，有时甚至需要引入外部专家的力量。虽然这个话题不是本书的主题，但如果你在寻找一个切实可行的起点， Agile Technical Practices Distilled （Packt Publishing，2019），可能是个不错的参考。