本文于2019年7月29日完成，发布在个人博客网站上。
考虑个人博客因某种原因无法修复，于是在博客园安家，之前发布的文章逐步搬迁过来。
依据领导的规划，本月启动了一项业务迁移工作，作为特别行动，部门安排首席SE亲自带领南京团队交付。
本次特战的目标，使用恰当的技术，重构已有的实时业务，一劳永逸的解决业务交付过程中遇到的问题。
当前基于Oracle交付业务，存在的问题如下：
- 业务方案不准确，存在反复。当前每月做一次生产上线，近期连续出现几次上线后第二天修复问题的现象，最近的一次上线，迫于方案导致的性能问题，被迫回退代码。
- 实现方案复杂。新人上手需要花费巨量的时间来学习。
- 故障恢复慢。遇到源系统数据延迟，数据错误等问题，修复数据时分析方案，实施方案，均耗时耗力。
- 时效性不满足要求。当前基于数据仓库的技术栈交付近实时业务，在正常情况下，源系统产生数据后，一般要两小时左右才能将数据加工出来。随便出现一点问题，整体时延均会增大，导致不可用。
本次完成的内容：
- 架构优化，基于主题的建设思路重新构建相关业务，简化加工处理的路径，减少处理层级。
- 方案复用，复用了主题的建设方案，Mapping和取值逻辑。
- 对齐理解，和下游业务团队对齐需求，方案。
1）梳理全部字段的取数方案，逐个和数据管家，下游沟通。
2）刷新关键字段的取数方案。
3）裁剪不必要的字段。 - 技术平台迁移，将基于Oracle交付的业务，迁移到HANA平台。
- 开发团队内部，对于源系统的业务流程，数据交互等，有了初步的理解，便于后续工作的开展。
本次改造由首席SE亲自带队。
假如由我来主导，存在的差异有：
- 沟通成本，沟通交流的成本比较高。首席SE带队，在方案评审等事项上不需要投入太大，不需要反复整理材料，反复给领导汇报。
- 周边资源协调不会这么顺利，包括：
1）周边人力，比如主题交付团队，数据管家，下游业务人员等，全力投入。
2）硬件环境，测试，生产环境等。 - 业务方案，推动下游业务梳理方案，投入程度，工作效率，输出结果等，可能会打折扣。另外交付团队在业务的理解上明显存在短板，迫切需要指导。
- 技术方案，基于HANA交付：
1）集成方案的选择和把控。
2）开发方案的选择和把控，比如视图，表，存储过程的合理运用。
3）上线方案的把控。
首席SE去年基于HANA交付过一个项目，在HANA方面具备相当的经验。对于本次项目而言，有效的节省了技术方案验证的投入。 - 交付进度。综上，考虑到上述的因素，很难在一个月内完成开发工作，保守估计至少需要两个月。