提几个关于archtect方面的问题，希望大家能一起探讨

panada

这几个问题是我以前从来没有想过的，但是在前几天的一次面试里面被提出来，我没有给出好的答案，所以想跟大家一起探讨一下：

1：作为一个架构师，通过什么样的途径学习的架构设计？
2：如果一个系统在上线的第一天，发现系统非常的慢，作为架构师的你，应该怎么做？
3：完成了用户需求后，你作为架构师，到客户那边，你所需要做的主要事情是什么？
4：在UML设计里面，你认为类图的设计最难和最关键的部分是什么？

wwwgjhxx.w5

我来尝试一下回答这些问题，
1：作为一个架构师，通过什么样的途径学习的架构设计？
==>大项目的实战经验。然后把你所曾经做的项目以及你的角色做一个比较简练、精准的描述。当然理论学习也不可少。 最好不要瞎吹牛。
2：如果一个系统在上线的第一天，发现系统非常的慢，作为架构师的你，应该怎么做？
==>这个问题有点TRICKY。作为洗个项目如果上线第一天就有大问题，首先说明项目的测试、管理是不很成功的。你应该主要阐述项目实施过程中的各种测试的重要性。
  其次上线过程安排可能有点问题，不要一次性就全上，可以一步一步进行割接；而不是赌博似的全部业务一起上，没有道理这样做，除非经过必要的、长时间的测试。
  然后，就是真的有问题，就具体问题具体分析，我做的都是数据库相关的应用，而且只是懂点ORACLE，所以，我就会从这个我个人的经验告诉你。
  首先查系统慢在哪里？
  应用的日志；
  数据库的AWR 或者 STATSPACK；检查V$SESSION_WAIT 看看发现什么特定的东西；
  OS： 文件系统是否有满了的？
       TOP/GLANCE 等看看TOP 的进程是什么？
       CPU/MEMORY/IO 哪个很忙？ 同时看能否找到相应的进程；然后就用GDP什么，PMAP等。。
  网络： 是不是网络堵塞严重呀？
  根据这些应该能找到问题的根本原因了。
3：完成了用户需求后，你作为架构师，到客户那边，你所需要做的主要事情是什么？
  ==>> 当然是把整理的需求跟客户以正式文件的方式确认，之前口头以会议的方式充分交流。要让客户真正理解你所收集的需求，而不是表面的理解。同事最后要求客户正式确认需求了。
4：在UML设计里面，你认为类图的设计最难和最关键的部分是什么？
==> UML 这个在很多很多年前用过，不过现在的工作不用这个想不来了，没有答案。。

额地神啊

我看很多solution archtect怎么都是presales的位置,
都是写tender,参加投标的.

righttang

那么专业的问题。。。
我上次去面，他们就问我，
1.如果你是主要设计，你会从哪几个方面入手开始设计。
2.你觉得你的工作重点是什么。。。

rationalrup

1：作为一个架构师，通过什么样的途径学习的架构设计？
There is no standard methodology for Architecture now, lots of theories are existing, and different customer has different ideas. But in general, architect is Technical authority of the project/solution; Establish and administrate the project process and procedures;Facilitate the team through the critical design decision process; And deliver a qualified solution. You need familiar with the techonologies and each part of the solution. So learning new tech yourself, learning from the past projects, learning from other successful architect, keeping an eye on the development for existing and new architecture frameworks, etc.
2：如果一个系统在上线的第一天，发现系统非常的慢，作为架构师的你，应该怎么做？
Agree with #2, normally as an architect, you need designed all test phases and test environments (especially, Press and volume test, Load test, Product verification test, etc) at the beginning of the project. If the problem really happen, first identify is software issue (solution arch need solve this) or hardware issue (infrastructure arch need fix this). If it's software, you need review the architecture solution to identied the bottleneck, try to solve it with less impact (cross my finger on you)
3：完成了用户需求后，你作为架构师，到客户那边，你所需要做的主要事情是什么？
For my view, you get agreed/signed requirement, then you can start following things: first is collecting the business processes (normaly business analysis will help you on this), second is starting conceptual architecture design. Sometimes, you also need involved in infrastructure arch work on the infrastructure side. As arch will be the tech authority of the project, you will need work with the PMO or the project manager to start Project Management Plan. For certain projects, gap analysis is also need conducted at the beginning of the project.
4：在UML设计里面，你认为类图的设计最难和最关键的部分是什么？
UML Class diagram is mainly used in detail design. As an arch, you are not involved too much in detail design. Your work should focused on high level design. You will need use Class Diagram to represent some high level classes. The difficuty is how to get these abstract/high level/key classes, and their relationships, which laye, which application they will be, how they talk to each others, etc..

