It took several hours of individual research, watching talks, reading blog posts; and took several pair-programming sessions of several hours over the span of four weeks to come up with a solution we liked.
We informed our client that this was a new area for us and that we didn't have hands-on experience with, but that we believed it would be beneficial to spend time to explore it, as it would be an elegant solution to several of their business problems. They agreed and we kept them in the loop with weekly meetings.
We're now in the phase of actually implementing real-life processes, the project will probably be in active development for another year or two.
How do you approach estimating effort for this sort of thing? I find it awkward enough in Scrum to guess up front how many days of effort research will take and commit to delivering a plan or design by the end. If you have clients and aren't strictly bound by someone else's framework, they still want some rough idea how long research will take. Especially if the client is footing the bill. If the research is un-billed time, then the estimate is critical to you. What do you do?
If you are perceived as just a cog delivering software patches, you've already lost. If you're presenting business proposals and designs, you've already provided research, analysis and business cases. Often this is alot of extra unrewarded work. Though, if a vendor has proven themselves already, they're in position to ask for billable time for more different types of roles. This upfront work is an investment in own business and can be used to attract other clients, but sure, most of it goes down the toilet unless a good outlet is found for all that creative work. A bigger consultancy can have many people cooperating on such work in order to add that extra value to hiring companies.
Everything starts with trust, of course. We've proven ourselves in several large projects and within our open source community before. The client knows that.
There's never any estimate of "so much hours will be spent in total on this research", we just honestly communicate with the client along the way, and they give us their trust.
Reaction Commerce behind an Airframe static site up quick.
Have an http server between the two, and log the requests.
Users don't update products or orders directly. The critical data that needs to be logged runs on a private network. Something with a lot of validation updates that.
Don't delete services when creating new features. Keep them running.
Avoid a central source of truth. Instead log discrepancies. Then your procedure is "Don't do this" along with "do this".
A lot of microservices are built starting as low as you can go.
I prefer to install proven working software and close it to modification. Have a bunch of them running together instead of making something new.
