碁峰資訊出版

架構師扮演著連結與轉譯的關鍵角色,特別是在一個各部門講著不同語言、有不同的觀點,甚至是往不同目標努力的大型組織中,架構師尤為重要。許多管理層級只會透過電話往上或向下溝通,無疑加劇了公司層級間的隔閤。最糟的情況是掌握資訊或專業的人沒辦法被賦予做決策的權限,而有權做決策的人卻無法掌握相關資訊。這對企業的IT部門而言,並不是好事,特別是科技已成為大多數企業重要驅動力之一的現今。

架構師升降梯

架構師能填補大型企業裡的這個重要間隙:他們密切地與負責專案的技術人員合作與溝通,也能將技術議題傳達給上層的管理圈,而不漏失訊息的本質。從相反的方向來看也一樣,他們瞭解公司的業務策略,也能將之轉化成技術決策並提供有力的支持。

若將組織的層級想像成是建物中的樓層,架構師就能運用我稱之為架構師升降梯的無形結構:他們搭著升降梯上下,在大型企業的決策辦公室與實際打造軟體的引擎室間來回穿梭。

把這個類比延伸一下,放到大型船艦的情境下來看,若艦橋的指揮官發現有障礙物,油輪需要轉向迴避的話,他們會讓引擎逆轉,把船舵轉向右舷。但若當時的引擎正以最高速前進,則將發生一場大災難。這也就是為什麼即便是一艘老式的蒸氣船,也會有一條用來複頌船長命令之通訊管線的原因。在大型企業中,架構師扮演的就是這樣的角色!

某些機構的樓層特別多

回到建物的隱喻上,架構師要搭升降梯過去的樓層數量取決於組織的類型。扁平型組織也許完全不需要升降梯——爬段樓梯就夠了。這也意味著在這類組織中,架構師的這種連結上下樓層的角色,其重要性也許小一些:若管理是能敏銳地在細節的需求層次上覺查到技術上的現實,而技術人員也能直接參與高層管理工作的話,則少一點「企業」架構師是有必要的。我們可以說,這種數位公司是開在平房裡頭的,因此不需要升降梯。

不過,駐紮在大型組織中的典型IT團隊,似乎有許多樓層蓋在他們的頭上。他們在摩天大樓裡頭工作。樓是如此之高,以致於單一個架構師升降梯可能無法涉及於所有樓層的事務中。在這種情況之下,若一位技術架構師與一位企業架構師互相搭配,並各自負責自己在「那一半」建物中的責任區,還是可行的。在這種情境下,架構師的價值不應該由他們能上到多「高」來衡量,而應該由他們能涉足於多少樓層而定。在大型的組織中,位居頂樓中的那些人可能會犯只看到並評價上半建物中之架構師的錯誤。相對地,許多開發者或技術架構師會將這類「企業」架構師視為是比較沒有用處的,因為他們不寫程式。某些情況下,這可能是真的——這類架構師通常喜歡待在建物上層,他們不太會再熱衷於搭升降梯下來。不過,一位願意下到建物下半層來與技術架構師們分享策略看法的「企業」架構師,就能產生顯著的價值。

不是一條單行道

你總是會遇到一些搭升降梯但一到了樓頂就不會再下來的人。他們太享受頂樓上的好景緻,從而覺得他們不用再努力工作,到髒髒的引擎室來。通常,你只要聽到像「我以前是搞技術」這樣的一句話,就能認出他們。無論如何,升降梯是用來搭著上下跑的。地下室被水淹時,待在頂樓裡吃魚子醬並無法轉變企業IT。

搭乘升降梯在組織裡上下跑,對架構師而言,也是一種重要的機制。如此可以取得對決策的各種看法,也能瞭解其在實行階段的各種可能結果。時間長的專案實踐循環無法產生一種好的學習循環,可能還會導致一種「架構師的夢,開發者的夢魘」狀況。在其中,架構師能達成其抽象的理想,但其實作則不切實際。只讓架構師享受往上看的樂趣,總是會變成可怕的只講權威不講責任的反模式。這個模式唯有在架構師必須去面對,或至少觀察到,其決策之結果時,才能打破。要能這樣做,他們必須持續地搭著升降梯上下跑才行。

