One of the challenges we face when building a new product is the selection of the technology. \u00a0Finding a\u00a0balance between a homogeneous or mixed solution can be difficult. \u00a0On the one hand, a single vendor is easier to work with. \u00a0However, on the contrary, you want to avoid lock-in, and single vendor solutions often lack the features of one built using multiple tools.<\/p>\n
In my experience, a single technology solution almost never works for custom solutions. \u00a0Tools like Microsoft Access, FileMaker, and others that offer all-in-one solutions can be useful. \u00a0However, their use is limited, and customization can be painful, if not impossible. \u00a0That being said, simple applications like general accounting, address books, and catalogs are entirely possible with these tools. \u00a0These are solutions that need little customization and follow a sort of template solution. \u00a0These tools work, but often the end solution would have been cheaper to buy off the shelf.<\/p>\n
The cost of these solutions tends to be low as you can find resources that know the tool and have proven experience in it. \u00a0They know how to stay in the “safe” areas of customization and upgrades are often painless.<\/p>\n
Another approach is to find the best tool for each feature or aspect of your solution. \u00a0This method often allows heavy customization and the ability to create your solution precisely. \u00a0However, there is a cost of integration. \u00a0The tools have to be made to work together. \u00a0Sometimes the “glue” used to put these disparate pieces together can be complicated to create and fragile once completed. \u00a0A change to any part of the solution could potentially bring down the system. \u00a0Upgrades become risky, and the pressure to leave things as they are can be enough to freeze the solution from enhancements and upgrades.<\/p>\n
The cost of these solutions can be very high. \u00a0In fact, this often is only a path open to enterprises and companies with a significant number of development\u00a0resources. \u00a0It is very rare for one person to know more than a few of these sort of technologies. \u00a0Thus, there is often a need for at least a resource or two per technology. \u00a0Note that I said, “at least.” \u00a0Projects may require dozens of resources in each technology silo. \u00a0Keeping everyone busy during implementation requires substantial planning. \u00a0Therefore these projects can be challenging to manage.<\/p>\n
There are more than two ways to view this problem. \u00a0So let’s look at the middle road. \u00a0Tools rarely are limited to a particular solution. \u00a0Thus, they will have strengths that can be used to solve other problems. \u00a0For example, a database\u00a0can include business logic. \u00a0However, the front-end or User Interface tools can perform some as well. \u00a0Neither of these tools is likely to be the best way to implement business logic. \u00a0Nevertheless, it is possible.<\/p>\n
The key to selecting your technology stack is to find the best tools for your most significant problems. \u00a0These are the uses that will occur most often in your solution and have the highest impact for the customer. \u00a0To put this simply, make sure your key selling points are the features that work the best. \u00a0Likewise, these areas of focus should be the most stable, scalable, and easy to maintain. \u00a0You are not likely to spend enough time on ancillary features to focus on those solutions.<\/p>\n