【题记】 如果你有意地避重就轻，去做比你尽力所能做的更小的事情，那么我警告你，在你今后的日子里，你将是很不幸的。因为你总是要逃避那些和你能力相联系的各种机会和可能性。--马斯洛
今天谈谈企业架构的事儿。
大约10年前给互联网公司做过咨询，彼时互联网业务风头正盛，也是国家给与政策上充分灵活度的好光景，具有互联网行业属性的CIO\CTO们无比自信于自身已经历过的技术架构并带来的当时看来特别新的业务模式—平台业务—其实就是电商3.0，他们将企业从传统笨重、官僚的运营模式努力地往敏捷的Devops运营模式上去拉动，这应该说是一历史贡献，暂且勿论其变革成败，让更多企业认识到了外来物种的进化模式正在打败他们的循序渐进，从而必须向新生产力学习。
数字原生企业跟传统企业一个关键区别在于技术债务不重，天然重用服务，它们考虑的是如何在数字原生环境下创新企业结构。另外一个关键区别在于数字原生代拥有着高技能和业务&IT经验丰富的技术人员，他们已经生活在一种新兴文化中，在几乎没有历史遗留问题的现代架构上天马行空、开发运营。
但是物极而必反，任何组织和人的能力都是有疆界的，当时的这些CIO\CTO们也如此，他们沉迷于改造企业、完成业务绩效的同时，却一直有一个疑问，似乎总是缺少这么个角色帮他做统筹构思，似乎彼时被他们嫌弃的“经典管理方法早已过时”的麦肯锡、波士顿、IBM、HP的管理方法，正在以如行业巨匠一般、一如既往、深耕细琢于企业整体性难题的既有态势逐步回归。在看着互联网公司呼啸而过的若干年，他们的经典思维就慢慢躺在那里、但从未停止前进，因为被风沙暂时掩埋的宝藏终于一天还是会被懂行的人群所发现。
这些经典方法中其中之一便是企业架构。
很多企业通常没有真正意义上的企业架构师，大多数那只能叫软件架构师，局限于某个系统，或者叫系统架构师，主要对系统接口、做数据集成的...往往没有任何正式头衔的“企业架构师”。当然，金融业往往是产业先驱，有些金融企业已经设置企业架构专岗了，一般在PMO办公室或者在架构办、战略办。企业架构师就是扫地僧，你短期内看不到他的显性价值，只有将其融入到企业运作之中，方显英雄本色。
企业的管理人群（包括互联网背景的人群）难以理解为什么他的组织里需要这么个看起来是扯犊子的货，他到底干点啥？给他业绩考核？他好像也不干啥正事儿、啥啥都懂、啥啥都能做，但他好像还不愿意去做销售，你让他去做技术？实在是大材小用，因为这哥属于通才，你让他去做管理？他还不屑于当官、管人...知识分子实在可恶！
不仅仅很多管理者认识不到，很多开发团队的沦陷于各种给历史系统做修修补补对接之中的现实也无暇抽身思考系统性问题，他们完全可以在个人技能水平上超越数字原生企业的人们，但是他们的历史包袱太重，只能低头拉车，无暇随风起舞。他们习惯于完成一个又一个的点对点连接，以变通方法解决棘手问题，几十年如一日，然而行业加速洗牌的现实不会给这些企业太多修补时间了。
而企业架构恰恰能帮到企业的就是减少技术债、让多元业务服务得到更为高效的管理，基本前提是你就别补了...大型企业重建企业架构的难度、成本、风险都比较大因此概率也低，除非是像金融业这种被阿里金融等先进物种的进化效率吓怕了，再不改就废了；运营商其实也被微信抢去了大半江山，但是貌似还是不知所错、没有悔改，反倒开始做起了系统集成业务....官老爷的时代已经过去了，用户几个投诉、你乌纱帽就要颤一颤，让你甩黑锅的供应商小伙子在你们公司告你一状，就够你喝好几壶的...企业不变革、风气不调整、思维不进化，组织没希望。修修补补没有前途，必须大刀阔斧，虽属不同国家行业，金融业显然棋高运营商们一招，亡羊补牢了。
随着技术在推动商业价值中的重要性增加，企业架构(EA)的目标和需求也在快速变化。对于一个想要在数字世界中构建优势竞争力的企业来说，企业拥有的EA职能应是基础的核心元素之一。在这种时代环境中，EA团队应有三个目标。
目标1：辅助实现战略决策
设定战略方向一直是重要的EA任务，但随着许多企业变得越来越数字化，它已经成为业务级别的优先事项。过去，重大故障只会影响IT预算。现在，它们影响了整个行业。例如，在一个典型的零售环境中，整体架构中的一个主要缺陷，比如一个不能很好扩展的集成架构，会导致IT成本的轻微增加，但对利润的影响很小。然而，随着很大一部分销售转移到在线渠道，同样的错误可能会导致中断，造成大量销售损失。
类似地，EA应辅助企业决策，例如在哪里建立跨国家或业务单位的共享解决方案最适宜，在哪里若不建立则会对企业的战略和运营模式产生直接的消极影响。再拿零售业来说。当企业架构师决定是在两个系统(例如，销售点(POS)终端和电子商务系统)中实施结账和支付功能，还是在一个系统中实施时，这不仅是一个价值1亿美元的重大投资决策，而且还会对运营模式和企业实现成为全渠道零售商的企业愿景的能力产生巨大影响。
目标2：确保可重用性
在过去，确保可重用性主要是出于成本考虑，这意味着开发通常被视为一次性的活儿。快速开发和测试一次性搞定，然后就没然后了，这种局部视角的一劳永逸使得系统不断累积后的伸缩性很差，并导致要承担更大的技术债。
再说一个案例，一家零售企业实施了一种算法，在所有促销优惠进入其电子商务系统后计算最终价格。然而，支持移动结账的需求导致零售商决定再次构建这一功能。随着复杂和快速变化的促销机制，这种重复不可避免地导致不同的结果，因此当在线显示的促销与商店中的促销不一致时，会导致糟糕的客户体验。
昨天我遇到的某个在线购物不爽事件即如此，物流和后台运营、客服看到的系统数据都是不一样的...用户反复解释都不好使，确属非常糟糕的客户体验，不过还好，后来该平台给与了相应的补偿，这才挽留了我这个用户。
EA有责任审核新的解决方案中要建设的功能、数据是否会重复造轮子，在避免这种不良后果方面，扮演着至关重要的角色。这有助于确保一致的客户体验。架构师应该促进产品团队之间围绕特性和解决方案的讨论，使找到所有可重用的特性变得容易，并确保与总体策略保持一致。
目标3：实现开发速度
如果数字业务的灵活性和响应性没有在技术基础层面得到体现，那么这些特性就会受到严重阻碍。这意味着企业架构师需要管理一个一致的技术堆栈，该堆栈作为“嵌入式组装”的、可供新开发团队使用的平台。EA可以通过提供两件事情来实现这一点:拆解和明确团队需要开发、部署和测试新功能的所有技术组件，以及一组精心策划的“架构模式”——关于如何存储数据、与其他团队集成以及在产品团队的日常生活中执行其他常见任务的最佳实践
现代技术组织下的企业架构师必须以与三年前截然不同的方式运作。他们需要变得更加实际，而不是延续传统的“系统架构师”的角色和认识，以帮助IT交付商业价值和推动卓越工程。这一点非常难做到，首先带这个角色的管理人员就得认识到，否则他招的人还会是做系统集成的....
企业架构师需要完成三大转变：
转变1.从技术理论家到实用传播者
传统上，企业架构师需要能够将业务需求转化为IT需求，或者想出如何协商更好的IT系统交易。这仍然很重要，但现在他们也需要能够与董事会成员和高管团队讨论技术决策的业务影响，尤其并购类的业务影响。如果CEO希望能够每年收购和剥离新企业，企业架构师需要解释所需的系统环境，以及在合并的情况下，需要合并哪些系统以及如何合并。如果企业投资一个新的企业资源规划(ERP)系统，企业架构师应该能够清楚地说明其含义以及对损益的影响。这种级别的对话不能基于PPT上的方框和图表，这是很重要的一种理论方法，但不够。企业架构师必须能够使用实用的“业务”语言来交流和阐明架构决策的ROI，以及它们如何对业务结果关键性能指标做出贡献。这种变化在领先的数字企业中是显而易见的，其中EA倾向于在CXO层面的沟通而不是与供应商进行更多的技术层面的沟通。
转变2.从系统架构师到企业架构师
第一个是深入实践的问题。
在Agile和DevOps的新世界中，许多架构师被“判定”是无用的。这通常是因为他们的编码知识已经过时，或者是基于对IT问题的理论理解已经过时，所以他们的意见和建议通常是错误的。例如，他们会推动对业务毫无用处的产品创新，或者采用新的用户体验(UX)框架，但不具备正确使用该框架的必要能力。
相反，他们需要像工程师一样思考和操作。现代企业架构师需要能够可信地与操作工程师交流，例如，关于如何让系统完美下架以减少技术债。他们必须知道如何改变代码来达到预期的结果。那些认为这种“把你的手弄脏”的解决问题和行动有失身份的人可能会发现他们对组织的用处正在减少。
第二个是专才与通才的关系问题
在实践中，很难找到既精通业务又精通it的企业架构师。但他们至少必须在一个领域有深厚的专业知识，并精通另一个领域。举个最鲜明的例子：销售团队、采购团队、库管团队、财务团队、客服团队，每个团队投入大量人力做大量数据分析，从ERP、各销售平台、各财务结算平台等拉数，而后做各类分析，比如品牌/品类利润率、库存分析、销售计划等。引发以下问题：
1）同一个指标各团队给的堪称百花齐放，相差十万八千里，管理上无法决策；
2）各团队都投大量资源在数据分析上，荒废了主业；
3）从公司层面看，没有结果但投大量资源，这是损失；
4）公司团队管理协同上形成各自为政的内耗，每个人、每个团队都有理有据的把问题推给别人或者别的团队。
此时系统架构师能解决吗？要么管理者自己完成思维转型，要么教育系统架构师转型，要么老老实实招人吧...
转变3.从执行者到教练
企业架构师作为IT规则和指导方针的执行者，是非常讨人烦的，各种条条框框给日常工作带来了很多麻烦。但是随着更加灵活的系统和自动化接管了许多与架构相关的策略，不再需要记录在纸上的“法律条文”。相反，将规则和指导原则集成到部署机制中即可。通过这种方式，开发人员可以及时、有效地收到反馈和关于各自主题的良好实践的建议。
这种方法反映了现代EA通过支持同事找到他们想要实现的解决方案来发展面向客户的思维模式的需要。然后，EA可以提供相关的文档、培训支持，以及所有团队都可以重用的明确定义的数据能力。
CIO实现EA角色和功能现代化的实用步骤：
对企业IT的基础，EA需要仔细考虑后再建议变革。有些企业在重塑EA的路上走得太过激进，譬如，因为拥有着互联网“进步风格“的”敏捷”团队们在没有指导或协调的情况下肆意而为，结果导致了崩塌与混乱，没标准、没管理、企业大了再向互联网那么管真不行。Anyway,最重要的是，变革要切实可行。
步骤1.澄清责任
企业往往弄不清楚谁应真正对EA目标负责。对CIO来说，定义这样的责任是一项重要的任务，但它必须伴随着授权和决策权，以便适当的领导者能够履行他们的职责。最成功的方法是部门之间简化和明确要严格执行的有效规则，而这个规则CIO就不要亲自操刀了，交给企业架构师吧。
步骤2.在整个企业建立架构思维模式
在大多数数字原生企业中，每个人要么是架构师，要么像架构师一样思考。但对要做数字化变革的大多数企业而言，没那么简单，有些基层员工连智能手机还不会用呢，你怎么说.....对数字化有很高期望的企业，就要对全企业进行教育：为什么好的架构是重要的、EA如何影响业务、应有什么样的EA思维模式、甚至一些最基础的数字化办公技能普及。这就意味着，例如，证明如果在线商店的集成架构不能正常工作，网站将会运行缓慢，客户将会离开，或者向董事会澄清EA中的根本原因问题如何对上层业务产生重大影响。
步骤3.在架构团队中培养软技能
架构团队通常拥有深厚的分析技能和开发复杂框架的经验。然而，他们经常缺乏的是利益相关者和变革管理所需的沟通技巧，这就是企业架构师要填补的空白之一。
架构师需要放弃强调结构和系统的PPT，转而关注理解业务语言:场景、P&L影响、ROI、风险、权衡等等。这些技能需要专门的培训和能力提升规划，从而支持企业发展愿景。
步骤4.寻找新的企业架构师
虽然培训企业架构师并指导他们进行必要的转型会有所帮助，但在许多情况下，CIO只能通过从外部雇佣具备相关技能的人才来加速变革。这种人才不容易找到，但这还不是关键问题，重点在于企业自己要先想明白了，什么是好的架构师，吸引优秀人才的机会才可能会增加，几年前我接到过某制造业集团的面试电话，谈企业架构师的要求，最后都扯到系统实施上去了，还问我知不知道啥是DAMA，我当是真想说，大妈啊，你还是长点心吧....回去好好看你们企业到底需要什么样的人，如果不需要这么高层次的人就说招系统实施工程师也没啥。
企业架构师往往会被有趣的问题所吸引，并辅助企业做出创新的、深层次、系统的变革，而不是单纯的完成某项任务。对于企业架构师来说金钱当然重要，但在EA顶尖人才的激励因素中只能排名第六。他们还希望在业务转型和决策权方面发挥有意义的作用，以实现必要的变革——这意味着CIO需要提升EA的形象:在许多组织中，大多数人甚至不知道企业架构师是否存在，就更别说精准招人了。
国内外很多企业的实践已经证明，锁定核心人才雇佣，多维度经验丰富的架构师可以成为企业数字化变革的重要催化剂。这些人通常不仅会带来他们在“如何以正确的方式完成事情”方面的经验，而且还会带来能够让他们与业务人员、技术人员进行深入的探讨的经验和创新火花。
以上分享来源于公众号：球迷Long笔记