panada

原帖由 rationalrup 于 2009-11-13 14:50 发表
1：作为一个架构师，通过什么样的途径学习的架构设计？
There is no standard methodology for Architecture now, lots of theories are existing, and different customer has different ideas. But in general, a ...

谢谢楼上的高人专门注册马甲来讨论问题。

panada

增加多一个问题：从你自己的理解，什么是软件架构，什么是软件架构师的职责。

rationalrup

This is my real id, not pseudo one. I just hate to type, so still bare feet.
Software architecture is still a pretty new thing, from my point, it has evolved from the system analyst. Analyst is more focused on the system/application, arch is more high level, broader view, and more involved with business prospect, how the solution fit in the business/enterprise context, how it fit/improve the business process. Normally arch will take all the technical responsiblity of the team, how to successfully deliver a qualified solution on time on budget (PM need pay more attention of the finance, but arch also need know it), how to build, mentor, guilde the whole team. It's not only about technical, also people management, knowledge management, communication, customer relationship, change management, risk management. You will be the bridge between the team and customer. You know the customer requirement, and let customer know what you will give them, how it will satisfy with their requirement, guilde the team to deliver what customer want, and finally deliver what you said to them.

benben

论坛上又出了一个牛人。我这就去搬凳子。

panada

软件架构
　　软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口_(计算机科学)来实现。
　　软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。
　　软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。
　　在“软件构架简介”中，David GArlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。”
　　但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。
　　在 Rational Unified ProcESs 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
　　从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。
　　是一般而言，软件系统的架构（ArchitECture）有两个要素：
　　·它是一个软件系统从整体到部分的最高层次的划分。
　　一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。
　　详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（TASk-flow）。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。
　　·建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。
　　在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。
　　历史早在1960年代，诸如E·W·戴克斯特拉就已经涉及软件架构这个概念了。自1990年代以来，部分由于在 Rational Software Corporation 和MiCROSoft内部的相关活动，软件架构这个概念开始越来越流行起来。
　　卡内基梅隆大学和加州大学埃尔文分校在这个领域作了很多研究。卡内基·梅隆大学的Mary Shaw和David Garlan于1996年写了一本叫做 Software Architecture perspective on an emerging DIscipline的书，提出了软件架构中的很多概念，例如软件组件、连接器、风格等等。加州大学埃尔文分校的软件研究院所做的工作则主要集中于架构风格、架构描述语言以及动态架构。
　　计算机软件的历史开始于五十年代，历史非常短暂，而相比之下建筑工程则从石器时代就开始了，人类在几千年的建筑设计实践中积累了大量的经验和教训。建筑设计基本上包含两点，一是建筑风格，二是建筑模式。独特的建筑风格和恰当选择的建筑模式，可以使一个独一无二。
　　软件与人类的关系是架构师必须面对的核心问题，也是自从软件进入历史舞台之后就出现的问题。与此类似地，自从有了建筑以来，建筑与人类的关系就一直是建筑设计师必须面对的核心问题。英国首相丘吉尔说，我们构造建筑物，然后建筑物构造我们（We shape our buildings, and afterwaRDS our buildings shape us）。英国下议院的会议厅较狭窄，无法使所有的下议院议员面向同一个方向入座，而必须分成两侧入座。丘吉尔认为，议员们入座的时候自然会选择与自己政见相同的人同时入座，而这就是英国政党制的起源。Party这个词的原意就是"方"、"面"。政党起源的关键就是建筑物对人的影响。
　　在软件设计界曾经有很多人认为功能是最为重要的，形式必须服从功能。与此类似地，在建筑学界，现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能（FORMs follows function）。
　　几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。最为著名的，当然就是模式理论和XP理论。
　　架构的目标是什么
　　正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：
　　·可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。
　　·安全行（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。
　　·可扩展性（SCAlable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。
　　·可定制化（CuSTomizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。
　　·可扩展性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展
　　·可维护性（MAIntainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费
　　·客户体验（Customer Experience）。软件系统必须易于使用。
　　·市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。
　　架构的种类
　　根据我们关注的角度不同，可以将架构分成三种：
　　·逻辑架构、软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。
　　比如下面就是笔者亲身经历过的一个软件系统的逻辑架构图
　　图2、一个逻辑架构的例子
　　从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。每一个层次都含有多个逻辑元件。比如WEB服务器层次中有HTML服务元件、Session服务元件、安全服务元件、系统管理元件等。
　　·物理架构、软件元件是怎样放到硬件上的。
　　比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。
　　图3、一个物理架构的例子
　　·系统架构、系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。
　　系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。
　　此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。
　　首先，一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。
　　其次，进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。
　　根据作者的经验，一个基于数据库的系统架构，有多少个数据表，就会有多少页的架构设计文档。比如一个中等的数据库应用系统通常含有一百个左右的数据表，这样的一个系统设计通常需要有一百页左右的架构设计文档。
　　构架描述
　　为了讨论和分析软件构架，必须首先定义构架表示方式，即描述构架重要方面的方式。在 Rational Unified Process 中，软件构架文档记录有这种描述。
　　构架视图
　　我们决定以多种构架视图来表示软件构架。每种构架视图针对于开发流程中的涉众（例如最终用户、设计人员、管理人员、系统工程师、维护人员等）所关注的特定方面。
　　构架视图显示了软件构架如何分解为构件，以及构件如何由连接器连接来产生有用的形式 [PW92]，由此记录主要的结构设计决策。这些设计决策必须基于需求以及功能、补充和其他方面的约束。而这些决策又会在较低层次上为需求和将来的设计决策施加进一步的约束。
　　典型的构架视图集
　　构架由许多不同的构架视图来表示，这些视图本质上是以图形方式来摘要说明“在构架方面具有重要意义”的模型元素。在 Rational Unified Process 中，您将从一个典型的视图集开始，该视图集称为“4+1 视图模型”[KRU95]。它包括：
　　用例视图：包括用例和场景，这些用例和场景包括在构架方面具有重要意义的行为、类或技术风险。它是用例模型的子集。逻辑视图：包括最重要的设计类、从这些设计类到包和子系统的组织形式，以及从这些包和子系统到层的组织形式。它还包括一些用例实现。它是设计模型的子集。实施视图：包括实施模型及其从模块到包和层的组织形式的概览。同时还描述了将逻辑视图中的包和类向实施视图中的包和模块分配的情况。它是实施模型的子集。进程视图：包括所涉及任务（进程和线程）的描述，它们的交互和配置，以及将设计对象和类向任务的分配情况。只有在系统具有很高程度的并行时，才需要该视图。在 Rational Unified Process 中，它是设计模型的子集。配置视图：包括对最典型的平台配置的各种物理节点的描述以及将任务（来自进程视图）向物理节点分配的情况。只有在分布式系统中才需要该视图。它是部署模型的一个子集。构架视图记录在软件构架文档中。您可以构建其他视图来表达需要特别关注的不同方面：用户界面视图、安全视图、数据视图等等。对于简单系统，可以省略 4+1 视图模型中的一些视图。
　　构架重点
　　虽然以上视图可以表示系统的整体设计，但构架只同以下几个具体方面相关：
　　模型的结构，即组织模式，例如分层。基本元素，即关键用例、主类、常用机制等，它们与模型中的各元素相对。几个关键场景，它们表示了整个系统的主要控制流程。记录模块度、可选特征、产品线状况的服务。
　　构架视图在本质上是整体设计的抽象或简化，它们通过舍弃具体细节来突出重要的特征。在考虑以下方面时，这些特征非常重要：
　　系统演进，即进入下一个开发周期。在产品线环境下复用构架或构架的一部分。评估补充质量，例如性能、可用性、可移植性和安全性。向团队或分包商分配开发工作。决定是否包括市售构件。插入范围更广的系统。
　　构架模式
　　构架模式是解决复发构架问题的现成形式。构架框架或构架基础设施（中间件）是可以在其上构建某种构架的构件集。许多主要的构架困难应在框架或基础设施中进行解决，而且通常针对于特定的领域：命令和控制、MIS、控制系统等等。
　　构架模式示例
　　[BUS96] 根据构架模式最适用的系统的特征将其分类，其中一个类别处理更普遍的结构问题。下表显示了 [BUS96] 中所提供的类别和这些类别所包含的模式。
　　类别 模式结构 层管道和过滤器黑板分布式系统 代理交互系统 模型-视图-控制器表示-抽象-控制自适应系统 反射微核
　　软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。
　　在“软件构架简介”中，David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。”[GS93]
　　但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”[IEEE98]。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。
　　在 Rational Unified Process 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
　　为阐明其含义，下面将详述其中的两个；完整说明请参见 [BUS96]。模式以下列广泛使用的形式来表示：
　　模式名环境问题影响，描述应考虑的不同问题方面解决方案基本原理结果环境示例模式名层
　　环境需要进行结构分解的大系统。
　　问题必须处理不同抽象层次的问题的系统。例如：硬件控制问题、常见服务问题和针对于不同领域的问题。最好不要编写垂直构件来处理所有抽象层次的问题。否则要在不同的构件中多次处理相同的问题（可能会不一致）。
　　影响
　　系统的某些部分应当是可替换的构件中的变化不应波动相似的责任应归为一组构件大小 -- 复杂构件可能要进行分解解决办法将系统分成构件组，并使构件组形成层叠结构。使上层只使用下层（决不使用上层）提供的服务。尽量不使用非紧邻下层提供的服务（不跳层使用服务，除非中间层只添加通过构件）。
　　示例：
　　1. 通用层
　　严格的分层构架规定设计元素（类、构件、包、子系统）只能使用下层提供的服务， 服务可以包括事件处理、错误处理、数据库访问等等。 相对于记录在底层的原始操作系统级调用，它包括更明显的机制。
　　2. 业务系统层
　　上图显示了另一个分层示例，其中有垂直特定应用层、水平层和基础设施层。注意：此处的目标是采用非常短的业务“烟囱”并实现各种应用程序间的通用性。 否则，就可能有多个人解决同一问题，从而导致潜在的分歧。
　　有关该模式的深入讨论，请参见指南：分层。
　　模式名黑板
　　环境没有解决问题的确定方法（算法）或方法不可行的领域。例如 AI 系统、语音识别和监视系统。
　　问题多个问题解决顾问（知识顾问）必须通过协作来解决他们无法单独解决的问题。各顾问的工作结果必须可以供所有其他顾问访问，使他们可以评估自己是否可以参与解决方案的查找并发布其工作结果。
　　影响
　　知识顾问参与解决问题的顺序不是确定的，这可能取决于问题解决策略
　　不同顾问的输入（结果或部分解决方案）可能有不同的表示方式
　　各顾问并不直接知道对方的存在，但可以评估对方发布的工作
　　解决办法多名知识顾问都可访问一个称为“黑板”的共享数据库。黑板提供监测和更新其内容的接口。控制模块/对象激活遵循某种策略的顾问。激活后，顾问查看黑板，以确定它是否能参与解决问题。如果顾问决定它可以参与，控制对象就可以允许顾问将其部分（或最终）解决方案放置于黑板上。
　　示例：
　　以上显示了使用 UML 建模的结构或静态视图。 它将成为参数化协作的一部分，然后会绑定到实参上对模式进行实例化。
　　构架风格软件构架（或仅是构架视图）可以具有名为构架风格的属性，该属性减少了可选的形式，并使构架具有一定程度的一致性。样式可以通过一组模式或通过选择特定构件或连接器作为基本构件来定义。对给定系统，某些样式可作为构架描述的一部分记录在构架风格指南（Rational Unified Process 中设计指南文档的一部分）中。样式在构架的可理解性与完整性方面起着主要的作用。
　　构架设计图构架视图的图形描述称为构架设计图。对于以上描述的各种视图，设计图由以下统一建模语言图组成 [UML99]：
　　逻辑视图：类图、状态机和对象图。进程视图：类图与对象图（包括任务 - 进程与线程）。实施视图：构件图。部署视图：配置图。用例视图：用例图描述用例、主角和普通设计类；顺序图描述设计对象及其协作关系。构架设计流程在 Rational Unified Process 中，构架主要是分析设计工作流程的结果。当项目再次进行此工作流程时，构架将在一次又一次迭代中不断演化、改进、精炼。由于每次迭代都包括集成和测试，所以在交付产品时，构架就相当强壮了。构架是精化阶段各次迭代的重点，构架的基线通常会在此阶段结束时确定。
　　架构师
　　软体设计师中有一些技术水平较高、经验较为丰富的人，他们需要承担软件系统的架构设计，也就是需要设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定的作出。
　　这样的人就是所谓的架构师（Architect）。在很多公司中，架构师不是一个专门的和正式的职务。通常在一个开发小组中，最有经验的程序员会负责一些架构方面的工作。在一个部门中，最有经验的项目经理会负责一些架构方面的工作。
　　但是，越来越多的公司体认到架构工作的重要性，并且在不同的组织层次上设置专门的架构师位置，由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。

