Local Food Northland - Software

local-food-northland.md

Local Food Northland - Software

continuing from the Local Food Northland Software Project document

Principles

Similar to what physical tools you have available on your work site, computer systems are tools we rely on to facilitate the work we do. This project requires us to build new computer systems, yet we want these systems to be re-usable for ourselves in other projects as well as others. To achieve this, for this project we are not building one tool, we are building an ecosystem of tools (re-usable micro-services) that each focus on a single concern of the overall problem space. To limit our scope, we will only commit to building the features of these tools that we need for this project.

Business Milestones

ASK: Clive, can you help shine more light on our business milestones?

...

In 6 months we want the app in use by:

• 10 producers (growers)
• 20 consumers (cafes, restaurants, ...)
• 1 broker

In 9 months we want the app in use by:

• 1 transporter
• 1 warehouser

In 1 year we want the app in use by:

• the public to see local activity

Later we may want to include

• 1 processor

Development Milestones

Each stage is roughly 6 weeks?

stage 1: setup and authentication

Authentication:

• As a user, I can login
• As a user, I can signup
• As a user, I can verify my email
• As a user, I can reset my password
• As a user, I can delete my account

stage 2: profiles and relationships

Profiles:

• As a user, I can view the profile of an agent
• As a user, I can update my profile
• As a user, I can search (by name, location, ...) for agents

Relationships:

• As a user, I can view the relationships of an agent
• As a user, I can invite another agent into a relationship with me
• As a user, I can accept an invitation into a relationship with another agent
• As a user, I can leave a relationship with another agent

stage 3: { resource, interaction } types

{ Resource, Transform, Transfer } Types:

• As a user, I can create a type
• As a user, I can update a type
• As a user, I can search (by resource, ...) for types
• As a user, I can view details of a type
• As a user, I can remove a type

stage 4: intent casting

Intentions:

• As a producer, I can cast an intention to produce (offer)
  • e.g. a grower expects the following yield of tomatos in the next season: ...
• As a consumer, I can cast an intention to consume (want)
  • e.g. a cafe manager expects the following demand for tomatos in the next few months: ....
• As a user, I can update my intentions
• As a user, I can view intentions that have been cast

stage 5:

Inventory:

• As a user, I can track a resource that I own
• As a user, I can update details about a resource that I own
• As a user, I can search resources that I have access to

Invoices:

• As a producer, I can generate an invoice to pay money to me for transferring resources to another agent
• As a broker, I can generate an invoice for two agents to exchange resources for money

unstaged

Commitments:

• As a user, I can see offers and wants that relate to my own offers and wants
• As a user, I can connect matching offers and wants into a commitment for a future interaction (transfer, transform, transport)
• As a user, I can commit to / guarantee / sign contract for a future interaction (transfer, transform, transport)
• As a user, I can view an agent's commitments

Events:

• As a user, I can log an interaction (transfer, transform, transport, ...) that has happened
• As a user, I can search interactions (by agent, resource, type, ...) that have happened

Reports:

• As a user, I can create a report that sends me recurring updates about a particular query of data
  • e.g. "What is the total value of all resources being transferred in Northland from the last month?"
  • e.g. "What is the total value of all resources in Northland right now?"

Aggregation or not?

• To what extent will resources be aggregated for distribution (via brokers, food hubs, food network administrators, etc.)?
  • For example, one customer (cafe, school, retail co-op, etc) might want one delivery of (for example) tomatoes, carrots, onions and garlic, which might be sourced from several producers.
  • So some aggregation agent might need to invoice the customer and distribute the payment to the several producers and the transporter.
• Likewise an aggregator might want to do some some pre-season supply and demand planning, matching producer and consumer intents, and informing producers and consumers about possible shortages and overages.
  • Aggregators might also want to arrange pre-season commitments from both producers and consumers where intents match.
• Or will customers deal directly with each producer, and the producers arrange their own transportation and do their own invoicing and payment handling?

Good work! Only noticing was that we had a stage 6 which was public release and stage 5 and 6 were each about 12 weeks. About 12 moths all up.

Nice work guys. I met with the other trustees yesterday and we went through this together. They were very positive about how it is shaping up. We have a funding application deadline of 16th March so I will use the above as a basis for this. I think it nails it pretty well from the business milestone perspective. Certainly for a higher-level scope that will be suitable for funders. I guess just to clarify, are we agreeing that we building these as open-source tools that could be picked up by other regions say to replicate what we are doing? One of our projects is what we are calling National Engagement - linking together with other regions in NZ to share resources, research and ideas. This fits in well to that thinking.

Looks good. From experience talking to growers and restaurants they Prefer to deal with as few parties as possible. Also when a grower is asked to grow on contract the units are usually something like units/week for 8 months. So cataloging how much is being planned to be grown works well for some crops but a weekly production amount would work better for others. A technical challenge I foresee will be harmonizing the different types of quantifiable properties of a cast offer and request especially when aggregation becomes involved. Interviewing our pilot customers and producers may make it easier to have the data model fit their ideal use.

One more quick thought, when someone makes an offer to fulfill a specific request, we should also add question and answer threads for each request/offer with authentication rules governing who can ask and answer in each context.

@bhaugen Sorry it has taken me so long to reply. Yes i think aggregation is something needed, though I don't think it is necessary in the MVP.

I think there are two approaches to Aggregation:

1. A new agent type is created - Aggregator. ie only registered aggregators can aggregate on the system.
2. Any agent can aggregate. I as a producer decide to buy produce from my neighbor and offer it with mine.

In the long run I think both of these are viable/desired/needed. But as I said earlier I don't think this is in scope for mvp.

@sean-stanley I particularly like the Q&A idea.

On the point that growers and restaurants want to talk to as few people as possible I would interpret as being symptomatic of the fact that dealing with your supply chain/value flow has been to date hard work and for many they don't see it as part of their core business/value proposition. What I am hearing from you is that you are qualifying this understanding through market research.

I think the proposed system is fundamentally challenging this by making it all so much simpler, as such I would take an approach of testing whether the proposed system increases stakeholder engagement in their supply chain/value flow. With engagement people will be more inclined to have multiple suppliers/consumers and aggregation will be more of a logistical offering rather than a one-shop offering.