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