前言
本書是我在IT應用開發領域累積15 年思考的成果。
在1990 年代晚期從我從事IT架構的工作開始，當時我寫了一本書，名為《IT Architecture and Middleware: Strategies for Building Large, Scalable Systems》（第二版與Peter Bye 合著於2004 年，目前仍買得到）。這本書是在介紹有關建置整合的應用程式之技術以及如何讓應用程式可被擴展、高妥善率以及高安全性。當時人們也以同樣的路線進行思考，Peter 和我所提倡的方案後來被稱為服務導向架構（Service Oriented Architectures, SOAs），因為基本的想法就是要有可再利用的服務，讓我們能利用整合的技術快速地組合成新的應用程式。儘管SOA 有許多我們認為很明顯的好處，但幾乎都沒發生。
IT管理者們當時很喜歡SOA，但並沒有真正實作出任何東西。某種東西被遺漏了，我在一開始的時候幾乎就已經懷疑這個遺漏的東西就是應用程式開發。換句話說，對於「如何開發一套SOA應用程式？」，我們當時並沒有答案。這個問題或許這樣表達比較好：「我有很多需求，我要怎麼做才能確保我最後會得到一個SOA 的解決方案，而不是一支獨立的應用程式？」。經過接下來幾年，我愈來愈少思考架構方面的事，但有關應用程式開發卻愈想愈多。
我最早從事應用程式程式設計是在1970 年代晚期。從當時開始，我主要的工作是在系統與環境軟體領域、修復問題與進行設計。我花很多時間來改善資料管理軟體，偶而會被指定去修復一兩個編譯器的問題或作業系統的問題。我已經做過許多設計與系統軟體程式的編寫工作。後來我做的是資料庫設計與知識庫設計（我可以講述很多有關版本控制方面的事，但很奇怪，很少人會想聽）。一直到2000 年，我已經歷了很多層面的電腦科技，但我卻從未做過太多單純的應用軟體設計與程式設計，因此我無法坦蕩蕩地走到應用開發者們那裡向他們說他們全都做錯了。
在那個時候，應用程式開發的精神領袖們對於架構並沒有什麼興趣，反而陷入彼此之間的交戰。 某一群人支持「大規模的事先設計」（big design up front, BDUF） ，他們推崇的設計是要基於UML（Unified Modeling Language）來進行模式化。這些設計具有結構化、文件說明完備、並且富有品質控制的流程。
在另外一方的是支持「敏捷（agile）」的一群人，他們信仰的作法是優先發行軟體，然後透過一連串簡短的更迭過程，將它修正到適合利害關係人的需求。他們意見不同的核心就在於與利害關係人之間的關係。在BDUF中，這個關係是契約上的關係，也有一套正式的步驟來蒐集需求。在敏捷的做法當中，他們相信最好的做法就是將功能分割成許多小區塊，在針對每個小區塊實作之前才找出細節的需求，並在可運行的軟體完成後不久就展示給利害關係人看。於是藉由持續的意見回饋，他們希望能藉由小部分且頻繁的修正來引導到實作上面。
無論我在何時向IT領域以外的人解釋敏捷的做法，他們都很清楚地認為那是接近不負責任的做法。但是敏捷方法的團體對BDUF 的批評則具有共鳴。利害關係人在看到應用程式執行之前要去理解所提議的應用程式的確會有困難。一紙合約並不能像施魔法般地讓IT應用程式受到喜愛。
然而，無論哪一邊都不能洞察出為何SOA 沒發展起來，彷彿這個問題並不存在一樣。
為何應用程式的開發會抗拒SOA 呢？其中一個原因是IT專案對於準時驗收、符合預算、符合利害關係人需求這些方面一直有不好的名聲。這導致壓力加諸IT開發者身上，而對這壓力所產生的反應之一，就是對專案界線的堅持。他們要控制在這界線以內的所有事物，並且能夠忽略界線以外的每件事。
其所造成的結果，往往就是每一件應用程式開發專案，就會產出一套獨立的應用程式。假如你有一件大型專案，你就會開發出一套大型的應用程式；如果你有很多個小專案，最後就會有產生很多小應用程式。此外很容易確定的是，大型IT專案特別容易失敗，於是人們趨向於寧可有多個小專案也不要單獨一個大專案，於是便產生了很多小的應用軟體而不是一套大的應用程式。另一方面，IT架構師們會嘗試著說服應用程式開發者建立一些服務、而不是一支獨立的應用程式，並且打造必要的機制以便和那些服務互相合作，他們沒有成功的希望。
在過去我一直不明白那種與外界隔絕的專案是什麼樣子，直到2000 年代早期我再次開始嚴肅地審視應用程式開發，才赫然發現到程式設計師與資料庫設計師之間充滿著緊張氣氛。程式設計師十分專注於他們當前的專案目標，對於組織中資料如何共享以及管理並沒有什麼興趣。
於是我想要對應用程式開發做的第一個改變就是—我要找到一個方法讓開發過程能夠對架構開放，讓所有應用程式的運作能對整個架構全面負責，而不是在暗中破壞。
假如專案是與世隔絕的，其中一個理由必須是需求本身也是與世隔絕的。換句話說，他們專注於特定問題而非組織需要的整個方案。當我從事架構方面的工作時，我下了很多功夫在調查IT應用程式如何支援企業的營運。
特別是，我見識過IT如何支援企業流程以及如何跨多重資料庫達成資料一致性。在每個案例中，IT應用程式的整合都是無比重要的。那麼為何這未被反應在需求上呢？為何企業管理者沒告訴IT應用程式開發者要建立整合的應用程式呢？我已經知道這個問題的答案，我曾在管理層工作過，也曾和業務人員、市場人員、以及財務人員工作過，我對他們的行為模式十分清楚。
再者，我見過銷售流程及其他企業流程的來來去去。簡言之，我知道另外一方所感到沮喪的事情。我知道管理人員通常很聰明，而有時會拐彎抹角的。我知道管理人員的意見並非永遠都是一致的，他們不只是不認同彼此的意見，也會不認同上司的意見。在這個大悶鍋裡走進一群天真的IT人員，他們興高采烈地告訴每一個人說他們正要建造一套能改變每個人做事方式的應用程式，因此請告訴他們你們要這套應用程式做些什麼。也許IT人員應該採取不同的方式，也或許企業管理部門應採取不同方式，但我認為基本問題應該比這個還要深入。
IT應用程式並不像一部影印機或一台iPad，它並非是個獨立輔助企業的東西，它的使用也是可有可無的。當然，IT應用程式對營業活動而言是不可或缺的，當今你若沒有它是無法進行營運的。
因此，在實作應用程式之前，我們最好能保證它的設計能支援正確的營業活動。最好連細節的部份也都能清楚無誤，並且能確認該組織知道它們將會得到什麼樣的應用程式，故能真正地支持它。在IT這個圈子裡，應用程式需求的變更是一項可被接受的事，甚至有人為它訂了一個專有名詞：需求翻案（requirements churn）。常常有人認為，這和快速變化的商業環境有關。沒錯，商業環境的確在變，但是我認為需求翻案最常見的理由，就是人們是一邊在進行營業活動，卻又一邊在設計營業活動。
解決的辦法就是說服IT應用程式設計師及企業管理部門，讓他們知道單純收集需求將無法解決問題。無論他們是否喜歡，他們是在從事一件設計行動，目的是為了造出更理想的企業解決方案並讓IT部門支持。 我想，能對企業管理部門與IT應用程式設計師們在達成需求建立的作法上提供革命性影響的，將會是需求的設計、而不是只是條列需求清單。
這是我對應用程式開發想做的第二個改變─我要讓需求收集本身變成一個設計專案，藉此改變與企業管理部門之間的關係。
當我從事IT架構的工作時，有個問題總是困擾著我，那就是我們為了將IT應用程式視覺化而繪製的設計圖並不那麼令人滿意。
這裡有兩個問題。第一，要描述一套系統，我們必須從多重角度去觀察它，並且建立多重視圖。例如我們可以捕捉：
企業組織視圖—根據組織圖將企業做切割。
企業流程視圖—流程通常會橫跨多項營運功能範圍。
資料視圖—呈現出具有哪些資料以及資料所在的位置。
程式設計師視圖—描述營運規則如何轉換為程式碼。
硬體結構視圖—描述所有元件方塊是如何組合在一起的。
其他還有很多建構多重視圖的方法被提出來。（參考文獻列於本書後面。） 這些視圖模型的主要問題是，要看到不同視圖之間的相依關係是相當困難的，尤其是在具有複雜IT系統的大型組織中。大型組織裡的IT系統，其錯綜複雜的程度是令人瞠目結舌的，上千套應用程式或是上百個資料庫並非不常見。（我一直在懷疑，軟體的複雜度跟被賦予寫軟體任務的程式設計師數量是成正比的，而不是跟他們嘗試要解決的問題之複雜度成正比，不過這又是另外一回事了。）
架構上的設計圖有另一個問題，那就是有很多視圖的階層架構並不夠嚴謹。擔心這件事也許有點奇怪，不過讓我稍作解釋。不管哪個視圖，我們要能夠從高階的位置（你可想成是從10,000 呎高空看來地面）來看這些資訊，並且會想要能夠把鏡頭拉近來看細節的部份（好比是在100 呎高的距離來看）。要做到這樣有兩種方法，我稱之為「地圖」與「工程製圖」。當我們把地圖放大的時候，一些新的東西會出現在畫面上。在高階時我們只可看到主要道路，但在低階時我們可以看到次要的巷弄。這樣做會有一些問題，例如，你永遠無法全然地確定你能夠找到從A 點走到B 點的最佳途徑，這是因為也許在某一條路上有一條捷徑，但是你在地圖上是看不到的。在另一方面，工程製圖裡的物件是由我們所稱的元件所組成的，而這些製圖顯示的就是這些元件是如何組裝在一起的。此外，任何元件本身也可能是由許多次級的子元件所構成的，因此應該有另一份工程製圖來解釋這個元件是如何由那些子元件組合而成。當你往低階檢視時，並不會有新的物件跑出來，而是會看到現有物件會被分解開來。
這樣做是有差別的。舉例來說，拿著一部汽車的工程製圖我們可以問，「它有多重？而它的重心在什麼位置？」這時只要計算每個元件的重量與位置，我們就可以計算出答案，因為我們不用擔心會有額外的東西突然蹦出來。
不幸的是，IT架構上的視圖都是像地圖一樣。例如高階網路圖只會顯示出主要伺服器與主要網路連線而已。當你往底層看時，它才會把小型伺服器、路由器、以及PC 等顯示出來。同樣的，高階的資料視圖只會顯示主要資料表，其他數百個資料表將不會被顯示出來，除非你看的層級夠低才能看到比較細的資料表。
這有什麼重要呢？長期以來幾乎所有人都察覺到，一樣是工程打造出來的汽車與建築物，但與它們相比時，IT應用程式是比較不可靠的。在我工作生涯的某一個階段，像是軟體工程師這樣的頭銜是很常見的，但後來變得不那麼時尚了。
或許是我比較悲觀，不過我有個印象覺得程式設計這個行業已經放棄追求成為工程學科的夢想了。我可以解釋為何程式設計不是一種工程，理由很簡單：我們沒有任何相當於工程製圖的東西。讀完第一章之後就會很清楚為何這會是個理由。因此我開始去想IT應用程式是否有高階的工程視圖，很自然的（因為我正在寫這本書）我認為我已經成功了，雖然說它們和典型工程製圖的型式有相當程度的差異。
這就是我想要改變的第三件事—我要讓應用程式的設計更像是一門工程學科。
當我開始在思考應用程式開發而有些點子想要告訴外面的世界時，我發現願意聽我說的人不多。當時我並沒有實例的研究以及足夠的聲望，而且我並沒有與生俱來的行銷常識來敘述其他人應該也會有的故事。我寫過一些論文並做過一些簡報，雖然每個人都很客氣地聽著我的簡報，但是並沒有什麼反應。不過因為當時是BDUF 對敏捷方法之戰打得最激烈的時候，我想我不應該為此感到驚訝。因為那就好像你走進一間擠滿人的房間，在那裡每個人都在互相喊叫著，他們想要聽到的只有一件事，那就是你要站在哪一國。
那是十年前的事了，現在BDUF 與敏捷方法的爭執已經退化成一種不太穩定的停戰狀態，而應用程式開發和以前一樣仍舊不受企業界所喜愛。就在這個時候，我回來再度成為一位程式設計師。我已經花了我大部分的時間嘗試去開發工具來繪製你在本書會看到的設計圖，我也花了部分的時間從事應用軟體的程式設計工作。雖然我的想法在本質上沒有太大的改變，但我想現在我比較有資格與能力讓那些論點更加豐富。我早期嘗試講這些故事的方式是透過許多沒有彼此連貫的短篇文章，而現在我要做的是將這些文章全部抓來統整在一起，並編排出全面性的架構，來說明如何由上而下進行應用程式開發。
我很清楚許多讀者會有很強烈的意見，而其中會有一些人相信自己已經解決了所有應用程式開發的問題而不需要我的訓誡。本書大部分的內容都是屬於問題的分析，因此即使你不相信我的解決方法，我也期勉你去思考這些問題，但願本書能夠鼓舞你這麼做。
2024專利防護中