作者 • Helge Buckow and Stéphane Rey　　来源：麦肯锡季刊

 

　　复杂性普遍存在于不断发展的任何企业之中。随着企业不断创新，增加新业务并推出新产品，或者在国际上拓展业务，流程会不断增多，而与流程有关的原则则被抛诸脑后。与此同时，由于老化的旧系统与新的应用程序互相竞争，以图支持业务需求，支持这些流程的IT也会变得越来越混乱。随着时间的推移，这类复杂性会使技术标准支离破碎，并且破坏架构蓝图的一致性。为了应对快速变化的经济、法规和业务环境，应用程序的数量会不断增长，并导致许多企业的复杂性问题越来越严重。企业架构管理(EAM)是管理IT架构的框架，能够确保IT与业务更好地保持一致，使这种混乱局面得以恢复秩序。

 

　　在绝大多数情况下，解决架构问题的努力全部依靠企业的IT实践、IT文化和IT领导人。部分原因是由于企业常常从技术队伍中挑选负责整个IT架构项目的首席架构师，这些人拥有深厚的IT知识，但对于领导一个涉及整个企业范围的改革项目，却缺乏直接经验或影响力。IT部门与业务部门松散的联系产生了一个空白，导致IT架构的质量难以得到提高，并且限制了企业的执行力和长期保持实施项目改革所产生的优势的能力。

 

　　一种实施企业架构管理的新方法，让此类改革项目摆脱了被IT部门独家掌控的境地，将它们更多地与业务需求联系起来。这种新方法始于采用业务部门能够理解的语言定义架构设计，其结果是业务需求得到了更加充分和高效的满足，进而改善沟通，并有助于业务部门和IT部门的领导在IT架构的开发中进行协作(见附文“革命性的架构管理：首席信息官的任务清单”)。更加广泛地参与将所有权交到了最终用户——业务专业人员的手中，使得坚持所需的改革变得更加轻松并提高整体管理水平。对企业架构管理采用此种方法的企业，可将开发架构所需的劳动力减少多达30%，并将调研新应用程序市场的次数减少50%。

 

　　让我们仔细研究一下一家银行是如何在转型中利用企业架构管理的，它能够使其他面临类似的管理和IT问题的机构获益匪浅。

 

 

　　一家多元化的全球投资银行发现自己陷于复杂且难以控制的IT环境中。多年来的收购、国际扩张和大量新产品的推出产生了一个集成度极差的网络，在某些情况下，网络上还存在多余的系统。IT开发由于缺乏强制性的架构框架使该问题进一步恶化，造成企业中各种不同的技术标准并存。

 

　　每个主要的业务部门都或多或少地存在各行其是的问题，它们将自己的IT需求视为其所特有的，甚至连人力资源和财务部门，也是如此，而在这些部门中，共享服务的模式如今已被认为是最佳实践。比如，尽管底层功能在各个业务部门中都相类似，该银行的投资银行部门依然认为，自己的证券结算和在线交易等核心业务与其他部门没有什么共同点。

 

　　随着对定制应用程序开发的需求呈螺旋上升，复杂性问题也日益恶化。由于IT架构的不合理，使得为了适应快速变化的监管和市场环境而频繁进行的系统升级，成为了最让人头疼的事情。尽管该银行启动了多项独立的企业架构管理举措，但由于这些举措被认为是过于从IT的角度出发，与满足整体的业务需求的关系有限，因而难以立足。实施这些项目的责任被甩给由来自该企业各全球机构的架构师组成的团队。尽管得到了高层领导的支持，但在最高管理层中，该架构组织却没有级别相当的代表。随着成本的不断上升和资源瓶颈的日益显现，该银行的中心IT部门不得不拼命为变革寻找理由。

 

 

　　该银行最终认识到，由于旨在精简、简化和标准化全球IT的企业架构管理措施过于偏向技术方面，使其看上去远离业务目标，所以，从一开始就注定充满坎坷。因此，该银行开始实施了一系列改革措施，形成了三项指导方针。

 

 

　　担任架构项目领导职务的人员技术背景很强，但在企业内缺乏更为广泛的影响力，这种状况使得该银行排除了任命一位首席架构师来领导企业架构管理项目的选择。取而代之的是，该银行设定了一个更为广泛的职位，任命深受尊敬的业务部门的首席技术官来领导企业架构管理项目，这位首席技术官在企业战略的制定方面已经拥有一席之位，并且拥有所需的预算权和决策权。

 

　　这位首席技术官的大部分职业生涯都是在金融服务业度过的，在该行业久负盛名，对业务问题非常了解。更为重要的是，他还拥有实施变革所需的政治技巧和影响力，清晰阐述用户的所思所想和需求所需的业务本领，以及通过协商在这些需求之间进行权衡取舍所需的专业技术经验，比如扩大银行的在线服务产品组合的同时，而不会让银行过多采用新的或未经实践检验的技术。他还了解这种多元化的大型银行机构所存在的IT集成挑战。

 

 

