今天工作上，发生了几次论题的讨论，其中一次比较典型，记录下来。
我们部门对公司内部主要提供两种实体的生命周期管理：IT资源和运行在资源上层的服务。
争论的原因是一个内部用户的非标服务，未按照服务标准化建设，期望能够以手工的方式随意使用其他服务的资源。
本来这个问题在服务管理中是提供了解决方案的，谁的服务使用什么资源，也提供了工单式的自动化申请和操作流程，但是服务方不想精细化资源的使用，期望能实现"一个服务申请，多个服务使用"。
按说方便使用资源，是个合理的需求，但是与用户接触的小伙伴着急实现用户的需求，提供了手工支持的建议。
整个实体的生命周期管理，是一个体系，表象上是申请方式不同，其实背后对应了一套记账、对账、账单、资源流转交付的能力。
解决这个问题，就要打破之前推动了2-3年的标准化工作。
当我们一穷二白的时候，可以充分发挥想象力，当我们的系统、平台已经成为体系的时候，问题就变的复杂，因为互相关联依赖、需要考虑的维度更多了，很可能产生蝴蝶效应。
我们需要在一定的限制条件下给出方案，而不是简单草率的非标支持，因为这会引入实体后续更长久生命周期的非标的坑。
系统的考虑问题是一种能力，如果没有复杂系统使用和架构经验的人，很难凭自己的想象理解这其中的复杂度。
当然这种错综复杂的依赖关系，会限制住我们的手脚，是需要整体产品架构上定义清楚彼此的边界的，也是我们后续努力的方向。
