作为一个Web应用系统的架构师，之前也做过两个比较成熟的架构，基本上都是从无到有，个人总结的主要流程有：

    1. 业务需求分析：分析整个公司对框架的需求，分析领导的信心如何，时间是否充裕，要实现那些目标。

    2. 制定详细的架构目标：在此阶段一定要明确架构的目标，作为日后架构是否成功的判定标准，否则很难跟领导交代你做的架构是否成功了。

    3. 架构设计：对整个架构进行层次设计，功能模块设计，理清设计思路，整理架构设计文档。

    4. 技术路线选择和可行性分析：根据设计目标选择不同的技术路线，比如：是选择开源的技术组建还是自己开发?

    5. 详细设计：设计完整细致的开发流程

        1) 数据库交互流程：设计如何跟数据库交互，实用实体还是sql？

        2) 业务请求处理流程：设计前后台应用如何交互，ajax，post，webservice等等

        3) 跟美工一起设计前台页面样式风格

            a) 整体系统布局风格。

            b) 单独控件功能设计和属性设计。

    6. 代码架构初始化：初始化目录结构，设定初始规则，搭建框架原型。

    7. 典型模块开发：在原型中，使用常用布局，常用控件，常用的请求流程开发开发常用功能。

    8. 进阶功能的设计与开发：开发一些计划中的高级模块。

    9. 整理框架使用文档，框架使用标准等。

    10. 寻找简单业务系统，进行测试，对系统开发过程中遇到的问题，进行进一步的维护和升级。

进入新公司之后，发现公司之前对架构不重视，造成现在公司内的系统架构几乎每个系统一套，无法公用。

领导最近发现此问题，希望尽快整理公司整个架构体系，考虑到现有业务系统，因此最近一段时间会对现有业务系统进行框架改造。

个人对这种老系统的改造，总有一种推翻重来的冲动，个人觉得最有效的办法就是重构，尤其是出现以下情况：

    1. 代码经过几个人维护之后，代码越来越难读。

    2. 新增一个功能不一定会碰见什么”地雷“。

    3. 遍地的if/else语句。

    4. 大量的无用代码和重复代码，甚至很多重复的第三方引用，仅仅版本一样。

但是实际情况是，领导在考虑人力成本，时间成本时，不可能让你把现有的系统改造，因此想办法在现有的基础上如何改造。初步思路如下：

    1. 先找出系统中现有的明显问题，在不影响架构的基础上，将能改的改掉。

    2. 在现有技术路线的基础上，制定相应的标准（在不影响整体架构的基础上可以适当的新技术）。

    3. 按照相应的标准，逐步将原有的重复代码去掉。

    4. 对新增功能严格按照标准开发。

    5. 在未来的一段时间内，实现所有代码都符合标准，变成一个有标准架构的系统。

    6. 在适合的时间，系统推翻重构，新重构的代码严格按照新的标准执行。

      PS：

            这么做的原因是，从旧架构改造成为新架构有成功的可能，如果是一个代码随意的系统想改造难度太大。

希望能在未来的一段时间内能有一些成果。