企业架构思想在软件架构设计中的引入思考

　　对于企业架构和软件架构设计两个方面的内容，在前面头条文章中都详细进行了说明，今天谈下EA企业架构思想在软件架构设计中的引入。企业架构思想核心逻辑
　　在前面的分析中，IT规划所遵循的思路主要是：业务驱动IT，围绕价值链分析和优化的核心模型往前驱动。核心过程包括现状分析、差距分析、目标提出、蓝图规划、实施规划等几个关键。
　　企业架构规划一般思路仍然是从端到端流程分析入手，再逐步分解到34级流程，直到能够识别具体的业务操作和业务对象。流程到子流程，再到业务活动，业务活动中承载的是业务单据和业务实体。需要对业务实体进行抽离，进行数据层面的数据建模和分析。分析在流程各个阶段和活动中产生的业务实体之间的关联和依赖关系。业务域对应到数据域和数据分类，进一步可以分析到具体的概念模型或逻辑模型。
　　在识别到具体的业务功能或业务操作后，再基于高内聚松耦合的思想从底朝上进行聚合，来构建具体的业务架构并划分具体的业务域和业务组件。在整个偏结构化的分析过程中，一般常用业务功能和业务数据间的CRUD分析来进行功能聚合和数据聚合。
　　业务架构完成后，将会过渡到应用架构，两者基本是对应的。其中较大的差别点在于业务架构只关注业务，业务本身分为功能性需求，非功能性需求。非功能性需要中包括了平台层面的支撑需求，即应用的集成支撑和数据的集成支撑，公共平台层功能等。另外还包括了纯技术层面的非功能性需求。
　　应用架构分析除了分析应用功能架构，还需要进一步分析各个应用间的集成架构和交互关系，同时通过应用架构来进一步模拟整个跨业务系统实现的端到端流程。
　　同时在应用架构的构建中还会发现一些和应用本身无关的技术支撑能力，这些应该统一规划到技术平台来进行构建并形成技术架构规划。传统的企业架构规划中的技术架构一般偏资源层的IT基础设施架构规划，而当前的技术架构规划则包括了PaaS层的技术服务能力提供，这个可以参考我前面相关文章。
　　对于企业架构分析可以参考下文：
　　从企业架构到信息化规划，从现状调研到架构设计的核心逻辑
　　企业架构和IT规划咨询核心逻辑2014软件架构设计41视图
　　一说到软件架构设计包括的内容，我们比较容易想到的就是传统RUP和面向对象分析和设计里面经常谈到的41架构视图，该图也更好地解释了软件架构应该包括功能性架构和非功能性架构两方面的内容。
　　逻辑视图即是从功能需求视角，逻辑视图更多的就是组件划分，组件间的依赖关系，当然你可以进一步细化到核心的类和类关系图。但是一般来讲搞清楚组件和组件间关系最重要。
　　对于非功能性需求实际有两个方面的考虑。开发态：即技术和开发框架选择，开发分层模型运行态：系统集成视角，进程视图，对于性能和可扩展性的考虑
　　当然RUP更加强调的是用例驱动，即最中心的是用例视图，用例视图是展开后续架构分析设计的基础。如果熟悉RUP方法论也可以看到，对于用例实现的分析才能够识别出关键的实体类，控制类和边界类，在类识别出来后才能够进行后续的组件划分和接口集成分析等。
　　详细内容可以参考：
　　一文讲解业务系统软件架构设计核心内容和逻辑企业架构思想在软件架构设计中的引入
　　很多时候在谈企业架构的时候都是针对跨流程，跨业务和跨应用系统的总体规划和分析，企业架构核心好处就是真正体现业务驱动IT，将业务和IT能够真正的匹配起来思考整个企业层面的架构问题。
　　而对于软件架构设计仅从软件实现层面来考虑问题，针对一个业务系统的开发，虽然也有业务建模和软件架构，但是这两个却进行了分离而缺少了系统性的思考，所以原来喜欢用系统分析师这个词来综合业务分析师和软件架构师两个岗位的工作。
　　对于企业架构思想融入到软件架构中，即真正对软件架构层面的工作进一步整合，减少在系统分析过程中从现实业务层面来抽象IT层面的脱节。改变传统软件架构仅仅考虑实现层面和技术层面的问题。对于引入方法和具体内容，还是从软件架构的一些核心内容来谈。
　　对于传统的RUP方法强调用例驱动，架构为核心。对于用例驱动在架构层面首先有全局的用例模型，但是多数情况并没有真正建立全局用例模型，而结合业务建模可以看到仍然是流程分析，子流程，业务功能逐级展开后形成全局用例模型，那么全局用例模型就不简单是用例图能够涵盖的，全局用例模型通过流程驱动真正融为一个整体。
　　再回来看逻辑视图，对于逻辑视图现在一般是基于领域模型的方式来分析逻辑视图，但是对于逻辑视图设计建议仍然是不要一下进入到具体的类图和类关系图层面，而更加重要的还是理清楚核心的业务对象模型和对象间依赖，关联关系。可以从用例建模中识别核心业务对象并进行对象建模，形成核心的逻辑视图。
　　用例视图偏动态的流程和业务功能，而逻辑视图偏静态的业务对象和数据模型。这是架构设计关注的两个核心内容，在这个完成后带来另外一个问题即组件如何划分？
　　当前在软件架构设计中进行组件划分时并没有深入去考虑这个问题，只是给出高内聚松耦合的大原则。这也是在模块划分我一直考虑在面向对象分析方法中需要引入传统的类似CRUD矩阵分析等方法的原因。
　　对于组件的划分，从原来的流程和数据两条线再来分析组件划分方法看到，既可以根据大的业务流程阶段，子流程来划分组件，不通的阶段或子流程划分为不同的组件，如供应商协同，招投标，合同管理，采购管理等。也可以根据核心的业务对象来划分不同的组件，如采购订单对应采购管理，合同对应合同管理，请购单对应请购管理等。
　　不论哪种方法，其目的都是为了减少组件间的交互和接口，组件划分工作不是一次就完成的而是需要通过反复的迭代，比如为了减少集成接口可能将某个业务功能从组件A移动到组件B等。对于组件划分的分析包括了组件划分完成后组件和组件间的接口和集成分析，组件和数据间的关系和CRUD分析，系统级流程在多组件间的协同和交互模拟等。而这正是开发视图和进程视图要解决的问题。
　　前面这些都分析完成后，自然会引入集成架构和集成视图的概念，即组件划分完成后需要考虑组件间有哪些接口，接口识别仍然是前面跨组件系统分析交互点，接口识别清楚后可以画出完整的系统内组件集成架构，跨组件业务协同流程等。这些内容是架构设计的核心，否则分解到每个组件设计的时候出现只见树木不见森林的情况。不清楚组件在整个系统中的具体位置。
　　这些都清楚后才应该过渡到物理视图层面，物理架构主要关注系统非功能性的需求，如可用性、可靠性（容错性），性能（吞吐量）和可伸缩性。软件在计算机网络或处理节点上运行，被识别的各种元素（网络、过程、任务和对象），需要被映射至不同的节点。
　　从前面整个分析设计可以看到基本没有谈到技术框架，架构分层模型等内容，也再一次说明了架构设计重点在功能性架构和核心领域逻辑，而不是一开始就陷入到分层技术架构模型中。只有把前面的内容都搞清楚了才能给更好的考虑如何建立业务系统本身需要依赖的技术平台。