Yep, it's been 9 weeks between my previous update and this one. What was meant to be a weekly update became a monthly update, and I didn't realise when it veered of into long breaks between updates.
I guess, that gives you a better idea than anything I can say or write about how busy it is at Amygda. And we are ready
A couple of years ago I watched a TED talk on how ER doctors triage an always busy schedule.
And since then I've stopped saying I or we as a team are busy. Everyone is busy, everywhere.
What will stand you out from others in challenging, chaotic time, is whether you are ready for it or not.
That mindset change is important.
In early days of a project you won't know all the answers (atleast we don't). And it can be easy to say let's write down all the scenarios and build for it.
I don't like that approach. At an early stage, speed is your friend.
I often say, we will be burnt on this one and we will solve it then. Because I have the balls to know that even if everything was on fire as a team we will come through it.
We are ready.
So whether you are thinking of of a start-up, or even otherwise try to remove the word "busy" from your vocabulory. It doesn't actually get any point across - infact it's a lazy answer in my eyes.
Yes, we should.
We have continued to build the Complex Event Processing (CEP) system for high-frequency streaming analytics.
In the last 3 months we have done two proof of concepts on two different industries.
We were able to deliver one proof of concept in 2 weeks. It takes 3 to 6 months to set-up a working proof of concept with a scalable CEP system.
We do our proof of concepts by giving customer access to the actual product. We don't just produce reports or presentations. But rather a usable product.
You can imagine, the effort we've put in to have something which can be productionised in 2 weeks.
That has worked because we built the architecture for doing high-frequency analytics from ground up. We could find efficiencies in productionisation that a lot of products that don't begin with a product-first mindset could never find.
Part of the 2 month silence has been that there's a lot ongoing. Data science practice adds heavily to the product.
One of the challenges we find is that industrial time-series data doesn't lend itself nicely to the ML methods where labelled data and frequency of data matters a lot.
For example, products like Datadog, H2O.ai, or any other Auto-ML product does a good job once the problem is set up.
Once this is in place, existing Auto-ML can do a good job. But in industrial domain that doesn't happen.
Which is why, we are putting a lot of effort into our own Autonomous AI stack.
It's our stack that is built for unsupervised application to data.
Humans drive a lot of knowledge in how potential damage or inefficiency in an equipment can be detected.
This accounts for capturing known-known issues. However, at a higher-frequency of data availability the sheer volume of data to churn through is huge. And analytics built for lower frequency of data don't work well.
When you have to select from 10 features, manually that could work.
When you have to select from 600+ features, you have to lean more on hyperparameter tuning or hyperparameter selection. Amongst others.
Autonomous AI enables Amygda to do that rapidly.
Another challenge in industrial domain is that historically maintenance information is collected and stored by humans in databse systems that haven't followed rigour in how information is captured.
So you end up with maintenance information that looks like this:
If you combine all the damage (failure info column) in one, you are assuming the damage mechanism originates, and propagates the same across all. Is that correct?
If you find out that they all have different origination mechanisms. Then do you believe that what humans have labelled is correct? Could there have been a mis-entry? Or a mis-understanding even perhaps of what the failure is.
To solve these challenges faster, it's important for us to continuously add to the Autonomous AI.
Distribution is important.
I have previously written about the importance of distribution in product development.
A lot of effort has gone into building multiple channels of distributing Amygda's data observability platform for asset-intensive indsutries.
Soon, we will share more on this.
Here's what we've been growing with
As you can see, there isn't one thing that is the magic bullet. As a project we are focussing on taking forward steps on many things.
Doing this with focus, persistently is what we are good at.
A beast at it actually. Very few people will out do us on the persistence of breaking through things.
Ofcourse, having a good network of folks to gain advice and insight from is important.
We are currently raising a seed round, and in talks with good investors who we align with. And who have the network and past experience of helping startups who look like us.
However, I've also started thinking much more about angel investors (wiki: angel investors).
Not just from the prospect of investment. But angels who can provide operational support as well.
For example, having an investment of £5,000 to £10,000 from an angel is good. What's even better is to have that investment from a sales leader, or someone from C-suite, who can bring operational or industrial experience as well.
Being an operator with us would be fun. Infact I love operators. They are the true acceleratos.
More on fundraising to come in the next few blogs.
There is so much ongoing. And we need more hands on deck.
To find out about roles we are hiring for, follow the Amygda page on Linkedin.