作为一个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：
这么做的原因是，从旧架构改造成为新架构有成功的可能，如果是一个代码随意的系统想改造难度太大。
希望能在未来的一段时间内能有一些成果。
出处：http://www.cnblogs.com/sdjnzqr/
版权：本文版权归作者和博客园共有
转载：欢迎转载，但未经作者同意，必须保留此段声明；必须在文章中给出原文连接；否则必究法律责任