最難的 IT 決策，不在技術選型，而在定位與邊界管理
當策略搞不清楚，再多技術都只是治標不治本？
我在執業過程中發現，企業資訊系統的運作大致可以分為兩種管理模式與兩種開發模式。兩種管理模式：一種是雇用員工自製軟體，另一種則是外包。而兩種開發模式一種是統一工藝，另一種則是異質拼裝。
統一工藝
某間製造玻璃的工廠，為了內部的管理需要，他們雇用了一位專業的軟體工程師，從零開始打造該公司的軟體生產管理系統。所有的功能全部集中於一個 web application 之內。
異質拼裝
某間線上教育公司在初期使用 Wordpress 搭配 shell script ，後來外包給一家 software agency 來將 shell script 的部分改寫成 web application ，並且與 Wordpress 的網站整合在一起，從外觀看來，該公司的網站就像是合而為一的系統。
做一些分析的話：
統一工藝的優點是系統可以做成單體式 (Monolithic) 系統，用這種作法搭配單一的程式語言，有可能做出高效能、易理解又優雅的系統。
異質拼裝可以有效實施的前提在於：「巧妙地切分企業的軟體需求，同時又可以找到足以滿足部分需求的 low code tool。」對於中小企業來說，很有可能有部分的需求，可以透過 low code tool 來滿足，也因此若將系統拆成：「可由 low code tool 處理、且需求相對穩定的功能」與「難以被 low code tool 處理或是高度變動的需求」時，就可透過 low code tool 搭配客製化開發來完成系統。
儘管這種系統從最初就因為異質整合會走向微服務 (Microservices) ，因而有著種種的額外複雜度、效能受到 low code tool 的限制、從工藝的觀點來看很醜，這種系統的一大部分卻很有可能可以由非工程師來維護 (因為有 low code 的部分)，因而可以大幅降低營運成本 (operational cost) 。
四象限分析
如果將兩種管理模式與兩種開發模式交叉組合，可形成四個象限：
第一象限：自製、統一工藝
第二象限：自製、異質拼裝
第三象限：外包、異質拼裝
第四象限：外包、統一工藝
第一象限通常只適合資金或是人材充沛的科技公司，對於這種公司來說，軟體不只是工具，更是武器與競爭力的來源。例如具備工程文化的 FinTech 或 HealthTech 類型新創公司。
第二象限常見於成長中的中小企業，有 IT 意識但是資源極度受限，只好邊開火邊前進。比方說：教育、媒體、又或是新創公司。
第三象限常見於數位轉型中的老企業或是大企業。資源多的前提之下，就會多找幾家廠商，做不好就換一家。經營很多年之後，企業裡就很多種系統，非常難以整合。
第四象限常見於非技術型組織。這種組織習慣找一家外包軟體公司完成一切的困難，又或是完全依賴套裝的 SaaS 軟體解決一切的問題，讓組織去適應軟體。
許多公司在做 IT 決策時，焦點放在戰術層面（要不要導入某個工具、要不要招募工程師、用 AWS 還是 GCP）。但這個四象限模型強迫你先回答：
我們公司需要的是工程能力還是整合能力？
我們的組織流程中，需要多少的絕對控制力？
IT 是否是競爭力來源？
是否有足夠的資金來做長期投資？
這些策略層級的問題，確認答案之後，後續的決策才容易有一致性。才不會動不動就陷入，花費極少的金額採取外包，卻期待軟體有極高的彈性與品質；又或是採取了第一象限的策略之後，日後發現公司無法承擔這種 IT 的投資。活用四象限分析的話，應該很適合用來啟動高層對 IT 定位的討論。
務實的第二象限
如果說，這四個象限有哪一個象限的吸引力快速地上昇，遠超過其它象限，相信 IT 定位的決策會簡單的多。然而，實際上每個象限各有其吸引力。比方說，由於 low code tool 軟體的功能日益增強，其實異質整合的選項也很有可能可以抵達相當遠。外包通常會比自製便宜。自製通常又可以更加充分地溝通，因而可以提高軟體專案的成功率。
在種種象限之間的張力之下，我認為，第二象限往往是最務實的選擇。在這個企業普遍面臨數位轉型壓力的時代，軟體能力很有可能是企業競爭力的一環，完全放棄雇用軟體工程師，等於放棄了組織在 IT 方面有高競爭力的可能性。另一方面，若雇用軟體工程師、完全自製系統，則成本往往過高，對多數企業而言難以負擔。搭配異質整合之後，有機會讓工程師只專注於 20% 必須要客製的部分，因而大幅降低成本。
回到之前的分析，第二象限需要的除了開發能力外，還需要廣泛的軟體知識、系統架構經驗，以及商業判斷力。理想的第二象限決策，需要知道：
什麼應該拼裝、什麼應該自己做？
在拼裝的部分，最靈活的 low code tool 是什麼？
在自己做的部分，該怎麼設計？
這樣的判斷能力，其實連許多資深工程師也未必具備。
結論
企業資訊系統的決策，本質上是一種取捨。四象限模型揭示的不僅是選項之間的差異，更點出了 IT 策略層面的決策難題，而這些難題不能只靠工程部門來回答。
對多數企業而言，第二象限的策略——自製 + 異質拼裝——雖不完美，卻最符合當下的現實條件與未來的靈活性需求。這種策略不是「便宜的第一象限」，而是「有意識地控制軟體能力邊界」的務實選擇。
真正困難的是，企業能否建立一種能力來判斷哪些需求該用 low code 解，哪些需求必須自己寫？能否培養出能跨越開發與整合思維的工程團隊？能否讓高層在 IT 決策中具備策略性的視野？
當我們談論「IT 策略不容易做對」時，其實是這些問題不容易被看清楚，也不容易被組織中的各方角色共同承擔。
一家公司若能釐清自身處在哪個象限，並且儘可能地取得在該象限成功的要件，那麼，它就已經比多數競爭者更接近 IT 成功的道路。