I’m going to diverge ever so briefly from my “Reversed Assumptions” posts to share some happenings in this current engagement I’m on and to tie in some of the previous posts on design and architecture. This post focuses on what architecture is and what it isn’t. As I have engaged with many different sizes of customers over the years, one thing remains true: architects and architecture are many things to many people. There has been a lot of talk and debate on this, and I thought it necessary to be sure about what architecture truly is, and who is qualified to practice it.
Articles Tagged with Architecture
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.
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.