This interview is with Tom Barber, Managing Director, Concept to Cloud.
Looking back, what path took you from NASA to leading cloud MVPs and modernization efforts in the private sector?
A lot of the work carried out at NASA then trickled over into my private-sector work, serving as a natural continuation of platform design and development.
This enabled us to commoditize the work we had been doing at NASA and helped drive modernization for our clients.
Starting from a fresh concept, how do you take a NASA-originated technology from idea to a workable cloud MVP?
When we worked at NASA, a lot of the work we did was data-driven: either data input, data output, or data processing. Taking many of the learnings from there, we deploy some of the open-source software we built in those projects along with our technical know-how for our customers. This helps us stay ahead of the market and enables us to build MVPs efficiently, ensuring satisfaction for our customers.
We have a three-stage process: Access, Build, Embed. This allows us to work with our customers to help build their MVP.
-
Access — Our design team works with customers to determine the MVP criteria, how users will access and use the product, and how it will be deployed.
-
Build — Once the design is finalized, we work with the customer to build the MVP, gathering continuous feedback and ensuring we build with them, not for them.
-
Embed — In the Embed phase, we work with the customer on an ongoing basis to ensure the software remains functional and secure during its operational lifecycle.
Building on those first steps, which NASA-honed practices help you move fast while maintaining reliability in early cloud builds?
Cloud computing is most important; by leveraging what cloud vendors offer, it greatly speeds up the build phase and means customers have less to manage once it’s deployed.
Also, keep the architecture simple—don’t overcomplicate things; keep it simple and effective.
This helps keep costs and maintenance down.
As early usage data and stakeholder feedback arrive, how do you decide whether to pivot or persevere on an MVP?
We sit down with both the customer and the development team to work out what’s going well, what’s going wrong, and where our expectations have diverged from reality. This regular feedback allows us to really hone in on the issues and then make either small or wholesale changes as required.
When legacy systems are in the mix, which single modernization pattern has served you best?
Dependency management on home-built legacy systems: ensuring that dependencies for software continue to be managed in a way that allows the software to be built, modernized, and maintained.
Of course, after that, leveraging Agentic Coding techniques—both for developers to build more efficiently and for automated bug fixing and patching—is important for us as an organization.
On security and compliance, what “just enough” baseline do you put in place for an MVP so velocity isn’t lost?
Ensure that any web services are secured. Keep data retention to a minimum, and ensure access to production databases is granted only on an as-needed basis.
The rest can come later, but ensuring that data is minimal and that public attack vectors are reduced is very important.
At the same time, implement low-touch tooling that adds security, like Snyk, Chainguard, etc., which is something we work on with customers upfront.
To keep executives, engineers, and domain scientists aligned, how do you define and socialize success metrics for a concept-to-cloud effort?
We define success with our customers, aligned to their goals and deadlines.
For most MVPs, the primary question is whether there is demand. We build quickly to gather both internal and external feedback as soon as possible.
- Metrics are usually feature-based.
- Did we hit our goals?
- Are end users satisfied with the features delivered to them?
When it’s time to scale, what signals tell you an MVP is ready to graduate to production in the cloud?
- End-user adoption
- Customer retention
- Scale needs
These indicate that the MVP was a success and that it is time to move to a larger production build-out that brings more security, greater scalability, and the ability to maintain the product for the future.