架构这个含义最开始运用在建筑上的，在架构漫谈中对于架构的是这样定义的：
- 根据要解决的问题，对目标系统的边界进行界定。
- 并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。
- 并对这些切分出来的部分，设立沟通机制。
- 根据3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作
满足上面四个条件就是一个软件架构，之后我又在百度上搜索一下软件架构，在百度百科中对于架构的定义是软件架构所指的就是说相应的系列性的抽象模式，可以为设计大型软件系统的各个方面提供相应的指导。从本质上来看，软件架构是属于一种系统草图。在软件架构所描述的对象就是直接的进行系统抽象组件构成。连接系统的各个组件之间就是做到把组件之间所存在的通讯比较明确与相对细致的实施描述。处于相应的系统实现环节，那么就会使得细化这些抽象组件成为现实的组件，比如可以是具体的某个类或者是对象。从面向对象领域进行分析，那么各个组件之前实施的连接实现往往是接口。相比较而言架构漫谈中对于架构的解释更容易让人理解与接受。在看完九篇之后，更加深刻领悟了软件架构的实在意义与重要性。
由此，引发思考，在一个软件项目的实际开发过程中软件架构师充当了什么样的角色？软件架构师是怎样发展起来的？以及软件架构师对人有什么样的要求？怎么样能做好一名软件架构师。
首先软件架构师是一个怎样的职业呢?软件架构师是指那些制定高级设计决策，并确定技术标准（包括软件编程标准、工具和平台）的软件专家。这之中的首席专家就是总架构师。在架构漫谈（7）中，作者提到如果你一直在解决自己的问题做着自己的事情，那你会成为一个工匠，但绝不是架构师，架构师解决的是别人的问题，别人的肯定才意味着架构师工作的成功，架构师要去衡量别人的利益，他是一个组织的领导人，
在知乎看到一位叫Justin Miller的架构师提到
有时候，架构师也被看做不同工作组之间的粘合剂。以下是三个例子：
- 横向：在业务部和开发人员或是不同的开发团队之间架起沟通的桥梁；
- 纵向：在管理者和开发人员之间架起桥梁；
- 技术：将不同的技术或应用整合在一起。
由此可见架构师在一个团队当中是有举足轻重的，是联系上下，统筹兼顾的重要职位。所以我认为一个优秀的软件架构师一定要有良好有效的沟通能力，如果不能对团队中的其他成员有有效的沟通，产品开发也会变得举步维艰。
而有些人会想，软件架构师的工作已经不再是在电脑上敲代码，更多的是安排工程的切分和建立沟通机制，那技术和语言对于一个架构师是不是不再重要了，这个观点在架构漫谈中被否认。作者说，对于一个架构师来说，技术和语言更像是用来解决问题的工具，在日常生活中，我们对于工具的使用应当是十分熟悉的，就像是一个楼房的建筑队，包工头或许并不会直接砌砖添瓦，但是他对于砌砖添瓦的工具肯定是熟悉的，甚至于在有些时候他能选择更好的建筑工具。如此来说，技术和语言对于架构师来说应该是信手拈来，当现有的语言不合适的时候，他甚至可以自己创造。
Justin Miller以自己的经验总结了一名软件架构师的日常
- 定义和确定所需的开发技术与平台；
- 定义开发标准，如编程标准、工具、审核流程、测试方法等；
- 对确定和理解业务需求提供支持；
- 设计系统并根据需求做出决策；
- 对架构定义、设计和决策进行讨论记录；
- 检查并审核架构与代码，比如检查前期确定的模式与编程标准是否被正确实施；
- 与其他部门和架构师合作；
- 对开发人员的引导及咨询；
- 将高级设计细化，并转化为较低级的设计。
综合上面来看一名优秀的软件架构师需要有良好的沟通能力，团队协作的精神，敏锐果断的决策能力，过硬的专业知识，强大的自信心等等，而现在在象牙塔中的我们，还没有真正的参与过一个软件工程的研发，毕业之后做到架构师的位置应该也需要至少两三年的时间，现在的我们可以为以后做准备的就是不断加强自己的技术与语言能力，不论以后做到什么职位只要在这一行业工作，专业能力都是绝对不容忽视的一个重要的因素，所以加油吧，现在再辛苦也好过以后没有工作或者工资微薄的凄凉。