Architecture Principles

 

Architecture Principles

I get a lot of questions from our customers about ‘architecture principles’:

  • what are Salesforce IT’s architecture principles?
  • what common architecture principles should be considered?
  • how do I determine my company’s architecture principles?
  • how do you enforce them?
  • how do you measure on-going alignment to them?

Without architecture principles, the old adage by Lewis Carroll applies…

“If you don’t know where you are going, any road will get you there.”

The Architecture Principles that we have set for Salesforce IT are as follows:

Wait! Aren’t architecture principles a big secret? Aren’t they a competitive advantage? The principles themselves are NOT a competitive advantage and should not be a big secret - adhering to the architecture principles IS a competitive advantage.

Leveraging your principles to do the right things IN THE RIGHT WAY is the super power that all companies should strive for.

When I was leading Salesforce’s customer-facing Enterprise Architecture team, we met with customers who wanted to determine their architecture principles. With those customers, we ran a two-day workshop which was structured as follows:

DAY ONE

  • Leverage a list of 10–15 common architecture principles (unless the customer already has their principles ratified and documented)
  • Pull a group of architects and sr developers together
  • Break the groups into sub-groups of about 5–8 people (eg 5 sub-groups)
  • Have each sub-group define and stack rank the list of architecture principles
  • Pull all sub-groups together to compare the definitions and prioritized lists — find consensus of the prioritized architecture principles and definitions — discard any principles that have very low priority (ie — not relevant or appropriate for your specific situation) And best practice is to select no more than 10 — and yes I realize that at Salesforce we have 12! More is better in that it provides FOCUS.
  • Break back into the sub-groups and document estimated current state and desired future state for each principle using a 1–5 rating (1 being low and 5 being high) Remember that not all principles will have a future state of 5 (ie — not every principle needs to be perfect)
  • Pull all the sub-groups together to compare the current/future desired state across the principles — reconcile differences and ratify a current/future view.

(SEE BELOW — THIS IS AN EXAMPLE)

Optimally you will have finished this exercise in one full day. In closing the day, ratify/document/publish the outcome. You want to share the decisions made, because your governance moving forward will be anchored to these principles.

DAY TWO — Here is the extra fun part

  • Bring everyone together and share a list of your top 5 projects
  • Break up into the same sub-groups and spend a few hours on rating/ranking each of the top programs on their specific alignment to the principles — “Project 1 — how does it align to principle 1, 2, 3, etc”
  • Don’t go crazy on perfect accuracy. You want a general Red/Yellow/Green or High/Med/Low. This will take time and discussion to agree in the sub-groups. Remember that this interaction is healthy and is a good team-building exercise.
  • Once all the sub-groups have ranked the top 5 projects across each principle, bring all the groups together.
  • Compare the sub-group findings, find consensus and ratify the results.
  • Yes, you will find that a few/some/many of your projects are contradicting your principles. That’s normal, especially if you have never ratified your principles OR governed your architecture using your principles.
  • Possible epiphany? “Holy moly! We need to rethink our top projects and align our architecture to our principles.” Again, you are not alone if this happens. Many companies come to this realization — don’t beat yourself up. The positive is that, moving forward, you can ensure that your architecture aligns to your principles for all projects.

In Salesforce IT, we leverage our Enterprise Architecture Review Board (EARB) and our Architecture Community of Practice (ACoP) to ensure alignment to our principles as well as create an on-going dialogue about our specific principles.

Value of Architecture Principles

Why are architecture principles important? Some of the value propositions are below:

Faster time-to-value

Increased agility & responsiveness; Adaptibility

More informed investment decisions; Reduce risk

Manage & reduce technical debt; Reduce IT TCO

Help to manage complexity

Maximize reuse

Reduce redundancies; more shared capabilities

Avoid rework

Increase awareness of risks; Tech & regulatory

Improve end-to-end security

My next blog related to this topic will cover the detailed governance process of architecture principles. Specifically, how to create an operating model in IT that ensures alignment to your architecture principles. Stay tuned…

Comments

Post a Comment

Popular posts from this blog

Enterprise Architecture Inside Salesforce

Image
  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 Sales...
Read more

Illuminate - Business Model Exploration

Image
  Illuminate — Business Model Exploration One of our world-class Salesforce Enterprise Architects, Jonathan Laudicina ( https://www.linkedin.com/in/jonathan-laudicina/  ) has done amazing work on Business Model Exploration. I want to highlight some of his work and I think you’ll find it useful. As a reminder, Illuminate is the Enterprise Architecture Methodology that we use inside Salesforce as well as with our customers. The overall Illuminate methodology is depicted below. You will notice that Business Model Exploration is the first step in Illuminate. Business Model Exploration is the methodology we use with customers to articulate: External Forces pushing on the business Internal Forces pushing on the business Customer specific Business Model Canvas At the heart of Business Model Exploration is the Business Model Canvas. It is the place in which you capture key factors about a company’s specific value proposition, partners, customer segments, cost structure and revenue str...
Read more

5 Key Components of a Successful Enterprise Architecture Function

  5 Key Components of a Successful Enterprise Architecture Function 5 Key Components of a Successful Enterprise Architecture Function Creating and managing a successful Enterprise Architecture function requires a variety of different hard and soft skills. In addition, each company is different and the Enterprise Architecture function needs to calibrate and align itself to the specific company. However, there are five common features of a successful Enterprise Architecture function that are applicable to all companies. 1. Governance Enterprise Architecture (EA) requires governance, however not in the form of complex documents, forms or processes.  Definitely avoid EA being seen as the policy-enforcement team — people will avoid EA if the perception is that EA is a blocker.  The best governance starts with a simple, recurring dialogue across multiple functions facilitated by EA. I am always amazed at how valuable it is just to get cross-functional teams to  talk . Pick...
Read more