Managing Complexity in Your Enterprise Implementations

Editors Note: This is the last in a 6-part series entitled Enterprise Architecture with Force.com. Our guest blogger, Greg Cook, is a managing partner of CloudPremise and currently holds all seven Salesforce certifications.

Salesforce Enterprise Architecture - Greg Cook Salesforce1 is a powerful platform that allows your organization to transform itself. But as Salesforce has grown, managing complexity in your Enterprise implementations has likely grown, as well. As a Salesforce Architect it is your responsibility to understand and orchestrate all the moving parts. This can be an overwhelming proposition when you consider some of the components that have been covered by this blog series:

And this just is scratching the surface…

So how do you begin to approach managing complexity in your Salesforce1 Enterprise implementations? Should all of your Salesforce resources be on the same team? Should Salesforce teams be distributed across Development, Architecture, and Operations? What is the best software development methodology to use? What tools are necessary? What are the roles and responsibilities that you need to consider when scaling Salesforce into your enterprise? And why should you – the Salesforce Architect, care about this?

Let’s start with the easiest question first: why should the Salesforce Architect be concerned with these issues? If you have looked into the qualification criteria for a salesforce.com Certified Technical Architect (CTA), you might be wondering why there are so many “non-Salesforce” aspects of the certification. Not only must you understand Salesforce inside and out; you must also understand things like Integration Architecture, Governance, Application Lifecycle Management, Change Management, Test Strategy, Release Strategy, etc. The reason behind this is that only someone who understands the Salesforce1 Platform AND these other components is truly qualified to lead a large Enterprise to their best approach for managing Salesforce.

So what goes into a good design for managing Salesforce1? Here are some of my recommendations:

Salesforce Architecture should fall under (and be a key driver) of your Organization’s Enterprise Architecture – This means following architectural guidance of any EA frameworks (e.g. TOGAF, Zachman, etc) that exist in your company.
Salesforce should adhere to IT Service Management best practices – I like to use the ITIL v3 framework here. You should consider your Salesforce Strategy, Salesforce Design, Salesforce Transition, Salesforce Operations, and Salesforce Continual Improvement as separate processes, and potentially different organizational constructs. Salesforce should fall under any organizational frameworks here, especially related to Change Management and Support.
Salesforce should remain as agile as possible – This is often a conflicting principle to the first two items in the list. But finding the right balance is critical to achieving agility AND predictability. There are numerous ways to do this: one is to create a clear policy of allowable production changes by administrators vs changes requiring a formal release window. Another would be to set up very clear technical boundary points between Salesforce and other enterprise systems through the use of staging tables or Apex Web Services.
Salesforce Support should follow a very structured Tiering philosophy – Primary support for Salesforce should come from Salesforce users themselves via a combination of self-service, knowledge documents, and delegated administration. Solely relying on your Salesforce administrators will lower your scalability potential.

So what does this “look like?” Here is a reference model that I use when trying to describe the organizational aspects of managing Salesforce. (Disclaimer: this is only a reference model and each company is different. What is important is to understand the Principles of the reference model, and then apply them to your own organization):

Let’s look at the layers and describe some of the important aspects:

Center of Excellence

The Center of Excellence (CoE) means something different to almost each company you talk to, and reconciling those differences is well outside the scope of this article. However I think some of the key aspects of the CoE are to provide Enterprise-Wide Salesforce strategy, standards, and governance. Therefore the CoE would determine what org a new project should be built in (or whether to have multi-org in the first place). They would also build and manage an Enterprise-Wide roadmap of business and technical capabilities for Salesforce. Therefore your CoE would need close alignment with your Enterprise Architecture team. Your CoE would also provide Enterprise-Wide configuration and development standards that all Salesforce orgs and teams should follow.

Lines of Business

It is quite possible (and sometimes desirable) to have multiple Lines of Business (LOB) coexisting in the same org. One of the key success factors for making this work is to build out a Delegated Administration function inside of each LOB. The goal is to provide immediate functional support to your business users without overloading your administration and technical teams. When a business user is empowered to build reports, create list views, reset passwords, even fix data, etc., it creates a great relationship between the business and Salesforce IT groups.

