金融系统架构开发的一点感悟

本人在金融公司做系统架构，今天在开会讨论一个综合业务管理系统的过程中，领导提到的以下思想值得总结并铭记于心。

技术开发有时就是做管理

我司有些业务，如债券权益业务，当前还采用业务主办岗全手工维护，更新Excel业务日志的方式进行记录。Excel中需记录经办员、复核员、日历类型（兑付、兑息）、权益登记日、权益发放日等信息。

但是，这类手工维护方式效率低且存在一定的操作风险。因此需要将这类业务电子化，由原来的纯手工维护数据，转变为通过开发针对该类业务的计算机系统来进行管理。

为了实现这些管理功能，需要对现有的业务模式有很深的了解，并且要将这些业务模式抽象为计算机易于实现的方案。而业务操作人员本身并没有这些管理概念，他们擅长的是业务操作、沟通业务细节及确认数据的正确性等。

因此，做金融系统开发，有时不但要对业务有所了解，而且还应该站在管理者的角度来思考问题，该深入业务细节的时候，需要细致入微地把控好所有业务的处理边界。而当面临业务管理类问题时，则该跳脱繁复的业务本身，将业务作为黑盒居高临下地进行审视。

• 业务必须规范化

要实现业务的电子化，前提之一就是这个业务适合电子化。而到底适不适合，需要业务人员的配合，梳理业务流程及业务特征。因为在程序员开始接手如何将业务电子化的工作时，他们可能对业务还一知半解，甚至非常陌生。这时就需要业务人员将这些业务知识通俗易懂地向开发人员讲解。当然，可能还有一些专业的金融知识，需要技术开发人员自己在工作之余去深入了解。

在梳理业务的过程中，操作起来有时会很自由，于是就导致了有多种实现方法。比如，在上文提到的日历类型（兑付、兑息）字段，就是根据业务逻辑和计算机最佳开发模式综合考量的结果。因为针对兑付和兑息，完全可以不定义日历类型，比如，可以将“兑付”做一个Excel，“兑息”也做一个Excel，然后在程序处理时，对应地开发两套系统。当然，这仅是一种可能的实现方式，实际并不可取。所以，当有多种实现方法时，需要考虑最优方法，并且将其他业务也一并考虑进去，这样实现的系统才有通用性，将业务模式简单化、规范化，也是一种系统之美。

值得一提的是，在我司自动作业调度系统的开发过程中，也凸显了规范化的重要性。当时，自动作业调度框架搭起来很快，但在规范化每个处理程序的过程中花了大量的精力。因为，要实现自动作业调度，需保证每个处理程序的输入、输出接口相同，人机交互接口统一和报警信息规范。

• 不仅要流水线，还要有质检员

工厂的生产线一般都是流水线作业，这是工业革命以来提升生产效率的有效途径。每个生产过程规范化之后，就可以根据生产过程实施流水线作业。但是为了保证生产品质，一般每一条生产线都会配备相应的质检员。质检员的作用不容小觑，他们是保证产品质量、降低产品瑕疵率的有力保障。

计算机程序也是一样，每一个业务操作节点都应该设置一定的自检机制，在我司称之为“业务稽核”。当某个节点出现问题时，需要自动检测并及时反馈，最大限度提升处理效率。否则，这些错误数据流入下一环节，将导致数据回滚的成本更高。

在系统运维方面，以后也可以实现自动化，而不是人工运维管理！我司运行部目前还有专人专岗来检查每天的勾单操作是否做完。但是，随着人工智能的应用，相信不知疲倦的计算机智能运维系统将会是这类运维管理工作的最佳候选。