写点什么

就算有“中台”模式,企业也应该重视“大部头”架构设计

2020 年 9 月 07 日

就算有“中台”模式,企业也应该重视“大部头”架构设计

很多人可能认为互联网企业没做过“笨重”的企业架构,依然不乏成功的创新和指数型的增长,甚至带动了各种跨行业的竞争和进步。


这点不容置喙,但是,我们也必须意识到,上述结论也有需要注意之处,比如,“幸存者偏差”,我们关注星光耀眼的互联网头部企业时,还有更多的互联网企业怀揣着各种创意、甚至比现有商业模式更好的创意倒在了路上,互联网模式并非所有互联网企业的“免死金牌”。


即便是成为头部企业的幸存者,他们也越来越重视企业整体的管理包括战略管理,不少大型互联网企业设有战略管理岗位,随着企业规模的增大,一些传统企业管理模式中珍视的因素会逐渐在新的认识下焕发活力。


不仅国内,国外科技企业随着规模的增大也会出现一定程度的“大公司”现象,前谷歌掌门人埃里克·施密特在其所著的畅销书《重新定义公司:谷歌是如何运营的》再版序言中坦言,谷歌人认为他写的是过去的谷歌,其中不少做法现在已经消失了


另外,作为企业架构的一种实现方式,“中台模式”及对业务架构的重视也正是头部互联网企业阿里巴巴提出来的,互联网企业也许不是没有企业架构,而是长得可能不太一样


所以,从客观的视角来看,笔者不认为搞“大部头”的企业架构一定是过时之举,导致方法论过时的未必是环境变化,而是让方法论不再前进的选择。方法论的生命力是可以与时俱进的,拥有 2000 多年历史的儒道法兵思想,即便在今天也还在被国内外的有识之士不断演绎创新,包括用在架构理解上。


企业架构至今不过“三十而已”,还不至于这么轻易就尘封于历史之中。


本文笔者想介绍的就是通过企业级业务架构实现战略落地。


一、总体过程

落地企业战略其实并非只是对战略本身进行分解,而是涉及到与战略落地相关一系列工作,内容的多少与企业的规模、复杂度、战略本身的复杂度都有关系,总体上来讲,可以分为自上而下的战略能力分解和自下而上的现状问题梳理,将这两部分内容综合起来,形成对战略的高阶需求分析。


只做到高阶需求分析当然不够,不然就回到过去导致战略只能挂在墙上的老路,要通过企业级业务架构对战略进行落地。首先是根据现状梳理获得的信息建立现状模型,包括流程模型和数据模型,以及通过流程模型和数据模型结合分析得到的业务能力模型,也就是组件模型。


得到现状模型之后,可以将高阶需求分析导入业务模型中,通过需求的定位和分解,可以明确原有业务模型中哪些流程需要新增、调整或取消,哪些数据实体需要新增或调整,进而得到目标流程模型和数据模型,二者的结合就会得到新的业务能力模型。虽然听起来繁琐,但是现状模型到目标模型改动量并不一定都是非常大的,这与战略对现有业务的调整程度有关。换句话讲,工作量大小并非是采用了模型方法的问题,而是企业希望做出多大的变动,模型不过是如实反映了这种变动,就算没有采用业务模型作为战略落地工具,也不意味着企业为战略调整需要付出的工作量会减少多少。


上述过程可以用下图表示:



在实际操作中,高阶需求设计阶段与现状建模阶段是可以并行安排的,现状建模的依赖是对现状业务的梳理而非高阶需求分析,目标模型的依赖则是高阶需求分析和现状模型。


建模方面的内容笔者书中有介绍,下面重点介绍下战略与高阶需求设计阶段的工作参考模式。


二、详细过程

(一)做战略的意义

高阶需求分析是一件很有挑战性的工作,当然也需要耗费一定的资源和时间,但是,如果我们希望慎重对待战略的话,这些付出也是必要的。大家对战略的看法一直很矛盾,战略往往会与计划相关,对计划的看法也反映了对战略的看法。德国军事家毛奇(1800-1891)认为“任何作战计划对于超过第一次与敌军主力交手之后的情况,都不能做出任何精确的预测”(这个意思有时也被演绎成“一旦两军开战即无计划可言”),谷歌在工作中也提倡不把商业计划奉为圭臬,“你的计划是错误的”,这些提法都是更注重应变。但是,至今军队也未曾停止过拟定作战计划,谷歌工作也非毫无章法。


