{"id":2929,"date":"2019-09-25T17:02:00","date_gmt":"2019-09-25T21:02:00","guid":{"rendered":"http:\/\/www.soul-repairs.com\/blog\/?p=2929"},"modified":"2019-09-25T17:02:00","modified_gmt":"2019-09-25T21:02:00","slug":"push-button-technology","status":"publish","type":"post","link":"https:\/\/soul-repairs.com\/blog\/2019\/09\/25\/push-button-technology\/","title":{"rendered":"Push Button Technology"},"content":{"rendered":"

There is a dream that lives in IT – it is the dream of the easy button<\/a>. Push one button (or even a couple of buttons, we’re flexible!) and get immediate value. Everyone wants these easy buttons, and every software sales company wants to sell<\/em> these easy buttons.<\/p>\n

<\/p>\n

For platforms and infrastructure, we want a CaaS, Paas, IaaS, or just XaaS – a thing, as a service, ideally an easy to use<\/em> service. For business requirements and questions, we want clear direction backed by clear analysis, ideally without needing to do that analysis ourselves via painstakingly framed questions. For the processes that surround IT, we want “straight-through processing” – processing that doesn’t hurt our brains. and can actually be completed.<\/p>\n

As architects, we sometimes call these “zero pain architecture upgrades.” You don’t have users (developers, in the case of architecture) complaining about the new platform, library, or architecture pattern – because adoption is so easy, and so on-point, and it so effectively solves a pain that’s been bothering them for a long long time,<\/em> that any “transitioning to new technology things” pain is vastly outweighed by the benefits and the ease of use.<\/p>\n

\n

These magical, unicorn-esque pieces of technology result in near-instant improvement without<\/em> net adoption pain.<\/p>\n<\/blockquote>\n

Some Examples of this Magical Unicorn Tech<\/h2>\n

Kubernetes<\/h3>\n

A fundamental principle for how Kubernetes works is that it describes the desired state of how containers should run. That means that, ideally, people think about how the containers should run, they codify that in a way that Kubernetes understands – and then they can set it and forget it.<\/p>\n

OpenShift<\/h3>\n

A big part of OpenShift’s magic in this area is something we call “opinionated reasonable defaults” (S2I as a method of taking a binary + an image to make a running container, the oc new app<\/a> command, projects, etc) for Kubernetes configuration. People don’t have to work so hard to set up K8s – or even know as much about it, thanks in part to the UI.<\/p>\n

Operators<\/h3>\n

Operators<\/a> take K8s and OpenShift even further down the path of the Easy Button – they take operational knowledge (knowledge necessary to make a\u00a0thing<\/em> do a task<\/em>) and they codify it – again, like K8s, watching for a desired state and correcting when the thing<\/em> drifts from that state.<\/p>\n

Automation – Jenkins, Ansible, etc<\/h3>\n

You know what’s awful? Doing the same boring task\u00a0over and over<\/em>. You know what’s worse? Accidentally doing that same boring task incorrectly once because you’re a person and not a machine. You know what’s great? A consistent platform on which to make the robots do that work for you.<\/p>\n

Cool! Gimme<\/em>.<\/h2>\n

Sadly, it isn’t quite that simple.<\/p>\n

We’ve definitely seen this happen, where the technology itself is really good and as a result has the potential<\/em> to just…solve pain. But…we’ve also seen a ton\u00a0of great technology that could<\/em> do this, but doesn’t<\/em>. Pain resolution in IT is our jam, so we tried to figure out why some technology with this potential lives up to it and some doesn’t – and why even the same<\/em> technology can have this effect in one company but not another.<\/p>\n

The conclusion we ultimately got to was that the technology itself is not enough<\/strong>. Unfortunately<\/em>.<\/p>\n

It’s a lot like watching infomercials for workout programs – you can watch the infomercial over and over, and probably that program is amazing, but you aren’t going to get ripped just by watching the infomercial – or even by just ordering<\/em> the workout program. You have to actually do<\/em> it, with intention and dedicated resources.<\/p>\n

Basically…there’s more to technology than writing a check, or even installing it. Even amazing technology requires processes that enable it, and support from people. Good technical tricks don’t mean anything without people behind them, because…ultimately people have to interact with technology – so it has to be implemented in ways that make both the technology and<\/em> the people successful.<\/p>\n

Push button technology is the combination of great technology<\/strong>, successful human interactions<\/strong> with that technology, and the processes<\/strong> that enable that technology.<\/p><\/blockquote>\n

Amazing Teams Deliver Push-Button Technology<\/h2>\n

The best way to do this, to get to the magical Easy Button place of amazing technology + the support it needs + the enablement of process it needs is…amazing teams<\/em>. Teams who think about people, and how people do work – and how they\u00a0want<\/em> to do work. Teams who think about how people are likely to want to interact with the technology, and what interruption it might give to their existing processes. Teams who can communicate, and support, and hold accountable.<\/p>\n

The Next Step for Easy Button Technology<\/h2>\n

When starting your journey to implement an innovative, pain-solving technology, make sure you wrap that journey in a team that understands people, communication, and process – as well as technology<\/strong>. Nail those, and you’ll solve your company’s pain points and roll out a successful new tool to solve business problems.<\/p>\n","protected":false},"excerpt":{"rendered":"

There is a dream that lives in IT – it is the dream of the easy button. Push one button (or even a couple of buttons, we’re flexible!) and get immediate value. Everyone wants these easy buttons, and every software sales company wants to sell these easy buttons.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"nf_dc_page":"","_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[41,4],"tags":[46,87,44,109,93,159],"wf_post_folders":[],"coauthors":[11,26],"class_list":["post-2929","post","type-post","status-publish","format-standard","hentry","category-processes","category-technology","tag-jenkins","tag-kubernetes","tag-openshift","tag-pain","tag-spring-boot","tag-xaas"],"_links":{"self":[{"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/posts\/2929","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/comments?post=2929"}],"version-history":[{"count":9,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/posts\/2929\/revisions"}],"predecessor-version":[{"id":3064,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/posts\/2929\/revisions\/3064"}],"wp:attachment":[{"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/media?parent=2929"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/categories?post=2929"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/tags?post=2929"},{"taxonomy":"wf_post_folders","embeddable":true,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/wf_post_folders?post=2929"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/soul-repairs.com\/blog\/wp-json\/wp\/v2\/coauthors?post=2929"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}