企业IT架构转型之道:阿里巴巴中台战略思想与架构实战. 2.6 改变组织阵型会带来组织效能的提升

简介:

2.6 改变组织阵型会带来组织效能的提升

如今大多企业的信息中心部门的职能还停留在“业务支持”的程度,是为企业的业务部门提供IT系统支持的组织。这也造成了这些企业的信息中心部门的员工,更多的是承担甲方项目经理的职能,很多事情本质上都是偏事务性的工作,也就是这样的工作并不会随着工作时间的长短而让人的能力得到持续性提升。这种以项目为导向的方式,使得信息中心的员工往往一个项目上线后,就会投入到下一个项目的工作中,对员工在业务或专业能力上很难得到持续的积累和沉淀,结果就是员工的积极性和创造力在逐渐被消磨,整个信息中心部门的生产力和创新氛围也会受到非常大的影响。

如果企业打造了共享服务体系,一方面会彻底改变现在“烟囱式”系统建设的模式,新的项目都会基于共享服务体系建设,在项目的建设周期和资源投入上会相比之前带来很大的效率提升,自然信息中心的员工也无需再投入那么多的精力负责项目管理的事务,接下来对整个共享服务体系中的这些服务中心进行持续“运营”的职能势必会落在企业信息中心这个部门,此时我们就可以将信息中心部门的员工按照服务中心的方式进行人员组织的重新编排,让员工在各自擅长和感兴趣的业务领域中持续发展,员工的业务理解和专业技能随着对应服务中心所提供业务能力的逐渐完善而同步提升,这样对于员工的工作积极性和创新意识的提升将会创造一个很好的氛围。

早期淘宝技术团队的组织人员组成跟今天企业中信息中心和技术部门的人员组成几乎一样,针对应用系统建设的不同阶段对人员的不同的技能要求,整个团队由几类人员组成,如图2-6所示。

用户体验设计师——User Experience Design,职责包括产品界面视觉引导,原型设计,与开发一起推动设计实现。

 

图2-6 传统应用开发模式下技术人员的分工组成

架构师负责设计系统整体架构,从需求到设计的每个细节都要考虑到,把握整个项目,使设计的项目尽量效率高,开发容易,维护方便,升级简单。总体上架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的人。

开发人员则是具体应用业务逻辑的实现者,具备使用自己掌握的编程语言实现业务的需求。

运维工程师更多的是负责应用底层服务器和计算资源(存储、网络、硬件服务器等)为应用的运行以及稳定运行提供基础架构的服务。

DBA(Database Administrator)数据库管理员主要从事管理和维护数据库系统的相关工作,负责业务数据库从设计、测试到部署交付的全生命周期管理。其核心目标是保证数据库管理系统的稳定性、安全性、完整性和高性能。

可以看到整个团队基本都是拥有较强技术技能的人员组成,每当有从业务部门产生新的应用系统建设或业务需求时,团队各司其职的人员协同配合,争取最快实现业务需求的满足。我们可以将整个技术团队看做成一个组合精密的流水生产线,源源不断的业务需求进入到这条流水线后,经过流水线上各专业人员的贡献,最终将业务需求以系统的方式输出这条流水线。

这样的方式确实是经过多年软件工程发展梳理出的一套合理的组织架构,也很好地体现出“专人做专事”的原则以及不错的系统开发效率。但这样的方式适合业务服务化后的架构吗?

流水线方式的弊端是对于不同角色人员的技能持续提升是会出现发展瓶颈的,做了3年的开发人员可能跟做了5年的开发人员可能在开发能力上没有太大的区别,根本原因就是这两年的差别仅仅是用自己熟练的技能多“生产”出几个不同的系统。设想一名技术员工在一个岗位上工作了一段时间(一般2~3年)后,认为在这个岗位上没有太大的技能提升,大部分工作都是重复的,在这样的情况下,就很容易出现两种情况:一类是工作的积极性没有之前那么高,得过且过的在本职岗位继续工作;一类则是看到外面公司有更好的工作机会,选择了跳槽。不管是哪一类,这两种情况都将给团队和企业造成不同程度的伤害。

所以如果继续采用这样的方式,各服务中心的需求都像之前传统的模式输入到流水线中,因为流水线上各岗位人员每天可能都面临的是不同服务中心或业务方的需求,很难对各服务中心现有的能力有清晰和深入的理解,所以对于服务中心能力的扩展和更新很难提供最为专业的支撑,自然也会对最后提供的业务需求实现的专业度和稳定性带来了很大的隐忧。