panada

职业名称】
　　软件架构师——（Software Architec）
[编辑本段]
【职业定位】
　　软件架构师是软件行业中一种新兴职业，工作职责是在一个软件项目开发过程中，将客户的需求转换为规范的开发计划及文本，并制定这个项目的总体架构，指导整个开发团队完成这个计划。主导系统全局分析设计和实施、负责软件构架和关键技术决策的人员
[编辑本段]
【能力要求】
　　在技术全面、成熟练达、洞察力强、经验丰富，具备在缺乏完整信息、众多问题交织一团、模糊和矛盾的情况下，软件架构师能迅速抓住问题要害，并做出合理的关键决定的能力 l、具备战略性和前瞻性思维能力，善于把握全局，能够在更高抽象级别上进行思考； 主要包括如下：
　　1、对项目开发涉及的所有问题领域都有经验，包括彻底地理解项目需求，开展分析设计之类软件工程活动等
　　2、具备领导素质，以在各小组之间推进技术工作，并在项目压力下做出牢靠的关键决策
　　3、拥有优秀的沟通能力，用以进行说服、鼓励和指导等活动，并赢得项目成员的信任；
　　4、以目标导向和主动的方式来不带任何感情色彩地关注项目结果，构架师应当是项目背后的技术推动力，而非构想者或梦想家（追求完美）
　　5、精通构架设计的理论、实践和工具，并掌握多种参考构架、主要的可重用构架机制和模式（例如J2EE架构等）；
　　6、具备系统设计员的所有技能，但涉及面更广、抽象级别更高；活动确定用例或需求的优先级、进行构架分析、创建构架的概念验证原型、评估构架的概念验证原型的可行性、组织系统实施模型、描述系统分布结构、描述运行时刻构架、确定设计机制、确定设计元素、合并已有设计元素、构架文档、参考构架、分析模型、设计模型、实施模型、部署模型、构架概念验证原型、接口、事件、信号与协议等。
[编辑本段]
【主要工作任务】
　　架构师的主要任务不是从事具体的软件程序的编写，而是从事更高层次的开发构架工作。他必须对开发技术非常了解，并且需要有良好的组织管理能力。可以这样说，一个架构师工作的好坏决定了整个软件开发项目的成败。
　　l、领导与协调整个项目中的技术活动（分析、设计和实施等）
　　2、推动主要的技术决策，并最终表达为软件构架
　　3、确定和文档化系统的相对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”
　　4、确定设计元素的分组以及这些主要分组之间的接口
　　5、为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效的传达和贯彻
　　6、理解、评价并接收系统需求 7、评价和确认软件架构的实现 专业技能

