Relatively new space for tech
Lots of legacy players
Geographically dispersed user base
Heavy focus on cropping
A lot in common with startups
Wide variety of business models
(Growing, breeding, ﬁnishing, agistment, intensive or station)
Heavily indebted with a range of stakeholders providing guidance
Risk management priority (multiple animal herds, cropping)
Lot of small operators, often acquired by large multinationals
Lot of entrenched service providers
(chemical companies, intermediaries)
Users vary from agricultural scientists to semi-literate labourers
Processes can be heavily detailed with bad failure states
App used in bright sunlight, dusty conditions
Really, really poor internet
Workﬂow heavily paper dependent
What is the level of the representation?
These are straightforward
While there’s a lot of calculation involved, the calculations are linear.
If we have the formula, we can implement them with time.
What is the core
For a bank account, the core objects are the accounts and the
transactions, which are owned and acted on by the user and the
For a crop focused
There’s paddocks, which contain crops, which are acted on by users.
Paddocks have a geographical location, a bounding box, a physical
area, crops and vegetation.
They may have a treatment history, a performance history, a
Tasks can be assigned against them.
They may move (or be split / expanded) but this happens rarely. The
area of land can still retain the history.
Single view of sheep
This would be the easiest for us.
Single view of sheep
Object is sheep, which is acted on by user.
Sheep can be added to group (ﬂock), can have treatment history,
birth history, age, weight, condition, task assignment.
Can have death or sale record.
Can have lineage and performance record.
This is the model that
Per-animal focus to draw out lineage and make selective breeding
Enabled with speciﬁc software and per-animal record keeping.
RFID chips and specialist hardware.
We can’t do this.
Many farmers don’t operate on a per-animal basis.
Animals are treated as mobs (herds / ﬂocks) that are separated at
diﬀerent times based on diﬀerent criteria.
Some are split by pregnancy status (twins / singles), some by age,
breed, some simply spread across paddocks.
They are split and added at diﬀerent stages of life.
Some farmers simply
don’t know exactly how
many animals they have.
Single view of mob
We can treat the mob as the object.
A user can act on a mob.
A mob can have a treatment history, a location, a feeding history, it
may have tasks assigned.
It may have aggregate measures of weight, condition, sale price.
What happens when a mob is split or combined?
Some calculations are
We can recalculate aggregate measures like weight and condition.
Some are not
How do we know which animals have been treated?
Which ones have a history of producing twins?
Of producing healthy oﬀspring?
Which ones got sick?
No easy solution
Combining records leads to false accuracy.
We need to maintain mob history back through splits and joins.
This can lead to a complex interlinking of mob records.
Bulls and rams
Bulls and rams are treated as individuals.
Well, kind of.
They’re animals, but they’re also farm equipment.
And they kind of act like a mob treatment.
Single view of ram
We can see the speciﬁc history of a ram or bull.
Healthy history, treatment, paddock movements.
We can generate a proﬁt measure against a speciﬁc ram or bull by
calculating condition and sale weight of oﬀspring.
Understand how your users conceptualise objects
Map actions by users and other objects
Understand that group objects are not always groups of objects
Understand aggregate vs actual values
Avoid false accuracy
Risk-manage when data is ambiguous