企业架构本身是解决企业整体业务与数字化框架与结构的问题，通过各架构逐层的定义，明确了从顶层到细节的各元素及其关联关系，能够约束、指导后续数字技术实现。但是，企业架构本身是业务视角为主，逻辑视角为主，并不意味着本身就是系统架构，或从数字技术实现的角度，要更多考虑物理上的技术实现结构，物理部件间关系。因此在很多企业的数字化转型中，企业架构与各系统实现容易脱节，形成两张皮，特别在使用成熟套装软件产品来部署和实施，基本上会显然“你说你的、我做我的”状态。

纠其原因，一方面企业架构和系统架构，本身就是两个不同视角呈现企业业务管理，不能相互替代；另一个方面，也是由于企业架构在具体设计中，粗略不当，过于约束或不当约束了系统架构设计与实现；第三个方面是系统实施（人员）不习惯不善于去理解和遵从企业架构，这也是有架构管控的原因。

因此，对于核心系统、关键应用的系统建设，为了避免两张皮，实现系统架构对企业架构的遵从，除了采用架构管控的方法，另一个非常重要的手段是将企业架构延伸到软件工程的“需求规格说明书”环节，以确保企业架构的要求转化为软件实现的需求，从而保障企业架构与系统架构的一致性。

需求规格说明书，是系统实施的起点，也是系统设计人员习惯的输入，需求规格说明书中，需要描述的业务场景、业务流程与用例、业务功能，以及各功能下的各项详细规则，都可以通过企业架构与数据架构来获得并以此作为需求。

业务架构中的流程体系（或叫流程模型），从L1-L5的层级上看，将企业业务按照价值链进行划分，L1确定本需求的业务范围、L2确定需求的主要场景应用范围、L3确定需求的流程实现与用例交互、L4确定系统应该实现的功能、L5确定系统功能中的业务规则和处理步骤；此外，需求中关于应用服务的筛选、识别、定义，也可以参考业务架构中的业务组件的颗粒度来进行定义与封装。

数据架构中的业务对象下的数据实体和属性（构成的数据模型），也是需求中系统功能中的业务数据与数据项的来源，也确定了这些数据项与属性的业务特征，例如数据取值范围、数据长度等。

基于企业架构中业务架构与数据架构的输入，能确定需求规格说明书中关于系统定位、功能组合、服务识别、流程逻辑、数据要求等，再进一步结合业务架构中的业务位置、业务角色权限矩阵等具体的信息，就能形成基本完整的需求规格说明书，后续的系统设计，再结合技术架构中的原则、技术路线、容量性能等要求，就能形成与企业架构保持一致的系统。