The title of this article is “In the Hybrid Cloud, Your Role Matters, but…,” and there is a big “but” there. How you use your role is what really matters. Whether you are a cloud, virtualization, or container administrator, evangelist, or architect, how you use your role makes or breaks the secure hybrid cloud. We have written a lot about technology, but it’s the people who really make the technology a win for the business. It is the processes you develop that make the difference. It is the roles you entrench that can hurt your prospects. So, how do we eliminate the “but”?
Articles Tagged with Architecture
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.
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.