想在不增加技術負擔的情況下降低IT成本?企業架構是一個很好的起點。想要改進業務或者IT集成嗎?企業架構有望成為首選工具。如何建立一個更精簡有效的業務?你應該先看看你打算走向何方。
這其中存在一個矛盾：雖然改善架構可以推動改革，但是本應該幫助您改善公司架構的框架和方法卻很少能夠兌現其承諾。相反，他們將EA功能轉變為象牙塔式的白皮書工廠，過度強調對實際行動進行深度的抽象概念化。
經過30年的努力，為什么失敗率依然這么高呢?原因是一些很少有人愿意承認的黑暗秘密。有多么黑暗?出于度量標準的考慮，我將使用Ansel Adams的區域系統，其范圍從0(黑色)到XI(白色)。
一言以蔽之：最黑暗的秘密終于將在這里被揭示。
秘密1:EA沒有成功的標準
區域系統評級(ZSR): IV
TOGAF是企業架構中最著名和使用最廣泛的方法，因此我們將它用作跟蹤對象。如果您不熟悉它，只需要知道TOGAF代表The Open Group Architecture Framework。根據Open Group的說法，“TOGAF®是一個開放的標準，是一個世界領先組織為提高業務效率而使用的經過驗證的企業架構方法和框架。”
這就引出了一個問題:TOGAF的權威性是如何被證明的?我在谷歌上搜索“TOGAF成功率”，結果一無所獲。據我所知，開放集團或其他任何人甚至都沒有定義TOGAF的成功指標，更不用說跟蹤其效率了。
秘密2：EA追逐著錯誤的目標
ZSR：III
TOGAF聲稱它能提高業務效率。但是，任何擁有一大堆指標的人都知道，“高效”總是一個比率 - 每單位其他事物的單位數，例如每加侖英里數，每服務器處理美元的交易數或每個程序員每小時的故事點數。
“效率”在不知道分子和分母的情況下是沒有意義的，而TOGAF既不知道分子也不知道分母。
這不僅僅是語義上的狡辯。當你從事大量交易時，效率很重要，因為明天的市場看起來就像昨天的市場。
大多數企業領導者都明白，變化是他們唯一不變的東西，這意味著靈活性和適應性不僅僅關系到效率。 TOGAF的瀑布性(下一個黑暗的秘密)使得它在獲得靈活性和適應性方面是一個糟糕的選擇。
秘密3:EA進行瀑布式的重復操作
ZSR：II
EA框架和方法論經常失敗的一個原因是，它們在本質上是瀑布式的。他們通過記錄當前狀態(一項耗時的工作)，設計理想的未來狀態(另一項耗時的工作)，并繪制路線圖，以縮小兩者之間的差距。
然而，當世界發生變化時，重新繪制所有內容同樣耗時。在實踐中，這意味著EA的參與根本無法推進業務變革的發展。
它拖累了變革。
秘密4:雖然重要，但EA并不急迫
ZSR：II
假設您是一個企業架構師。了解當前狀態、未來狀態、差距和路線圖——以及一旦公司達到理想的未來狀態之后，進行將節省資金的估計——最后您將與執行團隊(ELT)會面，以獲得資金。
祝你好運。在會議召開前和會議結束之后，業務部門領導人還將會見ELT，為他們的項目尋求資金。 ELT將您的請求與其他機會進行比較。 EA優勢的兌現總是遙不可及。這是因為它們是在其他業務定義的項目中實現的，這些項目在得到實現之前不能利用改進的體系結構，因而在完成之前無法收獲它們的業務收益。
所以，商業項目現在就可以啟動，但架構將不得不等待。
猜猜是什么最終能夠得到資助——尤其是當ELT能夠輕松理解改進的CRM的價值，而你卻只會喋喋不休地談論架構開發框架、無邊界的信息流、企業連續體等等時，你連自己都不知道自己在說什么了。通過將上百個專業詞匯和首字母縮略詞加入他們的詞匯表，EA從業人員便以為他們可以加入炫酷俱樂部了。
秘密5:EA框架不能描述真實世界的架構
ZSR:0
TOGAF的基礎包含一個基本缺陷：它按照固定的四個層次來描述架構：業務層，應用層，數據層和技術層。這一直是一種過度簡化——每個層都有段和子層。
這就引出了兩個最大最重要的黑暗秘密:
秘密5.1：平臺是應用程序 - 應用程序是平臺
ZSR：0
TOGAF的分層模型顯然是錯誤的。因為越來越多的平臺也是應用程序和應用程序已成為平臺。看看SharePoint。您可以將瀏覽器指向它，并以一種比共享文件夾更復雜的方式管理文件，如果您愿意，還可以創建博客、wiki和其他有趣的東西。
您還可以使用SharePoint作為開發通用應用程序的平臺，包括數據輸入、工作流、報表等等。它是一個平臺也是一個應用程序。
不喜歡這樣的例子嗎?那再看看SAP?它和它的同伴ERP系統是應用程序 - 非常大的應用程序。構建它們的目的是讓您定義自己的數據元素，并使用它們編成您自己的工作流和事務，同時不會破壞它們的結構完整性。
它們既是平臺又是應用程序。
你認為這是一個小問題嗎?EA的全部目的是讓他們準確而一致地描述架構。如果他們不能做到這一點——如果他們不能描述SharePoint和你的ERP套件是如何與你正在運行的或者將要運行的其他東西結合在一起的——那么他們能提供什么價值呢?
秘密號碼5.2:丟失的層級。
ZSR：0
平臺是應用程序。應用程序是平臺。現代IT不僅僅是實施和運行它們。現代IT將它們整合在了一起。
大多數組織將它們與一大堆自定義編程的批處理接口集成在一起，并依賴于被命名為“spiderweb”，“spaghetti”和“hairball”的接口，具體取決于它們的混亂程度。
TOGAF沒有地方來描述這些問題，也沒有地方來描述像企業服務總線(ESB)這樣的更符合體系結構的替代方案。這是不幸的。因為清理一個混亂的集成架構常常是改善架構的最大好處。
這很不幸，因為越來越多的IT部門不會僅使用一個底層應用程序作為平臺來構建應用程序。 IT使用ESB從一系列“記錄系統”中創建虛擬的“數據源”服務。
使用這些服務構建應用程序，而不是直接使用應用程序API，是無法使用TOGAF來描述它們的。
EA的秘訣是:不要給我帶來麻煩。帶給我解決方案!
ZSR:9
沮喪?不需要。雖然最流行的架構框架和方法都很混亂，但這并不意味著您必須忍受糟糕的架構。恰恰相反。這里有五個速成提示。
不要讓完美成為好的敵人
好吧,這不是原創。這也不是伏爾泰的原創作品。你會注意到，聰明的做法是首先實現IX級別的ZSR，而不是XI。規則是:不要試圖描述完美的未來狀態。對更好感到高興，并讓它發生。
嘗試詢問IT業的任何人。他們知道答案，也很樂意分享。您可以開始改善您的體系結構，而無需記錄當前狀態或以任何級別的細節描述您的未來狀態。
考慮一下敏捷
敏捷不僅僅是一系列應用程序開發方法。這也是一種思考方式。這里特別重要的是與迭代和漸進主義密切相關的想法。因此，當您設定ZSR IX的目標時，請確定您現在可以采取一些小步驟，以使架構更加完善，而不是完整的步驟集，這些步驟將幫助您完成所有任務。
不要與業務項目競爭——而是將架構集成到其中
您現在可以采取哪些小步驟來改善您的體系結構呢?與其與商業項目競爭資金，不如將體系結構改進到可以獲得資金的商業項目中。通過這種方式，每個與IT相關的項目都會使架構比其發現的狀態更好，只需要適度增加投資和范圍。
由于項目發起人不太可能愿意將自己的預算花在更好的企業架構上，所以您應該向ELT展示。只是現在你要求的是為每一個被批準的項目提供架構補貼，而不是單獨的資金。
使用設計原則來定義“更好的架構”意味著什么
通過放棄構建一個完整的體系結構的想法，你就可以自由地去理解什么是“更好的體系結構”。通常，它意味著你只需要遵循一系列核心原則。困難的部分不是制定它們。最難的部分是不假裝。
例如，幾乎每個人都同意消除冗余(規范化)是良好數據架構的標志。盡管如此，你只能假裝將這個設計原則作為設計原則，因為像大多數企業一樣，IT部門只會在需要時購買，并且只能在必要時進行構建它。事實上，這只是你可能的設計原則之一。
如果你能買就買，只在必要時才構建，那么你就無法避免數據冗余。沒關系。不要假裝。在多供應商環境中，相應的原則是記錄和同步冗余。
避免固定的架構師
好吧，這有點難。你真正想避免的是需要有永久人員配置的EA功能。這樣做，你將很難阻止它成為一個象牙塔般的白紙工廠。相反，讓它成為一個輪換的任務將使它更加穩定，因為每個人在執行任務時都必須遵守規則，否則當他們再次輪換時，將不得不忍受自己造成的后果。
總之
架構很重要。特別是，技術架構很重要。與那些缺乏簡潔架構的企業相比，擁有簡潔架構的企業更加靈活和有效。
實際上，體系結構太重要了，將它托付給當前的某些框架和方法茲事體大。這雖然很糟糕，但是至今也沒有一個方法值得依靠卻并不是問題。
這反而是一種解放。
京公網安備 11010502049343號