{"id":3583,"date":"2015-05-19T07:23:36","date_gmt":"2015-05-19T14:23:36","guid":{"rendered":"http:\/\/www.bryanfriedman.com\/?p=3583"},"modified":"2015-05-19T02:05:56","modified_gmt":"2015-05-19T09:05:56","slug":"5-things-id-tell-my-enterprise-it-self","status":"publish","type":"post","link":"https:\/\/archive.bryanfriedman.me\/cloudingup\/2015\/05\/19\/5-things-id-tell-my-enterprise-it-self\/","title":{"rendered":"5 Things I’d Tell My Enterprise IT Self"},"content":{"rendered":"

It was exactly one year ago today that I became a\u00a0Product Owner<\/a> (n\u00e9e Manager) at CenturyLink Cloud, and as a colleague of mine likes to point out, that’s a really long time in “cloud years.” As I reflect back on the experience I’ve had so far, it feels good to know that the me of today knows a whole lot more than the me of one year ago. Just as a college student wishes he could go back in time and educate his high school self, I now find myself thinking about the helpful things I could share with my enterprise IT self<\/a> and all my former colleagues. So with that BuzzFeed-esque premise, here are some things I’d let the trapped-in-IT-purgatory version of myself know about how life could<\/i> be.<\/p>\n

You Don’t Know The Cloud<\/h4>\n

Everyone I worked with in IT used to talk about “the cloud” as if they knew what it was and had used it on various projects. Sure, there were plenty of times that a vendor would\u00a0sell services\u00a0branded<\/em>\u00a0as “cloud” to attach some buzz to what was really more analogous to a traditional application service provider or legacy hosting model. In reality, almost nobody in IT actually understood or took advantage of cloud for any practical purpose. \"\"<\/p>\n

My favorite definition to use now<\/i> when describing the cloud is Dave Nielsen’s O.S.S.M. acronym<\/a>: on-demand, self-service, scalable, measurable. Before, all the cloud really was\u00a0to me was a series of “as-a-Services” \u2014 Infrastructure-as-a-Service (Iaas), Platform-as-a-Service (PaaS), Software-as-a-Service (SaaS) \u2014 and we seemed most comfortable with SaaS (a familiar story<\/a> for many enterprises). I complained plenty about how long it took to get a server stood up and I thought the move the company was making to colocation might begin\u00a0to solve things. I didn’t\u00a0recognize how much IaaS would have helped with that, or even more how the power of PaaS may have eliminated that need altogether.<\/p>\n

The barriers for entry to the cloud were the usual ones \u2014 security concerns about data not being on premise, the question of whether our regulated\/qualified systems could live on cloud, some perceived lack of control \u2014 I’ve heard them all by now. Except they aren’t barriers, they are just challenges<\/a>. Tides are turning and enterprises are embracing cloud<\/a>, from public to private to hybrid cloud<\/a> as well. It’s exciting to be working at a cloud company right now.<\/p>\n

Lesson:<\/strong> Have your IT organization seriously explore a cloud migration. Consider PaaS along with IaaS. Hybrid cloud may also be the way to go. Don’t be discouraged by the challenges \u2014 there are ways to work through them<\/a>.<\/p>\n

Your Project Management Methodology Is Broken<\/h4>\n

Most of the projects I worked on in my former life lasted more than a year and yielded little to no value for the business. By the time the original requirements were being delivered, they had already changed and probably weren’t even\u00a0right in the first place. The project methodology we\u00a0used, RUP (Rational Unified Process), was supposed to handle this problem with iterations. In practice though, this was mostly lip service as the project invariably fell to using\u00a0a more traditional Waterfall method.<\/p>\n

On the team I work on now, we use Agile. There is a wealth of information to be found elsewhere online about what Agile methodology is<\/a> and how it was born<\/a>. There are many forms of Agile such as Scrum or eXtreme Programming to name just two. One of the key elements of Agile is its flexibility in allowing for rapid\u00a0respond to change. It’s about shorter development cycles (called “sprints”) and it encourages early delivery and continuous improvement. We do 21-day sprints, though some teams have even shorter iterations (1-2 weeks) depending on what makes sense for a given product. Each sprint is focused on the progressive refinement of new features \u2014 delivering some level of value with each release, starting with the \"mvp\" Minimum Viable Product (MVP)<\/a>. This creates a constant feedback loop and allows the team to fail fast and course-correct quickly as needed. Every morning there is a “standup” meeting where the whole team stands up and talks about what they are working on. At the end of each cycle we have a retrospective to discuss what went well, what didn’t, and what actions we can take to improve the process.<\/p>\n

I can already hear some former colleagues pooh-poohing these ideas with utterances of “that doesn’t\u00a0work in a big enterprise environment” or “what about documentation and compliance?” or “it won’t fly\u00a0with the way we do budgeting.”\u00a0Not true. It can<\/em> work.<\/a>\u00a0One of our engineering leaders likes to say something like, “This is the best way we know how to develop software today. If we find\u00a0a better way tomorrow, we’ll do it that way instead.” Find a better way and make it work for you.<\/p>\n

Lesson:<\/strong> Use Agile. Forget about “services” and “projects” and build products<\/strong>. Fail fast. Ensure feedback loops. Embrace change!<\/p>\n

(It should be noted that some things I’ve read \u2014 mostly by IBM, the purveyor of RUP \u2014 are quick to point out that RUP is a framework while Agile is a software development process<\/a>, that RUP and Agile can co-exist<\/a>, or that RUP could even be considered Agile<\/a> (because it uses iterations). All I can add to the conversation is that this has not been my experience and I have seen more success by taking a truly Agile approach. Your mileage may vary.)<\/p>\n

Learn About DevOps and Spread the Word<\/h4>\n

For a few months at my old company, I was on a small team tasked with\u00a0delivering SharePoint. It started out experimentally and wasn’t widely used so we were able to fly under the radar a bit and follow our own processes. We did pair programming, frequent releases, progressive refinement, and just the right amount of documentation. Looking back now, we were exhibiting certain Agile characteristics without even knowing it. On top of that, we were responsible for both building and<\/em> running the whole stack and we embraced automation wherever possible. (I have fond memories of “Redeployer” \u2014 our ASCII-art-infused command line tool.) At the time, I’d never heard of DevOps, but I now know that these are some of the key characteristics of DevOps organizations.<\/p>\n

One of my first assignments in my new job was to read The Phoenix Project\u00a0<\/i>and it was a completely eye-opening experience. It’s a great way to be introduced to DevOps if you’re unfamiliar with it, as is Richard Seroter’s Pluralsight course, DevOps: The Big Picture<\/a>. Just like with Agile, the resources you can find online about DevOps are endless and will all do a better job defining it than I could. \"devops\"Sticking with the theme of four letter acronym definitions, John Willis coined C.A.M.S.<\/a> to describe DevOps: culture, automation, measurement, sharing. In a way, it’s kind of an extension of Agile<\/a> for the Operations world…but it’s really more than that. To me, it’s about the idea that everyone is on the same team, working together towards a common goal. No more “us vs. them” mentality.<\/p>\n

Unfortunately, our small, Agile-ish, DevOps-ish SharePoint team did not last long. It got sucked into the enterprise IT vortex never to be productive again. For an organization to truly adopt DevOps it must completely change the way it thinks, starting at the top with upper-level management and cascading all the way down to the boots on the ground.\u00a0There’s no tool for doing DevOps, but there are DevOps-y tools that have gained popularity like Chef<\/a> (infrastructure as code), Docker<\/a> (containers), and a\u00a0bevy of continuous integration (CI)\u00a0tools<\/a>.<\/p>\n

Lesson:<\/strong>\u00a0You probably can’t change your organization to magically embrace\u00a0DevOps, but you should at least\u00a0try to adopt whatever DevOps principles you can within your own team…and maybe you should slip a copy of The Phoenix Project<\/em> under the door of every executive at the company\u00a0and hope they\u00a0get the DevOps bug.<\/p>\n

There Is Database Life Outside Of SQL<\/h4>\n

One of my favorite computer science courses in college was the relational databases class. Throughout my career in IT, particularly during my days supporting the Finance organization, no skill served me better than my knack for writing complex SQL queries. So the first time I heard about “NoSQL” databases, my brain wasn’t ready to comprehend what that meant. Nobody I worked with was ready either. Every application I worked with in enterprise IT had an RDBMS backend. The only “choice” was whether to use SQL Server or Oracle.<\/p>\n

I realize this is still largely the case for many organizations. I see plenty of customers now looking for ways to put their critical relational database workloads on the cloud. Still, NoSQL and Big Data are some of the biggest buzz words around, and while enterprises have been relatively slow to adopt them, this could be the year<\/a> they really start to pick up. Admittedly, my experience with NoSQL databases is still relatively\u00a0limited, but becoming\u00a0familiar with some of the different types\u00a0(like key-value stores or document stores) and many\u00a0of the primary use cases (distributed, horizontal scalability, extremely large data volume, schemaless data structures) has me thinking about data storage\u00a0in a way I never used to.<\/p>\n

Lesson:<\/strong> Relational databases are not the only game in town. Sometimes a relational database is the right answer, but sometimes it isn’t. Look for the right situation to consider one of the many NoSQL alternatives that are available<\/a>. (Shameless Plug: Check out CenturyLink’s recent acquisition<\/a>, Orchestrate.io<\/a>.)<\/p>\n

Actually<\/em> Build For Scale<\/h4>\n

Towards the end of an IT project, just before go-live, we used to\u00a0retroactively write a Non-Functional Requirements (NFR) document (because it was a mandatory artifact) and usually it would contain made up numbers about performance or load requirements, most of which could never be tested or actually met in the real world. We always tried to scale the app, usually by\u00a0adding more servers and a load balancer. Of course this was never enough because we were a global company and we put most of our apps in a single location in the United States. (Plus, we usually had a single database server behind the app servers anyway…see above.)<\/p>\n

Enterprise applications don’t have to be on par with\u00a0Facebook or Google, but large organizations still need to build apps that scale for both heavy load as well as for a global distribution of users. Just about every application I built during my IT tenure used a basic three-tier architecture and a simple\u00a0load balancer. In today’s modern environment with the convergence of enterprise and\u00a0consumer apps\u00a0\u2014 users expect things to work just like they do on their web browser at home and on their smartphones and tablets \u2014 this just won’t cut it anymore. Since leaving the one-track mind of the enterprise, I’m just becoming familiar with some of the emerging\u00a0architectures (twelve-factor apps, \u00a0microservices, containers) that scale better and are more suitable for running in a cloud environment.<\/p>\n

Lesson:<\/strong>\u00a0Applications should be\u00a0designed for scale from the start. Global accessibility and consistent performance across geographies should not be an afterthought. If the tool you select or build does not support your scalability requirements, it will be a failure regardless of how well it works. Consider a more modern architecture and leave the three-tier apps behind.<\/p>\n

\n

As Bob Dylan wrote, “the times they are a-changin'” \u2014 and one thing I’m glad about is that in this past year I’ve finally begun catching up with the times. I know big companies usually have large enterprise IT organizations that always seem to have a stigma for being behind<\/em> the times. Well, here’s another quote for them from German author Eckhart Tolle \u2014 “awareness is the greatest agent for change.” If you’re trapped in an organization like the one I was in, don’t wait for your future self to travel back in time and educate you. Educate yourself now and start changing the way you do IT.<\/p>\n","protected":false},"excerpt":{"rendered":"

It was exactly one year ago today that I became a\u00a0Product Owner (n\u00e9e Manager) at CenturyLink Cloud, and as a colleague of mine likes to point out, that’s a really long time in “cloud years.” As I reflect back on the experience I’ve had so far, it feels good to know that the me of […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,3,8,7],"tags":[],"class_list":["post-3583","post","type-post","status-publish","format-standard","hentry","category-agile","category-career","category-cloud","category-devops","post-preview"],"_links":{"self":[{"href":"https:\/\/archive.bryanfriedman.me\/cloudingup\/wp-json\/wp\/v2\/posts\/3583","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/archive.bryanfriedman.me\/cloudingup\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/archive.bryanfriedman.me\/cloudingup\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/archive.bryanfriedman.me\/cloudingup\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/archive.bryanfriedman.me\/cloudingup\/wp-json\/wp\/v2\/comments?post=3583"}],"version-history":[{"count":91,"href":"https:\/\/archive.bryanfriedman.me\/cloudingup\/wp-json\/wp\/v2\/posts\/3583\/revisions"}],"predecessor-version":[{"id":3687,"href":"https:\/\/archive.bryanfriedman.me\/cloudingup\/wp-json\/wp\/v2\/posts\/3583\/revisions\/3687"}],"wp:attachment":[{"href":"https:\/\/archive.bryanfriedman.me\/cloudingup\/wp-json\/wp\/v2\/media?parent=3583"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/archive.bryanfriedman.me\/cloudingup\/wp-json\/wp\/v2\/categories?post=3583"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/archive.bryanfriedman.me\/cloudingup\/wp-json\/wp\/v2\/tags?post=3583"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}