May 10, 2019 at 12:00 am
Comments posted to this topic are about the item The Impediments to Change
May 10, 2019 at 5:59 am
Hi,
Nice article, we actually do have SA and in 90% of our servers are on 2016 and we are rolling out 2017 in the coming weeks, as soon as 2019 has a few CU underneath it we will move towards it.
So why only 90%? Simple really the vendor of a particular piece of software doesn't support it. This is made a bit more complex as the vendor will say "but if you take the upgrade of product A we will support 2017" then I have to try and convince the business to upgrade Product A which would be months of work. Its a battle where the version of SQL is held back by a slow adoption of vendor software.
Then we also kind of have to take upgrades where we can, our industry is heavily regulated and having out of support versions of SQL is a BIG no no unless you can say "well the vendor doesn't support it yet".
May 10, 2019 at 6:31 am
We have SA so licensing costs aren't the biggest issue - though the constantly shifting charging model, particularly on virtual hardware, makes doing thing like upgrading cores unnecessarily painful (you can't pay to just upgrade one server, for example, everything on the VM Host has to be licensed for every core the VM Host has!)
Testing of our internal code bases is by far one of the biggest time, and thus cost, sinks for us. It has got better over time, we did a 2000 -> 2005 migration that was very painful (at least in part to past developers having relied a lot on quirky assumptions) but our subsequent migration from 2005 -> 2017 has been a lot smoother.
Some things are still pain points though, we make very heavy use of Agent Jobs, including jobs that start other jobs, and the fact that the IDs change when you build a replacement server (in-place upgrades are rarely practical) means things need a lot of manual re-configuring. Having separate dev/test/live environments that we keep in step also triples the amount of work involved in things like this, which slows down the rate things can get done.
May 10, 2019 at 9:53 am
Housekeeping note: ArsTechnica’s survey is now closed.
May 10, 2019 at 12:08 pm
While there are surely many impediments to change, I think IT organizations really need to take responsibility for keeping up-to-date analysis of the other side of the coin, the potential risk and costs of NOT changing. If for no other reason, then protecting themselves from the 'Why didn't you tell us?' scenario. A record of all relevant situations needs to be maintained, updated, and regularly submitted to organizations reviewing those potential risks that are changing and growing over time. A historical perspective of regular analysis can be a strong motivation to making upgrades.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
May 10, 2019 at 1:17 pm
Some things are still pain points though, we make very heavy use of Agent Jobs, including jobs that start other jobs, and the fact that the IDs change when you build a replacement server (in-place upgrades are rarely practical) means things need a lot of manual re-configuring. Having separate dev/test/live environments that we keep in step also triples the amount of work involved in things like this, which slows down the rate things can get done.
ID's changing tells me that whatever you've coded isn't coded properly. That's a symptom of a problem. I would hope you'd be learning and adding new code over time that handles upgrades between servers. Unless I'm missing something here.
May 10, 2019 at 1:18 pm
While there are surely many impediments to change, I think IT organizations really need to take responsibility for keeping up-to-date analysis of the other side of the coin, the potential risk and costs of NOT changing. If for no other reason, then protecting themselves from the 'Why didn't you tell us?' scenario. A record of all relevant situations needs to be maintained, updated, and regularly submitted to organizations reviewing those potential risks that are changing and growing over time. A historical perspective of regular analysis can be a strong motivation to making upgrades.
Maintaining knowledge and docs across time is a hard thing for many organizations, especially in niche areas. A good idea, but a tough one to follow through on. It seems most humans want to reinvent their own wheel as often as possible.
May 10, 2019 at 3:44 pm
WOW, huge topic, Steve! The state agency I work for has a huge number of legacy systems. I'm on a team that's trying to replace some of these legacy systems, but it's very slow going. Staff knowledge is an issue. I don't know about other states, but it seems here there's been very little incentive ever to improve one's knowledge. I believe that's due to the huge inertia inherit around here. I mean, after all, why bother learning anything new when that 15 year old Microsoft Access app still works? And for a very long time management, so I understand (I've not been around long enough to know) hasn't wanted to improve anything. It's been more of a "stay the course" type of attitude.
However, I will say that I'm seeing positive changes. Right from the C-suite there's interest in Agile and DevOps. In fact my team is going to be spearheading the first software application using Scrum for project management. This is HUGE!!
Cost is still an issue. The DBAs (there's now two of them) are busy upgrading old SQL 2008 and 2012 systems to SQL 2016. However, some systems have to stay at older versions of SQL, due to the vendors' software. I wish some of these guys (the vendors) would upgrade their software's backend requirements!
We've looked at Azure, but at least for now are putting the cloud on the back burner. I know that there was a manager in the IT group that was looking at Azure Stack, which I think holds lots of promise for us. Being able to develop against a cloud architecture, and learn how to do that, while it's in-house I see as having lots of advantages. But now, other projects have pulled the guy away from that. I don't know what his other projects are, but I'm guessing its due to technical debt that's been accumulated over the years, which is now raising its ugly head and demanding attention.
So, putting it all into one sentence, I'd say the impediments I've identified are needing to change an long term attitudes towards adopting anything new, lack of knowledge, cost and a huge number of urgent demands pulling everyone away from moving forward.
Kindest Regards, Rod Connect with me on LinkedIn.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply