|
|
Like this article? PLEASE +1 it! |
|
Building Longterm Viability into Your Prototype
Written by: Andy PiperArticle Overview: Software prototypes are supposed to model how to implement a solution. But today's business world forces many prototypes (and all their short cuts) to be used in production environments. This article describes a number of characteristics that ensures a prototype can incrementally and effectively grow into the sophisticated product that lets you go to market on a wide scale.
![]() |
Free Download - Do You Have the Right Stuff to Partner with Microsoft HP or IBM By Andy Piper |
Building Longterm Viability into Your Prototype
In the world of software, prototypes used to mean proof of concept. But today, too often prototypes are thrown into production environments or used as a bare bones first release of a new software package. This causes a lot of headaches for software developers and managers alike. If you are not properly prepared, you can build a prototype that is successful, but actually impedes your ability to release the fully functional version of your product you need to address the market on a grand scale. Incorporating specific elements into your prototype will ensure your prototype has all the elements you need to be successful and set you up to get you the fully functional version of your product, as quickly as possible.
Before building your prototype, you must understand your enterprise readiness strategy. Your goal is not to achieve enterprise readiness for your prototype. Instead, your goal is to build your prototype on an architecture that allows easy achievement of enterprise readiness incrementally without too much redesign. That means you need to understand how your product will function with thousands of users and across a wide area network and build your prototypes, using technologies that allow you to achieve this vision. The other important aspect is that your prototype needs to include enough functionality so you can have an enterprise ready solution within 24 months of the initial release.
When it is time to build your prototype, make sure you use all the technologies that your full product is expected to run. For years, people have built applications using Microsoft Access, when an enterprise ready product requires them to run on SQL Server. Likewise, don’t build a pseudo directory in a prototype, when, ultimately, you are going to require Active Directory integration. Building your own directory may be easier for you than doing the integration. Building the directory integration up front saves your engineering team several man-months in having to rewrite major sections of your core product in order to achieve enterprise readiness.
Another way to ensure your prototype has long term viability is to build it using mainstream technologies that have earned their stripes over the years. That means sticking with products that have been around for a long time and proven themselves in an enterprise environment. Additionally, it means making sure your solution implements these technologies using established best practices published by the manufacturer for deploying their solution.
Finally, you want to use as many third party components in your infrastructure as you can. You will not have time to re-invent the wheel. Chances are, someone has a third party component you can use that is more robust than what you can build in your prototype time frame. Initially, this integration will give you a more robust solution with less development effort. However, you must keep in mind that this can increase the cost of your solution. Of course, you always need to make sure any additional cost associated with any third party components does not price your solution out of the market.
My brother, Todd, always says, “If you fail to plan, then you plan to fail”. When the subject is prototypes, this is definitely true. If you cannot follow these guidelines when building your prototype, you will most likely have to rewrite major sections of your application in order to be viable for large customers. These rewrites are costly and put a serious strain on already strapped resources. Avoiding these pitfalls gives you a product with a clear direction and manageable timelines. This increases the odds for developing a product that can easily grow to meet the requirements of enterprise customers and allows you to get there with the least amount of overall effort.
Article Tags: active directory, architecture, directory integration, elements, engineering team, functional version, headaches, initial release, microsoft access, new software, production environments, proof of concept, prototype, readiness strategy, ready solution, sectio, software developers, software package, software prototypes, wide area network
|
About the Author: Andy Piper RSS for Andy's articles - Visit Andy's website Andy Piper is the author of Enterprise Readiness 101 and the founder of www.enterprise-readiness.com. For over ten years, he has worked with enterprise companies. He has developed applications and implemented solutions as a systems engineer. He spent several years at Microsoft as a sales engineer. Since 2004, Andy has been a product manager for different start up organizations such as Ardence and most recently Casenet. Click here to visit Andy's website Relational Software Competetive Advantage Article Eneterprise Readiness |
Related Forum Posts
Share this article with your friends. Fund someone's dream.
Leave a comment below or share on the left and you'll help support entrepreneurs in Africa through our partnership with Kiva. Over $50,000 raised and counting - Please keep sharing! Learn more.
Get advice & tips from famous business
owners, new articles by entrepreneur
experts, my latest website updates, &
special sneak peaks at what's to come!
Email us your ideas on how to make our
website more valuable! Thank you Sharon
from Toronto Salsa Lessons / Classes for
your suggestions to make the newsletter
look like the website and profile younger
entrepreneurs like Jennifer Lopez.



