StripeCon 2020 - When is a CMS not a CMS?

Silverstripe CMS is a great tool for much more than just content management. This talk provides a case-study in using Silverstripe CMS' "ModelAdmin" feature to build business applications (in this case a risk management application) and shares some lessons in what it means for CMS' value proposition and future.

Transcript

2. When is a CMS not a CMS? Sam Minnée – StripeCon 2020
7. When it’s Silverstripe CMS! When is a CMS not a CMS? Sam Minnée – StripeCon 2020
8. My Talk Today • ModelAdmin case study: Risk Management app • Why is ModelAdmin a good choice • What is teaches us about Silverstripe CMS’ value • A little bit about what’s next for Silverstripe CMS
9. Why on earth did you build a risk management app?
11. • Flexibility • Moderately-sized organisations struggle with off-the-shelf tools, and heavy customisation / implementation is typical • Hypothesis: ModelAdmin gives you a custom app for an investment similar to purchasing and implementing one an ‘enterprise SaaS’ option Why build our own tools?
12. Plus it means I get to write code
13. What are the alternatives?
14. • Cheap • Easy • Not very flexible • Relationships between data, especially many-many, are weak Spreadsheet
15. Enterprise SaaS Salesforce, FreshService, etc • Flexible • Very expensive (US $100+ / user / month not unheard of) • Flexibility reduced because you can’t give everyone accounts • Implementation much more like a software project
16. • Really interesting tool • Like a spreadsheet but without the drawbacks • Much better at relationships than a spreadsheet • Still more likely to hit limits than a ModelAdmin AirTable et al
17. • Another really interesting tool for different reasons • Flexible because it doesn’t try to solve all problems • More part of a solution the whole thing – you need to build your own backend • Worth a look-in React Admin
18. • Provides both the data model and the admin • Flexible data modelling – all common relationship types and the ability to customise them with a little PHP • A variety of UI approaches, thanks to GridField plugins • Snapshotted versioning a great companion for apps requiring audit trails • Open source How does ModelAdmin stack up?
19. • It’s not primarily about being free • Building and hosting an app costs money! • But it stops you from tripping over licensing restrictions • You don’t inadvertently have your license costs explode Why is open-source of benefit here?
20. How did it go?
21. • So many tools to mix and match • Not just GridField – TagField, Display Logic part of this benefit • You can experiment with changes to the UX while relying on an out-of-the-box UI. Good things: GridField and other fields
25. • Basic relations supported easily • Customised relations require only a small piece of code Good things: ORM
26. Likelihood Impact Severity Score Risk RiskReduction Control Likelihood Impact BaseRating TreatedRating NewLikelihood NewImpact RiskRating
27. Denormalisation: a bad idea that worked • In practise, de-normalisation was the easiest way to make things work • E.g. GridField sorting / filtering on de-normalised data • Some denormalized data was updated via onBefore/AfterWrite triggers • Some was updated as an hourly cron job
29. What are the gaps?
30. • Collaboration • Access control • Reporting • Administrator customisation Gaps
31. • Internal comments • Assignment of objects / tasks • Notifications of comments, assignments, etc • “Workflow” covers this, but existing modules are difficult to drop in Collaboration
32. • Easy way to provide comments in a CMS • Very MVP right now. Needs • Better comment UX • Notifications (email, slack) • Tie-together of record change-tracking (especially Status) and comments sminnee/silverstripe-modelcomments
34. • Users and Groups work well • Drop-in MFA was great • But CMS’ permission system is limited and not up to the task Access control
35. • Even more MVP than before • But demonstrates that Permission codes can be used for a better experience • Key techniques • Embed object IDs into the permission code • Let individual objects be marked as “standard permissions” or “custom permissions” sminnee/silverstripe-microacl
36. • Editable statuses that an object can move between • Rights to make each change • Comments expected with any change • Preconfigured notifications at any change • Specific validation rules per status • Dev-managed automated status changes Workflow for business apps? New Assessed Treated Closed Needs review
37. • silverstripe/reports allows predefined reports • But no customised reports • Saved searches on ModelAdmin views would also be very helpful • This area needs work • (No MVP module this time) Gaps: reporting
38. • E.g. let administrators add more custom fields • Kind of breaks Silverstripe’s model • Comes up frequently in government RFPs • Could it be introduced in a limited way? Gaps: administrator customisation
39. • I misunderstood the scope of the app when I started • As I added more data to the system, the scope of the app and the best way to manage the data changed • As a single person acting as product owner / developer / user, this worked quite well • But this is a special case Surprises
40. The lesson?
41. BUILD MORE MODELADMINS!
42. • It's not what you demo out of the box with CMS • It's what you show off after just a few hours development • ModelAdmins let you solve more complicated business challenges • "Can't I just have Wordpress?" less likely to be the answer What’s exciting about Silverstripe CMS?
43. Our future • Content Management Systems these days is a product-category where website owners feel they should make the product selection • Silverstripe CMS has always been at core a rapid-development tool • In 2005 content management was an innovating, exciting idea • In 2020 it's a commodity, there are better niches to pursue
44. One of the great things about StripeCon is the variety of ways in which people are using Silverstripe CMS. • Trying to make it "one thing" • The future of Silverstripe CMS is about letting 100s of ideas flourish Our future
45. So what about CMS 5?
46. The problems of big-bang releases • Upgrading from 3 to 4 is a lot of work • I’m not keen to force that on people again • CMS 4 will be support for a while yet • At least 3 more years • But we have no specific EOL date in mind yet
47. So what about CMS 5?
48. So what about CMS 5? How do we keep innovating?
49. CMS 5 is not about CMS 5
50. Innovation abhors a monolith
51. Innovation on a monolith • You can’t improve everything to the extent you would like • Not everyone benefits from changes you make • The scope of upgrade is huge • Any API changes you make need to be set in concrete before you can release them.
53. Totally new ways of building admin interfaces Totally new ways of delivering websites ORM All the CMS4 stuff that works for you nicely Form Schemas CMS4
54. What’s likely to come next • Keep CMS 4 usable for the coming years • Allow use of PHP 8, Symfony 4+, PHPUnit 8, etc • Try and split up framework up further without breaking APIs • Allow experiments modules / refactorings to be used one at a time on projects that are primarily CMS 4 installations. • Use GraphQL as an enabler for this where it makes sense. • Don’t worry about a feature-complete CMS 5 contender for now.
56. Thank you!