Due to the promotion of the concept of "center console", more and more readers are concerned about business architecture, and many companies are eager to implement the "center console" and "center console" methodologies. History is always similar. When popular technology concepts such as SOA, microservices, DDD, or agile development, dual-mode development appeared before, they once gave everyone the hope of "shortcuts".
However, it turned out that there is no "silver bullet" in the software field . In many cases, it is a Nordic saying: shortcuts are the fastest way to get lost.
There is no shortcut to architecture , whether it is from the aspect of architecture design, architecture implementation or architecture learning.
1There is no shortcut for architecture design
The architecture design is like seeking medical advice, and it must be right . Blindly believe that any existing architectural design effort is dangerous and extremely irresponsible. Each person's body has its own characteristics, and so does the enterprise. Enterprise-level transformation and enterprise-level engineering are the biggest adjustments to the company's existing capabilities. They need to be carried out on the basis of a clear understanding of the company. Anyone who ignores the "look inward" process The design of the architecture is a foreshadowing for future confusion and even failure.
For complicated surgery, the doctor will not easily perform surgery on the patient without detailed diagnosis and repeated trial and error. Otherwise, he will not hesitate to use life to do the test. Although software engineering rarely has the "human life is off the sky" thing, wasting time is also equivalent to wasting life.
Having not done an in-depth "physical examination" for an enterprise and easily believe in "leading practice", it is easy to double the "time" to save the time and energy saved in the architecture design into the implementation process.
Enterprise-level architecture design often gives people the impression that it is too long and difficult to respond to changes, but people just ignore the accumulation of architectural knowledge and the process from quantitative change to qualitative change.
When people feel that a "traditional" enterprise-level business architecture design method may take one to two years, and the Internet era is chasing "fast", they are not fully aware that the architecture of Internet companies, such as Ali's "center console" It has also gone through more than ten years of accumulation, and the accumulation of more than ten years has just sorted out one direction, otherwise there will not be many opinions on the concept of "center console" today.
The Internet architecture does not mean that there are "shortcuts" in the design of the architecture. Instead, it proves that any "fastness" comes from its own accumulation, and it is the "fastness" that comes from the "inward look". " Fast" comes from a deep understanding of business, and the precipitation of public capabilities in "Central Taiwan" comes from the induction and refinement of business capabilities . Therefore, Ali attaches great importance to the training of business architects. Exploration is not limited to the precipitation of public capabilities. It will eventually rise to the understanding of the enterprise as a whole and what is business operation. This is a natural process.
The author learned from the recent exchanges with the former Ali Zhongtai core architect, Mr. Pilu, that during the design of Zhongtai, they also repeatedly thought that the technology should work hard to support the rapid changes in business operations.
What exactly is the business operation? In fact, after everyone's concern gradually rises from the domain level to the enterprise level, they will definitely think about what the enterprise is and how the enterprise operates.
The Internet architecture is not simply a quick trial and error. This trial and error is to support the ability to select business . From a technical perspective, it is a continuous refinement of the architecture capabilities. It is the strong architecture that enables rapid design.
Therefore, there is no shortcut for architecture design. Only accumulation can improve the company's own understanding and control of the architecture design, and then there can be a quick "capital".
Here, I have to say the Nordic folk saying mentioned earlier: Shortcuts are the fastest way to get lost. Whether it is an enterprise or an individual, you must have a deep understanding of the learning curve before switching architecture design methods. Otherwise, when others are in the original As you go further and further in the direction, you may still be spinning around, just to provide a case for others.
The author is responsible for setting up a risk management system at the company in 2019, and this work once again made me realize that the structure cannot be "copy".
Risk management is a very mature field. The three lines of defense system design method is used by both financial and technology companies, domestic companies and foreign companies. However, you cannot directly apply the defense line design of other companies. In the past, you must analyze your own company's processes on a work-by-work basis, identify risk points, identify the team responsible for the work item, and implement specific risk control responsibilities. Then, consider whether risk control measures can achieve "machine control", and It all depends on whether the work item is online.
Only in this way can a comprehensive risk management system that conforms to the actual working environment and integrates the direction of digital risk control. This kind of in-depth and detailed system construction cannot be obtained by copying any existing experience, otherwise there will be a situation of "cutting down and performing properly." There are no "shortcuts", only "paths".
2architecture is no shortcut landing
There are often readers who are curious about the implementation of enterprise-level business architecture design. The author bluntly stated in the book and at the center console Conference in Nanjing in December 2019 that the implementation process of enterprise-level business architecture design is not mysterious and special, nor should it Today, the author believes that enterprise-level business architecture is becoming increasingly important, not because it has any shortcuts to landing. The implementation process of any architecture design is realized by a logic, a logic, a module and a module .
The design of the enterprise-level business architecture only makes the organization of the business end more structured and integrated. Unlike the attention to local details of requirements analysis, and the regional characteristics of product analysis, the enterprise-level business architecture focuses on the overall capabilities of the company. Planning and structured expression, but it does not mean that there is any particularity at the implementation level, it just provides a "baton" in the software process and forms guidance for the division of software functions through business architecture design.
What's more important is that a business architecture model that can be understood by both business and technology enables enterprises to form a "common language" that can communicate, even across domains.
This "baton" is indispensable for improving the integrity of the enterprise, and management has been studying how to form a management synergy within the enterprise.
In the early days of the birth of business architecture, in the 1980s and 1990s, the level of enterprise informatization was not as high as it is today, and the deep integration of business and technology has not been valued by applications. But today, Taobao, Didi, Meituan, and Toutiao Such cross-border competitors have brought great competitive pressure to the original companies in traditional industries. Many people even agree that most of the companies in the future will be transformed into technology companies. ICBC leaders have also recently made such comments.
It can be seen that it is necessary to strengthen the deep integration of business and technology. The business architecture is a tool that meets the requirements of this era . It gives enterprises a clear view of capabilities. A clear structure coupled with the evolution of the architecture may continue to improve. Architectural flexibility.
Business management often pursues resilience. It is often said that companies want to be like tightening towels. The tightening and tightening will not break. In the future, given that enterprises have technological attributes, such "toughness" may come from the "elasticity of the architecture. ".
Improving the integrity of an enterprise is like training for a marathon. Although the business structure provides a powerful tool, the marathon still has to run step by step through the trainer. The improvement of performance depends entirely on the ability and perseverance of the trainer.
Back to software engineering, even if agile processes are adopted for the implementation of the architecture, it does not mean that there are any "shortcuts", but only the improvement of the engineering organization and the pursuit of efficiency.
The author recently read the book "Agile Revolution". Compared with the widely spread "Agile Values", the creators of Agile methods actually pay more attention to how to fully obtain and share information through a good thinking model in a short cycle. This method provides core values quickly, thereby reducing the risk of project failure caused by too long project cycles, and replacing long-cycle uncontrollable processes with multiple controllable "sprints" of short cycles.
The creators highly respect the OODA principle , which is the " observation-oriented-decision-action" model adopted in pilot training . In fact, this idea is reflected in every agile Scrum.
"Observation" represents the rapid acquisition of comprehensive information; "Orientation" is to rely on a mental model for rapid analysis, that is, a rapid design process; "Decision" is to determine the conclusion, no longer hesitate, and "Action" is to implement the decision .
The original author also emphasized that in a Scrum, as long as the needs are determined, they should be as immobile as possible. This is the same as the pilot's "decision" and "action" mode, because the air combat time is too short, and there is almost no chance to regret returning.
The agile method creators highly value Toyota's production methods, and I happened to have recently read "Xinxiang Zhongfu talks about Toyota's production methods". Toyota's production method, also known as "lean production" and "just-in-time", is the ultimate pursuit of rejecting "waste". This waste does not refer to the waste of raw materials, but the waste of time and efficiency.
For example, when Toyota is thinking about the waste caused by the transportation of raw materials between different production sites, the first solution is how to avoid the transportation and adjust the production environment through this thinking; for example, it is reflecting on how to improve the efficiency of the burring of parts. At that time, the method of introducing European vacuum processing technology was adopted so that the parts did not generate burrs at all.
There are many other examples of this kind. It is through this continuous pursuit of bit efficiency improvement for nearly 20 years that the Toyota production method was finally created.
The formation of any method is a process of long-term accumulation and reflection, and the application of these methods also requires the user to make a reasonable effort to master. Architecture design is ultimately a software engineering problem. There are no shortcuts, but only constant efficiency improvement. Whether it is the Toyota production method that inspired the agile method creators, or the agile method creators' own practice process, it is a process of continuous improvement and increasingly sophisticated methods.
Before you really understand the method, you ca n’t talk about efficiency at all. Instead of always switching between methods to get “fast”, you might as well practice your existing kung fu to the utmost. As long as the problem-solving efficiency is high, you It is "one faction". "Four thousand and eight thousand methods" can become Buddhas, and it is even better to be able to "boost the talents" in the cultivation process. In fact, the original author of the agile method created the agile method.
3architecture is no shortcut to learning
There is no shortcut to becoming an architect, only hard work. The study of architecture requires a lot of basic work and requires a wide range of involved. In this regard, the author has introduced in the article "Six aspects of learning to help you embark on the road of business architect", in architecture capabilities, process optimization, modeling technology , Software process, programming language, and overall thinking, there is a lot of knowledge to learn, and some reference books are also listed, and will not be repeated here.
No matter what kind of architect, you need deep accumulation, the architects are piled up by the project.
It is undeniable that the growth of Internet enterprise architects is indeed fast. This may be that the enterprise mechanism provides more testing opportunities for qualified persons to enable them to make rapid progress. If there are any methods that can be called "shortcuts" for cultivating architects, for enterprises, it is to seriously consider whether they have established a mechanism to quickly discover talents and cultivate talents. Otherwise, Ali said, business architecture Teachers can only train themselves, and nothing can be done without the right talent.
Recently in a series of "Doctor X", a superb medical heroine said in a very difficult operation: "Like a river flowing, repeated basic skills can create beauty The final surgical field is the ideal surgery … the most important thing is that no matter how difficult the operation is, you cannot abandon the patient. "I think this is also applicable to the field of architecture.
There are no shortcuts to the structure. Some are just the shoulders of the predecessors. They study hard, practice actively, digest and understand, and really stand on the shoulders of the predecessors to see the direction of the advance. The shoulders of the predecessors are not limited to what you are engaged in. industry.
About the Author:
Xiaoyan Fu, author of "Enterprise-level Business Architecture Design: Methodology and Practice", former senior business architect of State-owned Big Bank, responsible for business architecture design and project management, keen on new technology exploration and practice, has rich banking experience and enterprises Grade-level project business architecture design experience. He has led the business architecture design of core systems in customer relations, financial markets, peers, asset management, pensions and other fields. Now he works for CCB Financial Technology Co., Ltd. A new book, "Digital Transformation of Banks," is about to be published. Public account: Xiao Tanyan said.
由於“中台”概念的推動，關心業務架構的讀者越來越多，很多企業也對實施“中台”、“中台”方法論趨之若鶩。歷史總是相似的，之前無論SOA、微服務、DDD，還是敏捷開發、雙模開發等熱門技術概念出現時，都曾經給大家燃起“捷徑”的希望。
然而，最終還是證明了軟件領域沒有“銀彈”，很多時候，反倒是應了北歐的一句民諺：捷徑是迷路的最快方法。
架構沒有捷徑，無論從架構的設計、架構的落地還是架構的學習方面來講，都是如此。
1架構設計沒有捷徑
架構設計如同求醫問診，必須對症下藥。盲目相信任何已有架構設計成果都是很危險且極不負責任的。每個人的身體都各有特點，企業也是如此，而企業級轉型、企業級工程是對企業現有能力的最大調整，需要企業在認清自己的基礎上進行，任何忽略“向內看”過程的架構設計，都是為今後的混亂，甚至失敗埋下伏筆。
對於復雜手術，不經過詳細的診斷，不經過對術式反复揣摩，醫生不會輕易為患者開刀，否則，不啻於用生命做試驗。軟件工程雖然少有“人命關天”的事情，但是，浪費時間也等同於浪費生命。
沒有為企業做過深入“體檢”而輕易相信“領先實踐”，很容易把在架構設計上節省的時間和精力，加倍“奉還”到實施過程中去。
企業級架構設計往往給人以過於漫長、難以響應變化的印象，但是，人們恰恰忽略了由此帶來的架構認知的積累，以及由量變到質變的過程。
當人們感慨一次“傳統”的企業級業務架構設計方式可能耗時一到兩年，而互聯網時代非常追逐“快”時，其實並沒有充分意識到，互聯網企業的架構，比如阿里的“中台”也經歷了十餘年的積澱，而且十餘年的積澱也還只是理清了一個方向，不然也不會有今日對“中台”概念的眾說紛紜。
互聯網架構並不代表架構設計上有“捷徑”，反而證明了，任何“快”都來自於自身的積累，是充分“向內看”才有了外在的“快”。“ 快”源自對業務的深刻理解，“中台”對公共能力的沉澱正是來自於對業務能力的歸納和提煉，所以阿里才十分重視業務架構師的培養，而對“中台”的探索絕不僅限於對公共能力的沉澱，最終會上升到對企業整體、對何為業務經營的認識，這是一個自然的過程。
筆者在最近與原阿里中台核心架構師毘盧老師的交流中了解到，他們在進行中台設計時也在反复思考技術要努力支持業務經營的快速變化。
那業務經營到底是什麼？其實，大家關注的問題從領域級逐步上升到企業級之後，是一定會思考到底企業是什麼、企業如何運轉這些問題的。
互聯網架構並非簡單地快速試錯，這種試錯是對業務選擇能力的支持，而從技術視角看，則是對架構能力的不斷提煉，是架構的強大才有了快速設計的可能。
所以，架構設計沒有捷徑，唯有積累，通過積累提高了對企業自身的了解、對架構設計的駕馭能力，才有了可以快的“資本”。
此處，還得再說一次前邊提到的北歐民諺：捷徑是迷路的最快方法，無論是企業還是個人，切換架構設計方法前，都要對學習曲線有深刻的認識，否則，當別人在原來的方向上越走越遠時，你可能還是在原地打轉，只不過為別人提供了案例。
筆者2019 年在公司負責搭建風險管理體系，而該項工作再次讓我認識到，架構不是可以“抄”的。
風險管理是個很成熟的領域了，三道防線的體系設計方式，無論是金融企業還是科技企業、無論是國內企業還是國外企業都在使用，但是，你卻無法直接把其他企業的防線設計簡單套用過來，必須一個工作事項一個工作事項地分析自己企業的流程，確認風險點，確認工作事項的負責團隊，落實具體的風控職責，之後，再考慮風控措施是否可以實現“機控”，而這一切又取決於該工作事項是否已經線上化。
這樣才能形成一個與實際工作環境相符，並融合數字化風控方向的全面風險管理體系。這種深入細節的體系建設無法通過照搬任何現成經驗來獲得，否則會出現“削足適履”的情況。沒有“捷徑”，只有“路徑”。
2架構落地沒有捷徑
經常有讀者好奇企業級業務架構設計如何落地，筆者在書中、在2019年12月南京的中台大會上都直言，企業級業務架構設計的落地過程沒有任何神秘和特殊，也不該有，今天筆者認為企業級業務架構日益重要，並不是因為它有什麼落地的捷徑，任何架構設計的落地過程都是靠一個邏輯一個邏輯、一個模塊一個模塊地實現的。
企業級業務架構設計只是讓業務端的整理更加的結構化、整體化了，不同於需求分析對局部細節的關注，也不同於產品分析的領域性特點，企業級業務架構關注的是企業能力的整體規劃和結構化表達，但它並不意味著在實現層面有何特殊性，它只是提供了軟件過程中的一個“指揮棒”，通過業務架構設計形成對軟件功能劃分的指導。
而更重要的是，通過業務和技術都能理解的業務架構模型，使企業內部形成可以交流、甚至可以跨領域交流的“共同語言”。
這個“指揮棒”對於提升企業的整體性而言是必不可少的，管理學上一直在研究如何讓企業內部形成管理合力。
業務架構誕生初期，在上個世紀80-90 年代，企業的信息化程度還不如今日這麼高，業務和技術的深度融合還沒有受到應用的重視，但是今天，淘寶、滴滴、美團、頭條等跨界競爭者給傳統行業的原有企業造成了極大的競爭壓力，乃至很多人都認同未來企業大部分都將轉型為科技企業，工行的領導者最近也發表了此類言論。
由此可見，加強業務與技術的深度融合已經十分必要了，而業務架構正是符合這種時代要求的工具，賦予企業清晰的能力視圖，清晰的結構加上架構的演進，就可能會不斷提升架構的彈性。
企業管理經常追求韌性，常說希望企業能夠像擰毛巾一樣，越擰越緊卻不會擰斷，而未來，鑑於企業都具有科技屬性，這樣的“韌性”可能就要來自於架構的“彈性”了。
提升企業的整體性猶如進行馬拉松訓練，業務架構雖然提供了一個有力的工具，但是馬拉松還是得依靠訓練者一步一步地跑完，成績的提升完全取決於訓練者自身的能力和毅力。
回到軟件工程上，架構落地即便是採用敏捷過程，也不意味著靠的是什麼“捷徑”，而只是對工程組織方式的改進和對效率的追求。
筆者近日閱讀了《敏捷革命》一書，與廣為流傳的“敏捷價值觀”相比，敏捷方法的原創者其實更在意的是如何通過信息的充分獲取與共享、良好的思維模型，以短週期的方式迅速提供核心價值，從而降低項目週期過長導致的項目失敗風險，通過多輪短週期的可控“衝刺”替代長周期的不可控過程。
原創者非常推崇OODA原則，也就是飛行員訓練中採用的“ 觀察-導向-決定-行動”模式，其實每一次敏捷的Scrum中都體現了這一思想。
“觀察”代表了對全面信息的迅速獲取；“導向”是依靠思維模型進行快速分析，也就是快速的設計過程；“決定”就是確定結論，不再猶豫，“行動”就是將決定付諸實現。
原創者在書中也強調一個Scrum 內，需求確定後就盡可能不動，這與飛行員的“決定”、“行動”的模式一樣，因為空戰時間太短了，幾乎沒有後悔重來的機會。
敏捷方法原創者十分推崇豐田的生產方式，筆者恰好最近也讀了《新鄉重夫談豐田生產方式》一書。豐田的生產方式，又稱“精益生產”、“Just-in-time”，是對拒絕“浪費”的極致追求，這個浪費指的不是原材料的浪費，而對是時間、效率的浪費。
比如，豐田在思考原材料在不同生產場地間搬運造成的浪費時，首先的解決思路是如何做到不搬運，通過這種思考去調整生產環境；再比如，在反思如何提高打磨零件毛刺工作的效率時，採用了引入歐洲真空加工技術，讓零件根本不產生毛刺的方法。
諸如此類的例子還有很多，正是通過這種對點滴效率提升的持續近20 年的不斷追求，才最終打造出豐田生產方式。
任何方法的形成都是一個長期積累和反思的過程，而應用這些方法也需要使用者付出合理的努力加以掌握，架構設計的落地說到底是軟件工程問題，沒有捷徑，只有持之以恆的效率提升。無論是給予敏捷方法原創者靈感的豐田生產方式，還是敏捷方法原創者自己的實踐歷程，都是一個對方法持續改進、日益精熟的過程。
沒有真正理解方法之前，根本談不上效率，與其總是在方法之間換來換去地求“快”，不如真把自己已有的功夫練到極致，只要解決問題的效率高，你自己就是“一派”。“四萬八千法門”都能成佛，能夠在修煉過程中“博採眾長”就更好了，其實敏捷方法的原創者也正是這樣創立敏捷方法的。
3架構學習沒有捷徑
沒有成為架構師的捷徑，只有勤學苦練。架構的學習需要很多基礎性工作，需要很廣泛的涉獵，這方面筆者在《六方面學習，幫你走上業務架構師之路》一文中有所介紹，在架構能力、流程優化、建模技術、軟件過程、編程語言、整體思維方面，都有很多知識需要學習，也列出了一些參考書目，此處不再贅述。
無論是哪一種架構師，都需要深厚的積累，架構師都是項目堆出來的。
不可否認的是，互聯網企業架構師成長確實很快，這也許是企業機制提供了更多的考驗機會給適任者，使其能夠快速進步。如果說培養架構師有什麼勉強可以稱之為“捷徑”的方法，對企業而言，就是認真思考下自己是否建立了快速發現人才、培養人才的機制吧，否則，阿里說過了，業務架構師只能自己培養，沒有合適的人才是什麼也乾不成的。
最近在一部《Doctor X》的連續劇中，醫術高超的女主角在一場難度極高的手術中，說了這樣一段話：“就像河水流淌一樣，反复的基本技巧，就能創造出美麗的最終術野，那就是理想的手術……最重要的是，不管手術再艱難，也不能拋棄患者”，筆者想，這也同樣適用於架構領域吧。
架構沒有捷徑，有的只是前人的肩膀，努力學習，積極實踐，消化理解，真正站在前人的肩膀上，才可能看到前進的方向，而前人的肩膀也不僅限於你所從事的行業。
Ref:https://mp.weixin.qq.com/s/f8F2REf4AH37lsTybKTt2w