业务需求缘何应该主导IT架构..docxVIP

业务需求缘何应该主导IT架构作者：Helge Buckow and Sté… 　 　来源：麦肯锡季刊为了从IT项目中获得最大效益，企业必须确保项目领导人具有正确的态度，拥有必要的职业背景并掌握相关的技能复杂性普遍存在于不断发展的任何企业之中。随着企业不断创新，增加新业务并推出新产品，或者在国际上拓展业务，流程会不断增多，而与流程有关的原则则被抛诸脑后。与此同时，由于老化的旧系统与新的应用程序互相竞争，以图支持业务需求，支持这些流程的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系统。统一和改进底层架构群成为了企业架构管理项目的首要任务