作为技术人员，我们都知道企业正在不断的增加云计算的使用。越来越多的IT专家现在也意识到，在企业IT架构之外，更多云应用会出现。比如，个人业务单元会直接同第三方云提供商合作，没有直接介入IT，而实现了这种客户关系。
结果，最可能出现的是单一的企业，出于不同的目的，和不同的云服务提供商建立了多种关系。这些服务提供商可能忙于实现所有的功能，从基础架构即服务(IaaS)IT消费化(比如，灾难恢复、按需容量改善、虚拟测试平台等等)，到应用支持服务(PaaS)，企业内部开发者可以部署应用和组件开发到外部托管的应用(SaaS)，直接实现不同的业务部门的业务需求支持。
从业务部门的观点来看，可能有一些预期的优势，比如服务交付即时性，但是从技术治理的角度看，就会导致问题。其中一项挑战就是个人业务单元很少彼此协作，来确认他们正在从同一个提供商购买类似的服务。从安全和法规遵从的视角来看，造成了确保每一个厂商合适的审查以及管理的挑战，法规遵从问题则关乎敏感数据和法规数据，只能发送给企业，而且要能以安全控制的方式来审批。
服务目录价值
尽管一些配套齐全的企业正准备着手管理企业业务使用的多种云服务提供商，大多数企业却并没有这么做。由于很多这种关系都涉及了存储规定或者敏感信息，或从业务连续性角度看，数据对于业务是关键的，对这些关系不施以合适的治理，就会导致潜在的安全和法规后果。此外，因为这些关系可能出现在IT外部(多个源头)，存在逻辑负载型，因为这些关系可能并不能很好的适用于以前的治理模型。
围绕服务提供商关系构建一个目录，可以协助二者更好的管理潜在风险，为进一步的战略云计算应用计划实施奠定基础。首先也是最重要的，这个目录帮助企业识别和文档化正在使用的不同服务提供商。这很有帮助，因为服务本身不是静态的，也不是关于他们在企业中如何使用的。记住服务提供商，就像是组织机构一样，会不断改变其提供的服务，他们可能升级了安全控制，导致了宕机时间，或者成为违规的牺牲品，或者一个组织机构决定扩展使用的提供商的范围。为了管理这些，需要进行核心集中监督。
一个架构化服务提供商关系目录意味着很多事情。能够协助企业确定每一种关系的具体所有者，比如，谁签订的这项服务就来对这项用例负责。也要帮助保持与服务提供商产品更新保持一致，协助本地区域潜在的整合实现。比如企业可以利用服务提供商来部署更多，这都要进行协商，或者对比不同产品的效果。简而言之，追踪云服务提供商关系对于企业来说，和追踪第三方关系具有同样的价值。
构建详细目录
在将这些结构化目录放到一起之前，要找出大型企业中云服务用例的全部范围，这确实是一项额外的挑战。可能最简单的方法就是找到那些维护这些历史惯例的清单，编制出一个当前厂商关系目录。然而，这样做可能只能编制出一个真个网络的子目录。因为很多云服务提供商对于任何的客户都非常易用，其产品可能只需要用信用卡交易就能支付实现，这就很难追踪。有一些还针对一些用例免费。
实施云服务发现流程最好的办法就是查询企业内所有不同的业务、技术和支持团队，确定他们使用的用例是什么，包括正在使用什么服务，如何使用。
比如，如果针对企业可持续发展计划(BCP)的商业影响分析实践是定期管理的，收集云服务使用的用例，对于自动化这个流程也有帮助，减少了一些问题。或者，在应用风险回顾中询问目标问题，也有助于新计划和业务流程的回顾。
从个体收集数据时，记住很多用户对于“云”是什么并没有概念。比如，如果你问一个问题“你使用什么云服务?”，他们可能不理解像SalesForce这样的工具就是云服务，因此他们也不会提供你寻求的数据。相反，要问一些更合适的问题，“比如哪家公司托管和管理XYZ服务?”如果他们不知道答案，至少你知道下一步工作的方向。
底线
在企业中将云服务提供商目录放在一起是一项生产性实践，允许管理者对比他们正在审查和批准的关系，评估具体的用例类型以及对象可能要求遵守的法规环境。此外，在先关的调查中，可靠的目录格外有用。