grylli

天哪，原来这就是architect, 这么复杂， 要好好理解，再翻译成英文和老外说，还真不容易。 看来我的architect 路漫漫无止境了

grylli

在国内做了很多年的architect, 从来没有考虑过这些问题，看得都闷住了

DBOY123

Architec 很大程度要去MARKETING 的， 才能提到那个位置，就是会多

panada

我就是被国内的一个面试电话给郁闷了好多天。

Wangmingtaoau

一位architect路过

额地神啊

原帖由 benben 于 2009-11-13 15:27 发表
论坛上又出了一个牛人。我这就去搬凳子。

快,快,帮我也搬一个.

greanbean

刚刚看到SEEK上贴了个IBM SA的广告
要胜任，不但要有行业和领域经验，过硬的技术，还要懂管理，政策，资源
这样的职位快赶上一个高级经理了，不是一般人能做的 。
从SD到SA看来还有很长一段路要走
过来人分享一下经验和心得吧

To succeed in the role you will have:

• Considerable experience with the energy utility industry (electricity/gas distribution or transmission), typically gained through employment with a utility and/or several years of consulting, software or others services to the industry.
• In-depth expertise in the application of one or more smart grid or smart meter subject areas (e.g. network automation, wide area communications, network planning and analytics, SCADA/DMS, work and asset management, advanced metering).
• Specific systems architecture qualifications and/or several years experience in advanced architecture development. Detailed knowledge of service oriented architecture techniques.
• In depth understanding of Utilities Business Processes
• Expertise in developing interfaces definitions between upstream & downstream systems
• System Development Lifecycle experience
• Proven experience in understanding and managing resources, priorities, business objectives and policies
• A demonstrated ability to remain at the leading edge of utility and technology advancements

