中国银行业的“大集中”是IT架构发生历史性变化的典型例子。在“大集中”之前，各种应用系统的开发都是在以省级分行为单位的基础上考虑的，完全没有整体上的设计；更确切地说，当时的应用系统开发主要是出于对部门级或分行级应用的考虑，还谈不上企业级的架构。随着银行业务的发展，对数据的要求发生了变化，从而出现了新的数据架构的考虑，因此，“大集中”开始成为主流。
但是，“大集中”没有解决所有的问题，银行依然要面临种种困惑：“大集中”真的能满足银行业务与战略的数据架构吗？“大集中”是银行企业级架构的大方向吗? 核心数据集中了之后，还要对其他数据也“大集中”吗？如果都“大集中”了，怎样保证分行业务的灵活性和多样性，我们怎样应对银行业务的创新和发展？
对于上述的种种困惑，我们不可能有一个“放之四海皆准”的答案，正确的答案应该来自于各个银行自己的业务和战略发展方向。对这样一个企业级架构的问题，我们必须从企业级架构的基础—业务架构的角度来认真分析从而找到答案。
建筑师的思考方式
讨论架构问题，建筑工程和建筑师是最好的类比，业务架构的规划，如同建筑群中的区块划分。一个建筑群的设计要首先考虑这个建筑群的用途，其次要考虑其周边的环境等。因此，建筑师的第一步工作就是摸清楚客户的要求和建筑现场的环境。对建筑群功能的了解有助于将建筑群划分成不同的区域，规划各建筑之间的关系，如住宅区与写字楼区的关系等；进一步，建筑师还要了解使用者的情况，如住宅区可能居住的人员的习惯，办公区进住的公司类型等; 对环境的了解有助于考虑整个建筑群与外部城市的关系，如道路和水电等等。
做企业级IT架构的道理是与此相通的，架构师们必须首先了解该企业的业务情况，这包含企业的现有业务和将来可能发生的业务（即战略发展目标和方向）。企业的业务往往是由不同的职能部门来完成的，同时，相应的管理部门也在业务过程中发挥作用。为了有效合理地规划IT系统的建设，对业务和部门组织结构的了解就成了规划企业级架构的基础工作。与此同时，企业与其他企业和政府部门的往来情况也必须了解清楚，掌握企业架构的周围环境，这与建筑群对外交通和水电规划是一样的道理。对企业业务和外部组织关系的了解所得出的成果就是我们所说的企业业务架构。企业业务架构是对企业业务需求和战略发展的高度总结。
只有勾画出清晰的业务架构，才能定义出正确可行的、具有持续发展能力的技术架构。 企业业务架构从IT的角度，对企业的业务结构、企业机构与业务的关系、企业内部的关系以及企业与外部机构的关系进行整理定义。企业业务架构包含了：
● 企业的业务和战略目标: 描述企业的目标，包含近期目标，中期目标和长远的战略目标。
● 企业的组织机构：明确描述企业的组织机构和职能，以及与企业相关的机构和个体，如客户，合作伙伴和供应商等。
● 业务的分类：对企业的产品、服务和资源体系进行分类。这种分类包含了对相关产品、服务和资源的共性提取和总结。
● 各类业务之间的关系：对产品、服务和资源的相互关联进行总结。业务之间的关系体现为跨业务的流程及资源共享等。
● 组织机构与业务的关系：业务的执行是由机构来完成的，但是机构与业务并不一定是一一对应的关系。清楚地找出机构与业务的关系，将为应用与集成架构奠定可靠的基础。
● 企业与外部机构的关系：对与企业相关的外部机构或个人就其类型，业务类别，业务往来模式等进行分类。
● 企业的组织机构：明确描述企业的组织机构和职能，以及与企业相关的机构和个体，如客户，合作伙伴和供应商等。
● 业务的分类：对企业的产品、服务和资源体系进行分类。这种分类包含了对相关产品、服务和资源的共性提取和总结。
● 各类业务之间的关系：对产品、服务和资源的相互关联进行总结。业务之间的关系体现为跨业务的流程及资源共享等。
● 组织机构与业务的关系：业务的执行是由机构来完成的，但是机构与业务并不一定是一一对应的关系。清楚地找出机构与业务的关系，将为应用与集成架构奠定可靠的基础。
● 企业与外部机构的关系：对与企业相关的外部机构或个人就其类型，业务类别，业务往来模式等进行分类。
颗粒度的把握
在企业业务架构定义的过程中，存在一个怎样把握颗粒度的问题。如果定义得太粗，则失去对企业技术架构的指导意义。如果定义得太细，会使企业业务架构成为一个永远没法完成的任务。
怎样把握是一个具体情况具体分析的问题，但基本的原则是将主线留在企业业务架构中，将细节留在具体应用的业务架构或功能架构中去处理。
例如，电信行业的eTOM模型为电信营运商制定企业业务架构提供了参照模型。eTOM模型总结了全球电信营运商的业务模型，将电信业务归纳为不同的过程（Process）并将这些过程按起颗粒度分成不同的等级。并且，eTOM模型将这些过程按服务、产品、资源以及外部合作伙伴进行归类
eTOM模型包含了电信企业的规划、建设、营运和管理的功能。虽然由于其参照特性，eTOM模型没有对电信营运商的组织机构进行定义，但它对电信营运商的企业业务架构有着很好的指导意义；也正是由于这一点，使得eTOM模型有着广泛的使用性和参照性。
根据eTOM不同等级的过程和分类，我们既可以根据高等级的过程和我们企业的实际情况来制定企业级的架构，即怎样划分BSS、OSS和它们的边界；又可以根据低等级的过程来看具体应用的功能架构，如CRM该做什么、记费系统该做什么等等。从eTOM模型这个例子，我们可以学习在企业业务架构中如何把握颗粒度的方法。
业务架构的扩展性
企业业务架构的维护是一个长期的工作，不是一个“一次性”的任务。企业业务架构在明确了企业的业务和战略目标之后，从业务和机构两个基本点出发进行基础性的分类组织工作，然后根据业务的分工和业务流程与组织机构实现映射，从而形成对企业业务的完整描述。
在对业务问题进行分析时，不仅要考虑企业目前业务的情况，而且要考虑企业业务的发展，如新的服务或产品的推出等。组织机构也不是一成不变的，新业务的出现可能导致新的业务部门的产生，新的业务模式也可能导致新的业务部门的产生和变化，企业的发展还会带来企业的合并或拆分。
企业的业务流程的变化也是要考虑的因素。所有这些可能的变化都应该体现在企业的业务架构中，只有这样，企业业务架构才能对技术架构起到指导作用；只有这样产生出来的企业级架构才能真正为企业的业务和战略服务，并满足企业的长远发展目标。
通过对企业业务架构的定义，就可以很清楚地知道由于企业业务特点、业务流程的特点和企业的组织机构等原因对IT系统所带来的自然分块和各个分块之间的边界关系，从而我们就可以知道怎样从技术架构上来满足和支持企业的业务架构。企业业务架构的变化可以通过技术架构反应出来，技术架构的正确与否可以通过业务架构来检验，这样，才能通过架构来保证IT服务于企业的业务和战略。
我国的信息化建设长期以来的习惯是：重个体应用，轻整体架构。发展较快的行业今天已经面临着需要对其技术架构做出调整的时候了。如银行领域完成了“大集中”后，电信行业完成了97系统改造、BOSS系统改造后都要面临架构性的变革。
今天，很多企业已开始认识到企业级架构的重要性和IT规划的重要性，然而，作为企业级架构基础的业务架构却没有引起我们的足够重视。不认真从企业的业务架构出发来制定其技术架构和IT发展规划，很容易使IT的建设与企业的业务和战略脱节，从而导致重复建设和错误建设，并因此浪费大量的IT资源。因此，笔者建议，每一个希望认真从企业级架构入手制定IT发展规划的企业，必需认真做好企业业务架构的整理，定义和维护工作。 (计世网)
