Disruption and Reuse
It is my contention that 90% of costs are being eliminated from the traditional software development process and the time to market reduced dramatically by leveraging the reuse capable today via open source, APIs, fast deployment and resource sharing with PaaS. The cost of Enterprise Software was magnified by an order of magnitude by the lack of reuse prevalent in the old paradigm of software development. This is apparent as we see how fast we are able to build technology today. This is a major reason for the massive adoption of disruptive technologies of open source and APIs we see today.
Accelerating Pace of Change,
Faster Time to Market,
Internet of Things,
open source community,
open source software,
What is software development like today?
A complaint I heard from a CIO recently was that when talking to the high flying technologists at his firm he said: "they talked in strange names, Kafka this, docker that. Names of open source projects, APIs and languages that make him wonder if these people can program or just piece together technology and names? It's very easy to toss around a lot of names and convince somebody you know what you are talking about, but the real question: If you assume that you can do things like this; Is this the way we should be building software these days? Talk to developers today and a lot are doing something different than what we did just a few years ago. Today developers may use languages such as Ruby or Scala, PHP or Clojure or combinations of these things in a single project, they may use google APIs and back end as a service APIs, Salesforce APIs and APIs for doing pattern discovery, blob storage. They may use Storm or Kafka, App Factory, CEP, Stratos, docker, node.js or cassandra or an open source Identity Management. They may develop on IntelliJ or CodeEnvy in the cloud. They may build their technology with dependency injection, aspect oriented techniques, test using Chaos Monkey, appium and numerous other web services that in general allow them to have very high productivity. It is very likely they will complain bitterly if you don't have Git, Maven or Jenkins, Chef or Puppet and numerous other open source tools for them to use that they are familiar with. It's a new world that has evolved very rapidly. This cacophony of names is scary for some. I love this diagram that Kinvey came up with some time ago that illustrates some of the complexity of just the APIs for backend as a service in the new paradigm: