需求层面：

提示：领导在参与评审过程中，他是一个黑盒的状态，我们必须要明确目标和基线，这个时候领导才能做出很好的决策，不然就等着挨骂吧

例如：

• 我们这次工作汇报的工作内容的 **目标** （这里针对你汇报的成果的依据，我们要达到什么样的目的）是什么，目标要阐述明确
• 确定目标之后，定义的**边界** 是否合理（包括是否满足规划），基于业务场景的边界划分：
  -1）模块和系统的边界,各服务有清晰的责任及边界，一个服务对应一块业务，服务间多为单向依赖（系统边界）
  -2）各个模块或者组件所擅长的功能或能力（职能边界）
  -3）基于技术域和业务域对系统各个组件关系进行切割，最好阐述下自己的领域检查或DAG检查（业务边界）定义好关键业务，辅助业务，业务禁区，很多人对边界的定义很模糊，网上找了一个通俗易懂的case边界如何划分
  -4）边界划分好之后，表述系统间的集成方式
• 边界澄清之后，接着说自己平台或产品的**内部架构** ，架构目前我知道的规范有两种一个4+1视图，这个受众人群更多有无技术经验人员皆宜，还有一个是TOGAF标准 ，比较适合有技术积累的人员高效沟通
• 最后从各个**层级**和**视角**去陈述为什么是核心技术（核心技术可以从技术核心和设计核心去展开），各个层级可以从架构层面包括技术架构，业务架构，数据架构，应用架构站在技术视角和业务视角系统性的补充，当然像前期没有沉淀和积累的一些主流技术，通过对比行业，在主流技术的基础上突破了什么技术，也可以作为核心技术来说

实现层面：

提示：任何汇报都离不开需求，而支撑需求的是工程化，这里实现层面也需要承上启下

例如：
1.要输出技术架构层面和实施层面的知识，比如总体技术路线是什么样的，对外提供的服务有哪些，提供数据的交互的方式，最后怎么实施和部署这些要素要说清楚，
2.某个特定的功能或者能力，通过什么算法依托，结合哪些响应的组件和框架，并对哪些开源的框架或者算法做了什么改造，提升了什么能力，现在是一个什么状态，围绕这些要素去展开
3. 如果涉及到数据流程的环节，领导可能比较关注数据从哪里采集，具体采集哪些数据（全部采还是部分采），也就是我们要定义数据边界，采集后的数据怎么存，采集和存储有没有现成的技术框架
4. 技术选型要素，包括满足需求场景对比技术框架的优劣，开源的基础上有几种做法，对比几种技术**实施**路线，形成一个整体的解决方案
5. 有特定数据要求的情况下，比如数据仓库数据湖又或者数据中台，可能还要数据体系是什么样的，数据应该分成大类，小类，小类细化。数据体系怎么建立的？比如研发中台的数据体系应该是研发经理和项目经理以及产品经理的视角来看哪些数据是比较关注的，形成数据规范，这样数据架构就出来了，数据架构出来技术架构就出来了，实施方案就清晰了。

具体的框架要素包括：
一、技术背景背景：基于什么背景和技术实施的必要性以及实施后的意义以及带来的价值
二、需求分析： 1）包括用户目前的需求带来的问题以及未来需求的设想，假设后续的需求带来的性能要求等。2）描述现有的技术现状是否能够承接不同的数据环境，人员技术现状能持续满足后续的技术要求等
三、设计原则和要点、设计依据
四、选型方案：技术对比，技术调研 选型方案：技术对比，技术调研
五、总体设计：togaf标准架构图，
四、方案特点和优势：论述可靠性，安全性、高性能等特点和优势

文档产出：

提示：汇报的形式不一定是PPT，有时候领导风格不同，对具体要输出要求不一样，word能讲明白的就不用ppt，关注汇报的要素是注重结果的同时也强调过程

例如：

• PPT输出
• word输出（设计文档）
• xmind输出
  最后说一句：只有需求清晰，边界合理，落地才有保障