3 ms·

While I agree with most of the sentiment, it should be noted most companies don’t ‘hyper-focus’ specialization like that. There are always going to be interact

While I agree with most of the sentiment, it should be noted most companies don’t ‘hyper-focus’ specialization like that. There are always going to be interacting systems and having knowledge of other systems only helps your job performance. When scoping for a client, there are many legal concerns at play. The scope, handed from the client, cannot be too specific technically. The concern is, if the systems change(due to firm changes, etc...) or one part of the implemented functionality is turned off (typically a free, or exit fee cost) certain technical verbiage would require contract arbitration and renegotiation. Maintaince fees are different. Most firms are paid significantly for the software produced, if they employees are not paid a proportionate amount, that’s the firms problem not the client. Unreasonable internal scopes are different then client scopes. You just emphasized you worked in a client facing business, I thought it was an interesting topic to discuss.

apohn 7y ago
>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.

apohn 7y ago

>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.