闲话企业架构。。。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        这个时候该怎么办？

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

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

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

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

        不知道你有没有疑问，反正我是困惑了~

        企业架构（Enterprise Architecture，EA），从字面上看和信息化没有一点关系，但是这个词又确实是因为企业要做信息化才诞生的。没有计算机的时候企业就没有架构了吗？文字游戏害死人啊~

        我知道研究这种看上去在天上飘的概念没有多少人感兴趣，但是这种貌似空泛的理论是否真的接不了地气，是否真的就对我们的日常工作没有指导价值呢？

        本质上，企业架构也好业务架构也罢只不过是构建企业信息系统的一种方法论，分为TOGAF、DoDAF、Zchman等很多流派，大家在持续关注IT界的各种新理论、新工具的时候会发现它们大都宣称自己是包治百病的大力丸！如果被这种宣传口号忽悠的随波逐流，受伤的只能是没有独立思考的墙头草，还是不要迷信任何大牛和权威了，因为Frederick Brooks博士在1986年就告诉了我们——“没有银弹”！

        “没有银弹”是经过多年实践反复证明的，但是违反这一自然规律的借尸还魂现象从来就没停止过，也许有意无意的就会相信或者期待某种新兴的权威的工具或技术，可以在生产率、缺陷减少、可靠性和简易性等方面带来极大的变化！

        那是不是说大家都不要研究新理论、新工具、新方法了呢？因为软件业就是这么个泥潭，怎么折腾也就是那么回事~ 想必各位有志青年有很多话要讲。。。

        个人理解，进步是一种必然趋势，也许要推翻“没有银弹”理论需要很多年的努力，或者期待人工智能接近人类水平的那一天，在这之前保持一种审慎乐观的心态来接收各种新事物，但一定不能盲从和失去了自我思考。

        我之所以研究“企业架构”是因为正在尝试推动一套“业务建模”实践，说的好听点也是一种方法论，这时候有些问题就必须解决，如何给这套方法找到足够的理论支撑，如何从更高层次给它准确定位，如何有说服力的推演它的价值链。。。

        对这个领域有所研究的朋友都会发现，业务建模领域真正有实践指导价值的资料非常少，市面上的书籍分为两种流派，一种是比较高层次的企业架构类的书籍，这一类大都比较曲高和寡，或者说没有一定的积累很难理解那些书里在说什么；另一种就是偏技术类的书籍，这种书可能会以业务建模开个头，但是不会进行深入探讨，基本都是RUP理论中相关内容的复述或举例说明。

        而且软件领域的各种理论和方法基本都是围绕着如何成功的完成一个项目为目标的，也就是一次性的不考虑重用与积累的方法论。没有人站在软件企业的角度，或者说站在企业应用软件厂商的角度来总结一套方法和理论，如何降低成本、提高效率、规避风险、客户满意、员工开心、利润攀升。。。

        虽说没有银弹，但是没有一份公开资料或书籍讨论这个领域的问题，也真叫人心寒啊~ 也许是我孤陋寡闻吧，希望有这方面线索的朋友慷慨分享。。。

        站在企业应用软件提供商的角度来说，从战略上要占据行业制高点，各种新业务新概念必须要跟得上潮流，拿得出方案。但维持企业运转的是日常生产和销售，这是企业的发动机，谁不想马儿不吃草，马儿还能不停的跑啊~ 但是想把软件生产做好是非常困难的，有人说软件工人蓝领化是一条出路，有人说软件企业要靠创新和技术精英来拉动。。。也许都有道理，但是能不能解决问题，还需要时间来证明。

        我想探讨的是另外一条路径，也有很多厂商在这条路上摸爬滚打了不少年，比如大家比较熟悉的SAP和它提出的“业务流程平台”，还有金蝶、用友等国内厂商的各种私有平台，现在比较流行的以Google App Engine为代表的公共云平台等等。。。

        其实各大厂商都清楚，技术平台容易搭建，业务平台才是核心，业务平台来自哪里？只能通过深厚的行业实践经验不断积累，而如何完成有效积累？只能通过将“业务建模”工作落实到日常生产活动中去，才能持续的有效的建立企业业务积累。

        接下来也许会偶尔抽空对“企业架构”再说说闲话，可能更多的时间要放在“业务建模”的实践研究上，虽然这方面成体系的资料不多，但是散布在各种资料书籍中的亮点和精要还是很值得深入体会的，希望有兴趣的朋友多交流！