战略不一定总是个大工程,大企业的长期战略当然会内容庞杂,但是中小企业未必如此,而且战略分解也未必每年都需要在规划方面花很大工作量。战略其实是个思维习惯问题,当我们被互联网大咖的明星光环吸引时,也必须意识到,马斯克、张一鸣、张小龙等成功人物只是少数杰出者,对于大多数企业而言,特别是中小企业,反倒更需要依靠“阵地战”,依靠集体智慧,养成战略思维习惯正是统一大家认识,发挥集体作用的方法。


(二)战略设计与高阶需求分析过程

本文首先介绍一个比较完整的过程,企业在实践中可以根据完整过程进行裁剪。


该过程如下图所示:



可以将该过程分为组织准备、高层访谈、信息准备、方案形成和检查跟踪五个环节。


1、组织准备

组织准备对于战略设计和高阶需求分析而言是一个非常重要的环节,尤其是在规模较大的企业中。不少大型企业设有战略管理部,但是战略只是战略管理部牵头完成的工作事项,而非仅是战略管理部的工作,战略关系到企业各个层级,并非只有领导者该关心,各级业务人员、技术人员都应该关心,只不过关注的侧重点和形式上有所区别。高层当然关注的是战略本身和执行情况;各级执行层是关注的是分解下来的战略任务以及自己工作与总体战略之间的关系,因为灵活的处理来自于对战略方向的理解;技术则关心战略方向引导的业务方向,基于业务方向,IT 架构的适应性和调整,以及通过战略任务落实下来的具体开发需求。


可见,战略贯穿整个企业的工作,不是一个部门的工作,更不是一个部门自己做的交付物,需要充分的纵向、横向沟通,因此,为制定和落实战略进行合理的组织准备就是非常必要的,确定做战略的团队或者具体人,确定相关工作机制。


组织准备一定要注意资源的匹配、覆盖的广度,以及如何就疑难问题进行快速决策的机制,战略制定虽然要慎重,但是过程不能“久拖不决”,重要问题的及时上报和决策是保证战略制定工作时间可控的关键。


资源匹配中的一个难点是战略设计的专业人才,这也是很多企业会在战略制定工作中引入外部咨询的原因,毕竟专业做战略的人非常少,而战略制定工作的能力要求、经验要求都很高。大企业虽然出得起钱,但是必须注意对咨询公司能力的吸收,钱要花的“值”;中小企业如果在资金方面有困难,那适当通过接受外部培训的方式自我培养人才也是可取之道,毕竟,中小企业的情况也并非咨询公司都了解,企业自己内部的情况还是自己最了解,理论只有与实践相结合才能发挥作用,中小企业不缺实践,缺的是对方法论的吸收和思维习惯的养成,这些是可以靠时间和坚持来弥补的,就像企业架构能力一样,坚持就可以获得。


2、高层访谈

战略从某种程度上来讲是企业家精神的凝练和表达,所以高层访谈必不可少,做战略最要命的是没有解决好高层的概念一致性,其次就是高层意识与企业实践不衔接。这两个问题的解决都离不开充分的高层访谈和适度的问题暴露。


第一个问题要通过深入、单独访谈企业每个高层领导,认真领会每位领导的战略思想、关注点、对环境的认知、对企业的认知,比较差异、判断融合方式,对于关键分歧必须抓住,不然会在今后的方案制定过程中留下隐患。


第二个问题,由于每一阶段的时间有限,所以要集中访谈企业中的部门领导,也就是中层干部群体的核心,部门领导的日常职责就是承上启下,对企业实践的细节有更多认识,从中也可以分析出与顶层认知之间的差异,这些点都是需要在方案设计中注意的问题。


大型企业,比如宇宙行级别的超大规模企业,在这个阶段还可以加入对部分代表性地区分支机构负责人的访谈,也就是距离市场更近的中层领导,以获得更接近市场的信息。对于中小企业,干部群体相对而言少一些,访谈可以更为深入,并且可以随机选择少数员工,进行不同层面信息的比对。


高层访谈环节切记,不仅是要领会领导意图,与之同等重要的是发现差异。


