对于架构分析的入口点，仍然推荐是从端到端流程分析入手，细化到业务域的端到端，再细化到3,4级流程，最终细化到EPC最底层流程图。EPC流程图既是流程，本身也是业务功能。还有一条线可能是直接从业务活动收集和组合入手，如根据业务部门，岗位角色划分，从组织架构和岗位职责直接收集业务功能点。第一种方法既看到面又看到点，从上到下；而第二种方法则是容易只看到点，仍然无法贯彻整个企业端到端流程。
要注意流程分析并不一定能够涵盖所有的业务功能点，因为有些业务功能本身就是最底层的EPC流程，往往并不是从高端的端到端流程分解而来的。如用章管理是一个业务功能和EPC流程，但是并不一定能够挂接到高端流程上面。这也是端到端流程分析要注意点，高端流程分析和分解是建立全局思维，但是仍然要借助第二种方法收集完整的业务和活动。
流程到子流程，再到业务活动，业务活动中承载的是业务单据和业务实体。需要对业务实体进行抽离，进行数据层面的数据建模和分析。分析在流程各个阶段和活动中产生的业务实体之间的关联和依赖关系。业务域对应到数据域和数据分类，EPC层面可以分析到具体的概念模型或逻辑模型。流程分析偏业务操作和事件，而数据又正式业务操作的对象。SOA中强调操作和数据解耦，刚好是分析的两个维度。
业务架构中的业务组件划分特别强调的是业务本身的高内聚和松耦合原则。对于任何一个业务域基本有两种类型，一种是数据驱动型，一种是工单任务型。如资源，资产，合同管理等。这些是核心数据对象，业务操作层面重点是对数据对象实现全生命周期管理。因此业务组件划分基本遵循底层为基础数据支撑层，上层为生命周期管理层，覆盖该数据对象的核心生命周期阶段。这是业务组件划分的一个基本思路。
对于业务架构的构建，特别是我们对某个业务域往往并没有深入的理解前，最好的方式就是流程驱动分析，抽离数据进行数据建模，然后进行CRUD矩阵分析，分析数据和业务功能的关系。对底层的业务功能进行组合满足高内聚松耦合的原则，然后从底向上的对细粒度的业务功能进行组合，形成高内聚的业务组件。当然在整个过程中往往我们会参考业界标准的业务架构参考模型，如供应链的scor模型，电信行业的etom模型等。
从ARIS企业架构分析中的Y模型可以看到，Y模型的左边为业务架构，右边为流程架构，而最底层够归集到EPC流程。整个分析顺序为端到端流程分析到EPC，结合数据建模和分析，通过CRUD矩阵分析等方法从底向上抽象业务组件形成高端业务架构。
业务架构完成后转应用架构相对简单，业务架构和应用架构基本来说是对应的。其中较大的差别点在于业务架构只关注业务，业务本身分为功能性需求，非功能性需求。非功能性需要中包括了平台层面的支撑需求，即应用的集成支撑和数据的集成支撑，公共平台层功能等。另外还包括了存技术层面的非功能性需求。对于前者需要体现到应用架构中我们往往会技术支撑平台和应用支撑平台，技术支撑平台包括了安全，管控等；而应用支撑包含了数据平台，集成平台和流程平台等。应用架构一般会分为支撑层，应用层和决策层。其中的应用层基本可以做到和业务架构一一映射。
应用架构完成后再来考虑集成架构，而集成架构需要考虑的是业务系统间的具体的集成点。这个集成点的分析我们期望的将端到端流程，结合应用架构中的业务系统，CRUD矩阵分析形成跨业务系统的跨系统交互流程图。这种流程图已经不是纯粹业务层面的流程图，而是做系统交互分析的跨系统交互流程图。所有的跨系统交互点则为流程驱动下的业务集成点。而CRUD矩阵分析则帮助我们分析出数据驱动的数据集成点。前者为业务服务为主，而后者即以数据服务为主。两周在分析完备后最终都体现到应用集成架构中。
业务中的平台级和非功能性需求转化到应用架构中的底层支撑层，对底层支撑层中的核心技术进行抽取，最终转化到一个完整的技术架构。技术架构和业务无关，提供的是底层技术支撑层能力。在我们经常的产品规划中也可以看到产品，平台和技术必须分离。产品和平台都会提出相关的技术需求，技术架构为上层提供完整支撑。
技术架构逐步转化到公共的平台层，提供核心的资源池能力。业务组件本身转化为能力单元，业务组件由平台资源承载，提供业务服务能力。业务服务最终又可以通过的灵活的配置形成完整的业务应用。因此我们所说的解耦不仅仅是业务组件间的横向解耦。还包括了业务组件到底层平台，业务组件到上层应用间的纵向解耦。