【TechTarget中国原创】随着企业广泛应用面向服务架构（SOA），一种市场趋势倍受注目，该趋势不是引进新的产品和服务，而是转变那些成功实施SOA技术的业务组织结构。除了Centers of Excellence (CoE)的成长之外，提升中心关注SOA,并且关注在机构中引导SOA的企业架构（EA）组。但是企业架构组并不是唯一通过IT解决方案满足业务需要的。事实上，早在企业设计师规程有今天的预见力之前，机构就随着业务摇摆不定——业务分析师。
业务分析师在机构中起到了重要的作用，并且依靠业务所需的不同功能和资源，帮助人们满足业务需求。但是，既然企业架构师机构倍受关注，那么传统的业务分析和业务分析机构将何去何从呢？业务分析师是否是一个独立的组，是否在企业架构师组和SOA的交互操作中扮演着十分重要的角色呢？或者，业务分析师只是加入到SOA措施中的企业架构师的一种类型？另外，业务分析师的前途如何？在ZapFlash,中，我们要重点关注业务分析师和企业架构师所起到的作用，以便帮助机构尽量减少业务所需的资源。
业务分析师起到了怎样的作用？
为了了解业务分析师和企业架构师之间是如何发生作用的，我们首先要弄明白业务分析师究竟是干什么的。维基百科将业务分析师定义为执行业务分析规范的人。更为明显、深入的解释是“业务分析师负责分析客户的业务需求，帮助找出业务问题，并提出解决方案。在系统开发生命周期领域内，业务分析师在企业的业务方和服务供应商方起到连接作用。尽管，许多机构将分析师的头衔以及他们的责任区别开来，这些分析师通常选择的头衔是业务系统分析师，系统分析师以及功能分析师。”仔细阅读这些解释，我们就会发现业务分析师的职责似乎是将业务翻译成具体的细节。每个业务单独的部分都可以对这些细节采取行动。
为了增强定义，业务分析国际机构将“业务分析工作解释为风险承担者之间的联系者，以便引导、分析、交流并确认业务流程、原则以及信息系统所要求的变化。在要求和推荐的方案能够令机构实现目标的状态下，业务分析师理解业务问题和机会，然后和企业架构师涉及的区域相关联，我们实际上关心的是业务分析师的一种类型：即IT业务分析师。
CIO.com上的一篇文章将IT业务分析师的作用描述为能够扫描系统、诠释业务需要、可以将技术问题翻译为业务可以理解的语言，并能够找出项目细节和要求的机构，该机构能够将开发小组和业务代表联系起来并帮助项目组遍历机构原则，创建测试实例和情况，并且倡导项目干系人。从这方面来说，业务分析师本身并不是项目管理者，但是却和业务要求一样在每个IT项目中起着极为重要的作用。
有趣的是，业务分析师将在企业中首先使用IT技术摆在了头前。早在IT技术以前，业务分析师可能有许多他们用来解决风险管理的原则和方法，为机构内部的交流提供了便利条件，增强了劳动力的利用率，优化了流程，并执行其它需要连接业务战略方面的任务。当IT引进该混合时，业务分析师就成为了令一切运转起来的机制的一部分。
企业架构师的作用所带来的冲突与合作
咋一看，似乎业务分析师的职责和企业架构师的职责有重叠之处。在以前许多的ZapFlashes中，我们将企业架构师的作用定义成为：整个企业的所有架构工作的执行层面予以管理和指导，为整个机构建立核心架构实施，建立关注业务的服务域，这些服务域能够将所有共享相同业务环境的业务服务放置到一起，建立、协调并为小组提供资金，代表每个行业和IT运转服务域，与项目管理的VP密切合作，以确保架构和项目管理组之间的紧密合作，改进项目管理原则，和每个行业中的行政管理密切合作以便就SOA措施的流程改进和灵活性进行交流，协调进程定义，改进和管理活动，并且更好的使IT功能定位全局业务需求。根据Payscale.com，如果情况更糟的话，一个有5—9年经验的业务分析师一年的收入不超过6万6千美元，但是有同等经验的企业架构师的收入却超过了10万美元。
另外，我们在讨论SOA模型时，将企业架构师定义为将业务要求引入服务并管理这些服务在IT开发组织实现的个人或机构。这时，企业架构师的作用就显得相形见绌了，甚至阻碍了业务分析师在机构中的工作，那么业务分析师和企业架构师是否完成了相似的任务呢？并不完全是这样。
尽管我们关注了IT业务分析师的作用，但是显然他们的工作范畴和技术性质在很多方面是不相同的。企业架构师的任务是将业务要求译成能够成本有效地实施，能够被预先管理，并且能被安全控制的功能。。企业架构师的中心抽取是服务模型，以及其它和信息、流程系统、功能流动相关的模型。功能流动能够继续操作业务。这看起来很抽象，尤其是对于开发商来说，但是业务分析师是在更为抽象的层面发挥作用的。
业务分析师的首要任务就是生成要求，并为科技小组之间的交流提供便利条件，以确保这些要求能够安全实施。当一个业务分析师稳稳地植入业务-IT分割时，业务分析师(甚至是一个IT 业务分析师)对业务来说都起着举足轻重的作用。但是，那些正在试图从SOA和其它架构驱动的IT措施中获取最大的利益的机构应该着眼全局，在业务中将企业架构师和业务分析师二者的作用相结合，或者建立一个新的能够将业务分析和企业架构的作用紧密联系在一起的组织结构。
将业务分析师和企业架构师结合在一起的部分原因是因为，业务分析师缺少完成建模的技巧。建模对于一个好的架构工作来说非常重要。其次，大多数业务分析师都对业务规格了然于胸，并且不用关注IT是如何影响规格实现的。另外，业务分析师通常依据短期内需要解决的分散的业务需求进行思考。要完成预定的SOA重用目标、减少赘余、以及业务灵活性，企业架构师可以提供大多数业务分析师在解决现今业务需要时所没有的共有内存和长期IT规划。
ZapThink采取的措施
在大多数机构中，和企业架构师的相比，业务分析师的作用得到很大的发挥，并为大多数人理解和接受。因此，任何认为企业架构师要超过，或者取代业务分析师，甚至影响现有业务分析师功能的假设都是不合理的。但是，企业架构师和业务分析师将来是向两个互补的方向发展。在一定程度上，业务分析师更多的是处理关于灵活性、重用、以及为集成降低成本的要求，他们会发现实际上自己反映了企业架构师在机构中所有活动。同样，企业架构师越加认识到自己将含混的业务需求翻译成架构模型和服务定义时，他们就会觉得自己在机构中起到了业务分析师的作用。
无疑，在机构中，并不是业务分析师处理的所有事物都是以IT技术为中心的，同样，企业架构师机构不会涉及业务操作的每个方面。但是，在商业环境下我们希望能从IT技术中获取更多的价值和个更高的效能。在这种环境下，需要我们重新思考业务分析师和企业架构师的作用——即对于IT计划来说，经过扩展、具有战略意义、操作性强的作用。比起商品化的IT实施和操作，IT计划在业务方面发挥的作用更大。当我们重新思考了业务分析师和企业架构师的作用之后，架构本身就会具有战略意义，并从IT机构的管理范围转移到业务操作。