3、信息准备

领会过领导意图之后,就需要全面收集能够支持战略设计和需求分析的信息,信息的数量和质量对于战略的质量至关重要,虽然战略制定有艺术性成分,制定者的能力不容忽视,但“巧妇难为无米之炊”,可以蹦出个天才想法,但落地还是需要很多细节工作的,如同做战役指挥,一个伟大的战役构想需要大量细致的参谋作业才能转化成军团的行动。两支游击队短兵相接,考验的也许是个人能力;两个兵团短兵相接,考验的实际上是两个参谋系统的信息收集、处理和应变能力。所以,为什么前文会讲战略是个思维习惯,也是这个道理,对于大多数企业而言,除了个人,我们还始终需要一种集体能力,信息的采集和沉淀就是这种集体能力的基础。


信息采集的范围实际上是非常广泛的,面向数字时代,数据就是用来感知变化的,企业对内外部变化能感知多少就取决于能采集到多少信息,本文以做战略为主,从这个角度来讲,主要的信息包括以下几种:


(1)企业现有战略

新战略通常是对旧战略的调整,但是调整之中往往也有继承,企业变革一般不是休克疗法,对于旧战略的得失判断、影响因素分析有助于新战略的制定和推广,这也是一次战略层面的“PDCA”循环。


(2)基本业务信息

战略不能脱离企业的基本面,再重大的变革也是从当前出发的,“破”和“立”都是对现状而言的,前瞻性战略也不是无源之水,都是从现状到目标的过程,避免战略夸夸其谈就必须对企业的基本业务信息有充分了解,才知道如何从“不能”到“能”。对现状的理解是战略能够接地气的关键因素。


基本业务信息也是建立现状模型的重要输入,通过现状模型可以结构化地呈现企业当前的整体结构、运作模式、业务资产、数据资产包括软件资产,其实现状模型的制作过程本身就能够帮助企业暴露出很多不合理的状况,成为做解决方案的考虑因素。


(3)行业领先实践

“行业领先实践”就是大家常说的“别人家的孩子”,很多人都希望“自己家的孩子”多学学“别人家的孩子”,但是孩子跟孩子还是很不同的,况且“别人家的孩子”的到底怎么做的,只有“别人家的孩子”自己知道,有些情况还可能是禀赋的原因,不是能学的。


所以,在战略制定中尽管行业领先实践分析必不可少,“见贤思齐”并没有错,但是如果做不到华为学 IBM 那样深入,就必须立足自己,领先实践只是个启示,并不是现成的软件包,捡起来就用。学别人切忌肤浅,容易东施效颦。如果你问了三次,都搞不清别人到底是怎么做的,那可能就不具备学的条件。


关注领先实践的同时,也应对行业信息进行一个广泛采集,从而理解行业走向和领先者真正的领先程度。


(4)现状痛点问题

“现状痛点问题”真的是“自己家的孩子”,有啥毛病你都得先接受才行,接受了,深刻认识才有改变的机会,缺点不是用来“嫌弃”的,镜子里照出来的不是别人,是自己。


很多人可能会认为企业了解自己的痛点,但实际上未必,如同医生诊脉,治病不能治标,要治本,很多时候我们只是看到了痛的点,但是没有深入分析痛的根因,只是停留在表面上。如果能够基于对企业信息的全面了解,深入分析痛点,稍稍接受下领先实践的启发,很多问题企业其实自己能找到解决办法。


有时候企业内部也确实知道问题的解决之道,但还是会借助咨询公司“外来和尚好念经”的便利,这种情况在大企业中不少见,但实际上是一种资源浪费,也是企业文化的痛处。


(5)技术发展趋势

战略设计终归要有一定前瞻性,而面向数字时代,纯粹的业务战略设计将会逐步消失,很多大咨询公司也从当初的业务咨询转型为数字化咨询。业务与技术融合的战略设计越来越重要,技术在战略设计中已经不再是担任辅助角色,而是承担创新商业模式、支撑创意实现的关键职责,数字化企业的产品要么直接是软件、要么需要结合软件向客户实现完整交付,而且,即便是线下度较高的产品也很可能要先通过线上渠道才有触达客户的机会。


