The Purpose of the Prototype
The Art of Requirements I - Pet Projects vs. POC
Recent advances in LLM technology have raised the perennial specter of job displacement for those knowledge workers concerned with the development of new software platforms and technologies.
Yet unless such AI agents can break past the asymptotic boundary of their current intelligence and move a gradation or two closer to the threshold of AGI, the development and maintenance of software systems may be assisted but not fully usurped by agentic workflows.
Generative AI can perform a variety of low level tasks to an acceptable level within a condensed amount of time, but one dimension that even the latest and greatest models at this time are nowhere near managing is architecture, software and otherwise.
Solutions architecture is concerned not with the building of technology for its own sake or to satisfy the tinkering itch of its engineer, nor with the isolated perfected piece of technology to live and exist in an isolated cell, nor even to prototype a MVP to force the hand of stakeholders into technology adoption.
Each of these can and often do happen.
Solutions architecture ought however to be charged with the responsibility of building not just well in the abstract but in the concrete. Just as a building cannot be erected without considering the slope or stability of the ground or the surrounding buildings, so too digital solutions must pay a nearly obsessive attention to context.
That is why the first step of solutions architecture is to understand the organization as it exists now and in the future.
Even the most greenfield of projects—freed of seemingly ever constraint to roam free in the name of prototype or R&D—must still be embedded in a field of some kind, if its seeds are going to take root.
If your solution is part of a brand new LOB or BU, you will still be constrained by IT governance.
If your solutions is part of a dedicated Rapid Prototyping team with a direct line to the CEO, even your silo must prepare to accommodate compliance, SLA’s, and the hasty innovator’s worst nightmare: Site Reliability Engineering.
If your solution is part of a brand new company with zero tech debt and seed money for a brand-new totally from scratch green-as-the-grass first-time prototype, your solution will still be constrained by CEO and investor expectations and the criteria by which your product can with sufficient truthfulness be labeled a MVP that has reached the market.
Any development initiative without a distinct and laser-focused vision of that rubber hits the road moment of integration, when something becomes “production”, will likely founder even in the hands of the most skilled technicians and product owners.
Many will not see the light of day, or enough of that daylight to be considered a living, breathing, viable system.
Pet projects, prototypes, proof-of-concepts remain what they are, not “Ready for Production”.
This is not to say that such tinkering toys or half-baked projects are without value.
They are in fact very instrumental.
The greatest masterpieces of visual and literary art are often the successors of many sketches or “stillbirth” pieces. The crumpled up pieces of paper that are discarded become like rungs of a ladder. They have served their heuristic purpose in helping sharpen and hone the vision and focus of the artist or technicians to accomplish the final task.
Prototypes and proof-of-concepts are immensely powerful tools to advance the mission, to build solutions without the weight of overthinking. To try by doing and advance past the tempting dance of navel-gazing among opinionated stakeholders.
But the point is, if there are aspirations that your solution, your prototype is going to become something more, you must aggressively wrestle with the question of what you are prototyping toward.
As simple and glib as it may sound, you must ask what is the problem your solution will solve and how it will come to do so.
What makes a solution effective is that it does come into effect. It produces. It makes things happen.
So to build a solution requires the marrying of the future and present. It requires an upfront wrestling with properly contextualized questions: what does it mean to be production ready here? What does it mean to be production ready in light of general principles and best practice? What is the concrete roadmap to launch? To iterate? Who pays the bills? Who are the stakeholders?
That kernel of novelty your solution will introduce, that must be sown in light of these questions. If you want to be smart about it.
Of course, many can get away with a Series X investment round or a chain of promotions without really bothering with these considerations. Many battles in history have been won by the less-than-perfect, simply by virtue of right place, right time. Or by hanging around long enough.
But there is a difference to doing something and doing something well. The art of solution architecture is concerned with doing the thing well. And that requires forethought and planning.