架构如何为业务和技术“服务”(2)
从2010年初设立架构组，到后来的架构组名存实亡，中心的架构工作充满了问题和认识上的误区。在新的一年，我们的架构可以做些什么呢？下面我提一点初步设想。
3.1，目标一：建立 “企业架构”
按照企业架构的定义，结构，采用适当的工具，推动中心建立自己的“企业架构”。
具体来说，分为两个部分：
3.1.1，梳理业务架构将目前的FT，WFT，FTS，MB，玖富银行家，高阳空间等之间的业务关系，结构，层次进行梳理，寻找“核心业务架构”，分离各个业务上的流程和关注点，从而为新的业务、产品的快速搭建提供业务上的基础。
该工作需要公司管理层主动推进，靠架构人员是不可能完成的。
下图是2009年整理的FT和MB业务架构图，现在的情况已经发生了较大的变化，需要重新梳理。
（FT业务架构图）
（MB业务架构图）
3.1.2，梳理IT架构
现在已经有很多个软件系统正在运行，各软件系统的运行环境有相同或者相似的地方，也有完全不一致的地方，比如FT产品线主要运行在.NET平台，MB产品线主要运行在Java/PHP平台，有必要对这两大产品线的软硬件资源进行整合。
IT架构的梳理可以从不同的视角来进行，
以业务的视角：具体的整合过程可以分为一下几个层次：
Ø 系统层次：各软件产品作为一个子系统来梳理，比如FT子系统，FTS子系统，合理划分子系统之间的业务关系；
Ø 服务层次：子系统直接的关系划分清楚了，有必要根据业务的需求，以业务关注点来划分业务服务，作为各子系统的公共服务，可以采用SOA方式来治理；
Ø 组件层次：个业务组件的合理划分，比如基金基础数据，客户（资产）管理，组织机构管理，报表处理。
在2010年曾经进行过NBF平台的业务组件建设，但效果不太理想，主要是业务组件的可用性太低，粒度太细，没有通用性。
以运维的视角
也可以从以下几个方面来进行：
Ø 系统层面：各个软件产品子系统的逻辑概念关系，确定个子系统间的通信关系；
Ø 网络层面：由于运行的软件子系统越来越多，所需要的服务器和网络设备也越来越多，如果保证各服务器的正常运行和容灾处理，是需要重点关注的。除了“生产环境”的网络维护，还需要统一协调开发、测试、办公等网络环境；
Ø 管理层面：确保个软件产品子系统的各项功能正常可用，比如MB的发送短信功能，为了确保这些功能正常可用，需要提供一些监控措施，例如日志分析；
Ø 配置层面：现在越来越多的软件都采用配置的方式运行了，例如配置服务地址，邮件账号，运行模式等各项运行参数，必须有详细的配置手册可供参考。
以技术的视角
建立一套技术架构，是企业架构的重要内容（下面所列举的主要是.NET方面的内容，但实际上还包含Java,PHP等不同的开发平台）。
Ø 多种软件架构
除了最常见的简单三层架构，还应该学习掌握多层应用架构（例如NBF），MVC架构，MVP架构，分布式架构，SOA架构；
Ø 丰富的开发框架
选择、使用和评价各种开发框架，例如Web 中的JS框架（例如jQuery），MVC框架（实现了MVC架构的框架，例如ASP.NET MVC2），数据处理框架（例如Entity Framework,PDF.NET）；
了解其它框架，包括异常处理框架，依赖注入框架（IOC），切面关注框架（AOP）等。
Ø 丰富的组件库
引进或者自己开发各种通用技术组件，例如日志组件，权限组件，报表组件，各种UI控件库（例如DX控件）等。
Ø 开发工具
集成开发环境，各种代码辅助工具的选择或者开发；
Ø 开发平台
.NET开发平台，Java开发平台，PHP平台。
3.2，目标二：服务于“项目开发全过程”
一个软件的开发过程实际上贯穿了业务、需求、设计、开发、测试、运维等各个阶段，架构的工作应该贯穿整个软件“开发过程”，如下图：
[图片待上传]
3.2.1，架构的工作过程1. 在整个项目开发阶段，协助项目经理进行项目资源风险评估，协助开发经理进行技术选型和风险评估，作开发人员的技术顾问；
2. 在项目的开始阶段，架构组派人参与项目的需求分析，并进行架构概要设计；
3. 在项目进入开发设计阶段，协助开发小组的工作，进行架构设计，与开发经理一起进行设计，负责抽取系统中主要的和核心的功能，并进行相应的功能设计，设计成果由开发经理确认，架构组的工作成果仅作为开发经理和项目经理决策的参考；
4. 在开发编码阶段，架构组随时检查代码是否符合架构设计和规范，有权力让开发小组修正编码以确保符合架构设计和规范；
5. 在项目测试阶段，架构组协助测试小组进行关键功能和性能测试；
6. 在项目发布部署阶段，架构组指导部署人员发布部署软件，检查并确保部署工作符合架构设计；
7. 在项目交付维护阶段，架构组协助进行运维工作，处理重大难题事件。
3.2.2，架构的工作职责
1. 领导与协调整个项目中的技术活动（分析、设计和实施等）
2. 推动主要的技术决策，并最终表达为软件架构
3. 确定和文档化系统的意义重大的方面，包括系统的需求、设计、实施和部署等
4. 确定设计元素的分组以及这些主要分组之间的接口
5. 为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效的传达和贯彻
6. 理解、评价并接收系统需求
7. 评价和确认软件架构的实现
3.2.3，以项目为核心
我们目前还是一个以项目为主的部门，所以对项目的支持放在第一位，我们的职责应该是：
Ø 走在项目前面、
Ø 进行项目攻坚、
Ø 引领项目、
Ø 服务项目、
Ø 升华项目成果，
Ø 作为有经验的开发人员，对其他成员进行培训和帮助也是责无旁贷。
（以上摘自黄维勇原话）
写在最后
在写本文前，我花费了大量时间查阅资料，查看原来的文档，感觉“胜读千篇也难下一笔”，“架构”这个命题太庞大，概念似乎“太虚”，落地似乎“太难”。从“架构”的定义来说，它就是高度抽象的概念，是“形而上学”的东西，所以在某些情况下很难适用。
偶然看到有人说，如果团队规模少于300人，或者用户量、数据量达不到海量级别，没有设立架构师的必要。这句话有一定道理，个人觉得，自己现在还不算是一个架构师，顶多算是一个高级软件工程师，改变观念，团队需要什么就是什么，一切从实际出发，为团队服务。
