架构师成长之路：到底什么是架构设计？该如何理解架构设计？
架构设计是一个大家耳熟能详的词，基本都烂大街了。
可是，到底什么是架构设计呢？估计很多人就回答不上来了。
下面就来详细聊聊什么是架构设计，以及对架构设计的一些基本认识。
软件架构设计指的是：对一个软件系统进行的架构定义、文档编写、维护和改进、并验证实现的一系列活动，架构设计的产物就是一个系统的架构。
架构设计实际上是一个过程，围绕着软件系统，对它的架构，进行定义、文档编写、维护和改进、并验证实现等，把这一系列活动组合起来，就是我们所说的架构设计。
架构设计的产物，也就是结果，就是架构，这也是架构和架构设计的关系。
架构设计是一门科学，这个已经是业界共识。但是作为一门科学来讲，它一定要有它自己的基础理论，基础方法，也会有一些实现的方法论。
架构设计作为一门科学来说，还很不成熟。目前架构设计的基础理论还不是很完善，方法论上，更是百花齐放，大家都还处于一个探索的阶段。
从科学上来讲，架构设计主要关注架构设计过程当中的：技术、流程、资源、方法；以及如何去完善并改进架构。
刚讲到架构设计这门科学还很不成熟，再加上技术领域更新很快，新技术、新思想、新方法 层出不穷。
我们总会面对很多新兴的、没有先例的系统，可能会应用新的框架、新的技术、新的解决方案来实现系统。
因此，做架构设计的时候，是需要一定的创造力的。当然，艺术细胞缺乏的人员也不用太担心，架构设计上还是有很多是有章可循的，多半是在已有的架构体系上去做一些微调，微创新，并不是完全从零开始。
架构设计不是一蹴而就的，通常也是由粗到精，刚开始，可能只有一个粗略的架构设计，然后不断迭代和演化，逐步推进，去完善和细化，这样的过程。
这个可能有些人不太理解，认为说，软功过程里面，不是有专门的概要设计、详细设计的时间吗？架构设计不就是在这些设计阶段去完成的吗？做完设计了，把文档发下去，不就没事了吗？
有些公司也是这么干的，实际上这是有问题的。
架构设计会跨越软工的完整流程，对于一些大型的或者是重要的项目，可能立项期间，架构师就要参与，做一些粗略的架构规划，有两个基本的原因：
1：能不能做得了这件事
2：按照粗略的架构规划做下去，大致的成本会有多大
立项的时候，就要去考虑你的成本，风险和投资收益。
也就是说，立项的时候，架构师可能就需要参与，那就更不用说需求阶段、设计阶段了，架构师是肯定要参与的，前面讲需求分析的时候已经讲过了，这里就不多啰嗦。
到了编码阶段，有些人可能认为架构师是不参与的，这是不对的。架构师需要参与，只是参与的少一些，主要是一些重点、难点的地方，或者是公共基础功能，由架构师来实现。
另外在编码阶段，架构师还有一个重要的任务，就是确保开发人员按照架构设计去实现，不要乱做。这就需要两个基本的方式，一个是架构师要把架构设计的成果，跟开发人员讲解清楚，并不断沟通；另外一个就是要不断检查，Review，以确保架构设计的落地实现不出大的偏差。
后面的测试、部署、运维等阶段，架构师要做一些技术咨询，或者是技术指导的工作。架构设计里面，本来就包含部署架构的设计，因此，架构师也会参与这些阶段，只是参与的少一些。
总之，架构设计需要关注所有利益相关者的要求，参与系统设计实现的所有人员，也都是系统的利益相关者，自然而然的，架构设计就需要贯穿软工的整个流程了。
一个系统，要关注的方方面面是很多的，利益相关者也很多，大家关注点各有不同。
这就意味着，在做架构设计的时候，需要不断去做决策，在众多关注点中去寻求平衡，所以有人说，做架构设计，就是一种玩平衡的艺术。
比如：从技术上讲，A+B的方式是性能最高的；但是从成本上来看，A+C是最合适的。可能最后综合权衡后，B+C是各方都能接受的方案。
这种需要考虑的平衡很多，比如：技术和成本的平衡；方案适用性年限的平衡，是满足1-3年就够了，还是要考虑8-10年；技术方案和当前开发人员技能的平衡；性能和成本的平衡等等，非常多。
架构设计是一个过程，需要在这个过程中，不断去考虑各利益相关者的要求，并不断折中平衡，因此架构设计的产物，也就是架构，自然就是各方利益相关者的共识了。
要做出好的架构设计，经验是不可或缺的，不会每次都是从零开始。
比如以前做过类似的系统；或者是学习到的一些好的架构模式，设计模式，一些现成的组件；或者是一些开源的框架等等的，这些我们都可以看成是可重用的资源。
我们做架构设计的时候，需要不断去积累这样子的可重用资源，形成自己的工具箱。这样当我们在做一个系统的架构设计的时候，就有了很多备用的工具或手段。
有了这些经验和资源的积累，会使得新系统的架构设计变得更容易。
定义：
一个软件随着功能越来越多，整个软件系统逐渐碎片化，如果不采取有效措施，软件系统就会越来越无序，最终无法维护和扩展。
所以说软件在一段时间的生长后，就需要及时干预，避免越来越无序，架构的本质就是对软件系统进行有序化重构，使软件系统不断进化。
扩展资料：
系统构架是对已确定的需求的技术实现构架、作好规划，运用成套、完整的工具，在规划的步骤下去完成任务。
抽象来说，它是计算机系统结构，或称计算机体系结构，是一个系统在其所处环境中最高层次的概念；它确定一台计算机硬件和软件之间的衔接。
具体地说计算机体系结构指的是计算机系统设计的观念与架构，描述计算机在实做的设计原则。
它确定一个计算机设计的部件功能 ，部件间接口 并且计算机体系结构着重于“负责了计算机架构的中心功能：计算”的中央处理器内部的运行动作与存储器的访问。
参考资料：百度百科：系统构架
具体内容：
1、选择授权模式
①3种授权模式：1.集权式：管理权、决策权集中在决策层，老板亲自参与实际经营；2.授权式：根据岗位职责分配相应权限，权限与职责相对应；3.规范式：按制度、规范进行管理，最大限度降低人的影响；
②如何选：1.企业不同发展阶段，不同授权模式；2.发展、成长阶段，可选择集权式、授权式管理；3.成熟阶段，可选择规范式管理；4.集中化的营销和服务，往往选择集权式管理；5.个性化的营销和服务，多采用授权式管理；
2、选择组织架构类型
①5大类：1.有限公司制：公司以其全部资产对债务承担责任的企业法人，股东以出资额为限对公司承担责任；2.分公司制：受总公司管辖，但不具有法人资格的分支机构；3.子公司制：一定数额的股份被母公司控制的独立法人机构；4.事业部制：以产品、地区或客户为依据，将相关的多个部门结合成一个相对独立单位的组织结构形式；5.连锁制：经营同类商品或服务的若干个企业，组成的联合体，在整体规划下专业化分工，集中化管理；
②如何选：1.一般情况下，采用有限责任公司制；2.跨行业、跨产业经营时，可使用子公司制；3.扩张同时需要高度标准化、统一化管理时，使用连锁制；4.同一公司不同项目运营时，采用事业部制；5.计划扩张但又不需要独立法人机构时，采用分公司制；
3、选择组织导向
①3大类：1.营销导向：以销定产，营销在企业内部占主导作用；2.技术导向：以核心技术为依托，先开发产品，再考虑顾客需求；3.生产导向：先有生产，再有销售，生产什么销售什么；
②如何用：1.通过对组织导向的分析，决定哪些职能部门是主要业务部门，哪些是辅助业务部门；2.越是主导部门，编制越大、岗位越多；
4、选择企业产业类型
①3大类：1.单一行业型：所有的业务均集中在同一行业；2.多产业型：企业的业务分布在两个或两个以上的行业；3.生产链型：在现有产业基础上，向上延伸到基础产业环节，向下延伸到市场拓展环节；
②如何用：1.多产业型、生产链型企业，多采用事业部制、分公司制、子公司制；2.单一产业型，多根据产品种类和区域选择对应组织架构；
5、选择股份持有类型
①4大类：1.个人独资型：一个自然人投资；2.合作型：两个或两个以上股东；3.股份奖励型：对部分贡献大的员工给予部分股份奖励；4.市值流通型：上市公司的股份市场流通；
②如何用：确定股东的组合形式；
6、部门组织架构设计
①财务部：必须设立财务部，负责企业的各项财税和管理工作；
②营销类部门：与销售相关的各个部门，含，营销部、市场策划部、广告部、公关部、直销部、渠道部、零售部、进出品部、商务部、单证部等，亦可整合为营销中心；
③生产类部门：与生产及技术相关的各个部门，含，生产车间、质检部、设计部、维修部等，亦可整合为生产部或生产中心；
④行政中心：行政、后勤、人力资源等支持保障性职能部门，亦可分开行政部、人力资源部。
一、What | 什么是信息架构？ 1. 信息架构的起源 信息架构(information architecture)，简称 IA。 1976年，瑞查德·索·乌曼在担任美国建筑师协会会长时创造了“信息架构”术语，用来应对当代社会信息的不断增长和爆炸。她的妻子说道：“他所有的训练，作为一个建筑师，作为一个制图者，作为一个平面设计师，作为一个企业家，作为一个出版商，还有作为一个作家，本质上都是想要让信息变得清晰易懂。” “信息架构”是一种使问题变清晰的方式。
2. 信息架构的定义 IA 的主体对象是信息，由信息架构师来加以设计结构、决定组织方式以及归类，好让使用者与用户容易寻找与管理的一项艺术与科学。 信息架构=信息+架构。 信息包括各种文本、图片、影音等元素；架构则对应这些元素的选择、分类、导航和检索。 通俗点说，信息架构就是通过合理的组织和表达各种信息元素，让用户获取并理解信息更容易。为信息与用户认知之间搭建⼀座畅通的桥梁。
三、How | 如何进行信息架构设计？ 在本章节，我们先了解一下构建信息架构的3种方式，然后学习信息架构的4种常见类型，再学习一下信息架构的设计逻辑流程，最后给大家举一个非常小的设计案例帮助大家理解。
1. 信息架构的构建方式 信息架构有3种构建方式：自上而下，自下而上和综合运用。 1）自上而下的构建方式 自上而下的构建方式是由战略层驱动的，根据产品目标与用户需求直接进行结构设计，进行新产品规划或者产品重新定义的时候会用到。 自上而下的构建方式，会先从最广泛的，最有可能满足目标的内容及功能开始分类，再依据逻辑细分次级分类。（MVP的设计思路）所有分类都是空槽，最后将内容和功能按顺序填入。它有一个明显的缺点是：可能导致现有重要内容被忽略。
2）自下而上的构建方式 自下而上的构建方式是由范围层驱动的，根据对现有的内容和功能需求的分析进行设计，这是项目实践中大家最常用的一种方式。 在具体项目实践中，产品或设计师根据对现有内容和功能需求的分析，将它们分别归属到较高一级的类别，从而逐渐构建出能反映我们的产品目标和用户需求的结构。（常用卡片分类法辅助）它也有一个缺点：可能导致不能灵活兼容未来内容变动或增加。
3）综合运用的构建方式 正因为自上而下和自下而上都有其明显的缺点，所以理想的信息架构的构建方式都是综合运用的，同时从战略层和范围层进行驱动，以构建一个适应性强的系统。 一个适应性强的信息架构系统，能把新内容作为现有结构的一部分容纳进来（如图左侧），也可以把新内容当成一个完整的部分加入（如图右侧）。
信息架构的基本单位是节点，节点可对应任意信息要素或信息要素的组合，小到一个字段/控件，大到一个界面/功能都是可以的，不同场景下，节点的颗粒度不相同。 这些节点的排列方式有4种常见的类型，也就是我们所说的信息架构类型。大家在具体设计的时候，可以参考使用。
3. 信息架构的梳理逻辑与呈现 有了前面的构建方式和信息架构类型作为指导思想，结合我们的设计分析，可以帮助我们梳理出特定结构的信息架构和任务流程，并以受众易理解的方式进行呈现。 在梳理过程中，我们以业务侧在范围层提供的信息范围为基础，通过竞品分析（了解竞品的组织系统、标签系统、导航系统、搜索系统规则），结合本品现有信息架构的数据表现（了解我们用户在我们产品中的行为偏好），再配合以用户调研（通过用户问卷或者卡片分类，了解用户对信息归类组织的心智模型）最后利用逻辑推理，可以整理出适合我们产品的信息架构和任务流程。
所以真实的项目中做信息架构，绝不仅仅是将产品提供的功能、内容进行简单的归类分组，既要自上而下的考虑其拓展性，筛选/补充重要的节点纳入信息架构。还要考虑其命名（标签系统）用户能否很容易的认知理解。 然后再是将所有信息按照某个或某几个特定的维度进行分类组织（组织系统），最后再考虑呈现，以何种形式表达给大家，让大家更容易理解。
严格来讲，并没有标准的信息架构表达模式，在《信息架构——超越Web设计》一书中，罗列了多种信息架构的表达方式，只要能够向受众传达清楚，什么表达形式都是可以的。 在互联网项目中，大家用得比较多的形式包括：信息架构图和逻辑流程图。和交互设计原型一样，重点不是这张图的形式（这种图在技术层面上谁都能画），而是这张图背后的（组织系统、标签系统、导航系统、搜索系统）。
1）组织系统：选择合适的维度及结构 组织系统：以什么维度来归类组织这些信息，我以曾经做Material Design的组件分享为例，官网提供的组件如下图所示： 但归类方式肯定不止这一种形式，大家在学习的时候，可以按照自己的组织系统进行归类整理。
以新闻呈现为例，可以按照时间维度归类，可以按照主题维度进行归类、可以按照媒体方的维度进行归类，可以按照表现层视频、图文、文字的形式进行归类，到底按照什么维度进行单一归类还是进行矩阵归类，这就是你的组织系统要解决的问题。
2）标签系统：选择合适的语言及图像 标签系统，通俗来讲就是要我们对当前整个系统信息节点的命名，从而让信息的呈现更容易识别，包括文本标签和图片标签。 比如我归类的栏、控件和视图，用户是否也习惯这样的分类方式，我选择的图标是否能准确地表达文本标签的涵义。
3）导航系统：选择合适的导航结构 导航系统的内容比较多，我们将在下一堂课单独讲解 4）搜索系统：是否选择搜索 搜索系统是我们平日最常用的查找信息的功能，它能够帮助我们快速进行信息的检索。虽然搜索功能非常重要，但并不是每个系统每个页面都需要搜索。我们决策是否添加搜索需要考虑三点：
内容丰富度：产品所承载的内容丰富度/复杂度低，内容少（搜索可能经常得不到结果）往往不需要提供搜索。 内容性质：产品提供的内容如果是偏兴趣探索，浏览型的也可以不需要搜索； 搜索场景：如果搜索场景很简单，考虑是否只用筛选或分类就能够解决问题；反之如果搜索内容很复杂，我们还可以搜索结合筛选来更好地查找信息。
上述 3 点决定了我们是否需要考虑搜索功能。而关于搜索的具体设计，也是一个庞大的课题，我们先不做进一步的阐述。 信息架构图是一个中间产物，他的呈现形式是相对简单的，但这个形式背后的思考（组织系统、标签系统、导航系统、搜索系统）是需要设计师深思熟虑的，设计师在做信息架构时，务必要将信息（有哪些信息，如何命名）和架构（如何分类组织，如何呈现）都考虑清楚，之后的框架层设计才能更清晰明确。