panada

我想可能有两个不同的概念要区分开来，一个是软件架构师，一个是系统架构师。具体的还是要请高人来解说一下。

[ 本帖最后由 panada 于 2009-11-18 13:28 编辑 ]

greanbean

楼上的，你说的是TA和SA的区别吧
我觉得这两篇文章说的还是很清楚的
http://en.wikipedia.org/wiki/Technical_architecture
http://en.wikipedia.org/wiki/Solution_architecture

rationalrup

TOGAF have four views of the framework. Business (covered by Information Arch), Data, Application (covered by solution arch and data arch), and Technology (covered by Infrastructure arch)

Melbourner1978

其实这年头鱼龙混杂，什么水平的SA都有，我看来好的SA应该比senior manager要牛，因为senior manager懂的SA都要懂。

panada

帮主你也是在搞websphere 吗？

Melbourner1978

啥都玩过点，websphere，weblogic，tibco，啥都不精

flyspirit

原帖由 Melbourner1978 于 2009-11-18 14:35 发表
啥都玩过点，websphere，weblogic，tibco，啥都不精

架构师就是要啥都懂点，啥都不精的

greanbean

原帖由 Melbourner1978 于 2009-11-18 14:25 发表
其实这年头鱼龙混杂，什么水平的SA都有，我看来好的SA应该比senior manager要牛，因为senior manager懂的SA都要懂。