　　该银行的并购历史导致了目前的企业包含多种不同的企业文化和各自独立的IT系统。统一和改进底层架构群成为了企业架构管理项目的首要任务。为了实现这一目标并且避免过去的问题，首席技术官召开了一系列研讨会，在这些研讨会中，他将来自各个业务部门的架构团队召集在一起，开发不仅能满足局部需求而且还能成为该公司整体的最佳解决方案的架构(图表)。

 

经过精心调整的企业架构管理举措，将精力集中于薪资发放、支付和自动对帐单处理等核心业务功能，这些功能的改进和效率的提高能够产生最广泛和最持久的影响。作为改革措施的第一步，IT部门绘制了该银行当前的状况，并通过图表阐述了当时使用的平台、硬件、软件和网络应用的混乱情况。为了对其进行甄选，IT部门需要了解每个业务部门的关键需求。

 

　　新方法采用业务域重新定义了应用程序架构，业务域根据每个业务部门所需的业务功能，对该银行的数据、流程和应用等IT资源进行了重新组合。选中域的范围包括从客户服务和产品管理，到交易处理、人力资源和法务等。比如，产品管理部门必须能够在综合的基础上研究账户信息，以了解特定产品被不同地域和不同客户群的接受情况。该部门还必须能够访问贷款、存款和支付数据，以调整利润率、制定价格并履行其报告义务。在整个产品管理域内，还建立了账户、信贷、支付和结算等子域，以高效地整合、容纳并管理这些编程要求。

 

　　通过像构件一样使用域和子域，架构团队围绕着核心功能对银行的架构进行了重新组织，汇聚了共享应用程序，并挑选出了其他需要定制支持的需求。出乎该银行领导的意料之外，在该团队最初确定的100个左右的域中，只有20%需要针对业务部门的专门应用程序。其余的域，比如结算、支付和中心IT等核心功能，都是可以共享的。比如，不需要为每个部门提供不同的证券处理系统，一个域就可以将所有业务部门的证券处理功能通过标准化集中起来并进行维护。这种方法节约了开发人员和支持人员的时间，使他们可以从事具有更高价值的活动。简化的框架在整个架构框架中自上而下形成层叠，提高了基础架构的使用效率。

 

 

　　出色的企业架构管理项目使用明白易懂的业务术语来指导开发流程，并使业务部门产生拥有感。否则，该项目就会混乱，或者更为糟糕，疏远业务部门的受众，而变革的初衷却是支持他们。以一家银行部门为例，一个开发新支付环境的项目被董事会的领导层拒绝了。通过三年的努力，最终产生了一个包含架构细节信息、数据容量高达300GB的建议。尽管如此庞大，但对项目的描述却未能让高层管理人员直观地了解项目的内容，原因是陈述内容中没有执行纲要，未能向他们阐明项目的整体目标，并且介绍项目的财务和非财务优势。

 

　　IT团队决定要改正这一问题，他们将介绍细节的文件放在一旁，转而采用突出回答关键管理问题的简明图表。银行负责支付业务的管理人员对重新组织国内、地区和跨国交易的做法感到担忧，因此IT团队就在简洁的执行纲要中介绍了新架构设计的业务优势。该团队使用前后对照图表，展示了如何将拥有200多个不同支付系统的支离破碎的架构，精简为更为集成的跨界IT环境(见互动图表“企业架构管理：前后对比”)。既然所有人的想法基本上都是一致的，那么，大家就可以对该项目的指标进行充分的讨论，而项目也获得了董事会的批准。

 

 

 

　通过将整体架构分解为共享、标准和定制的三个应用层，该团队使银行的结构更加高效，并且具有更强的适应性，同时还支持业务部门不同程度的自主权。例如，信用卡支付流程这样的域，会在所有业务部门之间集中部署。而像核算等另外一些域，则允许各个业务部门为核心应用套件定制组件。

 

　　新的组织结构帮助该银行建立了由首席技术官领导的、全球性的网络治理委员会。这一结构不仅具有更高的透明性，而且还可更方便地管理正在进行的改进和项目整体绩效。尽管该项目仍处于推出过程中，但朝着更为标准化的IT环境的努力，减少了正在使用的应用程序数量，降低了相关的人力和支持成本。

 

　　企业架构管理为IT变革提供了治理模型。与其他任何的变革措施类似，IT变革也需要高层的领导。为了从企业架构管理项目中获得最大的效益，企业必须制定架构标准，建立严格并且稳定的治理流程，并任命拥有相应技能的人担任领导角色。