某個(gè)流程或關(guān)注點(diǎn)是怎么影響可擴展性的。答案通常相同，即組織中的人員或流程會(huì )創(chuàng )造應用的可擴展性，也會(huì )破壞它的可擴展性。這應該不會(huì )讓你感到意外。如果沒(méi)有正確的團隊支持，或者該團隊沒(méi)有采用正確的流程，那么得到能夠根據業(yè)務(wù)需求進(jìn)行擴展的架構的可能性是零。組織一個(gè)跨部門(mén)的團隊設計應用，可以確保具有不同知識的人協(xié)同合作，找到最佳的解決方案。此外，這些人現在還有了共同的目標，即要使這個(gè)功能獲得成功。不具備這兩個(gè)關(guān)鍵因素，在大多數組織中常見(jiàn)的知識不足和經(jīng)驗的鴻溝的情況都會(huì )注定使功能定期地出現故障，從而引發(fā)業(yè)務(wù)的可用性和可擴展性問(wèn)題。



要想確保設計的功能考慮到了技術(shù)的各個(gè)層面，并且打破團隊之間常常存在的壁壘，JAD是個(gè)關(guān)鍵的重要步驟。這個(gè)流程的第一步是確保對JAD團隊有 監督和管控，確保各個(gè)JAD團隊遵循了一致的標準。對JAD的監控和一致性檢査，都是以ARB的形式執行的。

架構設計原則與編碼標準相似。如果把它們形成文檔，教給所有工程師，它們就會(huì )被一貫地執行。但如果你沒(méi)有采取后續措施，檢査你的工程師，那么他們中的某些人，即使有些是出于好意，就會(huì )鉆些空子，企圖事后再作修補。但遺憾的是，無(wú)論他們的本意是多么好，由于對軟件開(kāi)發(fā)的時(shí)間要求常常很緊，所以他們很可能就不會(huì )再有機會(huì )修補這些空子。如果標準沒(méi)有被同級同事或經(jīng)理評審過(guò)，那么它們在執行過(guò)程中可能就會(huì )出紕漏。遺憾的是，幾乎在每個(gè)團隊中都能見(jiàn)到這種現象。在完美的世界中，工程師除了正確地完成項目之外，就沒(méi)有其他任何壓力了，但現實(shí)并非如此，幾乎總有額外的壓力需要平衡。關(guān)于標準的另外一個(gè)問(wèn)題是，有人可能會(huì )誤解標準，即使是最聰明的人也會(huì )如此。尤其是當有新的工程師加入團隊時(shí)，你需要確保他們都正確地理解了標準，并且能夠實(shí)施它們。要確保標準被真正理解了，可以討論假設的示例，甚至可以進(jìn)行測試，這些都是好的預測方法，但用真實(shí)世界的例子進(jìn)行驗證才是最好的方法。

驗證JAD設計使用和詮釋了架構設計原則是ARB的主要目的。通過(guò)評審某些JAD設計，可以確保團隊努力做出了最好的設計，而不是鉆了空子，并確保各個(gè)團隊對架構設計原則的理解和實(shí)施是一致的。

通過(guò)連續不斷地應用網(wǎng)站建設架構設計原則，可以確保應用從設計之初就是可擴展的。這是架構設計原則和可擴展性之間的直接聯(lián)系。JAD是用于設立標準，堅持應用這些架構設計原則，而ARB是用于檢查，即確保標準被執行了。