高速升降梯

現今,即使是傳統企業,企業目標與選用技術間的連結已更為直接。舉例而言,想把上市時間弄得再快些的這種期望,其所形成的競爭壓力已轉化成對彈性雲計算的需求,也就是說,應用需要能橫向擴展,所以需要將之設計成無狀態(stateless)的形式。客戶管道上的目標內容,需要分析性的模型,這需要透過Hadoop叢集(cluster),去攪動大量的數據才能調整,而這反而又傾向於運用本地端硬碟式的存儲,超過共享網路式的存儲。企業所需要的,已轉化成應用或基建(infrastructure)的設計,而這就強調了架構師得要去搭這升降梯。而且,他們愈來愈需要搭高速的升降梯,以跟上企業與IT交織融合的步伐。

在傳統的IT公司裡頭,建物中的低樓層可能擠滿了外部顧問,這可讓企業架構師不用動手去處理事情。不過,這樣一來,因為只著重在效率上,而忽略了速度經濟。在技術快速演化的時代中,這樣子的配置,成效必定不佳。以往習於待這類環境中的架構師,必須要擴展其角色,由供應商技術的純消費者,轉化成能主動定義技術的角色。要這樣做,他們需要發展自己的IT世界觀。

乘客群像

若你正如一位成功的架構師,搭著升降梯上上下下,你也許會在升降梯裡遇到一些人。也許你會,比方說,遇到一些業務或非技術的人,這些人已更深地瞭解到IT就業務而言是很重要的。善待這些人,把他們帶上,帶他們到處看看。

加入他們的對話——這能讓你更瞭解業務需求目標。也許,他們甚至能帶你到從未去過的更高樓層。

你也許也會遇上從頂樓搭電梯下來,只想要用一些行話來推銷自己想法的人。我們不管這些人叫架構師。只搭電梯但不出去的人,通常被稱為梯弟(lift boys)。他們從頂樓的忽視中獲益,所追求的是一種不用與實際技術接觸的「技術」職涯。透過讓他們對引擎室所發生的事感興趣,你也許能夠改變其中的一些人。若你沒成功,則大家最好就維持電梯裡的那種心照不宣的沈默,看看每一塊天花板磚的細節,以避免眼神的接觸。把你的「升降梯高論(elevator pitch)」留給與資深高管共乘一部升降梯時發表,而不用說給僅是傳訊息的人聽。

搭升降梯的危險

你可能會認為雇主會很感謝架構師搭著升降梯上上下下。畢竟他們為著企業的IT轉型,使其在數位世界中更有競爭力而提供了顯著的價值。令人訝異地,這樣的架構師也會遭遇到阻礙。實際上,頂樓與引擎室間可能已相當習慣於斷開彼此的連結:公司領導者會覺得數位化轉型進行得很好,而引擎室的人卻享受著在沒有許多監督下,嘗試新技術的自由。頂樓與引擎室這樣地斷開連結,就像一艘巡航艦,全速往冰山撞去:等到公司領導人瞭解到底發生了什麼事時,為時已晚。(摘錄整理自《軟體架構師全方位提升指南》第一章,碁峰資訊提供)

圖片來源 / 碁峰資訊出版

 書名  軟體架構師全方位提升指南:數位轉型企業中架構師角色的新定義

Gregor Hohpe/著;陳健文/譯

碁峰資訊出版

定價:580元

 作者簡介 

圖片來源/Gregor Hohpe

Gregor Hohpe

Gregor Hohpe憑藉著自身在企業IT、企業架構與雲端服務的豐富經驗,為技術主管們提供組織與技術平台方面的諮詢服務。他曾擔任過新加坡政府的顧問、Allianz SE的首席架構師以及Google Cloud CTO辦公室的技術主管。Gregor是《Enterprise Integration Patterns》一書的共同作者。

熱門新聞

Advertisement