这个是实话
SA也是良莠不齐，和公司，项目有很大关系。就比如consultant，现在已经被叫烂了。大家现在几乎都称自己是consultant了
如果能接触几个好的SA,少给点工资都合算，就当交学费了。
曾经接触过的比较好的SA,给人的最深印象就是，再复杂的问题也能分析的很简单和有逻辑性，基本大家都能明白，也清楚下一本怎么做。

panada

原帖由 greanbean 于 2009-11-18 15:26 发表


这个是实话
SA也是良莠不齐，和公司，项目有很大关系。就比如consultant，现在已经被叫烂了。大家现在几乎都称自己是consultant了
如果能接触几个好的SA,少给点工资都合算，就当交学费了。
曾经接 ...

我曾经碰到过一个算是我们公司架构师的人，正好相反，再简单的问题也能复杂化到让人晕头转向，这才是高人啊。

Melbourner1978

原帖由 greanbean 于 2009-11-18 15:26 发表


这个是实话
SA也是良莠不齐，和公司，项目有很大关系。就比如consultant，现在已经被叫烂了。大家现在几乎都称自己是consultant了
如果能接触几个好的SA,少给点工资都合算，就当交学费了。
曾经接 ...

见过这么多SA，只有我之前项目的老大是最牛比的了，有技术，有管理，跟客户讨论solution，基本上客户都被他欠着鼻子走，多么复杂的业务逻辑到他手里直接就变成excel的MACRO，系统出了问题，直接上去SQL调优

drin

... i thought you guys were talking about architect - architectural architect that designs building.

greanbean

原帖由 panada 于 2009-11-18 15:28 发表


我曾经碰到过一个算是我们公司架构师的人，正好相反，再简单的问题也能复杂化到让人晕头转向，这才是高人啊。

这种人自尊心很强，不喜欢别人挑战他的权威，所以就抛一大堆的专业术语和理论。你具体问，他还会很不耐烦，其实他自己也许就不是很懂，所以也解释不清楚到令人信服的程度。
俺讨论问题，就喜欢刨根问底。一般碰到这样的，都躲的远远的。