企业为什么要进行架构设计？是为了解决技术难题吗？架构设计中的“架构”究竟是指什么？架构设计的本质是什么？
1.架构设计就是解决技术难题吗？
通常来说，架构设计这个工作是一个听起来比较高大上的概念。十多年前，当我还是一个程序员的时候，那时候认为架构师就应该是能够搞定各种技术难题的技术大牛，是一个掌握十八般武艺的英雄，开发中的性能难题，扩展性难题，分布式难题，数据库难题，以及各种疑难杂症都应该是架构师们手起刀落可以轻松解决的。但是随着我在软件这个领域做的项目从几个变成十几个，几十个，这十多年的技术也更新了一茬又一茬，我开始对自己之前的这个架构师认知产生了疑问？如果一个厉害的架构师就是解决这些技术难题的人，为什么不叫技术专家或者高级工程师呢？那么架构师这个title里面究竟是在给什么东西做架构？另外这一个个技术难题的意义和价值究竟是什么呢？是因为这些难题一般人不能解决的成就感吗，还是为了满足架构师对于某些新技术的好奇心，还是为了在和别人讨论时可以满嘴都是各种设计模式？
曾经见过很多企业的架构师给老板或者业务部门说，虽然我们现在业务不行，但是我们的产品架构很牛，我们用的都是最先进的语言和框架。然后业务部门问，我们现在业务上有这些需求，你们能一周实现出来吗？然后架构师就说，你这个需求虽然很小，但是对当前的架构影响很大，改动起来至少要一个月。
这些疑问让我产生了一个新的问题，对于架构设计这个工作来说，究竟什么才是架构？这个问题的答案最终在《系统之美》《复杂》这两本书里找到了，当我们解决这些难题的时候，我们面对的并不是一个个孤立的点，而是一个复杂系统。所谓系统，就是由一堆元素和连接关系构建起来的一个整体结构。比如在国家这个系统中政府，企业，个人都是这个系统中的要素，这些要素和他们之间纷繁复杂的连接关系一起构建成了国家这个复杂系统。当我们想要改变一个复杂系统时，系统通过改变要素的特性来改变系统是很困难的，一方面是很多要素难以改变，一方面是由于系统自身的一些特性会让被改变的元素又变回原来的样子。因此，先要改变一个系统的唯一办法只能是改变系统内要素的连接关系，或者引入新的连接关系和新的要素。顺这个这个思路，所谓的架构设计，本质就是通过改变一个复杂系统的要素之间连接结构来解决这个系统的各种问题。
那么在企业架构设计这个命题中的复杂系统究竟是什么呢？要回答这个问题就需要重新回顾一下企业架构设计的历史，看看我们现在日常熟悉的企业架构设计的一些基本概念都是怎么产生的。
2. 企业架构设计简史
- 1987年，John Zachman 创立了全球第一个企业架构理论，其论文《信息系统架构框架》至今仍被业界认为是企业架构设计方面最权威理论。是其他企业架构框架的源泉。Zachman框架的本质是分类学，通过二维表提问的方式对齐企业信息
- 1996年，美国国防部的US Undersecretary of Defense for Business Transformation工作小组推出C4ISR AF 1.0，C4ISR（Command, Control, Communications,Computers, Intelligence, Surveillance and Reconnaissance）是军事术语，意为自动化指挥系统。这是DoDAF（Department of Defense Architecture Framework）的前身，2003年8月正式推出DoDAF 1.0，2009年推出DoDAF 2.0，DoDAF 2.0大体上可由八大视图与实施方法论组成
- 1995年，国际标准权威组织The Open Group发表了TOGAF（The Open Group Architecture Framework）框架，TOGAF的基础是美国国防部的信息管理技术架构，其中最有名且当下使用最广泛的为TOGAF，号称福布斯80%的50强都在被HP、IBM、SAP使用。我们现在经常说的业务架构，应用架构，信息架构，技术架构也都是源自这个框架。
3. 企业架构设计传递的信息
虽然这些架构框架都有不相同的地方，但是我们能够发现这些框架的共性：框架设计者希望能够从不同的视角去剖析一个组织（企业，军队）的信息系统架构。所以用现在大家最广泛接受的TOGAF框架来说，这些业务架构，应用架构，数据架构，技术架构其实就是不同的视角。在不同的视角下，系统呈现出来的要素和连接关系都会有所不同，因此不同视角呈现的结构也会有关联和支撑。
我相信基于大家的日常工作经验，架构设计最终的呈现方式通常都是一个架构设计图。之所以采用图的方式就是因为在描述一个系统的元素和连接关系时如果采用线性的文字方式进行描述会很难描述清楚。所以架构设计图的本质是一种高效传递复杂系统结构的信息传递方式。基于这点，一个架构设计图中最重要的两个点就是：这个信息是要传递给那些人的，他需要用这些信息来继续做什么？
还是用常见的TOGAF的4A架构来说， 业务架构Business Architecture只是从一个企业的业务视角来去分析有哪些业务元素还有元素之间的连接关系，但是由于企业内外不同的人会关注业务的不同方面，所以完整的业务架构需要针对不同的信息接受方来组织信息。 应用架构Application Architecture在中文语言里的全程应该是应用系统架构，AA需要根据业务架构设计出支撑业务架构的应用系统有哪些， 信息架构Information Architecture原本的初衷是描述应用系统里面的信息模型，信息模型的关联关系，以及这些信息模型是怎么传递的，也就是我们常说的数据库的设计，之所以从AA中独立出来是因为数据库被发明出来了以后，基于关系数据库，信息模型越来越复杂，所以需要单独设计。但是随着这些年DDD越来越流行，而且各种ORM框架越来越成熟，所以使用DDD方法来设计的时候可以同时获得AA和IA。 技术架构Technical Architecture的最重要作用就是告知开发团队设计的AA和IA应该如何落地，具体到有使用什么硬件，操作系统，软件，网络如何设计，系统如何部署，如何通信等等这些和落地相关的细节都是技术架构应该传递的信息。
基于上面的逻辑，我们可以看看中台，DDD，微服务这些火热的概念都是在解决哪个层面的问题了。 1. 首先说中台，由于中台是企业级能力复用平台，所以中台一般不会对企业的业务架构产生改变，你看阿里搞了中台以后并没有改变天猫，淘宝，菜鸟这些BU的业务，而是通过业务的横向分析，找到了可以复用的企业能力，重新设计了支撑企业业务的应用系统，所以中台设计更多的是企业应用系统架构层面的设计，只是相比过去，应用系统设计需要从企业级视角出发，而不是只考虑某个BU就够了。2. 再说DDD，DDD虽然会从领域（也就是业务）视角进行设计，但是很难用DDD设计新的业务模式，所以DDD是一种根据业务进行分析然后设计出和业务很好匹配的应用系统，一般来说限界上下文就是一个应用系统或者业务模块，由于DDD里面没有应用系统落地实现细节，所以也不涉及技术架构的内容。3. 到了微服务设计基本就和落地相关了，所以微服务设计回答的是技术架构的问题。当然应用系统落地除了微服务也有大单体，SOA等其他方式。只是现在由于云计算基础设施，微服务技术支撑技术越来越成熟，采用微服务架构设计的技术架构能够给让企业在设计应用架构时粒度可以更细，这样就可以更快的支撑业务架构的变化。
后面的文章我们逐一看看在这些不同的视角下进行架构设计的正确姿势是什么样的。
