Your team member pushes for unproven tech in your software architecture. How do you navigate this risky move?

This is almost a daily occurrence in today's world of burgeoning AI systems. Over the past year to year and half, there have been numerous business partner requests to add AI capabilities to an already in place platform. Sometimes it is simply because that platform has just added "their" new AI capabilities. To be successful in deployment and effective utilization, we've first done our security analysis, but that has been followed by pilot phases. Without naming names, some of these AI pilot efforts have shown promise while others were eliminated because of limited value. The importance of how an AI tool, or any proposed solution, fits your architecture you must prove its value before embarking on a production effort.

See if you can run both tech in parallel for a while. Start with existing tech as primary, and new tech as a shadow check. If results match up, then switch to new tech as primary with existing as back-up. Doesn't work with every project, but you should assess this possibility.

New product development, especially in the AI field, is about innovating with technology that is completely unproven. The key to success is pragmatic assessment. Not risk averse, nor optimistic. Porridge just right.

First, understand the proposal and listen carefully to the team member to understand why they believe this technology is a good choice. Ask them to present the advantages, case studies, or any evidence that supports the decision. Another point would be a controlled test; in other words, if there is potential in the technology, suggest a pilot project or a smaller-scale test. This will allow you to evaluate the feasibility of the technology without compromising the entire project.

Risk assessment is critical. Three key considerations I bring up are: 1. Is it secure? 2. Does it perform well? 3. Is there a good chance it will be supported in the years to come? If the answer to any of these is no, then that is a deal breaker. If the unproven tech is from a large technology company, there's a better chance that it will be supported than if 2 developers put a library out there.

Your goal is to begin a long-term process of smallest possible reversible steps and on-going monitoring that weighs expected results against reality. "Making a decision" is a problem if it creates a hard fork in the road. It has to be done at times - just make sure this is one of those times.

Don't consider a test. Do it. Then add some more tests. Make them part of an automated tool-chain, and part of everyday work processes and thinking.

In a world of continuous improvement and continuous innovation, production is a test. Keep the blast-radius close and the test cycles short. Telemetry is as pri0 as user auth and security.

Stakeholders come in a few variations, but in all cases managing expectations is the key to success. Think of them like customers; understand their pain and speak to them when and how they will be most receptive. They may not always be right, but they are always the stakeholders.

After implementation, continuously monitor the progress and performance of the new technology. Establish metrics that help determine whether it is delivering the expected benefits or if adjustments are necessary. Regular monitoring not only helps to detect problems early but also provides evidence of success that can justify further investment in the technology. This vigilant approach ensures that your company’s software architecture remains at the forefront of innovation while safeguarding its stability and reliability.

Tech analysis should be executed by those who have done good work in the area of interest in the past . It's usually a myth to believe that SMEs are trying to identify the best technology product rather it's about identifying the best suited product for an enterprise. If you are trying to explore a technology offering the 1st time at best you are only trying to understand the product. This can't translate to sound technology selection decisions in a short time. It needs a lot of pilot and iterations to understand the product and is usually time taking initiative. Usually this is done by COEs and not deliveries to have a larger beneficiaries across the organisation.