软件构架师负责在整个项目中对技术活动和工件进行领导和协调。构架师要确立每个构架视图的整体结构：视图的详细组织结构、元素的分组以及这些主要分组之间的接口。因此，与其他角色相比，构架师的见解重在广度，而不是深度。这和建筑师在某一方面有一些相同之处。那么在软件开发过程中，软件架构师又是怎么样进行自己的工作呢？
首先是在需求方面入手，需求是一个项目的基础重中之重，可以说需求做不好，就不要想后续的各个过程了。上学期刚刚学过需求分析，各个过程看似简单但是却是有大作用，而且一步步的深入可以说在一开始就是为项目构建了一系列的架构类的东西，我是这么看的，就像是建筑工程师画的蓝图一样，有了这个东西，项目才能进一步走下去。对于需求来说每一次经过人手时就会造成信息的丢失，这都是不可避免的。所以软件架构师需要从一开始就接手需求，了解客户的真切需求，才能最小化的减少信息丢失，然后就可以着手构建。
接下来就是对于系统的分解工作，在收集了客户的需求信息后，如何把客户的需求转化为软件需求，同时还要补充非业务需求，这就是对一个软件架构师的考验了。在我看来非业务需求也是为了用户的体验问题，这些东西都是需要很丰富的经验了，不然挖掘潜在的需求还是不是那么容易的。如何有效把握用户需求与软件需求的区别，是系统分解的核心。对于系统来说，真是需要考究很多的事情。然后是技术的选型，这种东西可能是用户在提出需求时就已经指定好了的，但是对于用户来说他们不是专业的否则也就不需要我们来做这些东西了，他们可能只是说一个大概，可以说是对于大的观念上，比如说什么java，C，Android之类的，真正需的硬性技术他们并不会交代的多么仔细。所以这就是需要架构师来进行决定，这对于架构师来说又是一个考验。就像是课上看的那样，建筑师看到的也都是一些客户急需解决的事情，而客户能想到的真是很少的，只是希望变化，并没有要怎么怎么样，而建筑设计师是怎么做的呢？能改的地方改，能加的地方加。对于客户的需求可以说理解一下就会很明了，知道用户真正想要的，虽然是潜在的，但是经验使然，他做的对于客户来说不是说满足那么简单，而是在此基础上创新。客户看到结果时是惊艳而不是在意料之中，这真是很难能可贵的东西，也是软件架构师需要虚心学习的东西，如果把软件做成惊艳的作品，那么用户体验上来说一定是最佳的，没有什么不愉快。当然这些看似简单，确实有很多东西在里面，需要做的还有很多，尤其是经验的积累。
技术是确定了，那么接下来的就是真正动骨的地方了，系统的设计方面可以说就是为系统构建了一幅骨架，能不能支撑起来，需要做的也是不少。起码架构师得对团队的人员有所了解，能否完成，且在时间内完成，这是需要下面人的能力作为基础了。当然真正的系统涉及到的东西还有很多，只是可行性上面是必然要考虑的东西，不然的话难免有空中楼阁之嫌，说的出做不出，这对于企业也是不好的。对于软件架构师来说，需要做的是把需求系统建好，然后再进行重构，形成多个小的子系统，以便下面的团队进行合作开发，这样的话对于元素的接口设计就要提到日程上来了，这也是对于架构师的考验之一了。等软件详细设计说明书完成后，就要对下面的人进行培训和指导，起码得让他知道你要他怎么做，文档再详细也是死的，如果有什么问题的话，他不可能去问你的文档吧，这也是沟通中的部分了，对于软件架构师来说，设计完成后，这个工作也是重中之重，毕竟理论没有变成实际之前，也不过是一张纸罢了，需要如何去执行，还是需要人去做的。然而下面的人并不是说都是老手，很多情况下都是有新手存在的，你要做的东西他可能接触的少你不给指导他很难按照你的要求完成东西，如果不行的话那就只是无用功了，这对于架构师来说就是很需要精力的一件事了。
最后就是沟通上的工作，上面也提到了，文档并不能代表一切，工作之中的沟通是必要的也是必然的，你不可能自己设计了自己去完成，这对于一个项目来说有点没有效率了，沟通是贯穿始终的一件重要的工作，不可轻视，也不能没有。