正是出于这些因素的考虑,阿里巴巴集团在构建了共享服务体系之后,对于各技术团队的组织架构也做了如图2-7所示的调整。

如上图所示,针对每一个建设的服务中心,从组织架构的形态上也发生了对应的调整,会有不同角色的人员(架构师、开发人员、UED工程师等)组建成了一个新的组织,每一个这样的组织都针对某一服务中心提供持续的服务能力开发及运维,更准确说是基于这一服务中心的业务能力进行“运营”。

所以在今天阿里巴巴共享服务体系中的这些服务中心,每一个服务中心都是由一个少则100多人,多则4、5百人的团队对负责的服务中心进行专业的运营。采用这样的方式,就很好地解决了之前流水线模式下,不同角色技术人员很难对于某一业务领域有持续的理解和沉淀,而采用围绕服务能力持续运营构建独立组织的形态,让整个团队对于该服务中心的能力逐步完善、专业以及稳定负责,在这个过程中,团队的成员就有了足够的时间和机会对于该服务相关的业务领域有了更深入的理解,从而为团队培养出既懂技术,也懂业务的复合型人才创建了良好的生长土壤。

 

图2-7 共享服务体系后人员组织的调整

在这样的一个组织中,最为核心的角色就是业务架构师,在阿里巴巴共享服务各服务中心的业务负责人一般为此角色,业务架构师的能力模型正是那种典型的即懂技术,也对负责的业务领域有相当理解的。这些架构师一般是从技术开发出身,在多年业务领域的需求浸染中,不断形成了对该业务全面的知识体系以及自身的理解,对该业务在集团内的职能定位、市场发展趋势都有一定的全局认识,能从业务的视角带领团队朝着服务中心的核心能力打造、专业、成熟的方向前进。

业务架构师即作为整个服务中心业务发展的领路者,也是保障服务中心核心业务保持业务通用性和公共性的最重要的捍卫者。在服务中心与前端应用进行业务的支持和对接过程中,一定会收到来自前端业务方对服务中心能力增加的需求,如果对这些需求不加任何过滤和判断,都引入到服务中心层面实现的话,势必会损害服务中心业务的通用性,过多的带特定业务属性的需求在服务中心层面实现,导致的结果就可能是随着不断业务的对接,服务中心逐渐丧失了他的业务通用性,最终变得对新的业务需求无法提供服务;同时服务中心的业务逻辑过于复杂,在增加了服务中心运营难度的同时,也为服务的稳定性带来的风险。

当然,以上组织形态并不是金科玉律,在实际发展过程中也会针对业务发展的需求进行适当的调整,以达到业务需求响应以及资源利用率最高。比如我们发现UED前端技术人员本身工作的性质决定了,他们未必需要对所设计的业务有特别深入和持续的了解,从而依然可以采用资源池的方式,将UED相关技术人员组建成专门负责前端交互设计的团队,为不同服务中心甚至前端应用开发团队提供专业的UED支持。

最终,通过共享服务体系的建设以及组织阵型的调整,在有效提升员工积极性和创新意识的同时,也势必让整个部门的生产力和业务响应效率得到极大的提升。最重要的是让信息中心部门从之前在企业中“业务支持”的组织职能,转变为基于企业核心业务和数据进行运营的团队,这个团队会更快、更好地支持业务发展的同时,逐渐掌握企业最核心的业务和数据,逐步培养出企业最稀缺的“既精通业务,又熟悉技术”的复合型人才。在接下来整个社会进入开放共享的时代,企业最大的价值将会是基于这些核心业务和数据进行对外开放的运营,到那个时候,这个部门将成为企业最为宝贵的资产。

