Your app, your product, your company’s future. The idea is sound, the market is ready, the team spent many months implementing it.
The questions corporate sponsors will be asking are: is it ready for production? When do we launch?
As an architect, how do you assess production readiness and chances of success in the field?
Here are some criteria to help formulate the answer to that question.
Code quality is good-to-great
Your code has little tech debt. The architecture is flexible, scalable. Features are easy to modify, augment, and add.
The dependencies are at the latest stable version.
The integration points have corresponding integration tests.
Core components have unit tests covering happy paths and failure paths.
Concerns are clearly separated.
Feature set is mature
The team and Product Owner has painstakingly iterated through the feature set multiple times, polishing workflows, interactions, screens, verbiage. Your features don’t just “work well”, the team starts using words like elegant, fun, cool to describe various things the product can do.
The last few times your Product Owner requested a new feature or a drastic change to an existing one, the team did not cringe and ask for “at least two sprints” to deliver it.
Change becomes fun when the software is architected well.
Onboarding, user management, and off boarding works near flawlessly
Once you are in production, you will get real customers. There is nothing more infuriating than an inferior or faulty onboarding process.
Your emails must look fun and exciting. Limit the number of steps until a customer can get in and feel like the registration is over. Defer all secondary actions to post-registration, if at all feasible.
Make it easy and fast for someone to provide the info you need to operate.
Give people options, for example make it possible to log in with email, phone number or user name. If you collect this data and require it to be unique but then don’t let the user identify himself to your system using the data he provided, you are not facilitating the best experience you can. Aside from that, people like to compartmentalize ids and passwords. Give your users the option to put your service in the “I use my phone number for this” compartment.
Change password, log out everywhere, change phone number, add another phone or email, recover password or user name, resend email confirmation – you remembered all of those, right?
Sometimes customers will want to leave your service. I know, crazy… But seriously, if they enter any data into your software, they are likely to want to take it with them and use it with a different service. Think of this and build a data export process before you go live.
Release pipeline is designed, implemented, and tested
Once you hit prod and get real customers, they are likely to be less forgiving and more inventive at breaking things than the best PO. You will have to roll releases fast and furious and your release pipeline better be ready for it.
Test your release pipeline like you test your software. Time it from the request for a code change to commit to build to verification to sign-offs to deploy. Identify the bottlenecks, understaffed areas, weak links, under-automated workflows. Correct the entire pipeline until you know you can release quickly and twenty people don’t have to spend six hours on a phone bridge yawning and hating your software.
Support process defined and tested
Go ahead and call or email your support pretending to be a customer. You are likely to realize that the support process is not ready, does not have enough support scripts, documentation, knowledge of the system.
This is what your customers will go through. Fix it. Document common workflows, escalation routes, build support utilities to help resolve common issues.
Also, do you have a good process for support reps to report frequently occurring issues to devs? It does not have to be catastrophic to become a sprint item, right?
It’s a great practice for support to publish a weekly newsletter with a name like “From the Trenches”, where they report successes, failures, funny stories, etc. We are social creatures, community building is important.
Code and environments are instrumented for analytics, logging, troubleshooting
Instrument your code well. Log important events. Provide workflow traceability. Your team’s post-release quality of life depends on it.
Understand what a customer will provide when calling about an issue and make sure your logs allow you to get from that input to that user’s interactions with your system. For example, customer will provide the email address. Can that tell you the APIs calls and workflows that user was executing and where things went off-rails?
DevOps are mature
As the system matures in production, it is likely to change. The moving parts may change, the hosting strategy may change, the external integrations and corresponding firewall and networking may change.
Is your DevOps organization mature enough to implement and support your release pipeline and rapid infrastructural changes you will throw at them?
To my mind, production-ready level of maturity for DevOps is when they can accommodate networking, security, hosting, pipeline changes within a couple of sprints at most.
How many things are DevOps still doing manually? Try to influence for more automation.
Hosting concerns resolved – certificates, servers, licenses, DSN, firewalls, load balancers, networking, CDN
I can’t tell you how many times I have seen releases plagued by incorrect or insufficient certs.
Weak servers, unpaid licenses, misconfigured DNS and firewalls… I’ve seen and lived through it all.
Test it, drive your system’s physical and logical hosting design, know the full checklist and people responsible for each part. Even if it is “another department’s fault”, it will be your software that won’t work.
Customers never report faulty firewall configurations, they report “I can’t log into your *&#@* app”.
Just like onboarding and customer service, giving your users a well-designed feedback pipeline will make them feel valued and will make your product look professional and polished.
If customers can recommend features, vote for favorite items on your roadmap, report frustrations, your backlog will become a ton more meaningful. And so will your product. Don’t make it an afterthought. Build it before launch. Early life is when you will need it the most.
Beta testers identified, relationship established
Identify early adopters, nurture those relationships, incentivize them if possible.
An active community of early adopters can make the difference between a successful launch and total flop.
Product Owner is happy
Is your PO happy? Is there an excited ringing to his voice when the product is discussed? Is he using it every day? Has he switched from talking about bugs and imperfections to planning for future features and updates?
If your Product Owner is happy, chances are your users will be as well.
Developers like using the product
Do developers log in just to do development and test their work? Or do they love logging in just to navigate around and get a little dopamine boost from it?
A happy developer is an even better predictor of customer satisfaction than a happy product owner.
These criteria, of course, describe a semi-perfect world of unicorns and rainbows. They depict an ideal, desired but rarely achieved. Corporate decisions are often made very differently. But that reality should not preclude us, technical people and especially architects, from having a good set of criteria and rules to guide us in formulating a plan to get to prod and to make our product better after the release.