点击上面↑“Teamcenter笔记”关注，回复“工业软件群"加入工软大家庭！
| 数字孪生 | 最佳实践 |
| 选型指南 | BOM方案 |
| 变更管理 | PLM资料 |
| ERP资料 | MES/MOM |
| SCADA资料 | IIOT资料 |
| 工控基础 | 职业发展 |
PLM 实施遵循一个迭代过程，在此过程中，业务问题和需求通过一系列技术交付成果转化为详细级别的设计模块并与之保持一致。正如本系列文章第 1 部分中讨论的那样，“PLM 解决方案架构师”角色在将愿景、高级路线图和业务需求转化为可通过技术实施、测试和部署的有形解决方案元素方面至关重要。在第 2 部分中，我们将介绍 PLM 实施中预期的通用“设计”交付成果，以及解决方案架构师必须克服的相关挑战。
简而言之，解决方案设计交付物的深度和广度会根据 PLM 范围以及集成和转换的复杂性而有所不同。PLM 解决方案架构师直接参与创建和管理这些交付物：
签署业务故事板如何转化为详细的 功能用例和非功能性需求；在与业务中小企业精心准备的设计研讨会上对这些进行迭代。
试行 概念验证、记录和演示 用例设计原则 以验证每个元素并获得业务和 IT 部门的认可。
开发 功能和非功能规范文档 （包括性能、安全性、协议、序列等），以使用例和情节提要与应用程序功能和配置要求保持一致。
创建和维护 业务流程模型蓝图，涵盖逻辑数据模型和所需的增强、配置和定制。
与其他企业和系统架构师合作创建 集成/接口规范 （消息协议、文件格式、生产者和消费者接口、消息模型、结构和转换、服务行为、连接要求、错误处理场景、安全模式，包括预期的维护和支持服务级别要求）。
记录与 数据质量评估、部署模型和遗留迁移策略相关的数据质量要求和影响规范 ——也作为上述技术规范的输入。
执行和记录 技术和交付影响分析，建立 技术治理论坛，并根据业务或 IT 提出的变化维护 技术决策日志 ；这包括提出建议的前进方向并支持交付经理获得利益相关者对修订后的部署计划的认可。
一些交付成果需要与其他 IT 技术团队携手合作，跟进功能和非功能测试期间提出的问题，包括系统渗透、数据迁移、应用程序和集成性能，以及中间件、数据库和编码优化要求。
在领导这些交付成果的开发过程中，PLM 解决方案架构师可能会与供应商和实施供应商进行交流，主导技术讨论并不断寻求协调。与创建、维护和获得这些交付成果的批准相关的典型挑战可分为以下 8 类：
可以访问所需的遗留信息、“原样”流程和业务意图。
定义并维护清晰的架构设计原则，从而实现有效的“设计权威”治理。
持续主动地与业务交付机构就解决方案假设、差距、计划和必要的交付活动进行协调。
尽早了解源数据质量和相关目标集成或迁移挑战。
与其他企业和 IT 架构师就可能参考现有架构标准的设计元素进行协调（或识别由于缺乏此类标准而导致的差距并提出解决方案）。
了解组织的成熟度及其选定的维护合作伙伴的成熟度和运作方式。
与业务变革领导者/关键用户和 IT 架构师（包括云架构师和其他解决方案提供商）建立信誉和一致性。
对项目和项目管理有基本的了解，并且能够在必须优先考虑其他交付参数时支持某些设计权衡。
一方面，随着云托管解决方案的兴起，混合集成需求将进一步出现；它们很可能会影响配置和定制设计元素。另一方面，在为多租户客户提供平台即服务 (PaaS) 解决方案的背景下，“PLM 解决方案架构师”的角色可能变得不那么重要——至少对于针对中小型企业市场的 PLM 解决方案而言。在应用程序级别，可以期望解决方案架构师更加关注业务流程架构、集成和数据映射。
