Platforms, integrations and systems of record
In operations software, a feature is often a small screen on top of a lot of data that comes from, or goes to, other systems: the ERP, the POS, the warehouse system, the data warehouse. This lesson shows you how a PM maps systems of record, assigns owners to master data, specifies an integration, plans a migration and cutover, and treats other teams as users when the product is a platform.
By the end you can
- Draw a system map for a feature showing where each piece of data is mastered, copied and how fresh each copy is
- Write a data ownership table for master data such as sites, articles, suppliers and prices
- Specify an integration: trigger, pattern, fields and IDs, failures and reconciliation
- Choose a migration approach and write a cutover plan with a go/no-go point and a rollback
- Explain what a platform team owns and how to measure a platform by the teams that use it
The everyday picture
Think of a family address book. Grandmother keeps the paper one by the phone, and everyone else has copies in their own phones. When an aunt moves house, the family has rules, whether or not anyone wrote them down: the aunt tells grandmother, grandmother updates the book, and she tells everyone else. If a cousin writes the new address only in her own phone, the next family wedding sends an invitation to the old house.
Every company has the same problem at a much larger scale. One system holds the real record of each thing, many systems keep copies, and the copies drift unless someone owns the record and the way changes spread. Most "the app shows the wrong thing" problems in operations come from this.
Systems of record and systems of engagement
A system of record holds the official version of a piece of data. When two systems disagree, the system of record is right by definition, and changes are made there first. Geoffrey Moore's 2011 white paper for AIIM, Systems of Engagement and the Future of Enterprise IT, contrasted these core systems, on which companies built their business processes, with newer systems of engagement that sit on top of them: the apps where people actually do their work and talk to each other.
At Mangrove, the ERP is the system of record for articles, suppliers, purchase orders, prices and the stock ledger. The POS is the system of record for each sale until it is sent to head office. The Store app is mostly a system of engagement: staff do the receiving there, but the official goods received note (GRN) lives in the ERP once it is posted. The Store app is the record only for what happens before posting, such as who scanned which carton and the photo of a damaged one.
For every piece of data a feature touches, ask five questions:
- Where is it created?
- Where is the master copy, and who may change it?
- Which systems keep copies?
- How fresh must each copy be: seconds, minutes, overnight?
- When copies disagree, how will anyone notice?
Put the answers on one page as a system map. It is the first thing to draw for any feature that touches stock, money or prices, and it usually reveals the real work.