相关文章
|
6天前
|
Cloud Native 安全 持续交付
构建未来:云原生架构在现代企业中的应用与挑战
【5月更文挑战第12天】 随着数字化转型的浪潮不断冲击传统IT架构,企业亟需灵活、高效且可扩展的技术解决方案以保持竞争力。云原生技术作为一种新兴的系统构建方式,以其独特的弹性、微服务和持续交付等特性,成为推动企业快速响应市场变化的关键因素。本文将深入探讨云原生架构的核心组件,分析其如何促进企业的敏捷性,以及在实施过程中可能遇到的挑战和解决策略,为企业采纳云原生技术提供参考。
|
6天前
|
Cloud Native Devops 持续交付
构建未来:云原生架构在现代企业中的应用与挑战
【5月更文挑战第11天】 随着数字化转型的深入,企业对技术的敏捷性、可扩展性和成本效益提出了更高的要求。云原生架构作为一种新兴的设计理念和实践方法,正逐渐成为推动企业技术革新的关键力量。本文将深入探讨云原生架构的核心组件,包括容器化、微服务、持续集成/持续交付(CI/CD)以及DevOps文化,并分析它们如何共同作用于企业的IT基础设施,实现灵活、高效的运营模式。同时,我们也将识别在采纳云原生技术时面临的主要挑战,并提出相应的解决策略,以帮助企业顺利过渡到云原生时代。
|
6天前
|
运维 Cloud Native 持续交付
构建未来:云原生架构在现代企业中的应用与挑战
【5月更文挑战第9天】 随着数字化转型的浪潮席卷全球,企业正迅速采纳云原生技术以实现敏捷性、可扩展性和弹性。本文深入探讨了云原生架构的关键组件,包括容器化、微服务、持续集成/持续部署(CI/CD)和DevOps文化,并分析了这些技术如何帮助企业加速产品上市时间,提高运营效率,并最终实现业务目标。同时,文章也识别了企业在采纳云原生实践中可能面临的挑战,如安全性考量、团队技能提升和复杂的网络管理,并提出了相应的解决方案和最佳实践。
|
6天前
|
弹性计算 Cloud Native 安全
云原生架构的未来展望:如何引领企业转型与创新
【5月更文挑战第7天】随着云计算技术的不断发展,云原生架构已经成为企业数字化转型的关键驱动力。本文将深入探讨云原生架构的优势、挑战以及未来发展趋势,为企业提供一种全新的技术视角,以实现更高效、灵活和可扩展的业务运营。
|
6天前
|
监控 负载均衡 API
微服务架构在现代企业中的应用与挑战
微服务架构已成为现代企业构建灵活且可扩展软件系统的首选。然而,随着其应用的普及,企业也面临着一系列新的挑战。本篇文章将探讨微服务架构的优势、实施时遇到的问题以及解决这些问题的策略。
|
22小时前
|
运维 监控 负载均衡
探索微服务架构下的服务网格
【5月更文挑战第20天】 在当今日益复杂的分布式系统中,微服务架构已成为企业技术栈的重要组成部分。随着微服务数量的膨胀和网络通信的复杂化,传统的服务发现与负载均衡机制显得力不从心。本文将深入探讨服务网格这一新兴模式,它如何在微服务环境中提供更灵活、动态且高效的服务间通信解决方案。我们将剖析服务网格的核心组件、工作原理以及它如何简化分布式系统的运维难题。
|
22小时前
|
消息中间件 持续交付 开发者
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第20天】 随着现代软件开发的复杂性日益增加,传统的单体应用架构逐渐显得笨重且难以适应快速变化的市场需求。微服务架构作为解决方案,以其灵活性、可扩展性和技术多样性受到青睐。本文将深入探讨微服务架构的核心概念,设计原则,以及如何通过最佳实践来构建和维护一个高效的微服务体系结构。我们将讨论关键的后端技术栈选择,服务划分策略,数据管理,以及持续集成与部署(CI/CD)流程的重要性。文章旨在为后端开发者提供一套实用的指南和思考框架,以支持他们在未来的软件项目中采用微服务架构。
|
23小时前
|
持续交付 API 开发者
构建高效微服务架构:后端开发的新范式
【5月更文挑战第20天】 在现代软件开发的潮流中,微服务架构已成为推动技术创新和服务灵活部署的关键。本文探讨了如何构建一个高效的微服务架构,涵盖其设计理念、技术栈选择以及面临的挑战与应对策略。通过深入分析,我们旨在为后端开发者提供一套实用的指导原则和最佳实践,以支持快速迭代和系统的可扩展性。
|
23小时前
|
API 持续交付 开发者
构建高效微服务架构的五大关键技术
【5月更文挑战第20天】 在当前数字化转型的浪潮中,微服务架构因其灵活性、可扩展性而成为众多企业的首选。本文深入剖析了构建和维护高效微服务架构的五大关键技术:容器化技术、服务网格、API网关、持续集成/持续部署(CI/CD)和分布式追踪。通过这些技术的整合使用,可以显著提高系统的可靠性、弹性及开发效率。
|
1天前
|
监控 负载均衡 Java
【阿里云云原生专栏】微服务架构在阿里云云原生平台上的应用实例与优化策略
【5月更文挑战第20天】本文介绍了在阿里云云原生平台实现微服务架构的步骤,包括基于Spring Cloud的Docker化部署、使用ACK部署微服务,以及优化策略:服务发现与负载均衡(借助Istio)和监控日志管理。通过这种方式,企业能提升应用的可扩展性、可维护性和敏捷性。
169 5