Building an Enterprise Architecture with Salesforce.com

An oldie but goodie… part of my original series of Enterprise Architecture on Salesforce.com and published on August 22, 2014

I’m a huge fan of the SFDC platform. It has the potential to transform businesses if implemented and managed correctly. Unfortunately I’ve seen many companies come up short when trying to reap value from Salesforce. There are countless reasons for this but here are some of the top reasons I’ve seen:

Strategy

1. No organizational vision or direction for the company’s use of Salesforce
2. No roadmap and product management strategy that ties the platform’s use to corporate goals.
3. No formal architecture, governance or change management strategy leading to an evolutionary design of either silo’d functionality or a mis-use of multiple Salesforce instances.

Environment

1. The original implementation was delivered with little-to-no technical understanding by the customer.
2. A lack of understanding between how and when to use configuration vs custom code.
3. The implementation consultants delivered “functional value” only and therefore lack any standards in the configuration design and coding layers.
4. There are no patterns, no modularization, and no chance to extend the functionality without significant refactoring.
5. Test coverage is completed only as an after thought and lacks any kind of design or assertions. There is a high risk you will break something when you change configuration or code.
6. Lack of any forms of living documentation that capture your design and the reasons for that design.

Adoption

1. Unwillingness or inability to retire legacy systems has kept people from using the system.
2. Lack of training or communication to end users
3. Data Quality in the new system is low and the outputs of the system are not trusted

So how do you prevent these types of issues? How do you fix them if you are already a victim of this problem? My recommendation to you is this: Build an Enterprise Architecture with Salesforce.com

How do you do this? It is not easy and it will take time, money, and platform knowledge. But if done correctly Salesforce can become a differentiator for your business.

This post and the ones that will follow it will walk you through the process of establishing an EA for Salesforce. The main framework I am using is the TOGAF Architecture Development Methodology. If you are not familiar with TOGAF, I recommend reading up a little on the framework. TOGAF is an approach for designing, planning, implementing, and governing an enterprise information technology environment and is an open standard of The Open Group Architecture.

The TOGAF v9.1 Architecture Development Methodology from The Open Group

Throughout the post I will follow the phasing of TOGAF and point out some relevant questions and considerations as you shape your Salesforce Architecture. That being said here is roughly the process you will follow as you build your plan:

Define Your Architectural Vision for Salesforce

1. Who are your stakeholders and your business goals?
2. What are the corporate goals that will influence your vision?
3. What are your architectural principals?
4. Where is your architectural repository and how will you manage your artifacts?

Design Your Business Architecture and Strategy

1. What Lines of Business will use Salesforce?
2. What are your business requirements?
3. What business processes will be implemented on or influenced by SFDC?
4. What building blocks of your business will be built on SFDC?
5. What is your org strategy?
6. Who are your actors and possible license choices?

Design Your Information System Architecture

1. How do you design an Application Architecture on SFDC?
2. How do you design a Data Architecture for SFDC?
3. What is your application rationalization plan? What will be added or retired with SFDC (and when)?
4. What is your Gap/Fit and what will you do about it?

Design Your Technology Architecture

1. What is your integration architecture?
2. What is the right architecture for custom development?
3. How will you manage your technical environments?
4. What are your technical risks and how will you mitigate them?

Design Your Implementation plan

1. What is the right methodology to use?
2. What is your SFDC Architectural maturity?
3. What is the appropriate release strategy?
4. How do you build a roadmap?

Plan your migrations

1. What is your Cost/Benefit analysis for each release?
2. What are you project dependencies?
3. What is the right deployment strategy?
4. What is your test strategy?
5. What is your data conversion plan?

Design your governance plan

1. What groups will you need to integrate your efforts?
2. How do you establish an effective CoE?
3. What is an Architecture Review Board?
4. How do you setup a system administration model?
5. How do you manage your vendors?
6. How will you ensure adherence to your architectural design and standards?

Define your Change Management Plan

1. How do you effectively manage change?
2. What types of changes can be made in production and by who?
3. What types of changes should be made in a project vs bug fix?

My recommendation would be to walk through the list in order and try to answer all of the questions at least once — to the best of your ability at the time. Then return to back to the first section (architectural vision) and start to refine into a deeper level of detail. TOGAF is cyclical and so too is your design and implementation of an EA for SFDC. It follows the concept of continual improvement that will evolve each time you iterate through the cycle. So get busy and build out your EA for SFDC. Your users, your technology teams, and your business stakeholders will thank you for it.