结合企业的主营业务方向收集关键技术的发展趋势是非常重要的,比如服务性行业必须关注虚拟技术对服务模式变化产生的影响,关注虚拟技术打开新渠道的进展,关注各种基于人工智能的交互类技术的进步。以银行业为例,尽管金融业务的本质相对稳定,但是从柜台到网络,服务方式已经变化很大了,而从今天的二维渠道升级到三维渠道,则可能产生更大的模式变化,所以,匹配战略覆盖的时间跨度,要尽可能了解关键技术的发展方向,以免“措手不及”。


总结下,这个阶段尽管工作量不小,但是时间也是需要控制的,所以,总体上要把握好宏微观程度,要搞清楚企业现状和关键痛点,这样才能让战略的重点明确,或者说知道战略需要处理的“坑”。信息的收集最终是为了开阔战略设计的视野。


4、方案形成

经过前面三个环节的准畚,就进入了正式形成战略并对将战略分解为高阶需求的过程。


(1)总体认知对齐

进行到这个环节,在操作层面上首先要对全体成员进行认知的统一,战略要保持高阶概念一致性,因此,在这个环节开始之际,通过讨论会等形式对之前发散的思考、信息进行收敛是非常必要的,所谓的收敛也就是将问题聚焦,通过问题聚焦将关注点聚焦,并不是什么样的现状问题都会上升到战略层面,即便上升到战略层面也会考虑资源的有限性进行分阶段解决。


(2)战略设计

完成认知的对齐后,需要根据入围的信息凝聚成企业战略。战略的制定当然是个复杂问题,没有什么操作过程能保证一定会做出卓越的战略,我们只能通过过程尽可能保证质量,但是卓越是无法保证的,这与软件开发一样,严格执行软件过程也许可以提升软件质量,但无法保证“爆款”。


尽管如此,但还是有一些做战略时值得注意的关键点。战略设计需要的前瞻性相当程度上来自于对过去的反思,因此,战略设计在时间上具有非对称性,希望向前展望 2 年,那可能至少要想过往看 10-20 年;希望向前看 20-30 年,需要看历史可能至少要数百年。当然,这不是要大家把过去的历史都通读了,而是把握从过去延伸到现在的趋势,理解了趋势才能摸清楚方向。


笔者《银行数字化转型》一书就是基于这种方法进行的数字化转型方向展望,因为将数字时代列为一个新时代,所以实际上是要将农业社会、工业社会、信息社会放在一起横向比对,去确定数字时代是不是一个新时代、一个什么样的时代、一个带来哪些转变的时代,从历史中也可以总结出人类社会发展在持续打破空间限制、持续增强个体能力的发展趋势,从而做出数字化银行是基于虚拟空间的银行,这是对空间限制最大程度的打破;数字化转型战略要赋能客户、赋能员工,来实现商业模式转型这样的战略方向判断。


实践中的战略通常不会做这么长时间跨度的设计,以 3-5 年的较多,往往是基于对企业自身过往经验的总结,加上对社会、行业的判断。比如建行之前的战略概括曾经是“综合性、集约化、多功能”,这个战略也推动了建行基于企业级业务架构的“新一代核心系统转型项目”;近年执行的“住房租赁、金融科技、普惠金融”三大战略,体现了对社会的关注,强调了银行的社会责任,也带动了成立住房子公司、金融科技子公司、大量增加中小微企业贷款等行动,贯彻“金融是温柔的手术刀”的理念。


战略的设计要注意客观地判断目标与实现周期的匹配性,也要尽可能寻找可度量的指标或可描述的结果,这样才能更有利于评价战略的实现情况。不过对于 IT 投入而言,除非公司运营模式是高度产品化,成本管理可以精确匹配到产品,否则很难准确核算 IT 的贡献,这是大部分传统企业设计和推动数字化转型战略时的难题。


对此,笔者建议是量入为出地进行可能的最大化投资,因为数字化转型最终发挥全部价值靠的是企业无形价值的产生,比如能够利用数字化技术进行高度协同的企业文化、能够充分利用数据的决策思维、能够让业务与技术更深融合架构思维的普及,这些并非可以靠投资的数额决定的,但却是由一个可以长期坚持的转型过程带来的。此外,技术发展较快,没有足够的投入本身就难以在这种时代切换期跟上时代的发展。


(3)高阶需求分析

