C02-商業模式與架構設計- IT閱讀

架構師需要考慮的商業要素 · 軟體是現實世界的對映和抽象 · 商業與技術的關係 · 商業和產品做加法，架構設計做減法 · 大樹的隱喻描述商業，架構，研發技術生產 ... C02-商業模式與架構設計 首頁 最新 HTML CSS JavaScript jQuery Python3 Python2 Java C C++ Go SQL 首頁 最新 Search C02-商業模式與架構設計 2020-06-09254 商業模式與架構設計：A段架構與B段架構 《思考軟體創新設計：A段架構師思考技術》 A段架構師必須具備鮮活的創新思維，睿智的策略思考，犀利的洞察力和靈活的戰術才能把握稍縱即逝的商機                              　　                            段架構師 B段架構師 關注點 產品策略規劃 實踐策略，執行能力，技術變遷 協作物件 協助產品經理 協助研發經理生產經理 思維的差異 獲利思維，知彼才能在複雜商業環境生存 成本思維，知己才能在成本和收益做出合適選擇                   目前我們所接觸的大多是B段技術的架構，更關注“知己”，我們做研發改進，敏捷管理，技術重構，就是為了更好的平衡技術的成本和業務的收益    A段架構與商業模式：以不變應萬變   架構師需要考慮的商業要素 決策前（A段設計）---->決策點--->決策後（B段設計）   商業思維三要素：商業模式，架構模式，創新產品   軟體是現實世界的對映和抽象 現實世界是複雜多變的，所以由需求就是複雜多變的，軟體也是複雜多變的， 所以現實中組織要發展就要面對變化的適合的變化，反應到軟體上也會隨需求的變化而變化，所以軟體本質上是一個演化的系統，是一個複雜的系統   商業與技術的關係 商業維度，現實世界是複雜多變的組織需要不停的適應市場的變化， 從產品維度需要不停的創新滿足客戶和市場的需求， 而從技術和架構的維度來看，架構則希望更少的資訊熵，用更少的技術元素來表述更多的業務結構，這也正是為什麼我們追求模型，模式，結構與演算法    商業和產品做加法，架構設計做減法  在複雜的現實中，用簡單的抽象來支撐商業的變化，用靈活的設計支援業務的創新   《深奧的簡潔》是一本科普讀物，裡面講述了碎行，自我組織，自我類似等等自然界好些美妙的規律 https://zh.wikipedia.org/wiki/%E5%88%86%E5%BD%A2#%E7%A4%BA%E4%BE%8B     大樹的隱喻描述商業，架構，研發技術生產管理 大樹的上層是枝葉，要吸收陽光雨露，要開花結果，是對外界展示的活躍和生機的一面，這裡用來表述商業模式和創新產品 這些都是要變化的部分，而且收外部影響較明顯   再次是樹幹是中層A段架構，中層要求穩既要約束和輔助枝葉發展和繁榮又要保護下層樹根承受壓力   下層部分的話就是B段架構，生產，技術，管理，這些是看不見但是很重要的元素，是整個樹木生命繁榮的根本     從複雜中抽象出簡單，用簡單和較少資訊熵，應對複雜多變的商業和產品 簡單的有序的產品和架構設計，通過一定的約束組合可以形成一個富有活力的系統，底層元素的簡單又保證了它可以包容現實中的複雜變化，應對紛繁複雜的現實情況，支援商業的變革和產品的創新     B段架構技術和業務的矛盾：用成本收益作為衡量標準   變的是需求和技術，不變的是成本與收益評估，是要創造價值的目標   "你這個功能啥時候能上?" "這個有難度目前不行，需要做重構，技術細節blablabla..." "提這麼多需求沒幾個有用的，根本不懂技術實現，你要覺的能行為啥你不上"   產品和技術的矛盾點： 1.資源的搶佔2.成本的評估3.內外部目標的差異4.內部目標設定不合理   解決問題：業務知識+成本核算 技術要了解業務背景，業務收益，要解決的問題是什麼？只有這樣才能解決問題，做出架構設計，做出模型設計，解決業務問題，幫助客戶解決現實場景的問題   優秀的架構要融和技術與業務的平衡和成本收益的評估   1.清晰服務業務短期目標，明確技術定位，輔助實現當前階段業務訴求 2.協調技術資源投入和分配 3.進行成本與收益的評估，確定做哪些，不做那些，先做那些，怎麼做收益更大 4.預留長期技術規劃和儲備   我們是解決昨日之債務，還是準備迎接今日之挑戰？ 衡量的標準就是做這件事的收益？   產品和業務做哪些收益更大：產品的願景和價值觀 本年度看做哪些收益更大（OKR） 本季度本月做哪些收益最大（月度發版路標規劃） 當天本週做哪些收益最大（周計劃）   舊系統的改造OR新技術的引進？ 技術儲備和技術棧規劃方面： 中小型創業型公司，非技術驅動的公司 關注中長期發展的技術與趨勢，不要太超前，不必做小白鼠   舊系統改造方面： 假如不能明顯的產生業務價值，單純的把報表生成把半小時優化到5分鐘，不如做一些其他更有業務價值的任務 假如沒有其他高附件值任務可以去做，假如報表生成佔用研發時間減少了質量保證時間，影響了交付質量也可以去做     相關文章 C02-商業模式與架構設計 netty原始碼分析(十七)Netty執行緒模型深度解讀與架構設計原則 乾貨|DDD實戰：基於洋蔥模型的分層程式碼架構設計 跟我學程式碼架構設計模式之--切面思想和代理模式 跟我學程式碼架構設計模式之--異常還是返回值？ 跟我學程式碼架構設計模式之--同步的引入 跟我學程式碼架構設計模式之--協議棧的設計思路 跟我學程式碼架構設計模式之--鎖和執行緒的補充 跟我學程式碼架構設計模式之--Lock和Condition 跟我學程式碼架構設計模式之--鎖和執行緒 Java高併發程式設計詳解：多執行緒與架構設計 交換平臺第二章：專案邊界與架構設計（上） 讀《MySQL效能調優與架構設計》筆記之充分利用Explain和Profiling .Net企業級應用架構設計之資料訪問層 .Net企業級應用架構設計之業務層設計 分類導航 HTML/CSS HTML教程 HTML5教程 CSS教程 CSS3教程 JavaScript JavaScript教程 jQuery教程 Node.js教程 服務端 Python教程 Python3教程 Linux教程 Docker教程 Ruby教程 Java教程 JSP教程 C教程 C++教程 Perl教程 Go教程 PHP教程 正則表達式 資料庫 SQL教程 MySQL教程 PostgreSQL教程 SQLite教程 MongoDB教程 Redis教程 Memcached教程 行動端 IOS教程 Swift教程 Advertisement 三度辭典 Copyright©2016-2021IT閱讀  Itread01.comAllRightsReserved. 0.001291036605835