The "not wrong" argument resonates with me. I also think that the amount of liability is also why startups may find it hard to land clients in the enterprise space. I mean if SAP gets a contract and screws it up, they can be held liable. Startups might just go broke and then poof the product/support is gone.
> The flip side, though, and this is awesome, is that you can work on really BIG things. Much bigger than any startup is tackling. That's fun.
But big in what sense ?Could you give some examples of these projects or comment on their nature if you can't talk exactly about the projects ?
Example: When I was at the Fed, I worked on a system that moved $100 billion a DAY. Yes, billion. More money flowed through that system every day than the GDP of most nations. I got to see what happens when you overflow the Money type in Java. We were delivering 10,000 transactions a second on a Unix/Java/Oracle stack, a feat IBM told us could not be done.
You don't get to do stuff like that with your new lead gen app.
I agree, but enterprise or large orgs usually are happy about enforcing strict rules even for internal tools. You deploy tool to 100 internal employees and worst that can happen is someone will have to have longer coffee break because your deploy didn't work. Then you still have to do 1h of paperwork for this internal tool and then another 1h of paperwork for hot fix. That is not how you do risk management.
> the amount of liability is also why startups may find it hard to land clients in the enterprise space.
This is definitely one factor, but I think it's something that enterprises manage on a regular basis. They have many suppliers and different arrangements to cover the risks. The problem is often on the startup side where there is a reticence to do anything that would change the product to suit a particular customer and "compromise the mission" of the startup. End users are important, but aren't the real customers of an enterprise startup.
If you are relying on enterprise customers this will naturally bring a level of tech debt in order to service them. It's better to embrace this than avoid it in many cases. I've seen startups in denial that certain features would be useful to many customers, only to provide them to a subset of customers where they are legally obligated, simply to maintain a facade that they aren't really a traditional enterprise startup (to support recruitment, product management egos, etc.)
> They have many suppliers and different arrangements to cover the risks
Doesn't that push up integration costs ? For every new product there is data migration from the old one, installation costs, API changes (maybe not this) and just cost due to downtime.
In my experiences, large enterprises make decisions based on integration surety over integration cost (if it's competitive within an order of magnitude).
A ridiculous number of integrations fail.
If you can convince someone with authority (either technically or via relationship) that an integration will be successful, you're in.
This is IBM and SAP's greatest asset: knowing that, if shit hits the fan, management can write a check for $x,000,000 and a team of engineers will be on-site tomorrow to fix the effort.
Not having that is exactly what scares management about open source and/or startups.
This is also part of the enterprise startup system... an enterprise startup doesn't need to and probably shouldn't build a whole enterprise sales chain. They just need enough to get a handful of enterprise sales - enough to prove their value proposition is high enough that enterprises will put up with startup shortcomings in order to get that technology. Then, sell the company to a big player like IBM, Salesforce, Atlassian, etc, who just add it to their sales/support portfolio.
> The flip side, though, and this is awesome, is that you can work on really BIG things. Much bigger than any startup is tackling. That's fun.
But big in what sense ?Could you give some examples of these projects or comment on their nature if you can't talk exactly about the projects ?