现在很多公司招人要系统架构师，请问象做ERP系统、管理系统的系统架构师主要做些什么？和系统分析有什么不同啊？
或者哪儿有这方面的资料可以介绍一下？
先在这谢谢了！

System analyst focus on the system functionality. While Software architect focus on the software architecture, to elabrate the system's static structure from its dynamic behavior. But in China, sometimes, they are used for a same role-design.

这样说的话系统分析我到是比较明白，但软件架构设计设计我还是不明白（很不好意思，我一直对软件体系结构主要指哪些东西还不太明白），因为我们以前开发系统好象很少做什么架构设计，都是做完功能分析、数据库结构设计就开始开发，做的很不规范，所以对架构设计没有概念，也许在开发过程中会涉及到这部分，但自己也不知道。而且感觉两层的系统好象也没什么架构可设计的（反正都是C/S结构，我以前一直是做两层的）。
所以能否简要说一下架构设计主要是设计哪些东西？或者有什么好的资料推荐一下，谢谢！

对多层体系我还不太明白，但象以前的两层结构的系统，体系架构都设计哪些东西呢？用C/S结构做erp、管理系统之类的感觉没有什么系统架构好设计的，数据库到是有不少东西需要设计。
系统架构是不是软件的一些重要的实现方案，象以前开发系统需要和已有系统进行接口，接口实现方案是不是就属于系统架构的范畴？

建房子有建筑设计,结构设计,装潢设计,水电设计等等,
做软件为什么就不能有呢?
软件的架构设计的地位和作用就相当于建房的结构设计.
把软件想象为一座大厦,你就会知道软件架构设计应该涉及哪些内容.

这点我也明白，前段时间看设计模式就看过这么说，我也觉得非常有道理，所以想搞清楚也是想对自己有个提高吧。但试着以自己以前做的系统为例看看架构设计应该做哪些工作就想不明白了。
经你这么一说我有点明白，架构设计是不是包括象一个大系统应该划分成几个小系统（多层中好象还有包）、每个小系统（或包）之间如何接口这是不是就象建筑盖房子的框架；以及如何和外部其他系统接口（是不是就象房子的门应该怎么设计）；系统如何设计保证今后一定的可扩展性等。
不知道上面这么理解对不对？应该还有其他什么吧！
还有象一些通用模块的提炼、接口设计是否属于架构设计范畴？

架构设计师的侧重于从技术的角度、整体把握系统的方方面面。有的资料上提出了这几个概念，也许有助你理清思路：
1）框架：J2EE，.net等，提供一组基础组件。
2）架构：以框架为基础，提取一个满足特定应用的子集。

有人这样定义架构：某个软件或计算系统的软件架构即组成该系统的一个或多个结构，它们构成软件的各个部分，形成这些组件的外部可见属性及相互间的联系。 事实上，架构应该是对系统各结构的一种描述，这其中包括数据流结构、模块结构、进程结构。架构在大型的较为复杂的系统建设中更具重要性。

 构架应该分为两种：
　

---

构架应该分为两种：
系统级别的构架：J2EE，.Net,提供分布式系统开发、运行的支持机制，基础设施
应用级别的构架：ERP,CRM，进销存... ...，针对应用领域特点提取的公共基础框架。
所以你的理解应该在后者，对他们构架是什么呢？就是如何划分子系统，子系统的接口如何，已达到以不变应万变。说白了，综合查询如何对业务应用提供支持，借口如何这既才能达到可以在各应用间自由使用，是构架所支持的构件体。那构架也就是联系构件的纽带，例如进销存之间关系的接口如何定义：可以用共享数据表。
所以构架并不是什么新东西，主要是对你的工作进行提炼，提取出共性，把握这种共性的结构就是构架，所以离不开构件的定义。
构架有各种粒度的，COM的结构定义就是一种代表。要明确构架的目的：针对领域应用，复用公共框架，支持组件开发。
不知有没有帮助？不好意思说多了。

 回复: 构架应该分为两种：
　

---

对于楼上这位朋友的理解我有点不同看法，现在说的是架构(Architecture)，而不是框架。我认为楼上这位朋友说的是框架（Framework),对于J2EE,.net事实上是系统级的应用框架（Application frameword)，而ERP则属于应用级的应用框架（Domain framework)，对于应用框架的搭建，我们要采用软件架构的思想去进行，但框架和架构还是有区别的。

I think the definition of architecture depends on the task of an architect. The task of an architect is to define the static structure of a system based on the system user's requirements, which is the system dynamic behavior. Just as some one here said, software architect is same the building architect. I totally agree with this guy.
So now we can see what is the software architecture. I think it includes the following concepts:
(1) Software component enviroment. A software survive in the whole enviroment. For an architect, it is his task to figure out this enviroment.
(2) Software component breakdown
(3) Service interface
(4) Subcomponents and its relationship
(5) How to achieve the dynamic behavior by the cooperation by these subcomponent. It is the verification of your design.

