Consulting for a Small Construction Company
-
@Carnival-Boy said in Consulting for a Small Construction Company:
"The solution you want, which is perfect for your needs, uses slightly out-dated technology, therefore please choose a different, inferior and more expensive solution"
Isn't that putting IT needs before business needs?
The two should be one and the same. And "slightly" outdated is totally missing the point. This is technology that was ridiculous to have been making since the late 1990s. Two decades of not bringing it up to date means that there is incredible business risk involved (based on averages.) This suggests that either we have unmaintaned code, a company that actively doesn't care about the needs of their clients or, most of the time, a company selling an old product that no longer has developers and they can't fix it if they need to.
You are making a wild assumption that this is superior or cheaper than modern, well made, supported software. I've never once seen that be true in a situation like this. What I've pointed out above is that companies that say that there is no other option (especially companies is super standard industries like this) is that they didn't look for options and just chose one bad one.
-
@Carnival-Boy said in Consulting for a Small Construction Company:
A client-server solution isn't necessarily crap, or insecure.
The architecture is inherently crappy and less secure than alternatives, though. Can it be made secure, yes, but it takes more work and can't get as good. But can it not be crappy? not really.
-
@Carnival-Boy said in Consulting for a Small Construction Company:
The immediate slagging off of any business that might consider buying a client-server solution is just hysterical.
You've totally missed the point being that they didn't check to see if better options existed, they are blowing off IT advice by making up obvious falsehoods to support their not being willing to look to see if better options exist.
-
What that part of the discussion would come down to, and if we want to discuss many would ask for a separate thread which is fine, is whether he should consult and give advice, or if he should just implement anything that the business asks for even if it is harmful.
There is a thread on this on SW right this moment where people are discussing what to do when the business demands RAID 0 for critical data. Do you just do it because they told you to? Do you refuse? Do you recommend something else and explain why?
-
Why is it less secure? What are the security risks?
-
@Carnival-Boy said in Consulting for a Small Construction Company:
Why is it less secure? What are the security risks?
It's not huge, you can secure it decently well. But the risk comes from the multiple connection points requiring the database to be more expose. And the much bigger risk is that it requires the database to be doing all of the security work, which databases are not designed to do and not good at, such as ensuring authentication, cleaning the data, etc. Having an application layer in front of the database that is server side provides a massive amount of security potential, including an air gap potential between incoming data and what hits the database.
Firewalls help, but only a little, for client server.
-
@scottalanmiller said in Consulting for a Small Construction Company:
And the much bigger risk is that it requires the database to be doing all of the security work, which databases are not designed to do and not good at,
What do you mean "not designed to do"? Security used by, say, SQL Server, seems pretty integral to the product? I've never heard of any risk arising from SQL Server security? What kind of risk is there? If anything, I'd have less confidence in the security provided by a small software house writing bespoke, industry specific applications, than the security provided by Microsoft's SQL Server developers. Is that wrong?
-
@Carnival-Boy said in Consulting for a Small Construction Company:
What do you mean "not designed to do"? Security used by, say, SQL Server, seems pretty integral to the product?
It's a tack on and very, very limited compared to what an application does. To do anything much, you have to start moving your application code into the database itself, which has been considered very problematic and a horrible design choice since databases were first invented.
You can do some, and you should have some security at the database, but the hefty, high level (meaning lots of knowledge of the data) should be in a front end application.
-
@Carnival-Boy said in Consulting for a Small Construction Company:
I've never heard of any risk arising from SQL Server security? What kind of risk is there?
It's actually pretty common. It's not SQL Server's fault in any way. It's just that it doesn't have the tools to really clean or validate the data. Things like SQL Injection attacks are the most common and can affect either kind of application (C/S or N Tier) but the later has way better potential for tools to combat it.
-
I should point out that in the vast majority of these cases don't use tools like SQL Server. The nature of places using ancient designs like C/S almost universally also use really crappy database products.
-
@Carnival-Boy said in Consulting for a Small Construction Company:
If anything, I'd have less confidence in the security provided by a small software house writing bespoke, industry specific applications, than the security provided by Microsoft's SQL Server developers. Is that wrong?
The idea is correct. But remember that the SQL Server level security would remain (and be far more likely to exist in the first place) in non-C/S applications. And in both cases, the security is all implemented by those bad programmers in either case.
But the C/S system brings endemic risks such as:
- Makes the software likely to be ancient and lack modern security measures.
- Makes the software and the software that it depends on likely to be unmaintained or poorly maintained.
- Almost universally means that the developers are not competent, even to the point of knowing how to start a basic, generic project, and are not prepared to secure their systems.
So your fear of the application people being the bad programmers is very real, but is amplified by the C/S design either as the cause or, more often, the result.
-
That feels like an ad hominen attack on client-server architecture. "People who maintain client-server applications are bad, ergo client-server is bad". We know nothing about the providers in this case or what their level of competence is.
-
But I would definitely say two things that I think are big factors and build on the thought processes that you've had:
- Software that is modern and/or designed well has the best chance of being currently maintained, and being build well. It's not likely at all that software would be fundamentally poorly designed and then coded well. That software uses a modern design certainly does not imply that it is well made. But at least it gives a realistic chance of being so.
- Using non-industry specific software is very often the best way to go. It's actually pretty rare that software unique to the industry is very useful. Companies kind of imagine this, in many cases, and ignore standard options from big names (like MS themselves) that might do the job just as well but have tons of support and security. And often a fraction of the cost.
-
@scottalanmiller said in Consulting for a Small Construction Company:
Using non-industry specific software is very often the best way to go. It's actually pretty rare that software unique to the industry is very useful. Companies kind of imagine this, in many cases, and ignore standard options from big names (like MS themselves) that might do the job just as well but have tons of support and security. And often a fraction of the cost.
Sometimes. As a general rule, I'd say 80% of your company should be run as a vanilla company (and hence use vanilla software), and 20% should be bespoke/unique. The 80% that is vanilla keeps costs down and efficiency up, and the 20% that is unique provides your competitive advantage.
Identifying which is which is the tricky part, and a large part of my job. Is this unique process/workflow used because it provides a true competitive advantage ("our customers choose us because none of our competitors offer this service"), or is it because "we've always done it like this" and offers no value? In my experience, it's normally the latter, but sometimes the former.
Without more info, I'm not going to jump to the conclusion that AJ's clients are simply idiots.
-
@Carnival-Boy said in Consulting for a Small Construction Company:
Without more info, I'm not going to jump to the conclusion that AJ's clients are simply idiots.
It's the reaction, not the choice, that I'm primarily concerned about. I see it constantly, businesses that make a choice without engaging IT, IT questions it and they provide a flimsy, almost surely false, excuse as to why neither they nor IT are to question a seemingly odd decision. Can there be a case where a C/S application is actually the only and/or best choice and their needs are very specific and this provides competitive advantage? Sure. It is likely? Not at all. If it were true, would they be in an industry where no one else has this problem and/or give such a flimsy reason for it? Almost certainly not.
-
I've worked with a few small'ish industry businesses (alcohol distributors and HVAC distributors) They both used a product produced by a vendor inside those industries as their 20% uniqueness - both packages are just horrible from a design/support perspective, both required local admin and damn near impossible to make run as a non admin.
These software packages are so unique though, that I don't know if a third party software solution would really work for them, without going to extreme lengths to import the data from each vendor, then create the interdependence between components as the current solution provides.
It's frustrating to look at what some of these places have to deal with.
-
@scottalanmiller said in Consulting for a Small Construction Company:
@Carnival-Boy said in Consulting for a Small Construction Company:
A client-server solution isn't necessarily crap, or insecure.
The architecture is inherently crappy and less secure than alternatives, though. Can it be made secure, yes, but it takes more work and can't get as good. But can it not be crappy? not really.
You say this, but I am sure that you realize most of the internet upon which we spend our time is written in a client-server architecture?
Our web Browsers request/send information from a web server. Our chat clients send/request information to/from a chat server... When you add a database into the mix, the web server becomes a database client, and requests info from and sends info to the database server...
Even in the case of an API type setup, there's a client and server somewhere in the mix.
What makes it so crappy? Do you have any ideas of better ways to do it?
-
@Dashrender said in Consulting for a Small Construction Company:
I've worked with a few small'ish industry businesses (alcohol distributors and HVAC distributors) They both used a product produced by a vendor inside those industries as their 20% uniqueness - both packages are just horrible from a design/support perspective, both required local admin and damn near impossible to make run as a non admin.
These software packages are so unique though, that I don't know if a third party software solution would really work for them, without going to extreme lengths to import the data from each vendor, then create the interdependence between components as the current solution provides.
It's frustrating to look at what some of these places have to deal with.
Just because the package is unique does not mean that it is useful, though. I've never heard anyone claim "competitive advantage" or "improved efficiency" or "improved profits" only ever "uniqueness" which is what people would say when they need a reason but don't have one for why they chose it. Uniqueness alone isn't an advantage.
-
@dafyre said in Consulting for a Small Construction Company:
You say this, but I am sure that you realize most of the internet upon which we spend our time is written in a client-server architecture?
No, it's not
-
@dafyre said in Consulting for a Small Construction Company:
Our web Browsers request/send information from a web server.
That's not what a client/server architecture is, though.
