在您的項目中，您是否直接與企業架構師合作？您是否收到企業架構師（EA）的文檔？企業架構師是否是項目設計和評估活動的瓶頸？你和我一樣，對企業架構師的角色有點困惑嗎？
一個小小的谷歌搜索將讓你確信EA是某種組織嚮導，他們可以看到所有並且知道所有。她是否住在一座塔樓裡並且像一個熟悉的人一樣養了一隻烏鴉。
定義很難得到。有很多，聽起來好像它們是由混淆機器生成的。但似乎有幾種不同的口味：
- IT-業務橋樑 - The Bridge負責瞭解當前的業務戰略並將其轉化為支持該戰略的IT項目。
- 集成大師 - 大師瞭解整個生態系統 - 應用程序，數據庫，服務 - 以及它們如何相互連接。她為IT項目團隊提供文檔和指導，以確保他們瞭解生態系統變化和約束的影響。
- 生態系統設計師 - 設計師是組織中的頂級技術分析師，負責制定項目團隊負責詳細設計和交付的系統設計決策。
- Enforcer - Enforcer為組織設置軟件標準，並確保所有項目團隊都接受有關這些標準的教育。
- 創新者 - 創新者的任務是展望行業趨勢和尖端技術，以確保她的組織具有競爭力。
當然，EA，如PM或PdM，不是一個可以輕鬆融入任何盒子的角色。 EA的作用部分取決於她所在的組織和她自己的專業領域。根據具體情況，她可以完成所有這些角色。我和同一家公司的不同EA合作過，這些公司採用了截然不同的方法。有些是“這裡是一個為您的技術設計提供信息的架構圖”。有些人“邀請我參加每次會議，讓我審查你們的所有要求”。當你搬到不同的項目或工作崗位時，這會讓你很難知道你應該期待什麼。
敏捷世界中的企業架構師
這種混亂在敏捷世界中更為明顯。我見過的大多數模型都說明了團隊的責任，他們非常重視EA的活動，將實際的軟件團隊顯示為EA團隊想象和設計的能力的提供者，有時將業務分析完全排除在外。這與Agile軟件開發的現實並沒有真正同步。那麼組織如何將EA集成到敏捷中呢？
我們對敏捷的關注主要集中在用戶故事上，這是一種提供軟件功能以提供業務價值的請求，通常範圍非常小。無論您是將用戶故事視為更大功能的細分還是作為獨立請求，都將重點放在用戶身上。但如果用戶故事是整個故事，那麼你就遇到了問題。可以一次建造一座樂高城堡一座塔，但是如果你沒有從足夠大的底板開始，你最終會把它拆掉並重新開始。
我向EA詢問了我是否曾在敏捷組織中就構建權進行了一些見解。他解釋了他與敏捷團隊合作的理想方式。我將把它作為我下一個項目的路線圖，以確保我有效地參與建築師團隊。
閱讀更多 智能時刻 的文章