通过对趋势的把握,可以提炼出战略的核心思想,上文介绍的其实就是战略核心思想的表达。有了核心思想,还要把视野聚焦到近期的问题上来,包括企业内外部的面对的问题、机遇和挑战,通过这种分析得出支撑战略实现的关键能力。


关键能力仍然比较抽象,需要通过各部门结合实际进一步细化,分解为更加细节化、可以落实到业务层面的、较大的需求点,这就是高阶需求分析。高阶需求分析不是什么公式推导,更像是在提炼大量信息后的“头脑风暴”。


笔者在《银行数字化转型》一书中将数字化战略在客户、产品、组织、人力和技术 5 个子战略并采用价值链分析的方式进一步细化成 17 项战略能力,可供大家参考。


在笔者参加过的实践中,当时将行内的战略按照客户、产品创新等 5 大业务目标,分解为包括客户统一视图、产品全生命周期管理等 26 个业务方向,并将业务方向分解为包括提供客户洞察力、更快的产品创新流程等 72 项转型举措,划分了 108 个能力主题,加上导入的现状问题,最终衍生出 2000 多项高阶需求。这是一个覆盖面完整、需要广泛参与和深入讨论的过程,需要“亲力亲为”。


高阶需求分析需要与现状业务架构进行比对分析,这样才能从现状出发找到差距,才能判断为实现战略需要做的调整。这些工作必然都会耗费些时间,尤其是在横向沟通层面,毕竟战略是企业整体战略,各部门是需要一定协作的。所以,笔者在以往的文章中一直提倡初次做基于企业级业务架构转型尝试务必给予足够的时间,才能让工作质量有保证,也才能让参加的人有转变的时间,让过程为人赋能,好的过程可以提升产生好结果的概率。


笔者前文中也在强调,企业应当自己培养战略人才,信息的采集和沉淀是基础,而这种战略设计和分析实践是锻炼人的重要过程,最终事情都是人做的,培养人才是最重要的工作。对于大企业而言,战略人才可能是专职人员,而对于中小企业,笔者更建议将战略管理转变为一种企业管理习惯,一种思考企业发展问题的思维方式,这样也可以使战略工作更接地气,并逐渐形成企业自己的“套路”。


5、检查追踪

PDCA 是一个很有价值的循环模式,很多工作都应该借鉴这种模式,战略也一样,对战略的执行,需要有效的跟踪和评价,这方面企业级业务架构其实是个很有建设性的管理方式。前文介绍是通过企业级业务架构去承载高阶需求分析的结果,用战略能力指引现状模型走向目标模型,那目标模型自然就是检验战略落地成果的标尺,可以用于评价业务或者技术的转变成果。


有业务架构模型就有了结构化的跟踪工具,没有架构模型,对战略执行的跟踪就退回到了原来的方式,跟踪会议纪要的执行。


战略在实际执行中,越大的企业,其基本理念的传导需要的时间越长,由于体量大、惯性大,执行的反应也需要时间去观察。执行过程也是需要因地制宜去调整落地方式的,战略是思想的“一刀切”,但并非行动上的“一刀切”,需要在坚持总体目标和原则的基础上具备执行的灵活性。


现在的管理发展趋势是缩短决策链,倾向于让一线多做决策,在战略执行上更是如此,为一线提供更多的信息和资源支持,提供目标方向,让一线灵活捕捉战机。结合当前流行的敏捷方法论的思路,战略的执行也需要做好“OODA(观察—调整—决策—行动)”,需要一线执行者在尽可能获取充分信息的前提下对总体战略进行更为灵活的执行把握。


三、总结:传统与创新

综上,笔者简要介绍了基于企业级业务架构做战略设计和高阶需求分析的过程,这个过程相对完整,不同规模的企业可以参考这个完整的过程进行适当的裁剪和变通。


文本讨论的仍然可算方法论层级的战略管理,笔者一直认为研究方法论对企业而言很重要,并不是浪费时间的奢侈行为,而是企业成长、传承的必然,头部企业都在取得成功后不断输出自己的方法论,企业争相效仿的同时,不应当忘记自己的独立探索,自己的才是最合适的。理论只要用功都可以学得到,结合自家实践最重要,做到“知行合一”。架构也好、战略管理也好,做到解决自家问题并非登天难事,“人胸中各有个圣人,只自信不及,都自埋倒了”,不自信,遇到困难即放弃,因而无法达到。


