從2005年開始，支付寶的技術架構經歷了「煙囪型」、「面向服務型」、「雲平台型」三個時期。
「煙囪」是一個形象的比喻，支付寶的第一代架構就像一個個獨立的「煙囪」。沒有基礎架構可言，做一個業務就豎起一個「煙囪」，「煙囪」之間的關聯性不大，每做一個新業務就要將一個煙囪進行手動改造，而支持主要業務的「大煙囪」經歷了無數次的改動。
2005~2006年，支付寶業務發展得很快，任何一個商業想法，從產生到提供給用戶使用的時間都是按天來計算的，如每年「雙十一」大促時的支付寶紅包，就是程立用四天時間做出來的。
應該說，第一代「煙囪型」的系統較好地滿足了小團隊開發、業務快速試錯的需求，但是這個架構不能支持大團隊的分佈式研發。在「煙囪型」的技術架構下，每當開發新的產品和功能時，只能允許所有人在一個系統裡去寫代碼，與此同時，它的部署也是集中的，核心系統就是一個集群，數據庫也只有一個。因此，隨著業務量的上升，這樣的數據庫和集群都會達到極限。
從2006年開始，支付寶的技術團隊意識到，「煙囪」架構無法支持支付寶未來業務的發展，如果要繼續拓展業務，必須先把架構分佈化，建立底層服務架構，讓專業模塊做專業的事情。當時，分佈式系統在互聯網界的應用並不罕見，規模較大的互聯網公司系統都分佈化了，但是對於金融系統而言，分佈化是沒有先例的。這是因為金融系統要求高穩定性和高安全性，任何改進都要先保證用戶賬目上的錢分毫不差。在系統數據分離之後，保證系統之間業務處理的一致性就成了核心的問題。
這時，程立剛從技術團隊的主力架構師升至首席架構師，團隊主管要求他不必寫代碼了，而是專注去「畫大圖」，為團隊的未來發展指明方向。可是對程立來說，這是一個完全不同的任務。整整一個季度的時間，他沒有畫出一張令自己滿意的「大圖」，KPI考核只得了3.25分，程立甚至一度想辭職。
程立所要畫的「大圖」，就是支付寶二代的架構。
後來，到了2007年初，程立的腦子裡漸漸產生了一個想法。與此同時，業界的技術也逐漸成熟，特別是大規模SOA系統[3]中的分佈式事務處理標準逐漸明晰，程立就和同事一起，從2007年上半年開始準備將支付寶的系統做分佈式的改造，現在看來就是把支付寶的架構改成一個分佈式服務和分佈式架構。
程立選擇先拿交易服務來開刀，首先將最複雜的交易服務重構，使交易服務變成「微服務」，這樣就能將它拿出來和其他事務打交道，同時還要保持事務和核心虛擬賬戶業務的一致性。為了解決這個事務問題，他們使用了WS-Transaction服務規範[4]。
2007年5月，項目正式啟動。支付寶的技術團隊分為幾撥人：一撥人寫分佈式事務的底層框架，一撥人設計新的核心的交易系統，還有一撥人做分佈式事務的框架。兩個月後，開發完工，系統運轉了起來，一切看上去似乎都很正常。
但當程立從系統的複雜度去審視時，他發現了一個問題，原本非常簡單的處理過程，現在卻變得異常複雜。比如，僅一個消息處理，分佈系統之間的消息就有10~20個，如果這樣，系統上去是要「死人」的。
進退之際，他想起了自己在2005年做支付寶三期時的經驗：如果系統存在問題，就不要抱任何僥倖心理，要敢於面對問題，查找原因，從頭再來。項目團隊經過反覆思考之後，決定把前面的架構推翻重做。
後來，程立又想到了一個簡單的架構，他要求同事按照新架構開發。在團隊的支持下，到9月底，開發工作全部完成。2007年「十一」長假，他提前三天回來，把代碼重新檢查了一遍，又加了很多的監控日誌。「十一」過後，新系統順利發佈。
二代架構在支付寶技術發展過程中是很關鍵的一步，因為新系統將原來的大系統拆開了，在當時這個項目叫作「交易服務化」。有「交易服務化」作為基礎，後來支付寶又做了賬務三期。做完賬務三期之後，核心賬務系統也分佈化了。從2007年開始，支付寶陸續用了三年左右的時間對整個系統進行分佈化。
這樣，支付寶就夯實了分佈式事務的基礎設施，核心賬務可以分佈，核心交易也可以分佈，所有的業務都可以分開來做。結果是，支付寶的系統可以伸縮了，每一個系統都是分佈式的，如果遇到業務峰值，就可以增加資源。幸運的是，當支付寶的二代架構做完後不久，淘寶就開始搞「雙十一」大促了。
支付寶的第二代架構為第三代架構「雲支付」奠定了良好的基礎，因為如果使用雲計算，系統首先要分佈，只有這樣才能用很多小型機器、雲資源作為支撐。
但二代架構過渡到三代架構的過程並非一帆風順，在二代架構完成後，雖然支付寶把系統拆開了，但是如何讓新業務長在複雜的分佈式系統上是一個非常複雜的問題，在業務很多的情況下，系統會變成一張複雜的網。
支付寶技術團隊想到把業務進行拆分和梳理，從而將系統變成一個邊界明晰的雲服務平台。比如，系統裡有一個支付服務的平台，它的作用是對外提供支付服務，任何一個業務需要用到支付時，直接對接就可以，這樣支付的功能馬上就可以調用了。類似地，會員服務的系統、運營服務的系統與營銷服務的系統紛紛搭建出來，各種服務像「水、電、煤」一樣能夠即需即用。
總之，第三代雲支付架構能夠完成兩方面的改造。一方面是在底層使用雲計算技術，另一方面是在上層把服務變成雲服務，這樣建立在其上的業務就可以很快地生長。
從二代架構過渡到三代架構，支付寶又花了三年時間，在此期間，支付寶開始自主研發中間件、數據庫、大數據平台。正是這個雲計算的架構，支撐了近幾年淘寶大促的交易，也使後來的「雙十一」能夠平穩地進行。
用程立的話說，如果這個事情做得晚一點，這幾年的「雙十一」大促就別想挺過來了。不僅如此，雲服務的三代架構也為今天螞蟻金服的發展奠定了堅實的基礎，現在的螞蟻金融雲就是建立在這個架構的基礎之上的。螞蟻金服對此並不滿足，現在已經開始研發第四代架構，這是一個適應目前數據開放、互聯、全球化的架構。