闲话企业架构（一） 博客分类： 架构

        随着企业的不断发展，企业的规模和复杂性急剧膨胀，企业外部环境不断变化，各种竞争与挑战不断升级。。。对企业来说，变化已经成为常态，变化已经成为生存之道。

        回顾一下软件构建理论的演进历史，其实就是企业采用信息化手段之后的进化史，从“面向过程”到“面向对象”再到“面向服务”。。。其本质是对复杂世界析构与简化的方法论。

        那么，“企业架构”是个什么东西呢？

        首先来看看各种流行的定义：

        A.企业架构是构成组织的所有关键元素和关系的综合描述。

        B.企业架构是一种战略信息资产库，定义了使命、执行使命必须的信息、执行使命必须的技术，以及在响应使命变化需要实现新技术时的迁移过程。

        C.企业架构是关于理解所有构成企业的不同企业元素，以及这些元素怎样相互关联。

        我们的大脑对于同一个概念是很难同时存储几种不同定义的，所以不妨自己给企业架构下个定义：

        “企业架构就是企业关键要素及其关系组成的多维网状结构。”

        也许你脑海里浮现出一块正方体海绵，无数个孔洞和无数个连接组成的复杂结构，没人说得清一块海绵是怎么组成的，但每个人都知道海绵的特性和功能，还好我们的企业远比海绵的构成要简单。

        其实这种胡子眉毛一把抓的空泛定义并不能帮助大家理解什么是企业架构，我们只能继续探究。。。

        TOGAF(The Open Group Architecture Framework, 开放组织体系结构框架)把企业架构分成四大架构领域：业务架构、数据架构、应用架构、技术架构。当然这种划分只是一家之言，不同的组织有不同的定义和理解，但我们不妨以此为线索试着理解一下。

        我们还是先回到地球，看看我们日常工作中的常见问题。

        客户变更天天有，一个简单需求可能要做个把月。在补丁上打补丁是常有的事，产品越改越笨重，为了赶工期bug越来越多而且越来越变幻莫测。产品从1.0到现在已经很多年，相关的设计研发人员来去换了两三批。客户提的新需求，能不改就不改。即使到了非改不可的地步，也会容忍已经僵化的代码带来的种种限制。直到有一天，那根压死骆驼的最后一根稻草从天而降，代码已经彻底改不动了。。。

        在信息化初期，我们的客户并不了解信息化可以为他带来什么、改变什么。随着时间的推移，企业信息化层层深入，甚至已经演变成企业在市场竞争中的利器，于是逆转的情况就出现了。企业客户的业务流程从之前的顺应软件，逐步的变为让软件去顺应企业的发展。于是客户们提出了各种个性化的需求，加功能、改流程、维护优化等等。这是企业级应用系统的宿命。。。

        这些问题出现的根本原因是商业软件的设计与开发方式已经不符合企业信息化的发展要求。现在市面上大多数软件，是几个程序员凭自己对业务的理解，把各种功能拼凑起来成的，在初期这些软件因为弥补了空白提高了局部工作效率，企业确实看到了收获，随着项目的推进和新需求源源不断的产生，系统的维护压力越来越大，而且软件中的系统流程与企业发展过程中的业务流程开始产生偏差，于是为了适应企业信息化的要求不断的修改，最后软件越来越笨重，导致很多新的业务功能无法实现，代码已经改不动了，所以这套所谓企业信息化的系统能解决的大部分是固定程式的业务，企业信息化陷入泥潭。

        这个时候该怎么办？

        直觉告诉我们——要有优秀的架构！

        要想潇洒的拥抱变化，就要摸清变化的方向和规律，优秀的业务架构就像如来的五根手指，任由孙猴子随便蹦跶也无妨。业务架构一定是静态和动态分析的集成和融合，在分析过程中相互影响又相互促进。动态的信息即我们说的普通的价值链分析的思路，从企业端到端的一级流程到各个业务领域二级，三级等流程的分析。形成一级流程->子流程->活动->活动单元->任务->事件的主线；而对于静态信息则包括组织，人员，岗位，角色，业务对象和表单，规程，模板等各种信息。静态信息的重点是业务领域和业务对象，即形成业务领域->业务主题域->业务模块->业务单元->业务组件的静态数据逐层分解。静态信息+动态信息+交互点和接口分析后形成完整的业务架构。可以看到流程在细粒度分解后的活动单元的组合可能构成业务组件和业务模块，同时业务模块本身又存在更细粒度的流程和活动分解，业务组件本身又是多个流程的组成部分，因此静态和动态相互融合，形成交互，所以必须分析交互和接口。

        我们假设已经建立了“业务架构”和“技术架构”协调一体的机制，有效地驱动了软件产品的持续完善，从根本上保证了管理软件和企业发展的动态平衡关系，使软件产品具备了较长的生命周期。

        随着时间的推移我们渐渐发现，因为企业的应用越来越多，企业应用的多样性、复杂性以及它们直接相互关联交互的需求增强，企业级系统的应用层和数据层越来越突显出来，如果还是像传统软件一样，将他们简单的划归“业务架构”或者“技术架构”已经不能满足要求。这时候就应该将“应用架构”和“数据架构”提到“业务架构”和“技术架构”的高度，协同合作解决日益复杂的企业级问题。