系統分析員屬於Analyst角色組合，與其相比，架構師則是屬於Developer 角色組裏的一個角色，一個非常重要的角色。
架構師的職責及工作描述
The software architectrole is responsible for the software architecture, which includes the keytechnical decisions that constrain the overall design and implementation for theproject.
負責在整個項目中對技術活動和工件進行領導和協調。構架設計師要確立每個構架視圖的整體結構：視圖的詳細組織結構、元素的分組以及這些主要分組之間的接口。因此，與其他角色相比，構架設計師的見解重在廣度，而不是深度。
架構師負責理解系統的業務需求，並創建合理、完善的系統體系架構。架構師也負責通過軟件架構來決定主要的技術選擇。這典型的包括識別和文檔化系統的重要架構方面，包括系統的需求、設計、實現和部署"視圖"。
The software architect has overallresponsibility for driving the major technical decisions, expressed as thesoftware architecture. This typically includes identifying and documenting thearchitecturally significant aspects of the system, including requirements,design,
implementation, and deployment "views" of the system.
The architect is also responsible for providing rationale for these decisions,balancing the concerns of the various stakeholders,
：注 :這就是說架構師要在大家意見不統一的時候給出一個基本的並且這些人都比較能接受的基本意見，這就是要求架構師要有一定的判斷力和決定能力以及體現核心作用、核心力量和支柱的這樣一種領導力。
driving down technical risks, and ensuring that decisions are effectivelycommunicated, validated, and adhered to.
：注： 架構師一定要具備降低風險（當然主要是技術方面）的能力，以及他的這種架構思想切實得到貫徹和落實的能力。
建模軟件應用和方案，並創建和管理可重用的模式和模型；維護在我們的軟件系統中的系統組件和他們的接口。
建模信息架構，創建和維護組織技術設施的佈局，並提供滿足業務需求的技術觀點和遠景。
架構師的技能要求和能力素養
In summary, the software architect must be well-rounded, possesmaturity, vision, and a depth of experience that allows for grasping issuesquickly and making educated, critical judgment in
the absence of completeinformation. More specifically, the software architect, or members of thearchitecture team, must combine these skills:
構架設計師必須多才多藝、成熟練達、洞察力強、經驗豐富。這樣，他才能在無法獲得完整信息的情況下迅速領會問題並根據經驗作出審慎的判斷。更準確地說，構架設計師（或者構架團隊的成員）必須兼具以下技能：
Experience in both the problem domain, through a thoroughunderstanding of the requirements, and the software engineering domain. Ifthere is a team, these qualities can be spread across the team members, but atleast one software architect must provide the global vision for the project.·
經驗：既包括在問題領域的經驗（通過徹底瞭解需求），也包括在軟件工程領域的經驗。對於一個構架團隊，這些素質要求可由各團隊成員來分別承擔，但其中至少要有一名構架設計師能夠把握項目的全局。
Leadership in order to drive the technical effort across thevarious teams, and to make critical decisions under pressure and make thosedecisions stick. To be effective, the software architect and the projectmanager must work closely together, with the software architect leading thetechnical issues and the project manager leading the administrative issues. Thesoftware architect must have the authority to make technical decisions.·
領導才能：能夠推動各個團隊的技術進展，並能在壓力下作出關鍵性的決策然後將其貫徹到底。要提高效率，構架設計師和項目經理必須緊密協作。構架設計師主要負責解決技術問題，項目經理主要負責解決行政管理問題。構架設計師必須有權在技術問題上作出決定。
Communication to earn trust, to persuade, to motivate, and tomentor. The software architect cannot lead by decree, only by the consent ofthe rest of the project. In order to be effective, the software architect mustearn the respect of the project team, the project manager, the customer, andthe user community, as well as the management team.·
溝通：能夠贏得他人的信任，以對其進行說服、激勵和指導。構架設計師不能靠命令進行領導，而必須要贏得項目中其他人員的贊同。爲了提高效率，構架設計師必須贏得項目團隊、項目經理、客戶、用戶羣體以及管理團隊的尊敬。
Goal-orientation and Pro-activity with a relentless focus onresults. The software architect is the technical driving force behind theproject, not a visionary or dreamer. The career of a successful softwarearchitect is a long series of sub-optimal decisions made in uncertainty andunder pressure. Only those who can focus on doing what needs to be done will besuccessful in this environment of the project.·
以目標爲中心、積極主動，不懈地追求成效。構架設計師是推動項目發展的技術動力，而不是空想家。在其職業生涯中，成功的構架設計師一直都要在捉摸不定和承受壓力的情況下作出折衷決定。構架設計師只有將注意力集中在該做的事情上，才能在項目中取得成功。
從專業角度看，構架設計師必須具備系統設計員（designer）的所有能力。但是：
However, unlike the designer, the software architect:tends to be a generalist rather than a specialist, knowing many technologies ata high level rather than a few technologies at the detail level makes broader technical
decisions, and therefore broad knowlege and experience,as well as communication and leadership skills, are key.
注 : 此處兩點，一語道破架構師和設計師的本職區別。請認真體會，側重點是不同的。
架構師應該能 夠： 理解企業應用的體系結構，能夠對分佈式企業應用系統體系結構、面向服務的應用系統體系結構的設計要點給出指導性建議的。
團隊裏架構師配備的方法和指導原則
If the project is large enough to warrant an architecture team, the goal is tohave a good mix of talents, covering a wide spectrum of experience and sharinga common understanding of software engineering process. The architecture
teamneed not be a committee of representatives from various teams, domains orcontractors. Software architecture is a full-time function, with staffpermanently dedicated to it.
如果項目較大，需要組建一個構架團隊，則應儘量廣聚賢才，使該團隊既擁有廣泛的經驗，又對軟件工程流程具有一致的認識。構架團隊不應該是由各團隊、領域或承包商的代表組成的委員會。軟件構架設計是一項長期的工作，始終都需要配備專職人員。
For smaller projects, a single person may act as both project manager andsoftware architect. However, if at all possible, it is better to have theseroles performed by separate people, in order to ensure that time pressure
onone role doesn't cause the other role to be neglected.
注 : 小型項目架構師可以兼做項目經理。但是不要因爲時間安排問題導致兩種角色互有影響。架構師需要對此有很好的調節能力和全局安排、協調處理、解決能力。
軟件架構模型（4+1）
架構模型
軟件架構用來處理軟件高 層次結構的設計和實施。它以精心選擇的形式將若干結構元素進行裝配，從而滿足系統主要功能和性能需求，並滿足其他非功能性需求，如可靠性、可伸縮性、可移 植性和可用性。Perry 和 Wolfe 使用一個精確的公式來表達，該公式由 Boehm 做了進一步修改：
軟件架構 ＝
軟件架構涉及到抽象、分解和組合、風格和美學。我們用由多個視圖或視角組成的模型來描述它。爲了最終處理大型的、富有挑戰性的架構，該模型包含五個主要的視圖（請對照圖 1）：
邏輯視圖（Logical View），設計的對象模型（使用面向對象的設計方法時）。
過程視圖（Process View），捕捉設計的併發和同步特徵。
物理視圖（Physical View），描述了軟件到硬件的映射，反映了分佈式特性。
開發視圖（Development View），描述了在開發環境中軟件的靜態組織結構。
架構的描述，即所做的各種決定，可以圍繞着這四個視圖來組織，然後由一些用例 （use cases）或場景(scenarios)來說明，從而形成了第五個視圖。正如將看到的，實際上軟件架構部分從這些場景演進而來，將在下文中討論。
圖 1 － "4＋1"視圖模型
注： 請特別留意這四個view的各自主要使用對象。比如Development View，主要是programmers 看到的系統架構圖。
我 們在每個視圖上均獨立地應用 Perry & Wolf 的公式，即定義一個所使用的元素集合（組件、容器、連接符），捕獲工作形式和模式，並且捕獲關係及約束，將架構與某些需求連接起來。每種視圖使用自身所特 有的表示法－藍圖（blueprint）來描述，並且架構師可以對每種視圖選用特定的架構風格（architectural style），從而允許系統中多種風格並存。
我們將輪流的觀察這五種視圖，展現各個視圖的目標：即視圖的所關注 的問題，相應的架構藍圖的標記方式，描述和管理藍圖的工具。並以非常簡單的形式。"4+1"視圖模型具有相當的"普遍性"，因此可以使用其他的標註方法和工具，也可以採用其他的設計方法，特別是對於邏輯和過程的分解。但文中指出的這些方法都已經成功的在實踐中運用過。
邏輯結構——面向對象的分解
邏 輯架構主要支持功能性需求――即在爲用戶提供服務方面系統所應該提供的功能。系統分解爲一系列的關鍵抽象，（大多數）來自於問題域，表現爲對象或對象類的 形式。它們採用抽象、封裝和繼承的原理。分解並不僅僅是爲了功能分析，而且用來識別遍佈系統各個部分的通用機制和設計元素。
進程架構——過程分解
進程架構考慮一些非功能性的需求，如性能和可用性。它解決併發性、分佈性、系統完整性、容錯性的問題，以及邏輯視圖的主要抽象如何與進程結構相配合在一起－即在哪個控制線程上，對象的操作被實際執行。
進程架構可以在幾種層次的抽象上進行描述，每個層次針對不同的問題。在最高的層次上，進程架構可以視爲一組獨立執行的通信程序（叫作 "processes"）的邏輯網絡，它們分佈在整個一組硬件資源上，這些資源通過 LAN 或者 WAN 連接起來。多個邏輯網絡可能同時並存，共享相同的物理資源。例如，獨立的邏輯網絡可能用於支持離線系統與在線系統的分離，或者支持軟件的模擬版本和測試版 本的共存。
進程是構成可執行單元任務的分組。進程代表了可以進行策略控制過程架構的層次（即：開始、恢復、重新配置及關閉）。另外，進程可以就處理負載的分佈式增強或可用性的提高而不斷地被重複。
軟件被劃分爲一系列單獨的任務。任務是獨立的控制線程，可以在處理節點上單獨地被調度。
開發架構——子系統分解
開發架構關注軟件開發環境下實際模塊的組織。軟件打包成小的程序塊（程序庫或子系統），它們可以由一位或幾位開發人員來開發。子系統可以組織成分層結構，每個層爲上一層提供良好定義的接口。
系統的開發架構用模塊和子系統圖來表達，顯示了"輸出"和"輸入"關係。完整的開發架構只有當所有軟件元素被識別後才能加以描述。但是，可以列出控制開發架構的規則：分塊、分組和可見性。
大部分情況下，開發架構考慮的內部需求與以下幾項因素有關：開發難度、軟件管理、重用性和通用性及由工具集、編程語言所帶來的限制。開發架構視圖是各種活 動的基礎，如：需求分配、團隊工作的分配（或團隊機構）、成本評估和計劃、項目進度的監控、軟件重用性、移植性和安全性。它是建立產品線的基礎。
物理架構——軟件至硬件的映射
物 理架構主要關注系統非功能性的需求，如可用性、可靠性（容錯性），性能（吞吐量）和可伸縮性。軟件在計算機網絡或處理節點上運行，被識別的各種元素（網 絡、過程、任務和對象），需要被映射至不同的節點；我們希望使用不同的物理配置：一些用於開發和測試，另外一些則用於不同地點和不同客戶的部署。因此軟件 至節點的映射需要高度的靈活性及對源代碼產生最小的影響。
場景——綜合所有的視圖
四種視圖的元素通過數量比較少的一組重要場景（更常見的是用例）進行無縫協同工作，我們爲場景描述相應的腳本（對象之間和過程之間的交互序列）。
在某種意義上場景是最重要的需求抽象，它們的設計使用對象場景圖和對象交互圖來表示。
該視圖是其他視圖的冗餘（因此"＋1"），但它起到了兩個作用：
作爲一項驅動因素來發現架構設計過程中的架構元素，這一點將在下文中討論。
作爲架構設計結束後的一項驗證和說明功能，既以視圖的角度來說明又作爲架構原型測試的出發點。
視圖之間的對應性 各種視圖並不是完全是正交的或獨立的。視圖的元素根據某種設計規則和啓發式方法與其他視圖中的元素相關聯。
模型的剪裁
並不是所有的軟件架構都需要"4＋1"視圖。無用的視圖可以從架構描述中省略，比如： 只有一個處理器，則可以省略物理視圖；而如果僅有一個進程或程序，則可以省略過程視圖。 對於非常小型的系統，甚至可能邏輯視圖與開發視圖非常相似，而不需要分開的描述。場景對於所有的情況均適用。
迭代過程
Witt 等人爲設計和架構指出了 4 個階段：勾畫草圖、組織、具體化和優化，分成了 12 個 步驟7。他們還指出需要某種程度的反向工程。而我們認爲對於大型的項目，該方法太"線性 化"了。在 4 個階段的末尾，可用於驗證架構的內容太少。我們提倡一種更具有迭代性質的方法，即架構先被原形化、測試、估量、分析，然後在一系列的迭代過程中被細化。該 方法除了減少與架構相關的風險之外，對於項目而言還有其他優點：團隊合作、培訓，加深對架構的理解，深入程序和工具等等（此處提及的是演進的原形，逐漸發 展成爲系統，而不是一次性的試驗性的原形）。這種迭代方法還能夠使需求被細化、成熟化並能夠被更好地理解。
場景驅動（scenario-driven）的方法
系統大多數關鍵的功能以場景（或 use cases）的形式被捕獲。關鍵意味着：最重要的功能，系統存在的理由，或使用頻率最高的功能，或體現了必須減輕的一些重要的技術風險。
開始階段:
基於風險和重要性爲某次迭代選擇一些場景。場景可能被歸納爲對若干用戶需求的抽象。
形成"稻草人式的架構"。然後對場景進行"描述"，以識別主要的抽象（類、機制、過程、子系統），如 Rubin 與 Goldberg6 所指出的 ―― 分解成爲序列對（對象、操作）。
所發現的架構元素被分佈到 4 個藍圖中：邏輯藍圖、進程藍圖、開發藍圖和物理藍圖。
然後實施、測試、度量該架構，這項分析可能檢測到一些缺點或潛在的增強要求。
捕獲經驗教訓。
循環階段:
下一個迭代過程開始進行：
重新評估風險，
擴展考慮的場景選擇板。
選擇能減輕風險或提高結構覆蓋的額外的少量場景，
然後:
試着在原先的架構中描述這些場景。
發現額外的架構元素，或有時還需要找出適應這些場景所需的重要架構變更。
更新4個主要視圖：邏輯視圖、進程視圖、開發視圖和物理視圖。
根據變更修訂現有的場景。
升級實現工具（架構原型）來支持新的、擴展了的場景集合。
測試。如果可能的話，在實際的目標環境和負載下進行測試。
然後評審這五個視圖來檢測簡潔性、可重用性和通用性的潛在問題。
更新設計準則和基本原理。
捕獲經驗教訓。
終止循環
爲了實際的系統，初始的架構原型需要進行演進 。較好的情況是在經過 2 次或 3 次迭代之後，結構變得穩定：主要的抽象都已被找到。子系統和過程都已經完成，以及所有的接口都已經實現。
接下來則是軟件設計的範疇，這個階段可能也會用到相似的方法和過程。
注：請注意區分架構設計和軟件設計在過程當中的先後次序關係。
4+1視圖允許不同的"風險承擔人"找出他們就軟件架構所關心的問題。系統工程師首先接觸物理視圖，然後轉向進程視圖；最終用戶、顧客、數據分析專家從邏輯視圖入手；項目經理、軟件配置人員則從開發視圖來看待"4＋1"視圖。