近年来,很多行业受到互联网思维的冲击,渐渐露出新产业革命的征兆。在这个大背景之下,关于传统与创新关系的讨论也时时响起,到底什么样的方法合适,“老的”真的“老”到过时了?“新的”真是“无根之水”、凭空出现的吗?


这些争论有时会混淆方法论与实践之间的关系,比如大热的中台,头部企业的成功是否就代表了方法论的成功?其他企业仿效的失败是否有代表了方法论的失败?互联网企业成功的模式各有不同,并且也只是 21 世纪开始后这 10 几年的时间,从方法论的视角看,还属于复制能力有限的雏形阶段,如同前文提到的“幸存者偏差”。互联网速度确实快,连仿效、抄袭产生的边际效益递减速率也大幅加快。


如果认真仔细地观察互联网企业成功案例,这些成功其实起源于对某个社会痛点,也就是具有潜在大规模需求的痛点的深刻认识,这种深刻认识加上具有“武侠精神”的浪漫主义执着、互联网的传播速度和些许的“幸运”,才走出了一条不一样的成功轨迹。


对痛点的深刻认识是成功的起点,其解决思路,无论是基于广泛研究的深思熟虑还是闪电霹雳般的灵光乍现,实际上都是戳中了传统方法未能很好解决的“命门”,从这一点上看,亚马逊的图书销售、阿里巴巴和京东的电商模式、脸书和腾讯的社交、Uber 和滴滴的打车、美团的外卖、小米低价高质的国产情结、爱彼迎的酒店、SpaceX 的可回收火箭等等,无不隐藏着对“痛点”的独到理解,创新并非始于创新,而是始于前车之鉴,这是传统与创新之间最为深刻的关系。


无论通过何种方式,创新都是对传统的深度吸收和再造,没有不站在前人肩膀上的创新。因此,成功的创新管理源应该自于对自己、对企业、对行业、对社会的观察和反思。小到生产操作方法的些许改进,大到马斯克的火箭都是如此。


创新需要人才,但并不是所有企业都可以坚持谷歌、桥水等顶级企业选人的“苛刻”方式,所以笔者才在本文中多次强调集体智慧的力量。通过战略管理、企业级业务架构等方法论,不断将零散的智慧吸引到共同的目标与框架上,通过对方法论和相关信息的沉淀不断提升集体获得成功的机会。


所谓创新,就是将过去延伸至未来的思考。创造新方法论的目的并非对旧方法论进行颠覆,仔细想来,有哪个工程方法真的把“瀑布模型”要做的事情彻底省略掉了?创新只是为了解决问题,而解决问题离不开对历史的思考,不要把传统和创新对立起来看,特别是在软件工程、企业架构这样还太过年轻的领域。


互联网思维也需要大家更多反思,这是走向数字化的必经之路,不客气地讲,也是传统企业的“生死大考”,跨不过“数字化”关口的企业终将成为历史,成为前车之鉴。在这个时代切换的关头,企业必须在自己的管理思维中首先融入架构思维,融入对数字化的理解,把未来愿景想融入战略管理。


还是笔者常说的那句话,企业无论大小都有战略,在这个关头也都离不开战略管理、架构管理和转型方法,这是帮助企业扩大自己的“舒适区”,多数企业并不是要把自己逼进无人区,无人区往往只有头部企业有机会触达,更多企业是要通过数字化提升企业整体能力,“增益其所不能”,进而扩大“舒适区”,获得发展的机会,这是从“传统”致“未来”的战略落地之路。


作者简介


付晓岩,新书《银行数字化转型》刚刚面市,受到热议。另著有《企业级业务架构设计:方法论与实践》一书,对企业级业务架构设计、企业数字化转型、金融科技发展有持续的研究和深厚的实践积累,现就职于建信金融科技有限责任公司。公众号:晓谈岩说。


2020 年 9 月 07 日 14:131866

评论 6 条评论

