Skip to main content Back CRM Cloud Mastery Sign up Create account

Application Architect: Designing for Change

The composite Application Architect view: the data model as a change budget, and designing for the next change.

  • Advanced
  • 30 lessons
  • 8 modules
  • English

Designed and created by Salesforce Expert

What you'll learn

  • Read an existing application and say what its design is costing
  • Treat the data model as a budget for future change
  • See the visibility consequences a data model has already decided
  • Place the declarative/programmatic line deliberately
  • Hold and defend the application architect role on a real programme

Course content

8 sections · 30 lectures

What an application architect is for 3 lectures
  1. 1.1 The design that was right in March and unaffordable in November
  2. 1.2 A credential with no exam: what the composite certifies and the four it is made of
  3. 1.3 The four seams: where App Builder, data, code and sharing make each other impossible
The application in front of you 3 lectures
  1. 2.1 Halverstock, 62 studies, and the amendment the org cannot express
  2. 2.2 Requirements that are really constraints, and the difference it makes to write them down separately
  3. 2.3 The half-life of a requirement — designing against what you already know will move
The data model as a change budget 5 lectures
  1. 3.1 Master-detail is a sharing decision and a deletion decision before it is a data decision
  2. 3.2 Modelling the thing that has versions, when both versions must stay true
  3. 3.3 Field, record, or metadata — three places to put a difference, and what each one costs to change
  4. 3.4 The junction object that becomes the bottleneck, and the denormalisation you can defend
  5. 3.5 What you can change later, what you can never change, and the migration in between
Visibility your data model already decided 3 lectures
  1. 4.1 The sharing requirement the model answered for you before anybody asked it
  2. 4.2 Subtracting access: when the requirement is 'nobody may see this', and the redesign it forces
  3. 4.3 External users change the model, not the settings
Declarative, programmatic, and the line that keeps moving 5 lectures
  1. 5.1 'Clicks not code' is not a principle, it is a cost model — and it has four terms
  2. 5.2 The four questions that actually decide it, in the order that makes the decision cheap
  3. 5.3 Configuration-driven design, and the rules engine you should usually not build
  4. 5.4 Order of execution is an architecture constraint, not a developer detail
  5. 5.5 When the platform ships the thing you built — designing so that being superseded is cheap
Designing for the next change 4 lectures
  1. 6.1 Extension points: putting a seam in before anybody asks for one, and the three that are never worth it
  2. 6.2 Boundaries — one application or two, and what actually decides it
  3. 6.3 Many tenants inside one org: sponsors, brands and business units, and the four ways to hold them apart
  4. 6.4 Naming, deprecation, and the debt you take on purpose
Halverstock, end to end 4 lectures
  1. 7.1 The design as it stands, and the case for it — argued properly before it is touched
  2. 7.2 The four decisions, taken, with every trade-off said out loud
  3. 7.3 The amendment arrives six months later — running the new design against the change it was built for
  4. 7.4 The other design that would also have worked, and the one that would not
Being the application architect 3 lectures
  1. 8.1 The composite, honestly costed — the four credentials, the order, and the case for stopping at three
  2. 8.2 Governance without becoming the department of no
  3. 8.3 Handing the design over, and where ARCH-401 picks it up

Requirements

  • ARCH-301 Data Architecture and ARCH-310 Sharing & Visibility
  • BLD-101 App Builder and BLD-110 Apex Foundations

Description

Application Architect is a composite credential, and this course teaches the judgement that composite is meant to certify. What an application architect is for, the application actually in front of you, the data model as a change budget, the visibility your data model already decided, the moving line between declarative and programmatic, and designing for the change that has not been asked for yet.

Halverstock is then taken end to end, and the course closes on what being the application architect actually involves.

Who this course is for

  • Architects consolidating the composite credential, and senior builders moving into architecture.

Skills you'll practise

Application architectureSolution designData modellingDeclarative vs programmaticDesign trade-offs

Related reading