数字化转型与架构 - 架构设计篇｜如何开发一个各部门都满意的系统？

　　满意在每个人心里的定义都不一样，一个系统在每个部门的期望也不一致。

　　业务部门希望系统满足业务需求并紧跟业务变化；IT 部门希望系统上线后不出问题；法务部门希望系统符合法律法规的要求；采购部门希望系统物美价廉；项目部门期望系统如期上线。参与项目的干系人都有各自的立场也有各自的目标和标准。如何开发系统才能满足以上的所有期望？

各部门期望示意图

满足当下，展望未来的业务需求

　　系统满足业务数字化的需求是第一要务，保障业务成功的系统才是一个有价值的系统。系统的设计过程应该忠实还原业务流程和业务逻辑，不能因为技术因素采用替代方案。所有替代方案的隐患都将在未来的某一时刻爆发。

　　新业务模式的产生，需要新的系统工具进行支撑。在原有的系统代码上进行升级改造是一个颇有挑战的工作。新功能的开发只能在测试环境中进行验证，成败都在系统上线切换的那一瞬间，所以也被形容为飞行中的飞机换引擎。所以，进行系统功能迭代需要满足五个步骤，才能尽量降低风险及减少对业务的不良影响：业务建模明确业务目标及需求含义；系统建模和技术架构理清实施范围及实施路径；系统测试确保业务验证通过；系统分批上线控制影响范围；可操作的回滚预案，保障系统恢复。

　　除了不断变化的需求，还有不断增长的业务量。系统需要服务的用户量越来越多，业务存储的数据量也越来越大。系统需要进行水平扩展，保障系统可以满足业务的响应要求。水平扩展的实施，依赖系统整体架构的支撑。不同容量的水平扩展需要采用不同的技术架构。业务体量判断的前瞻性，可以为系统扩容预留出更多的时间窗口，提前进行系统扩容的工作。

业务部门依赖的特性示意图

稳定压倒一切

　　系统稳定的衡量标准由三个指标组成：无故障运行时间、故障恢复时间、无故障运行周期。满足这三点需要做出很多的努力。

　　“确保”系统无故障，首先要能掌握系统的情况。系统健康状况就显得尤为重要，云主机有配套的监控平台、docker 有 k8s，业务系统可以接入普罗米修。当掌握系统的健康状况后，我们才能对系统故障进行预判，从容量角度保障系统正常运行。

　　其次，要确保系统对外界具备一定的抗干扰能力。系统对外暴露的接口进行业务校验，不会因为错误的参数使系统造成逻辑处理错误。

　　最后，系统具有自我保护机制。系统通过限制来自外部的请求和向外发送的请求，保障系统资源不被耗尽。满足以上三点，系统就具备了可控性、适应性和可恢复性，系统的稳定性在 IT 层面得到了应有的保障。

IT 部门依赖的特性示意图

用户隐私安全才是数据安全

　　用户隐私信息是一个越来越敏感的话题。在系统的建设中尤其需要关注如何合规的获取、存储、使用这些隐私信息。用户隐私信息获取必须遵循两个原则才能进行信息的采集和使用。两个原则包括：必要且最小范围的隐私信息，采集内容及用途告知并获得用户允许。隐私信息的存储应进行加密保护，预防隐私数据泄露的情况。隐私信息根据用户授权的范围进行使用，且不得转出及转售用户信息。

　　系统避免内外部的安全问题也是需要考虑的。线上系统环境应及时更新到最新版本，确保系统及服务程序没有已知的安全漏洞风险。避免非法用户登入线上环境，记录员工线上系统的操作行为，为审计工作提供凭证。系统对外接口具备完备的鉴权机制，避免越权访问数据。

法务部门依赖的特性示意图

成本是项目收益的风向标

　　控制成本最直接的办法是减少不必要的功能需求和避免需求变更导致的不断返工。需求变更不仅仅增加了成本，同时也拖延了项目的开发进度。通常采用增加项目人员的方式追赶进度，但是人员增加会导致管理复杂度提高，项目可能再一次延误进度。适当的延后交付时间节点是避免过度增加成本的有效方法，同时也可避免项目进度持续失控。

　　如果系统上线 1 年就达到容量上限，就需要重新开发系统。适当预留系统扩展空间是节约整体成本的好方法，系统容量可以参考企业两到三年的发展规划，如果没有参考依据至少预留当前业务规模 2 至 3 倍的容量。

采购部门依赖的特性示意图

履约是建立信任的基础

　　软件开发作为一个系统工程，在实施过程中也需要进行科学的项目管理。不管当下的项目管理方法有多少种，但是万变不离其宗。所有的项目管理方法都是在优化目标定义和过程管理。其中的过程管理通过时间结点和风险控制再进一步细化管理。目标定义应该综合考虑团队能力、企业资源和项目周期。

　　时间结点可以根据项目各阶段预估里程碑结点。通过 WBS（WorkBreakdownStruct，工作分解结构）把项目拆解成细粒度的工作包，明确责任人和范围之后可获得更准确的时间评估。

　　项目进展过程中，发生概率较低却需要付出较高成本解决的事项称之为风险。潜在风险被识别之后，需要制定相应的策略降低风险出现的概率或转移成本，在无法避免时需要接受相应的成本。

　　Scrum 方法是最流行的敏捷思想开发框架，通过拆分整体开发目标降低项目出现目标偏差的风险，从而减少返工的成本。小目标对应着较短的开发周期，过程管理更容易也更精准。敏捷思想本身不是一种提升开发效率的方法论，而是通过更频繁的反馈，降低出错成本的方法论。一味追求缩短开发周期，可能陷入重复推翻系统架构的情况。从完整的软件生命周期来看，错误地使用敏捷框架反而导致工作效率更加低下。

项目部门依赖的特性示意图

　　虽然评价系统的维度大同小异，但是各种评价标准的权重又略有不同。为了满足以上的各种条件，在系统设计的过程中需要采用适当的架构风格、选择成熟的 IT 组件搭建系统技术架构；在系统实施的过程中集成可靠的软件框架，熟练运用设计模式进行编码。