不知不覺也快要來到挑戰的尾聲，今天的分享有別於前幾周的內容，著重的點在於解決方案的scope與整體的架構面，並且再將idea轉換成可瀏覽的資訊(ex : 圖片或是文字)。
當需求清晰以及有明確開發的相關事項時，大致上會有兩種角度檢視接下來可以進行的方式，第一種是偏向技術面的實踐，例如當前可以使用什麼框架、資料庫、設計模式等等，其中也會涵蓋效能上的考量以及開發者的分工調配。
第二種相較第一種有一部分時間會貼近業務端，或者是與其他的部門協調和溝通，所以在考量解決方案的時候，除了技術如何實現之外，更多的是會依照當前公司的政策和發展走向，以及找出滿足系統的適合方案。
所以說這兩種的差異點在於第一種是特定領域的專家，第二種則是在有程式語言的基礎下，能夠跨部門溝通與做為純技術和高層主管的橋樑。
至於上述提的橋樑剛好有看到一個關於不同層面的架構師參考資訊的文章，裡面有提到關於架構面的技術職有分為三大類，分別為Enterprise Architect、Solution Architect、Technical Architect。
剛剛的兩種比較偏向於Solution Architect和Technical Architect，至於Enterprise Architect會比較像是在一間公司的高階主管，或者是在產業面很資深的顧問，也由於職等越高的情況下，對於技術面的衡量會比較是大方向的觀點，所以在細節上的實踐與評估就是剛剛提到的兩種角色一起合作(下圖為三種不同角色的座標軸參考)。
描述完不同層面的架構師後，接著焦點拉到設計架構圖的部分，通常整個解決方案因為涵蓋的層面較廣，所以就如文章開頭提到需要將idea轉換成可瀏覽的資訊，這個部分會介紹兩種類型工具，分別是GUI以及純寫程式的做法，而今天會介紹GUI可以參考的工具
首先介紹的Draw.io算是工作較常用到的工具然後有提供網頁和桌面版，並且也有Github repo可以檢視，接著我們可以到下載區選取對應系統的版本。
開啟之後會看到建立新的與匯入現有的選擇，這個部份選擇建立新的版本。
載入之後的畫面會看到不同種類的Template，這時候就可以依照當前需求選擇適合的流程圖或者是架構圖，然後舉例的部份我們來檢視Azure的多個架構服務。
載入之後可以看到範本會呈現在正中間，而左側可以加入各式各樣的物件，並且若需要進一步編輯屬性，在選取指定的物件後的右側導航欄調改。
如果想要使用UML設計使用者的操作流程，也可以先選取範本後再做進一步的修改。
最後設計完成之後匯出的格式有多個選擇可以使用。
除了剛剛提到的工具之外也可以參考例如Lucidchart、Microsoft Visio，總之市面上有非常多畫流程和架構圖的選擇，就依照各位的喜好和操作習慣來選擇囉!
iThome鐵人賽
看影片追技術