组织架构承载 组织架构怎么表达

　搭建一个简易狗屋时，我们不会去设计三维图，做预算，规划施工等，而建个复杂建筑时，缺少架构是不可能能完成的。就像我们程序员做个小功能，可能都不需要做设计就可以实现了，但是当问题复杂了，考虑因素多了，产品关联复杂了，那么还一直摸着石头过河，事前不做架构不做规划，那么最终结果必然是失败的。

    

　　盖房屋需要架构，做功能需要技术架构，那么给企业做信息、业务规划就需要做企业架构，那我们如何描述企业架构呢？

架构复杂性

• 设计：

• 为了避免大家的误解，架构师设计时应该采用一种通用的、易于理解的一组词汇，这些词汇不能特定于单一架构领域。
• 提供通用的和组织特定的指导、最佳实践、架构图描述标准和其它能够提高架构质量的方法
• 架构时迭代、反复完成的一个过程，需要支持对架构决策的跟踪和变更管理

• 沟通

• 架构需要同组织内或组织外的不同涉众（如管理人员、设计人员、合作伙伴等）进行沟通
• 能够对不同涉众关注的方面进行精确的描述

• 实现

• 从以往的架构中提供反馈
• 可能的话，还需要集成已存在的设计工具

• 变更

• 架构的变更对组织影响非常大，预先评估变更导致的一系列活动，仔细计划架构演进

4个架构视图

组织的业务流程的目的是实现他们的产品，软件应用是支持业务流程，而技术设施是运行应用，信息是在业务流程和应用中使用。

1. 业务架构（business architecture）：业务战略、组织结构以及业务流程
2. 应用架构（application architecture）： 服务、应用
3. 信息架构（information architecture）：业务对象和数据
4. 基础设施架构（infrastructure architecture）：硬件、网络和软件环境

模型

　　为了解决上面这些复杂性，明确的描述架构的核心模型是非常有价值的，而单一架构领域的细节可以不用定义（比如UI模型、主外键设定等），因为这属于特定专业的内容了。在《架构 － 又一个类似与“平台”一样的词汇》中描述了架构的一种定义是：架构是由软件元素、元素的外部可见属性以及它们之间的关系组成。

我们在描述架构时，最重要的就是关注核心元素以及它们之间的关系。在描述企业架构时，我们使用模型（models）。

• 领域（Domain）：总体描述中的一个子集概念
• 模型（Model）：一种聚焦特定领域内的抽象但很明确概念以及概念之间的关系，UML就是我们常见的一种描述模型的语言
• 建模（Modelling）: 对总体概念的部分进行抽象描述的动作

基于符号和语义的模型（Symbolic and Semantic Models）

基于符号的模型

基于语义的模型

　　以后blog中，如果没有明确提出语义模型，都指符号模型。

架构描述基本概念

 

View和ViewPoint

　　没有哪个人会关心架构所有的范围和细节，我们需要针对不同的涉众提供符合他们关注点的特定视图。这里涉及到两个概念：

• ViewPoint: 视图模板，定义了如何看这个视图
• View: ViewPoint的实例，展现模型中的这个ViewPoint包含什么

下图为TOGAF的架构内容框架中的一张图，表明了元模型、View和ViewPoint的关系

建模语言：ArchiMate

　　企业架构的核心方法就是使用一种集成的、一致的方式来描述多个领域的概念，ArchiMate是一种图形化的企业架构语言，可以参考《架构 － 使用ArchiMate描述企业架构》

 本文转自 jingen_zhou 51CTO博客，原文链接：http://blog.51cto.com/zhoujg/518634，如需转载请自行联系原作者