Salesforce Architecture framework, Martin Kona
Download as PPTX, PDF3 likes2,141 views
The document discusses the Salesforce architecture framework, emphasizing the importance of a structured approach to avoid technical debt and ensure effective implementation. It outlines the Architecture Development Methodology (ADM) as a continuous, iterative project lifecycle that involves defining architecture principles, identifying stakeholders, and gap analysis across various phases. Key takeaways highlight the need for governance and the establishment of review processes to align with architectural standards while adapting the framework to specific project conditions.
Salesforce Architecture framework, Martin Kona
- 1. Salesforce Architecture framework by Martin Kona
- 2. #CD19 ● 12x Salesforce certified App & System Architect ● 2x CPQ certified (Apttus & Bit2Win) ● TOGAF 9.2 Foundation and Certified levels ● Karaoke singer
- 3. #CD19 ● Salesforce is usually implemented without any vision, roadmap or governance ● 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
- 4. #CD19 ● The Open Group Architecture Framework ● It is complex and generic framework Enterprise architecture methodology that offers a high-level framework for enterprise software development ● 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 #ADM Have you heard about TOGAF?
- 5. #CD19 ● The result of continuous contributions from a large number of architecture practitioners ● It’s a project lifecycle ● Is iterative over the whole process, between phases and within phases What is ADM?
- 6. #CD19 ● 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 environments The Architecture Vision is essentially the architect's "elevator pitch“. A: Architecture vision phase
- 7. #CD19 ● 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 processes. Architecture Development Iteration
- 9. #CD19 ● View is developed from the architecture viewpoint, which addresses stakeholder’s concerns Views and Viewpoints
- 10. #CD19 ● Define the actors using Salesforce and ideal license choices ● Refine business scenarios into business requirements ● Which business processes will be implemented or influenced by Salesforce? ● What is the org strategy? B: Business Architecture phase
- 11. #CD19 ● 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
- 12. #CD19 ● 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
- 13. #CD19 ● Iterate within two phases E and F ● Outcome of the iteration is to gain buy-in to a portfolio of solution opportunities ● Another outcome is Migration plan from baseline to target Transition Planning iteration
- 14. #CD19 ● 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
- 15. #CD19 ● Identify project dependencies (mainly integration services) ● What is our deployment strategy? Change set or IDE+MetadataAPI or Copado/Gearset? ● What is our test strategy? Apex positive & negative tests policy, manual/automated (Provar, Selenium)? ● What is our DATA conversion plan? F: Migration planning phase
- 16. #CD19 ● 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 management process ● Subsequent iterations carry out the periodic reviews of changes to resolve issues and ensure compliance Architecture Governance iteration
- 17. #CD19 ● 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
- 18. #CD19 ● How to manage changes? ● What should be categorized as hotfix? ● How to handle hotfix? Exception deployment rules? H: Architecture Change Management phase
- 19. #CD19 ● Do your own research on IT frameworks ● Adapt them to your own project situation ● Governance on release process and deployments is always underestimated ● 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. Key takeaways
- 20. #CD19 Q&A
- 21. Thank you!
Editor's Notes
- #4: 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?
- #5: 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!
- #6: 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
- #7: - - guide us with decisions
- #10: elektrikar
- #11: 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?
- #12: 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
- #13: 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?
- #15: - - Do we need to invest more in governance, code reviews etc? Chaotic, every 2 weeks, as salesforce?
- #18: 80/20, ako sa to riesilo, review board, odkazovat sa na arch. principle
- #19: Who approves the changes? How to plan them? So they wont skip the planning with “hotfix”
- #20: Its usually a bottleneck on the projects