Your LOBs will be making a number of requests that cannot be fulfilled by their Delegated Administrators. Clearly defining theses processes (New Business Case, Logging an Incident, Salesforce Change Request, etc.) and how they pass into your technical teams is very important.

Help Desk

A mature organization will utilize the Help Desk if possible. Initial Salesforce implementations often bypass this step, but as your organization grows into Salesforce it is important to provide a single focal point of Service Requests to your users. It is also helpful to be part of this process when supporting complex solutions that might have many technology components such as middleware, CTI, SSO, etc. I recommend involving your Help Desk in your Salesforce Support processes as early as possible.

Salesforce.com Production Support

This is your core Administration or DevOps layer. Your admins and environment managers live here – supporting users, making (pre-authorized) configuration changes, deploying new releases, triaging and researching production incidents, etc. I recommend this group be the only users with true system admin privilege, and to use great discipline in all activities (such as logging all changes with cases, etc.). This group should be walled off from Development teams and users with only clearly defined entry points (service requests from users, deployment packages from developers, etc.).

Salesforce.com Technical Oversight

This layer is responsible for understanding the detailed design of your Salesforce environment. In a multi-org approach you might need one of these layers PER ORG. The reason is that this group is responsible for commissioning and approving any changes that happen to the org. I recommend at least three individuals in this layer: a technical architect who understands all of the code, integrations, and data conversion within the org, a functional architect (“app lead” or “solution architect”) who understands all of the business processes of the org inside and out, and a data architect who understands each object and field inside of the org.

This technical oversight team should be very hands-on and would be responsible for approving any releases to production. They should be completing design reviews throughout the development process. They should also be validating all changes conform to the Salesforce standards.

Salesforce.com Technical Teams

It is possible to have multiple technical teams working within the same org at the same time. You can have one team working on a specific LOB while another works a generic backlog for all others. Or perhaps you have one team working under a quarterly release cycle while you have another working on a weekly sprint. You can have a small internal development team but outsource large projects to a vendor. Whatever your use case, if you take the time and discipline to set up your teams and processes correctly, you can achieve this salesforce.com nirvana as well. Once you are mature enough with your management practices, you can centrally commission development efforts to discreet teams who can build and package your projects following your salesforce.com standards and deployment methodology. This is when you can really start to scale your usage of the Salesforce1 Platform in your enterprise.

Support

Another key success in managing complexity in your Enterprise Salesforce1 implementations is rigidly following a tiered support plan. Most support issues should be handled as close to the user as possible, with only the most severe and significant issues ever being escalated to your technical teams. Take the time to define your tiers and the escalation points. If you need an example here is one that might work in your company:

Tier 0 – Customer Self-Service Sites, Knowledge Documentation, Micro-Training Solution, Delegated Administration
Tier 1 – Your formal IT Help Desk where issues are logged, triaged, and escalated based upon formal Service Level Agreements. User access issues can even be deflected here with IVR and or SSO solutions.
Tier 2 – This is where your core administration team would really get involved. These should be true system issues or service requests that cannot be fulfilled by your delegated admins or help desk.
Tier 3 – Once issues are formally researched and escalated by the production support team, a technical team would get involved. This usually takes the shape of the original development team (if the project is still under warranty), a managed services team, a dedicated technical support team, or if all else fails, your salesforce.com Technical Oversight Team.

Understanding the Brick Wall

One of the most important aspects of the reference model is the brick wall. The brick wall is to signify the formality of migrating change into the production environment. The brick wall is your organization’s primary control point to ensure that only quality components migrate to production, and then only on a predictable cadence. I hope you read my article on Deployment Strategy – then you will understand the discipline necessary to migrate successfully and ensure your production environment (and all your sandboxes) are functioning as desired.

Summary

In many ways, managing Salesforce is no different than managing traditional technology platforms. It requires good strategy, architecture, development, deployment, and support processes. To me, the difference is that the usual traditional technology platforms CANNOT survive without those processes, while Salesforce projects can often survive without them due to its robust design. However it is impossible to scale the use of Salesforce in your company without taking the time and discipline to manage the platform as an Enterprise asset. With the right combination of organizational design, ITSM processes, and architectural governance, your salesforce.com implementations can truly help transform your Enterprise.