使用Salesforce.com建立企业架构
我是SFDC平台的忠实拥护者。如果实施和管理正确,它就有可能改变业务。不幸的是,我已经看到许多公司在试图从Salesforce获得价值的过程中脱颖而出。造成这种情况的原因不胜枚举,但以下是我见过的一些重要原因:
战略
- 公司使用Salesforce的组织远景或方向
- 没有将平台的使用与公司目标联系在一起的路线图和产品管理策略。
- 没有正式的架构,治理或变更管理策略会导致孤岛式功能的进化设计或多个Salesforce实例的滥用。
环境
- 最初的实现是在客户几乎没有技术理解的情况下交付的。
- 在如何以及何时使用配置与自定义代码之间缺乏理解。
- 实施顾问仅提供“功能价值”,因此在配置设计和编码层中缺乏任何标准。
- 没有模式,没有模块化,并且没有机会在不进行大量重构的情况下扩展功能。
- 测试范围仅是经过深思熟虑而完成的,并且缺少任何类型的设计或断言。更改配置或代码时,很有可能会破坏某些内容。
- 缺少能捕获您的设计及其设计原因的任何形式的动态文档。
采用
- 不愿或无法退休的遗留系统使人们无法使用该系统。
- 缺乏与最终用户的培训或沟通
- 新系统中的数据质量低下,系统的输出不可信
那么,如何防止此类问题呢?如果您已经是这个问题的受害者,您该如何解决?我对您的建议是:使用Salesforce.com建立企业架构
你怎么做到这一点?这并不容易,需要时间,金钱和平台知识。但是,如果操作正确,Salesforce可以成为您的业务的与众不同的地方。
这篇文章及其后续文章将引导您完成为Salesforce建立EA的过程。我使用的主要框架是TOGAF体系结构开发方法。如果您不熟悉TOGAF,建议您阅读一些有关该框架的知识。TOGAF是一种用于设计,规划,实施和管理企业信息技术环境的方法,并且是The Open Group Architecture的开放标准。
The Open Group的TOGAF v9.1架构开发方法论
在整个文章中,我将遵循TOGAF的阶段,并在您塑造Salesforce体系结构时指出一些相关的问题和注意事项。话虽这么说,大致是您在制定计划时将遵循的过程:
- 为Salesforce定义架构构想
- 谁是您的利益相关者和您的业务目标?
- 有哪些企业目标会影响您的愿景?
- 您的建筑原理是什么?
- 您的体系结构存储库在哪里,您将如何管理工件?
- 设计您的业务架构和策略
- 哪些业务部门将使用Salesforce?
- 您的业务需求是什么?
- SFDC将实施哪些业务流程或受其影响?
- SFDC将建立您的哪些业务基础?
- 您的组织策略是什么?
- 谁是您的演员以及可能的许可证选择?
- 设计您的信息系统架构
- 您如何在SFDC上设计应用程序体系结构?
- 您如何设计SFDC的数据体系结构?
- 您的应用程序合理化计划是什么?SFDC将添加或淘汰哪些内容(以及何时使用)?
- 您的差距/契合度是什么,您将如何处理?
- 设计您的技术架构
- 您的集成架构师什么?
- 什么是定制开发的正确架构?
- 您将如何管理技术环境?
- 您的技术风险是什么?如何减轻风险?
- 设计实施计划
- 什么是正确的使用方法?
- 您的SFDC建筑成熟度如何?
- 什么是合适的发布策略?
- 您如何制定路线图?
- 计划您的迁移
- 您对每个版本的成本/收益分析是什么?
- 您对项目有什么依赖性?
- 什么是正确的部署策略?
- 您的测试策略是什么?
- 您的数据转换计划是什么?
- 设计治理计划
- 您需要哪些小组来整合您的工作?
- 您如何建立有效的CoE?
- 什么是架构审查委员会?
- 您如何设置系统管理模型?
- 您如何管理供应商?
- 您将如何确保遵守建筑设计和标准?
- 定义您的变更管理计划
- 您如何有效地管理变更?
- 生产中可以进行哪些类型的更改,以及由谁进行?
- 在项目与错误修复中应进行哪些类型的更改?
我的建议是按顺序遍历列表,并尝试尽一切可能至少回答一次所有问题。然后返回到第一部分(建筑视觉)并开始细化为更深层次的细节。TOGAF是周期性的,因此您针对SFDC的EA的设计和实现也是如此。它遵循持续改进的概念,每次迭代时都会不断发展。因此,请忙于为SFDC建立您的EA。您的用户,您的技术团队和您的业务利益相关者将对此表示感谢。