不同人说的架构其实不是同一个东西

在IT帮企业架构实践公开课中，我经常讲下面这张架构实践成熟度的图

企业级架构我已经写了不少内容，而关于最低级别A的项目级IT架构很少写，今天我们就来简单说一下架构的分类。

我2001年来到公司开始学习Delphi语言。虽然是拖拽式就可以写出软件了，但是我们要求看源码，学习设计模式，自己编写控件，然后我又开始写类库、编框架、做引擎等，之后又搭建技术和业务平台。那些年学RUP、设计模式、应用架构模式、DSL、模型驱动开发以及各种编程语言，多年IT架构工作再加上之后的业务分析、产品管理和企业架构工作，我发现更多人所说的“架构”其实并不是同一个层次的架构内容。基于我之前的一些经验，这次着重从IT角度去把架构分为：应用程序架构、系统架构、软件架构和企业架构，希望能帮助大家理清一下概念。

应用程序架构

大部分软件开发人员说的架构都属于这一类。应用程序架构通常指由单一技术编写的应用程序，例如Java网络程序、Windows桌面程序等。

应用程序架构的关注点是某一个具体应用程序，包括类和组件的分解、设计模式的正确应用、框架的构建和使用等，通常只考虑单一技术栈，例如Java、微软NET等。它着重考虑的是软件和代码组织，其结构单元主要以软件为基础，由类、组件、模块、函数、设计模式等加以描述，包括编程语言和结构、类库、框架、API等。

系统架构

大多数软件系统实际上是由不同层次和技术的多个应用程序组成，例如你可能有一个Java EE中间层消费Oracle数据库提供的数据，同时向 .NETSilverlight客户端提供web服务的软件系统。其中每个部分都有自己的应用程序架构。我们可以把系统架构看作是类似这种更大规模的应用程序架构。

要让多个应用程序工作起来就要思考如何组合这些单独的应用程序，这势必要从较高层次去理清这一些列程序的整体结构。另外，大部分的软件系统也不是孤立存在的，他们之间存在着一定的交互，所以系统架构还要关注互操作性以及集成。跟应用程序架构相比，系统架构更关注组件、服务、子系统等更高层次的抽象元素，包括各种软硬件、从编程语言和软件框架到服务器和基础设施。

软件架构

软件架构可以看做是应用程序和系统架构的结合，也就是从代码结构到生产环境，以及与一个软件系统重要元素相关的所有东西都归为软件架构要关注的内容，重点是考虑如何架构更好的软件出来。

软件架构除了关注面向对象的原则、类、接口、控制反转等技术实践之外，还要关注横切关注点（如登录和异常处理）、安全性（如认证、授权和敏感数据保密）、非功能性需求（性能、可伸缩性、可用性和其他质量属性）、审计及其他监管需求、集成和互操作性、运营维护、架构一致性等。这并不意味着低层次的细节不重要，只是从大局来说，软件的整体视角可以确保你的程序代码能遵守并符合整体愿景。

企业架构

身边有不少人声称自己在做企业架构，其实大部分都属于前三个架构分类内容。企业架构是站在企业级角度，着眼于如何组织与利用人员、流程和技术来使企业有效和高效的工作。它更看重的是如何在整个组织中最好地利用技术，而无需实际介入这些技术的工作原理，也没必要关注技术细节。

有些开发人员和软件架构师开始把企业架构作为未来职业规划方向，于是开始学习基础概念、如何建模，甚至去考企业架构证书等。然而就像我在公开课中所说的，从事企业架构工作的思维方式和软件架构工作思维是有很大区别的，他们对于技术及其在组织中的应用视角很不一样，包括对于业务和战略的重视度也是截然不同的。简单的说，企业架构需要更高层次的抽象，这关乎广度而非深度，关乎战略到运营而非代码。

了解架构的不同分类之后，你是否想成为一名架构师？之前工作中总有一些人问我“如何成为一名架构师？”

要成为一名软件架构师绝非一夜之间或一次晋升那么简单。我之前公司没有架构师这一级别，我更把它看成是一个角色，我把“架构师”角色要做的事情列举出来，它适用于以上各层级架构师，只是具体关注的层级和内容不一样而已，大家可以参考一下。

架构师成长之旅是一个循序渐进的过程，希望更多走向架构师行列的人能够少走弯路。