>While I agree with most of the sentiment, it should be noted most companies don’t ‘hyper-focus’ specialization like that. There are a lot of on-premise softwa

>While I agree with most of the sentiment, it should be noted most companies don’t ‘hyper-focus’ specialization like that. There are a lot of on-premise software vendors who are exactly like this. The consulting group exists to deploy, configure, and customize their software. While the consultants may connect and integrate with other systems, it's just a bad idea to start configuring systems from other vendors. For example, the software we (the company I worked for) sold could pull data from MS SQL. One of our customers had a product from another vendor that stored real-time data in an MS SQL server. Except, it was stored in a funky table structure and the SQL server was installed as part of that product install. It wasn't a standalone SQL server the client installed separately. The customer asked us to pull data in real-time from that server. After about a day of digging, it was clear the other vendor never intended for data to be pulled from this database and I had a ton of concerns about locks and lost data. So I said they needed to talk to the other vendor about this. As soon as I said "data loss" my management agreed with the decision to not mess with that database. I could certainly talk about our system and what we were trying to do with the other vendor, but we wouldn't touch that SQL server unless they said do. Consultants at Mulesoft, Talend, and even Cloudera are going to do the same thing. They may pull data from other databases, but the sensible consultants aren't going to start making big changes to a customer's MS SQL server, even if the consultant is highly experienced with that database.