【原创】不合理的架构真的不合“理”么?

发布日期:2021-08-04 11:23:37   浏览量 :80
发布日期:2021-08-04 11:23:37  
80
球迷Long导语

近日跟朋友讨论应用架构问题:当一个做2C业务的公司开始投入2B业务的时候,要强化企业级服务的客户资源管理与销售管理,因此要强化CRM系统,此时是在原有2C的CRM系统上做二次开发功能聚集,还是独立开发一个新系统,让两个系统边界清晰、分工明确,便于未来各自的发展与演变?如果你是CIO你会选哪个?


很多企业开始选择第二个,开发一个新的!

(当然也有第一种情况,本文不具体展开详述)


第一,无数鲜活案例证明通过ESB总线等方式集成现有系统难度大、效率低、持续投入大,效果并不理想,索性这些年很多企业已经将能迁移的系统都迁移到了新的环境之中,老的系统就放那里了、不动了,伴随着生命周期消亡而消亡吧。


第二,前面业务在打仗要你系统赶紧跟上节奏,快上吧,作为当届CIO为了完成任务必须配合业务需求,想要以稳定、标准、安全、架构合理等因素去说服业务是很难的,老板也不会认同,为啥?因为这个业务死活还不一定呢。应用架构存在的首要目标是支持业务,很多成长性企业或初创公司面对生存的压力,更是不能为了保证架构的合理性而拖延系统实施速度导致企业错过发展时机。


这种情况在市场化强度高的互联网型企业很常见。业务还在试错期,系统需要尽快保证支持业务试错,如果一上来就谈论整体架构的合理性,很可能花费巨大成本实现了所谓合理架构后,新业务已经取消或失败。优秀的架构师和CTO要懂得在合理架构设计和灵活多变的业务发展之间做出智慧的权衡取舍。


对于企业架构师(很多企业是CTO、CIO或者资深技术人员take)要保证整体企业应用架构的合理性,只要大框架合理,局部的偏差可以忽略,修正的成本也比较小,如果大框架有偏差,修正的代价会非常高。对于系统架构师(2B企业叫系统负责人,2C企业叫产品经理),则要保证局部框架的合理性,避免出现设计不合理造成的返工和补救工作。


那么什么是合理的架构?


没有什么合理的架构,只有最合适企业需要的架构!


业务高速发展、业务迭代试错或者业务下滑的企业段然不会花太多精力去照顾架构合理性的问题了,一切系统设计原则都要以解决业务实际问题为最终目标,业务如果本身就不是严谨的,你怎么能要求架构严谨呢?脱离实际业务的技术情怀架构往往会给系统带入大坑,任何不基于业务做异想天开的架构都是耍流氓。


所有问题的前提要搞清楚我们今天面临的市场形式、业务量有多大、业务模式是如何、增长走势如何,哪些是最紧迫需要的,这是一个快速循序逐步迭代的过程。但整体架构的规划也要有,以当前的技术快速发展趋势来看1~2年为宜。


很多时候架构师团队要做出判断,是另起炉灶,还是继承原系统;新系统如何介入,老系统如何适应;数据如何流转,系统之间如何关联,底层数据如何打通、共享、管理;是否要复用其他系统模块,是否要将某些模块抽象化、服务化、平台化。


说到这里,我们必须明确区分几类架构师了,网上到处都在说架构师,猎头也在招架构师,其实完全不是一个角色,譬如我这种角色,更适合企业架构师,但大多数猎头联系我在招的其实都是系统总架构师或者系统架构师,这也体现了当前中国企业对架构领域的认识和直接需求。


在这里把架构师明确归为几类,供企业和猎头用人参考:


1、业务架构师。这本身不是一个IT部门的角色,他一般定位于业务部门对整个业务的结构化运作进行设计,如果是集团企业,往往这个角色在一个职能部门带头,各BU有owner。业务架构师要开展业务规划、业务区域设计、业务流程设计,对整个系统的业务进行拆分,基于DDD对领域模型进行设计,把现实的业务转化成抽象对象。实际工作中很多IT专家在干业务架构师的事儿,当然很多先进企业的BU已经开始具备BA能力了。


2、应用架构师。是要构建以解决特定问题为目标的软件应用系统(1个或多个)的结构设计,确保各系统满足各种功能性需求以及维护性需求+非功能性需求及维护需求为设计目标。识别出可能存在的系统以及系统间演变风险,及时升级控制不了的问题,避免做出错误决策。按照架构范围分总系统架构师与单个系统架构师,后者要在系统级别的粒度做进一步判断,很多企业也成称其为产品经理。

3、数据架构师。顾名思义,近年来由于数据治理重视度的提高,国内企业也开始认识到了这个角色单独设置的必要性。


4、基础架构师。顾名思义,不用多说了,Infrastructure领域的架构支撑设计。


5、方案架构师。围绕着某个业务领域开展方案的规划、设计、业务Engage。


6、企业架构师。要覆盖上述所有领域,他应以企业的持续经营目标为考虑要素来构建企业所需要的内在结构设计。这类架构师凤毛麟角,而且国内企业真正理解到需要这么个角色的也很少。这类角色不必成为所有领域的技术专家,但是知识面必须全部覆盖,能够总体把握企业级规划与信息化能力、数字化能力的清晰对接结构与框架式流转脉络。


到这里,我们举个例子看看这个职责是哪类架构师:1 确认需求;2 系统分解;3 技术选型;4 制定技术规格说明...........对,这是系统架构师。


言归正传,我们很多企业其实明知架构不合理,但为了响应企业发展也只能硬着头皮上,尤其是在采购以成本为考核、评标权重较大的前提下,进一步导致了大家都围绕着某个局部领域的需求直接满足来考量,以最低成本、最快速度的标准来对接,也因此进一步扩大了架构的长远风险。这跟企业对IT采购等的认识、职能定位水平也有很大关系。


今后再聊...


文末让我们看看顶级架构师的思想

-->