And frankly it does really depend on the company on which point is more valid.
At the end of the day, csmithuk viewpoint is a solution/enterprise architect's view point which caters more to the overall business needs of a company.
And based on my experience, the challenge of getting any new technology in a company that is mature and successful is really hard. The challenge of changing the status quo once that tech has become embedded in their business processes is twice has hard. There is always a benefit/cost ratio. The cost is not just development - it's training, its documentation, its lost time, etc.
>At the end of the day, csmithuk viewpoint is a solution/enterprise architect's view point which caters more to the overall business needs of a company.
Not really. I've worked as an Enterprise Architect and worked in good as well as bad architectures. If you engineer a system that backs the company into a corner of "we can never upgrade," then you're a crappy architect. Even more so if you can't hire someone to step in and maintain a project or have a drought of hardware suppliers.
>The challenge of changing the status quo once that tech has become embedded in their business processes is twice has hard.
Business process is not synonymous with "tech stack." If it becomes synonymous, you done fucked up.
>And based on my experience, the challenge of getting any new technology in a company that is mature and successful is really hard.
That's because some people do tech-for-tech's-sake. If you open the conversation with "hey, if we switch out IIS for nginx/apache, it will take 8 months, but we'll save money on maintenance and licenses, as well as spending less money on hardware," then you're in better shape than just pitching the new hotness. Of course, it's been my experience that these decisions are usually done on a whim in mature companies (hooray business!).
>There is always a benefit/cost ratio. The cost is not just development - it's training, its documentation, its lost time, etc.
Yes, of course. It's also cost of life management, staffing costs for niche/antiquated skills/getting developers willing to do long-term damage to their skills (imagine becoming an expert in coding for IE9 and lower, how do you think your resume will look in a few years?) for short-term profit.
Unfortunately most products built in the early 1990s-mid 2000s suffer from poor architecture. The growth of companies and the technology shift were impossible to anticipate. This is the unfortunate reality of all of those <IE7 dependencies you see. Also there was no foundational research done into how to build these things -- people were pissing in the dark with immature tech and knowledge. This is no longer true fortunately.
Unfortunately for the average corporate, the cost/benefit ratio only becomes an issue when the vendor pulls the rug out from underneath you. In this case when IE7 is EOL in 2017.
We're destined to follow the trailing edge because that is exactly where the best cost/benefit ratio lives. Do nothing is cheapest.
If you engineer a system that backs the company into a corner of "we can never upgrade," then you're a crappy architect.
Sometimes the we can never upgrade is part of the job description. A lot of control software for industrial systems is like that. You do not expect to be thinking about having to upgrade the core code for at least a few decades, as downtime for development and testing is obscenely expensive.
My usage of the word tech is with regards to systems in place that support business processes, so that includes the Excel Spreadsheet all the way up to the ERP system.
I'm sorry, it's hard to go to a company that has already invested in the Microsoft stack, have developers that work in that stack, have many internal and third party applications, have SharePoint all over the place, that run on ASP.NET (and hence IIS), already have sunk costs with SQL Server and Windows servers and make a strong case for changing over. The case might be easy for SQL Server (use PostgresSQL instead) but generally its a no go. I know you used this as an example, but like I said, a lot of it depends on the company.
And frankly it does really depend on the company on which point is more valid.
At the end of the day, csmithuk viewpoint is a solution/enterprise architect's view point which caters more to the overall business needs of a company.
And based on my experience, the challenge of getting any new technology in a company that is mature and successful is really hard. The challenge of changing the status quo once that tech has become embedded in their business processes is twice has hard. There is always a benefit/cost ratio. The cost is not just development - it's training, its documentation, its lost time, etc.