发布
用户头像
能加微信交流下吗?MrDeer42
2020 年 11 月 20 日 06:43
回复
用户头像
治大国如烹小鲜,越是大的企业越是需要清晰的战略架构设计。架构设计并不是为了规定什么,而是让企业所有人都站在同一个出发点上,让所有人有一个整体的认识。和一般技术架构不大一样的是,企业战略(EA)往往是为企业量身定制,没有统一的标准。接触的人也少。所以往往不被人了解。实际上阿里等国内互联网企业,在成长过程中,也接受过很战略咨询。只是大家不知道罢了。
2020 年 09 月 11 日 14:38
回复
用户头像
10年前的陈词,既缺乏“创新”和独立思考,也没有和主流的方法论产生共鸣,只能成为企业尾大不掉的又一说辞。
2020 年 09 月 08 日 01:59
回复
用户头像
当前有太多的企业或者从业者太过急躁了,静下来好好的思考战略与业务,业务与IT的对齐。这个过程确认会耗费大量的资源,时间。笔者也给出了一个可裁剪的内容框架,流程,组织方法,值得慢慢品味。
2020 年 09 月 07 日 15:26
回复
用户头像
的确是对企业架构方法论很好的反思,企业级视角能把IT拉回到业务层面看问题,而不是只有互联网的技术视角。互联网公司有能往外说的,也有不能往外说的,除了开源技术,流程、组织、业务模式、外部环境方面呢,在互联网公司成功因素占比是怎么样的?光环效应很容易让追随者死的快啊。
2020 年 09 月 07 日 15:04
回复
用户头像
高端的辞藻,空心的内容
2020 年 09 月 07 日 14:34
回复
没有更多了
发现更多内容

Netty-物联网设备Channel管理

凸出

Java Netty ConcurrentHashMap 物联网 channel

Java如何调用Python(二)

wjchenge

让Vue项目更丝滑的几个小技巧

前端有的玩

Java Vue 前端 技巧 ES6

React Hooks 温故而知新

卧龙小明

Java 前端 React

谁说天平不稳——安全性与用户体验设计思考

石君

安全产品设计 安全设计 用户体验

为什么我们要自主开发一个稳定可靠的容器网络

BoCloud博云

云计算 PaaS fabric 容器云

【数据结构】Java 常用集合类 ConcurrentHashMap(JDK 1.8)

Alex🐒

Java 源码 数据结构 并发编程

Self-Compassion,对自己好一点

霍太稳@极客邦科技

创业 个人成长 自我管理 创业心态

BSN北京市区块链主干网正式发布

CECBC区块链专委会

随着并发压力的增加,系统响应时间和吞吐量如何变化,为什么?

chenzt

【数据结构】Java 常用集合类 HashMap(JDK 1.8)

Alex🐒

Java 源码 数据结构

Java如何调用Python(一)

wjchenge

【第七周作业】

Aldaron

创新监管首批8个试点应用公示 其中7个涉及区块链

CECBC区块链专委会

1.5W字 | Webpack4 完整入门教程(共 18 章)

pingan8787

前端 Web webpack

15 个很有用的自定义 React Hooks

卧龙小明

Java 前端 React

自动化测试的三两事儿

测试那些事儿

MySQL - 主从复制的几种方式

Aaron_涛

MySQL 架构 分布式 主从复制 数据一致性

API网关——Kong实践分享

BoCloud博云

云计算 容器 PaaS API

BIGO海量小文件存储实践

InfoQ_3597a20b53cc

创业使人成长系列 (4)- 常用账号申请

石云升

支付宝 微信商户 商标

百度大脑OCR技术助力钢铁物流实现智能管理

百度大脑

人工智能 百度大脑 文字识别

超详细讲解网络中的数据链路层~

程序员的时光

【第十三课】性能测试与优化

Aldaron

数字货币并不能完美诠释区块链金融

CECBC区块链专委会

区块链技术 社会价值 打通数据孤岛 重建产业信用

架构师训练营 - 第七周 - 学习总结

韩挺

深入理解 CSS 中的外边距折叠及 BFC

卧龙小明

CSS 前端

架构师训练营 - 第七周 - 作业

韩挺

Django Models随机获取指定数量数据方法

BigYoung

django 数据 random 随机 Models

10086小姐姐的问好背后,藏着云与计算的时代巨变

脑极体

性能测试学习总结

周冬辉

性能测试

低代码的认知误区与落地实践

低代码的认知误区与落地实践

就算有“中台”模式,企业也应该重视“大部头”架构设计-InfoQ