January 13, 2016 at 11:35 am
Sometime you don't have to buy or build it. I have a whole slew of utilities for Windows that are free or OSS. Not to mention the entire stack on the Linux systems.
January 13, 2016 at 3:58 pm
chrisn-585491 (1/13/2016)
Sometime you don't have to buy or build it. I have a whole slew of utilities for Windows that are free or OSS. Not to mention the entire stack on the Linux systems.
Open source and freeware tend to have a completely different set of costs associated with them.
January 14, 2016 at 12:19 am
In my world buy vs build raises the question of who integrates the solutions and what is required to enable that to happen.
If you build it then could you sell it or licence it and add a new revenue stream to the organisation. Remember things like Apache Cassandra arose because someone decided to build their own database
If you build software and support it then make sure you have robust fully automated tests surrounding it, documentation suitable for the problems raised at 3am when you are decaffeinated. In short make sure you know what you are getting into
January 14, 2016 at 7:30 am
The economic argument in favor of Buy is stronger if the product has robust and simply features for customization and scripting.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 14, 2016 at 7:32 am
Ah. The always popular 'Build vs Buy' debate. The answer to which changes with every management change.
I supported the service desk software for a lot of years. I was the one who brought it in house knowing we would need to customize it. The software came with a designer and very good documentation on how to do it.
Fast forward several years and this software had mutated to be wrapped around our business processes and our business processes were wrapped around this software. We were trapped in a hybrid solution.
Overall the combination worked very well. We had support from the vendor for the core product and our internal support for the customizations. But it wasn't easy and it wasn't cheap.
If an off the shelf package will do 80% or more of what we need and the price is reasonable there's no reason not to buy it unless that missing 20% is critical. If there's nothing out there that can do what we need then building makes sense.
So the answer as with so many of these questions is "It depends".
February 17, 2016 at 4:46 pm
Absolutely agree.
September 5, 2019 at 11:02 am
Other considerations that I have had to make for TCO are that it sometimes takes multiple COTS products to "cover the ground". Individually, many of them are poorly architected. Collectively, they don't work well together, even if they are from the same vendor, and require a massive amount of home grown "glue" to make them work together. Each product has to have its own copy of data, its own security model. It takes a large amount of human and computer resource to keep these copies synchronized. The users of the products get tired of having to figure out which product to go to.
Additionally, we have no control over how long the company that produces the product will exist, be bought, decide to not support, or otherwise leave us high and dry. If that happens we have to go through the acquisition process again.
Whether we build or buy, we need to determine what our requirements are. With COTS we have to settle for the closest match or matches and, as stated above, often pay for bloat, poor or non existent documentation, and poor support.
In an environment with high security requirements, every update to COTS products should undergo analysis to make certain that no back doors or other security holes are being introduced. This can also be a very expensive proposition.
September 5, 2019 at 11:03 am
Well I'm just starting a project around - let's throw in a buzzy word - "AI Vision". I do this completely in my free time so what might cost me most is actually time (I still need some hardware in any case so someone's getting happy about some of my $$$$ somewhere).
Now I have been looking at things like:
In the end at least for the start (which will hopefully come this weekend) I decided to go with SoMs with well documented pcb layouts, stacking and whatsoever. I could have gone for different SoMs but the main appeal here for me was: The one chip I absolutely cannot pass (and looks like a nightmare to solder if you've never done that before) is on the SoM right there and on top I get a well documented ecosystem, easy Integration into Azure IoT (which leads me to believe MSSQL is no problem either and communication can be encrypted).
They even offer some webinterface and hosted service which you could use in your project which is nice if you want to use that but I will pass most of that except for general sensor / functionality Evaluation but what's there really looks like it could be of good use.
Yes it would've not been any issue from all the SoM drawings to get up with the exact BoM and spec the SoM has, even if I have some shop print my PCBs I still would not just run the risk of frying silicate based Chips but I still would have to find out myself if and how my bunch of chips would make it to Azure with SSL and all the other given requirements.
I'm really happy that I found these SoMs since the chipset isn't that common yet, if needed I would've gone through all the pain (yes, I do have some help on the soldering / .Net Core side of things) but this will reduce the time I need until I have something to show, quite substantially which I do consider important as very long running projects without anything actually working (because it's all WIP) tend to get boring quickly if you're not being paid for it.
Maybe I will have some very custom boards with that chipset somewhen in the future, too. But until I know what exactly I want in those things it's a great relief to have something to start with off the shelf.
I do see some potential if things work out as desired to put some of the code we come up with on GitHub not just in the spirit of OSS but of course hope that some day someone might drop by and says something along the lines "you had a bug there, I helped you fix it" to eventually make maintenance of the SW a little bit less painful.
September 5, 2019 at 12:13 pm
This brings back memories of about my third job as a developer at a company where we leased payroll/personnel software at the source-code level, and then made modifications for our own needs. Those were also the days of compiling drawers full of 80-column punch cards of source code which were identified by 6-digit line numbers. The vendor would release modifications that had to be applied by their line numbers which incremented by 10, and the source had to be updated by those numbers and then have our customizations applied the their code, fitted between the existing line numbers. If our mods didn't fit in between the numbers, we had to branch out with a 'Perform My-Change through MyChangeExit' in order to accomodate our modifications.
Of course, if you ever dropped a card deck you had a manual sorting job on your hands before you could put them in the card reader for a recompile. The punch cards came in boxes of 2000, and the coding sheets had to be sent to the 'keypunch department' on coding sheets to have the new/modified cards punched so you could add them to the existing deck. Then carry the deck in its storage drawer to the 'computer room' for the 'computer operators' to run your compile between other production runs. The results of the compile came back to us on 11x14 continuous paper and if there were errors you had to write the code on new coding sheets, re-submit them to have new cards made, fit them into the deck by number, and submit the deck for another compile.
Such were the ongoing costs in my early days.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
September 5, 2019 at 1:13 pm
If you outsource you get a fixed scope and budget.
What you don't get is your internal staff plugging the gaps that form the NSRs.
NSRs are the None Stated Requirements that, if missed, will result in blame storming in the postmortem for the project.
The trick with SaaS/PaaS solutions is in the integration. Get the choice wrong and the job of building the integration piece can easily exceed the savings from going with a SaaS/PaaS solution. This is equally true of getting microservice design wrong.
Companies want a quick fix that will cost nothing and last forever. I've yet to see that done successfully and I'm coming to the end of my career.
Careful planning and design will reap the rewards of SaaS/PaaS but that planning and design is a non-trivial activity
Viewing 10 posts - 16 through 24 (of 24 total)
You must be logged in to reply to this topic. Login to reply