Enterprise Architecture Inside Salesforce

Enterprise Architecture — How We Do It Internally

The two words, “Enterprise Architecture”, elicit various reactions — everything from “we tried that and it doesn’t work” to “we need that!” to “we have an effective EA practice”. Unfortunately it is possible (even easy) to do Enterprise Architecture incorrectly, with an approach that is lethargic, technology-first and theoretical — the classic ivory tower.

(In Salesforce, the internal IT group reporting into our CIO is called “Business Technology” so you’ll see me use BT to refer to Salesforce IT)

I lead the Salesforce Enterprise Architecture team within Business Technology and I’m often asked the following questions:

• how does Salesforce do Enterprise Architecture?
• why do you need Enterprise Architecture?
• how do you shift the conversation to business capabilities?

Illuminate — The “How” of Salesforce Enterprise Architecture

Let me start with the “HOW” first. Within Salesforce BT, we use an Enterprise Architecture methodology we call Illuminate. This is a seven step methodology that I created and evolved over many years at many companies.

There are three key principles associated with the Illuminate methodology:

• Business-value led based on business capabilities
• Pragmatic and Light-Weight — an achievable, agile approach
• Minimum Viable Product / Iterative

A few key things about Illuminate:

1. The first three steps are focused on the business in terms of goals/objectives and then business capabilities. We purposely do NOT recommend starting with technology because the most important thing is the business goal(s).
2. Current State (step 4) is tricky — don’t get stuck in an infinite discussion loop about the problems of the current state. Apply a good-enough approach to documenting current state. Internally we use a tool called LeanIX to document our current state but there are many tools that provide this function.
3. Future State (step 5) should be fun! It’s what I call the “north star”. It’s ok if there are transition states between your current state and the future state — realistically it’s not one single step to the future state.
4. Roadmap (step 6) is what I consider the toughest step because it’s all about chunking up the evolution to the future state, optimally into quarterly deliverables. The best Enterprise Architects are great at articulating a pragmatic roadmap and it should be appreciated how critical this is.
5. Business Value (step 7) — although this shows up as the last step in the methodology (when it is finalized and ratified), it is actually started at the beginning of step 1. In a nutshell it demonstrates QUANTIFIABLY how you will meet the business goals and objectives through the roadmap of deliverables — specifically it shows “at each milestone, here are the quantifiable business metrics we will affect’”.

Why do we need Enterprise Architecture?

Having an Enterprise Architecture team is critical for three key reasons:

1. Data is a Shared Asset — Every business function needs data and often needs the same data, such as customer, employee, product, etc. Our argument would be that, if each business function in your company is trying to solve the data challenges separately, your data will be silo’d, inaccurate and untrustworthy. Improving data requires everyone to work together, agree on data owners, data stewards, data definitions, etc. Enterprise Architecture should be actively engaged in the data coordination effort.
2. Business Transformation — We would argue that true transformation should be anchored on “experience” — employee, customer and partner experience. To create an amazing end-to-end experience, all your business functions must work together and be aligned. No one business function can create an amazing end-to-end customer experience, for example. Enterprise Architecture should be actively engaged in the business transformation effort.
3. Heterogeneous Environments — All IT groups are dealing with numerous technologies, numerous architectures and many companies are actively acquiring other companies — our environments are heterogeneous. Enterprise Architecture is the group that is looking at the big picture, consolidating/simplifying systems, building common, reusable services.

How do you shift the conversation to business capabilities?

The most important philosophical approach of Illuminate is talking primarily about business capabilities and not technology. A great Enterprise Architect has deep business acumen AND technical acumen. They are able to converse in business terms and continually bring the conversation back to business capabilities.

The best way to understand business capabilities is to look at our business capability maps.

We have received so much interest from customers about how we use a business capability view, that we’ve made all of our business capability maps available to the public.

You can find them here, https://prezi.com/view/vsni9VjRvbKhVT6Qb6hK/

Each business capability has a definition, function, key performance indicators and best practices.

Illuminate allows us to change the conversation in powerful ways. For those of you who have already shifted to business capabilities, you will know that it creates a much more strategic conversation between business functions and IT.

Hopefully this gives you insight into how we do Enterprise Architecture at Salesforce, why Enterprise Architecture is critical in any company and why we use business capabilities as a way to create a more strategic dialogue between the business teams and IT.

I can always be reached on Twitter @brett_colbert

Feel free to DM me if you have questions or feedback.