架构设计包含哪些内容

架构师和架构设计

曾经有句调侃的话“十个人九个是经理，还有一个是副经理”形容头衔的泛滥，而今更进一步经理升级为“总”了。 与此类似，在IT技术圈架构师也越来越多了。包括各种级别的， 高级，资深，首席。也可以看到做着各种不同范围工作的架构师，有的只写PPT的， 有的还要编码，写测试用例，给老外维护老旧产品的架构师，兼着项目经理的架构师。 一次以前同事的聚会，一堆IT老男人还是饶有兴趣地讨论一些技术问题， 自然免不了提到架构一词。 席间一位发问，架构设计具体包含哪些工作？ 呵呵， 大家之前没有正式思考整理过，也没即席得到一个全面的答案。就在这整理一下， 我现在的名片上也印着资深架构师，先要自己明白自己的工作。
架构设计包含几个方面。大家对架构师工作范围彼此认知不一致，多半是因为事先没有界定究竟是哪个方向的架构。一般来说分四类业务架构，应用架构，数据架构，基础架构。以下一一描述。
1. 业务架构。 主要的工作是梳理业务需求，确定业务活动流程。其中一个重点是确定业务流程涉及的职能部门或者工作人员角色。 每个职能部门或者人员的角色职责，和哪些业务活动节点相关。职能部门和相关人员的组织结构，上下级关系，或者在业务活动中的交互关系等。整理业务活动流程中流转的数据信息。将众多的业务活动流程划分为若干个业务系统，包括抽取出每个业务系统中共同的业务流程，构建出新的业务系统，为其他业务系统提供支撑。确定在各个业务系统之间交互的数据信息。业务架构设计是业务人员的工作，但IT人员也需要很细致深入地了解。
2. 应用架构。有了业务架构分析结果，就要考虑怎么样构建应用系统来实现这些业务需求。对应若干个业务系统，自然会有多个应用系统。应用系统和业务系统可以是一一对应的，具备相同的边界，也可以不对应。一般为了复用，功能集中的要求，会设计很多细粒度的应用系统。另外也会有一些新的对应技术层面需求的应用系统，比如监控系统，集成总线，前置系统等等。要定义这些应用系统的接口和调用接口的规范，确定各个应用系统相互交互的内容和过程。接口的设计包括人机接口的设计，要规定应用使用人员的不同角色和不同权责。
对于一个应用系统，要设计由多少个应用程序，或者客户端API库组成。每部分各自实现什么功能，分布在多少个节点上，彼此怎么交互。每个程序的层次结构，线程驱动的应用逻辑