In fact, I did not see books which focus on software architecture. But according to my experience, I think the following is useful:
(1) Design pattern, especially architecture design pattern
(2) UML process, especially design process

I hope my explanation is useful to you.
　

Here i can recommend two books just about software architecture,
《Software Architecture in Practice》and 《Evaluating Software Architeture》

说是一种思想似乎不太贴切，说是一种方法可能还恰当一点，包括UML也是。架构是整个软件系统的一个或多个结构组成，它要全盘去处理系统各个结构，以及各结构的外部可见属性，还要表现出相互间的联系。而应用框架则注重于行业共性，注重于可重用的设计和分析，应用框架提供的是某个领域内的通用的底层服务，比如说你建立起一个ERP应用框架，那么具体的用户只需要在你的应用框架上做一些特定功能的定制就可形成自己的应用系统。

谢谢，有点明白了！

如果说一个软件象一座大厦,只有其框架结构,那么,一个系统就好比一座城市,架构的作用会更加明显.
1.城市架构的第一部分是城市道路,需要设计主干街道,分流街道,小区道路等等,还有立交桥,这些道路桥梁不仅把城市分割为不同的条块,而且还提供城市人流物流的通道,这是城市架构最重要的部分.
2.城市架构的第二部分是城市功能的部署,什么地方建工厂,学校,商场,剧院,住宅,酒店,风景区,体育场等等都要与历史、地理、人文环境相适应,同时还要相互配套.这是城市架构的主体内容.
3.城市架构的第三部分是城市的管理规范，这是软性的，却也是非常重要的。它规定一旦城市被“启动运行”，在城市中活动的“生物们”就必须按照怎样的法规和约定做出行动和相互沟通，以保持城市的秩序化的良性循环运作。
城市的架构设计不会设计某座工厂如何建设，如何生产；学校如何招生，如何分配。那些都是功能设计。总的来说，城市的各项功能通过城市的架构有机结合，才构成城市欣欣向荣的景象。否则，就会出现城市发展的不平衡，导致资源急缺或浪费。
做一个ERP的架构设计，大体就和规划一个城市差不多。
关于析分和架构设计师的关系，我认为是两个正交轴的交叉点。
一个轴X是从业务需求->系统需求->系统设计...方向，另一个轴Y是从体系结构->功能点方向。
系统分析师占据X轴的系统需求列，而架构师则占据Y轴的体系结构行。

架构设计师关注结构上的实现；
普通设计师关注功能点上的实现。
分析员需要对架构的需求和功能点的需求做出分析。
按道理也应该有架构分析和功能分析的分工。
此外，对业务层和系统层的工作你还需要加以区分。

Here are my points:
(1) Analysis focus on problem domain. So for an analyst, his task is to give out solution to resolve the problem. Normally, it can be achieved by usecase modelling.
(2) Architecture focus on solution domain. So for an architect, his task is to find an architecture to match the solution.
(3) In practice, these two roles will be acted by one person.
(4) For architecture, it is granular.
(5) The dynamic behavior of a system is the result of the architecture.

 回复: 再举一个例子,如城市规划
　

---

谢谢你如此详细的解答，看了各位的帖子，我现在对架构设计和系统分析的职责有个初步的概念了！
我刚买了本RUP的书，上面有不少对系统分析和架构设计的描述，希望对我的进一步理解能有所帮助！
今后如有不明白的地方，希望各位能多指点指点！

thank myrontan,I agree with you.In my point,the concept "problem domain " means "the functional problem domain",the concept "solution domain" means "the structure problem domain"。
谢谢myrontan，我完全同意你的观点，我理解的“问题域”是“功能性问题领域”的意思，“解决方案领域”就是“结构性问题领域”的意思。
我的基本观念是：一个系统的问题总可以分为两类，也就是结构性问题和功能性问题。
多指教。

 概念完整性和结构师
　

---

Brooks在《人月神化》20周年经典记念版的第19章提到：其软件开发过程的核心观点是－－概念完整性和结构师；委派一名产品结构师是最重要的行动。结构师负责产品所有方面的概念完整性，这些是用户能实际感受到的。结构师开发用于向用户解释使用的产品概念模型，概念模型包括所有功能的详细说明以及调用和控制的方法。结构师是这些模型的所有者，同时也是用户的代理。在不可避免地对功能、性能、规模、成本和进度进行平衡时，卓有成效地体现用户地利益。这个角色是全职工作。结构师就像电影导演，而经理人则类似于制片人。

 回复: j2ee,corba...
　

---

不太明白用CORBA怎么做架构，但是如果用建模的思想来实现架构，用模式来搭建系统，这样形成面向功能的系统框架，好像好理解一点。