When you write software for a business that isn't a software company you'll inevatibly start to get into some conversations about what software is or isn't, should or shouldn't be.
Good software developers in the line-of-business space can take the rules and wants of a businness and turn them into consistent rules and organized containers. Still, a software program is far from "tangible". Yes the software exists, but to look at the ideas in that software as "things" is a tough ask. Sometimes it's easy because we find real-world equivalents like "ShoppingCart" or "Order". But things like "WorkflowStep" or "SecurityProvider" are harder to picture, and unfortunately failure to do so allows a particular software to be over-generallized.
Generalizations happen a couple of different ways. Sometimes it's just mistaken identity. "E-Store" seems simple enough, but once you ask questions like is it B2B or B2C, is the product customizable, can you schedule shipments, is it an auction, can you delegate ordering, are cart items considered reserved, or is your product regulated, then these items likely drive your final solution well beyond "allowing a user to buy my products on-line."
Sometimes the generalization comes from choosing the "what". Is a recall something you do within a larger system of cars? Or is "car" just a type in a system designed around recalls?
It is here that developers start to wish words like "leverage" didn't exist. When sales can find a generalization that can fit both an existing solution and one they want to sell, all of a sudden they are the same thing. It is here a "platform" idea arises.
For me a platform is about building blocks. The .net "platform" is bunch of blocks of various shapes but relatively small sizes. You can connect them together to make almost any shape but they are smaller so it takes a while to make a larger shape. But that also means it's really flexible, well supported, and can easily be changed. There's also other companies that build their own custom pieces (components) or chunks (open source or code snipits). Other more specific platforms, like CRMs, ERPs, etc, come with massive building blocks. They drop in large chunks and the shape grows quickly - but the variability between pieces is much smaller than something more general like a programming platform - so adding to your creation requires some conformity, or you must learn some pretty specific rules on how to create your own pieces.
But sometimes a "platform" seems to have become is a singular piece of software that can be configured to meet conceptually similar needs. While a stretch, this isn't that far from the truth. But if you try to explain that you "configured" the .net platform by combining different assemblies and compiling them with Visual Studio, you're likely going to get some strange looks. This just isn't what sales had in mind. They ment a "platform" that is specific enough have a specific function without being tied to a specific business case.
I'm not saying this isn't possible. When you look at some CRMs or financial tools, they do allow a lot of business specific customization without starting with a blank solution in Visual Studio. But to me, there is no such argument as "build vs buy". There is only shades of grey in terms of how much you can buy and how much you can build. Do you buy a estore and then customize it, or do you back up a little bit and buy a shopping cart component and pay for a payment processor? Each step up gets you more canned functionality, but it also gets you farther away from resources and support. You can find a developer, component options, and articles on how to use the smaller pieces in minutes. But finding somebody with experience with yahoo's store designer is a whole different story.
And it's not really a matter of cost - I beleive the build vs buy lines eventually cross. Build might require more investment upfront, but customization becomes easier with each component that you own. Need to add a new concept to your data? No problem, add another table to your database, add some relationships, and refactor. Buy on the other hand, can often can get you a lot of functionality upfront, but there is no option to refactor in something that you don't own. Any customizations have to be done within extensions that have been offered based on the 80/20 rule - if 80% of their customers also want it, than it might be well supported. But anything else and you're doing a work-around that is made complicated by the simple fact that it IS a work-around with somebody else's rules and isn't a direct solution.
I've been looking for an anology that explains this for years, and through a link my boss sent me, I might have found one. Consider vehicle "platform"..
Taking a vehicle platform to a drivable car is “custom” work – shaping the vehicle, organizing and styling the interior, etc. But it is there I think businesses make the mistake…they mistakenly boil the “needs” down too far. The need of a car for each individual person goes WAY beyond driving from point A, to point B. It’s about do you have kids so you want sliding doors so they don’t smash them into things or a split middle row so they can get in the back seat on their own. Is it a bigger guy so bucket front seats are out for him, or do you need AWD/4WD for winter driving?
These are COMPONENTS to build AND shape final solution - many of them actually dictate what the vehicle is in the end (I‘ve not yet seen a sedan with a sliding door option :)). Even things like climate control and lighting seem ubiquitous but they require ducts and electronics specific to that vehicle. It is rare for a company to sell a premium version as a base model only to get those premium features with a simple configuration You can’t get under a 2WD vehicle and see a 4WD transfer case that is just “disabled”. “Here sir, let me enable SS mode so you can see what another $10k feels like” :). Even if we could do this without making the customer feel dupped, it still is not free. Think about how much more a 4wd recall would be if you even had to apply it to 2wd cars. In the software world its the equivalent to having to consider unused functionality for fixes.
To see how this still holds up, take a possible counter argument: GM is trying to reduce the number of platforms from 26 to four – but even they are giving themselves 8 years out to do that and it took them 100 years to get this far :). And think about why they might be able to reduce the number of “platforms”. I don’t think it’s because they can move more features into the platform and turn them on and off depending on the application. I think it’s because the development practices have advanced and components are cheaper to where more of the “custom” vehicle can take up the slack that was once delegated to 26 different variations - the case of innovating the factory over the product. The only other option is to drastically reduce their offering which they can do…but in that case I might go buy a Ford instead.
I'm not saying a platform can't exist. If you do something long enough you start to see some really good abstractions and can eliminate some boilerplate code that's found in every solution. But abstractions are not software - they are not concrete. They are the BASE for something more complicated. And so when someone asks you if a previous solution can be "levereged" you can say yes - the EXPERIECE can absolutely be leveraged. But that isn't the same thing as saying, "it's already done".