The Challenge of New Platforms

  • Comments posted to this topic are about the item The Challenge of New Platforms

  • Hearding cats is easy compared to managing application development.

    Computing has to deal with constant change: business requirements, priorities, costs, budget, available hardware and software, skills, etc. The applications that get developed are like photographs - they capture one specific state of play but the action continues and changes.  The code that gets developed is also akin to a sculptor carving a statue - expensive to produce, esoteric, and with a result that is fixed in time.

    If we in computing were building bridges or skyscrapers these things would be essential, but in our industry they are like millstones around our knecks. One major result is a constant desire to find faster cheaper flexible ways of doing our stuff which drives a constant flow of new software and methodologies into the market place. Even though we know most of it must be snake oil, each person hopes that the bit they grab hold of is a magic bullet that overcomes the contradictions that are inherent in software development.

    Within computing, an architect should be looking at how the business can be supported this year, next year, and every year for the next 10 years. Their assets include fungible people and liabilities include non-fungible domain knowledge.

    From an individual's viewpoint, their employer is fungible while their skills are non-fungible. The skills walk out the office door every evening and sometimes get funged to a different employer by the time morning arrives.

    A good architect will want to keep the product-specific skills needed by the business within the set of frequently-found skills present within the group of potential employees. This mandates change over the medium term (3-5 years), even though the direction of that change is difficult to discern at the start of that term.

    Skills that are currently common in both businesses and people will change only slowly, but will migrate to updated versions of software.  Esoteric skills are likely to change quickly, potentially becoming either common or extinct.  A good architect needs to allow some controlled experimentation in new techniques that could benefit the business.  However even useful new techniques may need to be dumped if they are not being picked up elsewhere.  It is a bad architect who allows the business to become dependant on a collection of esoteric skills known only the the current/previous set of employees.

    My view is to keep mainstream and keep current. Be willing to check out anything new that could be of real use but only adopt it if it gains widespread use.  If the business managers insist on maintaining esoteric business knowledge then make sure they realise the application development needed to support this is going to remain expensive.

    Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.

    When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara

  • Once in my career I switched commpanies and started an IT operation totally using IBM systems and a new language, then two years later guided the decision to change the company IT structure entirely from IBM to Burroughs (now Unisys).  This changed the operating system, networking, introduced end-user terminals for the first time, and required a fair amount of code changes to interactive programs for data entry for the new compilers.  While keeping the 24-hour operation running we traveled to a regional data center at night to learn the new systems and do the code modifications.   All went well and it turned out to be a very good thing for the company to allow growth in IT infrastructre.   Later on in this same place I moved the whole IT operation entirely from one programming language to another and introduced the first database usage for them.

    Another time I made a job change which required learning and adapting to two new programming languages and a new database system at the same time while supporting early custom graphic design software on a completely different operating system.

    And a third time I switched jobs again to become a DBA and SQL developer running on my first Windows environment and SQL Server.

    Over 42 years I was employed in IT eight different companies of very different sizes and business types, from manufacturing, banking, food and supply warehousing and distribution.  I realize now that I never really gave the whole thing much consideration at the time.  It was simply part of developing a career.

    • This reply was modified 2 weeks ago by  skeleton567. Reason: spelling
    • This reply was modified 2 weeks ago by  skeleton567.

    Rick
    Disaster Recovery = Backup ( Backup ( Your Backup ) )

  • Reasons against adding new DB platforms (you mentioned many of these):

    * More skillsets to support

    * More systems to patch, upgrade, generally keep running

    * Chasing the current fad.  The experts love it now, but will it really catch on?

    * Application and data sprawl, redundant storage of similar data

    * Cost.  It is almost always cheaper to make an existing instance larger than it is to add another DB system.

    So generally I'm skeptical when someone wants to start a new DB platform.  However, some reasons for adding new platforms:

    * Need to continually experiment.  SQL Server is great, but maybe the new thing really is much better for certain scenarios.

    * Agility.  Moving a large database estate to a new platform (for example, cloud) is much easier if you can do it in small chunks.

    * Performance.  Separation of data means no resource contention, ability to tune independently.

    I'm more in the "don't do it" camp.

  • I am as well. I'm open to new platforms, but not just because someone had experience and likes it. Or thinks it would be better. We need some sort of PoC that shows significant reasons to require a new skillset from our staff (or future staff)

  • Amen Steve

     

  • Amen, Steve.

     

  • EdVassie wrote:

    If we in computing were building bridges or skyscrapers these things would be essential, but in our industry they are like millstones around our knecks.

    Didn't expect the K there.

    Trying to figure out the world of SQL as marketing consultant for SQL Solutions Group https://sqlsolutionsgroup.com/

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply