Session describes how to apply enterprise architecture framework (TOGAF) on Salesforce projects in order to achieve successful implementation and governance. Session will focus on Salesforce specific concerns contained by architecture phases like data model design, product road map, environment strategy, deployment strategy and many more.
Biggest issue with salesforce projects is that customer wants to just copy way of thinking from old system to Salesforce. Decision audit. Why it was implement in this way?
Bullet – project situations can be wild Haven’t worked yet for customer with TOGAF established on enterprise level. Be the example, which others can follow!
Long story short – it’s a list of phases and in every phase we focus on few Salesforce related project concerns, document them and solve them
- - guide us with decisions
Mention ukrajinu, inhouse developers instead more expensive license to solve missing standard objects -> issues with managed packages John uses huge plate for dinner->Pick plate size accordingly to Johns dinner We should not just throw all processes to salesforce from old system. Are there any legal constraints to use more than one org? In different continent?
Don’t copy data model, optimize Roles, territories, apex or external system?! Grouping of tabs and their visibility for actors Which apps will be the first one in Salesforce? How we decommission old systems? Managed package != OOTB, we need to pay support
Mature company usually has API portal already, with small companies you need to document it by yourself
Technical risk = External system does not support bulk api? => Increase of traffic will cause issues. Do we pay for bigger limit or modify external system?
- - Do we need to invest more in governance, code reviews etc? Chaotic, every 2 weeks, as salesforce?
80/20, ako sa to riesilo, review board, odkazovat sa na arch. principle
Who approves the changes? How to plan them? So they wont skip the planning with “hotfix”
Its usually a bottleneck on the projects
Salesforce Architecture framework, Martin Kona
Salesforce Architecture framework
by Martin Kona
● 12x Salesforce certified App &
● 2x CPQ certified (Apttus &
● TOGAF 9.2 Foundation and
● Karaoke singer
● Salesforce is usually implemented without any vision, roadmap or
● Customer is left with vague documentation/decision audit
● Green field projects are being delivered in lightning speed, but the
technical debt is raising exponentially. It’s impossible to make simple
changes in the future
Why I think this is important
● The Open Group Architecture Framework
● It is complex and generic framework Enterprise architecture
methodology that offers a high-level framework for enterprise software
● It is not a silver bullet
● It is open, google it!
● I can’t even introduce it in 50 minutes! And I’m not trained to do so
● In our case, we will focus on Architecture Development Methodology
Have you heard about TOGAF?
● The result of continuous
contributions from a large
number of architecture
● It’s a project lifecycle
● Is iterative over the
between phases and
What is ADM?
● Identify business scenarios
● Identify stakeholders and business goals
● Define architectural principles Example: 80/20 rule, control technical
diversity, data is an asset
● Establish architectural repository
● Generate first-cut high level description of baseline and target
The Architecture Vision is essentially the architect's "elevator pitch“.
A: Architecture vision phase
● Iterate within three phases B, C and D
● Every phase should define following:
1. Describe Baseline Architecture
2. Develop Target Architecture
3. Analyze the gaps
4. Select relevant architecture viewpoints
● Repeating the cycle makes perfectly sense with Salesforce project,
since OOTB or managed packages might drive or change the business
Architecture Development Iteration
● View is developed
Views and Viewpoints
● Define the actors using Salesforce and ideal license choices
● Refine business scenarios into business requirements
● Which business processes will be implemented or influenced by
● What is the org strategy?
B: Business Architecture phase
● What is our data architecture?
● What is our sharing architecture?
● What Lightning Apps are we implementing?
● What is our application roadmap? Are we planning to purchase
managed package or implement it by ourselves?
C: Information Systems Architectures phase
● Design integration architecture (who is master of what, data flow, API)
● Define coding standards and architecture/patterns for custom
development governed by code reviews
● Design environments strategy
● Identify technical risks and how to mitigate them
D: Technology Architecture phase
● Iterate within two phases E and F
● Outcome of the iteration is to gain buy-in to a portfolio of solution
● Another outcome is Migration plan from baseline to target
Transition Planning iteration
● Agile or Waterfall? => Wagile
● Schedule and estimate implementation roadmap
● Identify resource risks (do they know Salesforce? )
● What is our release strategy?
E: Opportunities and Solutions phase
● Identify project dependencies (mainly integration services)
● What is our deployment strategy? Change set or IDE+MetadataAPI or
● What is our test strategy? Apex positive & negative tests policy,
manual/automated (Provar, Selenium)?
● What is our DATA conversion plan?
F: Migration planning phase
● Governance is defined as the processes that ensure the
effective and efficient use of IT in enabling
an organization to achieve its goals.
● Iterate within two phases G and H
● Initial iteration’s goal is to mobilize governance and change
● Subsequent iterations carry out the periodic reviews of changes to
resolve issues and ensure compliance
Architecture Governance iteration
● Which teams are involved on the project and their impact?
● Establish effective Center of Excellence
● Establish Architecture Review Board to adhere to our architectural
design and standards
● Define process to make decisions if something should be
configuration or custom development
● What is our system administration model?
G: Implementation Governance phase
● How to manage changes?
● What should be categorized as hotfix?
● How to handle hotfix? Exception deployment rules?
H: Architecture Change Management phase
● Do your own research on IT frameworks
● Adapt them to your own project situation
● Governance on release process and deployments is always
● Even if no one from project is interested in architecture framework, use
the phases as a personal checklist, document it and make it
transparent. Others might follow.