Question: Are the system you using open standards (e.g. RESTful APIs)? Do they have Data Models that follow some sort of sensible standard that allow for interop with other systems via sensible mechanism systems?
A lot of the hell that is enterprise software is how systems talk to each other. I'll give an example. Project is started to bring data from Vendor A Product into Product from Vendor B. Vendor A claims system is "open" but there is no documentation outside of some cryptic .NET examples. Even when a successful connection is made, the data and data model makes no sense and nearly impossible to map to what users see in UI.
Vendor A gets a call. Vendor A repeats "open" and brings an "SME" to explain data model. SME is really a Sales Engineer who concludes Vendor A has another product that will expose the data in usable way. Start evaluating this product, and it turns there is a lot overlap between features in Vendor A new product and Vendor B's product. Plus, you still need to use .NET and a proprietary connection to get data from A -> B. Plus,Vendor A's new product does data transformations in a black box..nobody knows what exactly.
Vendor A and B are pointing fingers and each trying to make a case for why their product needs to do X features. Nobody understands this .NET library, so a consulting company is used to build data pipeline from Vendor A -> B.
Granted, a lot of the above wouldn't be acceptable today and a lot of these types of systems are going away and being replaced by ones that are actually designed to be interoperable with other systems. This type of story is hopefully going away sooner than later.
I use a lot of proprietary systems in my current job at extra-big company, but at least they use stuff like SQL, RESTful APIs, etc. I can understand our Data and how it maps. Those are transferable skills.
I can only hope that FAANG isn't building systems where everything is proprietary and make no sense to anybody outside of the Eng team that built them.
A lot of the hell that is enterprise software is how systems talk to each other. I'll give an example. Project is started to bring data from Vendor A Product into Product from Vendor B. Vendor A claims system is "open" but there is no documentation outside of some cryptic .NET examples. Even when a successful connection is made, the data and data model makes no sense and nearly impossible to map to what users see in UI.
Vendor A gets a call. Vendor A repeats "open" and brings an "SME" to explain data model. SME is really a Sales Engineer who concludes Vendor A has another product that will expose the data in usable way. Start evaluating this product, and it turns there is a lot overlap between features in Vendor A new product and Vendor B's product. Plus, you still need to use .NET and a proprietary connection to get data from A -> B. Plus,Vendor A's new product does data transformations in a black box..nobody knows what exactly.
Vendor A and B are pointing fingers and each trying to make a case for why their product needs to do X features. Nobody understands this .NET library, so a consulting company is used to build data pipeline from Vendor A -> B.
Granted, a lot of the above wouldn't be acceptable today and a lot of these types of systems are going away and being replaced by ones that are actually designed to be interoperable with other systems. This type of story is hopefully going away sooner than later.
I use a lot of proprietary systems in my current job at extra-big company, but at least they use stuff like SQL, RESTful APIs, etc. I can understand our Data and how it maps. Those are transferable skills.
I can only hope that FAANG isn't building systems where everything is proprietary and make no sense to anybody outside of the Eng team that built them.