目前软件开发面临两个难题：
(1)软件在不断地发展，用户需求在不断地增加，软件功能模块在不断地扩充，软件的重新设计和整合的成本成为企业无休止的投资陷阱。
(2) 目前管理软件中不同种类的操作系统、应用软件、系统软件、数据格式相互交织，要将这些不同网络、不同平台、不同数据格式、不同软件完全统一是不可能的，只能在现有的软件、数据、平台基础上进行扩充。
基于上述两点原因，我们在软件架构的上需要做出必要的调整。
首先，要解决软件功能模块扩展的问题，减小未来软件投资风险，除了常规的软件升级更新，扩充功能以外，降低模块间的耦合度、模块间使用明确定义的接口进行交互、模块组件化的方式，能够有效地减小模块间的依赖性，延长模块生命周期，增加模块间交互能力，增强软件扩展能力，减少企业软件开发和集成投资，并能够保护用户的IT基础建设投资，提高产品竞争力。
一、系统文档的问题
目前遗留的文档，从库上来看，仅有交互原型文档，没有系统的分析设计，场景描述缺乏，相应的手册没有按照角色场景来写作，使用者肯定不会很明白，片面孤立去看问题，那么肯定是不会理解的。
完善的文档有《系统数据库设计文档》，《测试用例》以及BugDone平台。
二、系统代码的问题
因为赶工的问题，没有遵循相应的规范，不是干净的Code，维护起来很麻烦。
历史版本，没有打基线。
数据库脚本全部堆集在一起，没有归零可用的脚本，需要进行修剪。
早期主持经历了三轮测试，每个人对系统场景的理解比较片面，现在对整体系统的理解较为完美。仍需不断测试，别无他法，现在已经基本理顺。
对应措施:
(1)减少破窗户效应，使新增及重构的代码遵循规范。
(2)拧在一起代码与接口，最好是单拧出来解决。
(3)每条工作流的通路，保持通畅可用。
三、系统设计方向的理念
不要引进过时的东西，但也不要那种看似时髦却又不够博大精深的东西。
强于基础性动作的演练，那么叠加起来过于平滑。
何为组件理念?
类本身是个细粒度的可重用实现，为了解决功能或机制层面更大粒度重用的问题，又引入了组件的概念。组件的英文是Component:
组件对外暴露一个或多个接口，供外界调用。组件内部由多个类来协同实现指定的功能。对于复杂的组件，会包括很多类，还可能包含配置文件、界面、依赖的库文件等，组件也可以包含或者使用其他的组件，构成更大粒度的组件。
构建一个高度可重用的平台层，可以使应用开发人员只需集中精力关注业务逻辑，而与业务无关的功能组件和机制都由平台层提供，供直接调用，并且多个应用程序可以充分共享这些组件，这样就极大地简化应用开发，缩短软件交付周期，并保障软件质量。
而构建一个高度可重用的平台层，最核心的挑战就是设计和开发高度可重用的组件，使其能够提取应用的共性需求，简化接口，真正做到应用开发时可以直接拿来就用，而且非常简单易用。
组件，作为可重用的软件，不会承载太多的功能，组件的规模不会很大。因此，最理想的情况，组件就是单独的一个类。组件使用者用起来，将会是极致的简单。
组件的精练，代码风格良好，可以使产品质量提高，交付质量有保证，属于公司的良性资产。
四、系统的改进方向
1、推动系统平台化、组件化发展、以及技术细节的实现，指导相关团队完成架构落地，解决周边系统和业务发展遇到的架构问题；
2、负责关键技术的攻关，优化现有系统的性能，并解决系统开发、运行中出现的各种问题；
3、带领团队攻克例如大数据量、高并发、高可用等带来的各种挑战及技术难关。
五、系统架构演进方向，多结点并存
最终是一个由各个单服务组成的多服务系统。
