One of the things I find very peculiar is the tendency of companies to hide their documentation. Sometimes the documentation is available only to existing customers, behind a login on the support site. At other times, the only documentation is the online help. Often the only things available to prospective customers are a few shiny marketing documents and maybe an equally shiny case study. At the same time, we hear that 67% of the buying process happens before talking to salespeople. Personally, I find that the technical implementation guide gives me a better understanding of a product than a lot of marketing slides. I also like to read a few support documents to get an idea of what issues I might face if I deploy a product.
When I was a small child, I used to enjoy watching a Japanese language program. Called Monkey, it was all about a disruptive monkey with a massive ego. The monkey was turned into immortal being that could shrink and grow and travel on a flying cloud. Punished by the heavens for its transgressions, it was traveling with a Buddhist monk called Tripitaka on a journey to recover holy scriptures. The program also included a water monster, a pig, and a dragon who was shaped like a horse. It was a thing of its time, and you need to have watched to understand. By now, you most likely think that I have finally snapped, but this rather oblique journey somehow got me thinking about IT architecture and the ability to scale.
I wrote a couple of articles many years back about building an agile and flexible enterprise using a set of models, principles, and design rules that address the need to maximize financial return, improve performance, minimize risk, and enhance business agility. I want to revisit the premise of that article and view it through the lens of DevOps.
We live in interesting times. If I were to chart the increase in the number of customers asking for help with DevOps, that chart would look like a hockey stick, that same kind of hockey stick our CFOs are always dreaming of. If I added another line on the chart for the percentage of those companies that actually knew what DevOps was, it would be a flat line at the lower coordinates of the chart. What we are seeing is that everyone wants DevOps, but not everyone knows why or exactly what DevOps means. Continue reading The Value of DevOps in the Enterprise
Does this scenario sound familiar? A sprint team delivers another release on time and on budget. It boasts about how much its velocity has improved and how many story points it was able to cram into a two or four-week sprint. It shows its business partners a bunch of nice, pretty charts that illustrate how it is cranking out software and how agile the organization has become. The business partner is not impressed, however. Her competitors are crushing her by getting more rich features out each month. The competing products seem able to adapt on the fly and quickly address new requests from customers. The business partner asks the team to call out the major features delivered in the last release. Continue reading Agile Requires Architecture, Not Methodologies
There is an old saying, “the definition of insanity is to repeat the same thing over and over and expect a different result.” The way many enterprises are approaching the cloud, insanity would be a great way of classifying it. When we look across most enterprises, we see a collection of technologies from every era of computing. We have just about every vendor solution imaginable—often multiple versions of products from the same vendor—and a hodgepodge of architectures that makes spaghetti look organized.