Why Modern Software Architecture Needs a Lightweight, Agile Approach

老子有云：“千里之行，始于足下”。

和大多数人一样，我是从一个软件开发人员开始自己的职业生涯，与团队合作开发软件系统。随着时间的推移，我开始设计自己的软件系统，并最终成为一名软件架构师，为企业提供架构设计，帮助众多技术团队受益。

在IT咨询机构工作期间，我发现要更好地服务客户并扩大组织，需要更多的软件架构师加入团队。

1、软件架构理论需要更易用。虽然业界已有一些导向，但进入软件架构师的门槛仍然不低，现有的架构类书籍角度各异，往往偏向研究或学术，缺乏面向实际开发人员的解决方案。

2、所有软件项目都需要软件架构。我喜欢敏捷开发，但许多敏捷方法缺乏对软件体系架构的明确关注，误以为不需要事先设计，导致错误结果。因此，在复杂团队背景下，前瞻性和充分的思考尤为重要。

我偏好轻量级的软件体系和方法，像搭积木一样，及早形成可交付的作品，这种渐进式成功带来更强的成就感。

3、轻量级的软件架构实践

这些年我发展了一套自己的软件架构方法论，包括设计过程、技术识别、沟通与记录风险等。过去的实践已经传播给成千上万的人，并看到他们与传统架构的区别。

这并不是一种全新的软件开发方法，而是在传统、普遍、前沿思维之间寻找一种舒适的中间路径，特别是在敏捷方法的前期设计和架构演化方面。

我们从最基本的开始，“架构”一词在大众心中与实际含义有严格区别，尤其在互联网上有不同的定义。

在不同场合和用户中，我收集了对软件架构师职责的全面定义：

模块，连接，依赖与接口

有大局观

改变的代价是昂贵的

难以改变的事物

设计时考虑更大的图景

接口而不是实现

美学（匠人，干净的代码）

概念模型

满足非功能性要求/质量属性

一切都是“架构”

沟通能力（抽象，语言，词汇）

一个计划

鲁棒和坚固性

蓝图

系统，子系统，交互和接口

治理

战略决策的结果

必要的限制

结构（组件和交互）

技术方向

战略和愿景

架构模块

实现目标的过程

标准和准则

整个系统

工具和方法

从需求到最终产品的路径

指导原则

技术领导

构成产品的元素之间的关系

意识到环境的限制和约束

创始人

抽象视图

把问题分解成更小的可实施的元素

产品的骨架/主干

天，真的很难找到一个单一定义！幸好“architect”这个词既是名词也是动词，恰好体现了架构师的双重角色。

你认为哪个词最符合？

文：张小闲