獅子羔羊（公共微信平台）
創作的衝動來源於對過去的尊重和對未來的向往。字裏行間無意中表達出你的理念，你對生活，工作，愛情的詮釋。文章均為獅子羔羊原創，版權歸獅子羔羊（CN) 及其筆名擁有者所有。為保護微信公眾平台的【原創】特性，有意轉載者請聯係作者
二零一零年底我接受了惠普的聘用加盟惠普，我的職位是企業應用架構師。開始工作的第一個頂目是為一個中西部州，叫它MI州吧，開發的一個管理車輛駕照的政府職能操作係統。
在這裏先介紹一下在我加盟匯普之前的事。在二零零七年時在美國市場上最大的谘詢服務公司有IBM，HP，EDS， 和Accenture 。
說最大也就占市場的4%到6% 之間。EDS 和HP各占4%左右。如果兩家加起來就是最大的谘詢服務公司了。EDS 曾今是GM的一部分後來分出來了。還有一家公司不能不提，那是Saber，Saber是一家由兩個印度兄弟開辦的公司，雇員大多是印度人。他們以非常有競爭力的價格從政府那裏拿到項目。有選舉係統，有失業救濟係統，有車輛駕照管理係統，有兒童早期教育係統。應有盡有。公司做得有模有樣。
相反EDS就不那麽成功，總是在價格上輸給Saber。 最後突發奇想決定買下Saber。 最後以168 Million 成交。兩兄弟得了錢後就走了。可是EDS的業績還是不行。最後到了破產的邊緣。迫於無奈最後以低於其年產值的價格賣給了恵普。一般公司的市值應該是其年產值的三倍，由此可見其經濟狀況的困難了。在交談中有一位EDS的資深人士對我說如果惠普推遲一周簽字的話EDS就要宣布破產了。
話說惠普在其CEO Mark Hurd的領導下買下了EDS成了世界上最大的谘詢服務公司，而且價格如此優惠，就算是拿下EDS的客戶群也值了。這也正是惠普市場轉型的關鍵步驟。
可是由於其它原因Mark Hurd被匯普董事局開除了。隨著 Mr. Mark Hurd走的也有他重組改造EDS的計劃。這樣把EDS弄到破產程度的EDS領導層繼續領導在惠普名下的EDS/Saber.
在這個過程中最成功的要算Saber 的印度兄弟。他們成功地把公司做成一個看起來不錯的公司並賣了一個好價錢。其實其職員水平很差。產品介紹無中生有。EDS繼續它的破敗之路。最倒黴的是惠普，買了一個無底洞隻投錢看不見生錢。最後大麵積裁員，在財務上write off。這個項目是二零零八年開始的，原計劃二零零九年完成。可是在我二零一零年底加入恵普，項目還沒有結束的影子呢。
其實我認為這個項目是可以成功的，隻是由於EDS管理層的無能和Saber員工的無德，好的主張和有真才實學的人無法得到重用以致最後項目失敗。
開始時我還住在克利夫蘭，一周兩次，往返兩百邁。在公司時與編程人員一起看程序，了解曆史背景，了解係統設計。在家工作時埋頭看程序。兩個月後太太也加盟恵普。我們就舉家遷移到哥倫市的都佰林市定居下來了。
在這裏先介紹一下那個係統的來由。大約在二零零六年左右，Saber拿到了第一個客戶，就叫它VT州吧，公司就開始了這個開發項目，一年後又拿到了第二個客戶，叫它RI州吧，公司就把源程序複製一份然後在複製的基礎上為RI的需求進行進一步開發，VT州的開發工作繼續向前。當時對RI州的賣點是“我們有一個現存的係統，改改就成了，我們是這一方麵的專家”
二零零八年，saber用同樣的手法簽下了MI州的合同。根據合同，項目一期工程一年後交付使用。可是在我二零一零年底加入惠普時係統還遙遙無期呢。
在二零一零年中故技重演簽下了第四個客戶，叫它NM州吧。在EDS買下Saber時公司看起來一片興旺，除了車輛管理係統還有兒童早期教育管理係統，競選係統，失業保險係統，州政府醫保係統。可是其內在的問題非常嚴重，它不停地啟動新項目可是卻不能成功地完成項目。可是EDS並沒有認真地審查公司的技術含金量就貌然決定重金買下Saber，而且最讓人大跌眼鏡的是EDS放棄其奉行幾十年的應用開發流程，全盤接收Saber的應用開發流程，好像是終於找到了救命靈丹了。可見EDS的領導層的水平如何。
從技術上講，Saber的複製-修改的做法至少是短視的。從架構的角度上講是一個嚴重錯誤。我在HA時也遇到過類似的經曆，我當時的態度是：除非我死了，不然想都別想！“Over my dead body！". 正確的應對應該是一、盡量用數據配置的方法來實現不同用戶的需求，二、 確保係統核心源程序共享，同時允許個性化不同實現。這兩個方向都需要很高的設計水平，如果架構師的水平不夠的話是有較大的難度的。從我後來與原架構師的溝通中我對他有些了解，也非常理解他的處境和技術水平的。在項目後期他被迫離職了。
放開多用戶源程序共享不談，其實他的設計也不太差，如果開發人員都尊照他的開發思想去做的話，也不致於到了徹底失敗的境地。失敗是有多層麵的原因的。讓我來具體分析一下：
從管理層來說，他們對軟件開發的複雜程度了解甚少，雇的人的水平也不好，在質量方麵總是抱著僥幸的心理。我的老板就我發現的技術問題對我說了這樣的話“可能你發現的問題不像你描述得那樣嚴重，可能客戶不會發現呢？我們就希望客戶中沒有像你這樣高水平的架構師。你可不要為那個客戶工作呀！”
從架構設計師的方麵，一個重要的問題是架構師的水平，和他們的工作態度。架構師們總是把自己放在開發人員之上，連座位也與開發小組分得開開的。就有一位架構師私下的我說他的理想工作就是不再看源程序了。他們所提出的主張一般都不太現實，可是他們不用在具體工作中受苦，所以無所顧忌。
從項目管理人員來說，他們最關心的是項目進度，一切注重質量，致力於長期開發效率的努力都不被他們歡迎。可是正是由於他們對進度的瘋狂追求反而造成了一次一次地不能按時交貨。
從開發人員來說，本身的技術水平就不高，沒有架構師的指導，也沒有有效的設計文檔。工作時間安排非常之緊，一旦出錯就被斥責。他們的態度就是隻要胡過今天就好，絕無長久的打算。可是就像住在公寓裏房客，因為不是公寓的擁有者，從不注重公寓環境的保護，總是以為你是暫時住在那裏，可是不管你是不是主人，你卻天天住在裏麵，一住就是三年，你也是你對環境破壞的受害者。每天工作痛苦不堪。
經過一段時間的了解和研究我開發出來一套在不太影響（10%）開發進度的情況下改進架構設計的工作流程，其關鍵步驟就是我審查所有的程度更動，提出修改意見並與開發人員一同工作實施修改。六個月後初見成效。一年後成績顯著。我以為我為公司找到了成功之路，就寫了一篇文章。從理論到流程，從技術到實例最後以程序質量指數證明其作用。並為此做了專題演講。演講結束後，一位資深架構師與我說：“there are only 3 persons understand what you were talking about. The first is you, the second is you, the third is also you." 他的意思很清楚：一、他懂我在講什麽並且讚成。二、其它沒人懂，也沒有人有興趣懂。
果然總架構師並不重視，開發經理多番作梗，原本有希望力挽敗局的我麵對日漸敗落的係統捶手頓足，一籌莫展。
就在這個時候，VT州的客戶找了個第三方做了個項目評定。第三方谘詢公司毫無困難地給出了一長長的問題清單和整改要求。VT州不像NM州那樣直接終止項目而是將這個評定報告給了惠普，並要求惠普給出整改計劃。我參加了整改計劃的討論，並就每一項問題提供了具體的整改措施。可是總架構師否決了我的大部分措施，理由是太過費時費工，與項目進度要求不符。在恵普的正式回複中對大多數的問題的回答是"開發期間不予處理，上線後期作為產後支持解決”。其結果是可想而知的了，VT州終止了合同並把恵普告上了法庭。
因為這幾個項目源於同一套源程序，VT項目有的問題MI項目也都有。我以為公司會從VT事件中吸取教訓會認真地在處理MI項目中的設計問題，認真地一一給出了技術解決方案並做了相應的論證試驗。可是出我預料的是項目經理和總架構師同出一轍地淡化問題，簡化解決方案，最後基本上是什麽都不做。
其間RI項目也出了狀況，客戶拒絕了整個係統要求限期整改並提出項目項目上線日期。麵對這樣的情況有一個架構師，就叫他G吧，他提出了軟件工廠的思路，根據G的思路軟件工廠生成75%的源代碼，程序員隻要寫1/4的源代碼加上測試就好了。EDS的上層領導層覺得好像是找到了金鑰匙，全力支持，就像幾年前全盤接受Saber 的軟件開發流程一樣。
由於我在HA的經曆我對這個從頭再來的計劃膽顫心驚，我約了G出來吃飯並分享了我在HA的失敗經曆。提醒他注意並且對他的軟件工廠向思路提出了質疑。可是他並不重視我的意見和經驗，一意提出了一個非常激進的開發計劃。具體地是六個月一期交付使用，九個月二期交付使用，十二個月項目結束。對此我的態度是“這真是太好了，好到不敢相信的程度。” 斷定不可能如期實現。與我有同樣觀點的還有一位熟知車輛管理流程的需求專家。可是EDS的高層壓製一切反對意見決定采納G架構師的方案。我與我的上司，架構部的主任，反應了我的觀點。可是我的上司卻告訴我他押在軟件工廠的方案上了，要求我全力支持。並要求我參與項目擔任架構總監（oversight）的職務。
作為一個敬業的工程師，我努力地工作，可是這造成了我與G的衝突。最後我寫了一個長長的電郵給我的上司主動提出退出項目。在電郵中我這樣寫道：如果你仍然相信G的設計，為了給他一個公平的機會你們應該讓他獨立地主持架構設計。如果有一天你們對他的設計失去信心了希望我來主持這個係統的架構設計，我會盡力去做的。不過把兩個設計理念不同的架構師放在一個項目裏不是一個最好的方法。對此，其中一個項目經理力挺留下我，可是他也被人放在一邊了。
自從那以後我基本上被閑置了。那是二零一二年。我除了做分配給我的工作開始了新的技術研究。我的研究有幾個方麵：一是在個人博客上發表係列文章描述我發現的技術問題和解決方案。二是致力於MVVM 軟件開發模式的研究。三是致力於移動應用的研究。四是學習最新版本的C#語言並努力通過微軟的資質證書。
在博客上發的第一篇文章就是“Tailor Ed has 4 sons.... The third suggests to use auto tailing machine. ”結論是“if something is too good to be true, probably it is!"
Ed is 影指EDS, auto tailing machine is 影指軟件工廠。4 sons 影指四個州的客戶。 結論是那不可能成功的。一年中發了近五十篇文章。
在MVVM的學習方麵我用學到的技術寫了一個用於監測股市的軟件。同事們都竟相索要。基於這個軟件我又寫了一個發言稿希望有機會在架構師部門做一個介紹。可是老板說隻有我同意與另外兩位架構師一道署名才可給機會讓我講。我問道：那他們在這方麵有研究嗎？答複是他們有興趣學習。我說“那這樣吧，為了鼓勵他們的學習精神，讓我把已經掌握的知識放一邊，與他們一同學習吧。”結果談話不歡而散，講座的事不了了之。
在移動應用開發方麵我在微軟視窗8.1麵世三個月後就推出了一個基於8.1的移動應用。並得了最佳應用獎。後來在同行的邀請下在哥倫布微軟移動興趣小組作了演示和演講。演講之前請示領導，得到的答案是隻要不提惠普，不提惠普的客戶就行。
在C#的學習方麵也取得了成功，在二零一三年初我就通過了徽軟件的資質考試。在這些工作的同時我還因為身體健康原因在二零一二年初又去克利夫蘭診所做了一個不小的手術。我的老朋友Daniel知道了我的近況後說你總是有辦法讓我驚呀你的成就，你是我的榜樣。
在一次例行一對一會議上我問我的上司：我在惠普工作了四年了，隻聽到這個那個項目終止了，沒聽到過哪個項目勝利完成了。你是不是聽到看到一些我沒聽到或看到什麽成功的案例呢？他說：我也希望我能說有成功的項目，可是我沒聽說過。I wish I could 。我又問道：那這是什麽原因呢，你有什麽見解可以改變這個現象呢？他的回答是：那不是我操的心了。(That is above my pay grade)
二零一三年底我覺得我真的不願意在惠普工作了，就開始找工作。在一四年三月就找到一個經理級的架構師的工作。工資漲了許多。由於惠普沒人睬我，也沒有管我，我在完成惠普分配給我的工作的情況下開始了新的工作。不過第一周我還是用了假期的。就這樣直到二零一四年一月，惠普辭退了我並給了十五個星期的遣散費。
離開惠普後不久得知MI州終止了項目並把惠普告到法庭。RI州的項目並沒有如G架構師計劃的那樣一年之內交付使用。一直拖延到一五年底並接近完全失敗。終止項目隻是時間問題了。惠普上層對EDS/Saber 這個部門完全失去了信心，決定終止所有項目辭退大多數人然後關閉這個部門。聞訊後我痛心地對太太說：我本可以救這個部門的隻是他們沒有給我這個機會，可惜了！
因為新的工作需要每周出差到佛羅裏達州，我又開始了飛人的生活。
我在想，樓主如果不在這種服務性質的公司，而是到大公司去做原來被服務的那些人的工作。可能收入也不見得低多少，運氣好可能一點不差甚至更好。 但絕對會輕鬆許多。
Coming back to you question, a architect first need to be a good programmer. Second it need to be able to design with big picture in mind. You need not only know "how" but also know "why".
Before "how" and "why" you need to know "what"
It takes lots of hard work, probably making lots of mistakes before you can be a good architect. It also takes lots effort to keep it up with these new technologies.
There is a book I like it a lot, the title is "architecting application for the enterprise" it might answer some of the question you have. But do not expect you becoming an architect after you read the book.
Please send my private message should you have further question on technical topics.