Monday, August 7, 2017

What's in a Name?

Over the years, I've written on the topic of application release on several occasions (here and here, for example).  The topic itself is generally straightforward in that automating your application release process provides several benefits:
  • Increased reliability insofar that the deployment process is being managed by software, meaning that "friendly fire incidents" are less likely to occur
  • Increased release velocity as the time to deploy the application in a single environment is reduced, sometimes substantially
  • Increased release cadence as more frequent releases are now possible given the previous two points
Is ARA always about applications?
Not only this, but automating your CICD pipeline is a key enabler for DevOps, as it is one of the five tenets of that school of thought.  (The others, if you aren't aware, are cultural change; efficient processes that are void of wasteful, time and resource consuming steps; measurement of the effectiveness of your processes; and sharing the information in a feedback loop for continual service improvement.)

Lately, I've seen a few examples of alternate ways to apply the concept of application release automation (ARA) to effect process improvements:

Database DevOps.  This is a term I'm using to describe software solutions that automate the development and release of database objects.  Companies like Datical and DBMaestro recognize that, although databases are an essential component of any traditional 3-tier application, they are also able to stand alone in their own right due to the complex nature of the DBMS ecosystem.

Back-office Release Automation.  ERP and CRM solutions frequently offer the ability for organizations to customize the functionality of those systems to meet the unique requirements of that organization.  Well-known solutions such as SAP and Siebel are immediate examples of such back office solutions where custom module development has a process analogous to traditional software development.

But the most interesting area (to me, at least) where this is being applied is in non-traditional application release.  By this I mean applications that aren't comprised of binary executables or even scripts.  Instead, these are objects of other solutions like Informatica where they are developed and tested like any application and also have a life-cycle of environments that they traverse during their journey to a production deployment.

I realize that one could make the argument that these are just an extension of Database DevOps or Back-office Release Automation.  However, there are only elements of those other two categories while the majority of this use case is unique.

Consider the Informatica example.  Informatica has its own workflow objects that access databases and can execute shell scripts as part of their "execution."  All of these components are artifacts in the Informatica application, even though that term is a misnomer since Informatica is the application and not the workflow objects that it executes to perform standard ETL types of activities.

Yet, ARA can have a positive impact here because:
  • The general release process is the same.  You copy artifacts to the target machines; deploy them by importing the Informatica objects into the repository; and you effect changes to the database that the Informatica workflows access.
  • The non-automated process has the same challenges.  Manual deployments have several potential points of failure; manual approvals via email slow down the release velocity; and releases are often managed by spreadsheet or some other manually maintained ledger.
The point that I'm trying to make is that ARA doesn't have to be about applications that you write in some standard programming language like Java or C#.  Instead, this should be viewed through the lens of the challenges faced by an organization and the net benefits that can be realized using an automation solution such as CA-Automic's ARA.

Wednesday, June 14, 2017

Only the Finished Product Matters

For many years, people have lamented the ever increasing use of automation in the workplace.  In the 80's it was on the assembly line, and people complained that the impact on the blue collar labor force would have a detrimental and even a material impact on the economy.  Since the late 90's, this discussion has shifted to the white collar labor force, especially as it relates to IT Automation, and the resulting amount of noise has increased exponentially in the last 10 years.

"The robots are coming!"
What, specifically, is the complaint? "Replacing people with robots" (as we've often heard it characterized) eliminates the need for the people in the first place.  They lose their jobs, which is bad for both moral and economic reasons.  Often, FUD (Fear, Uncertainty and Doubt) is incorporated into the message along with "#skynet" as people say that we will only be one step away from computers taking over the world and eliminating humankind a la Terminator.

Ok, maybe it's not quite as bad as the last statement, but I have seen inklings of that in the various comments whenever this topic is discussed.

From a purely business perspective, however, it's a much easier discussion since business is driven by money.  Ignoring the "money is the root of all evil" commentary, business simply want to bring in more money than they are spending, and they want the distance between those two numbers to increase over time.

As I've written before in The Executive Relationship (parts 1, part 2 and part 3), one of the ways companies achieve this is to streamline existing processes (also a core tenant in Lean and DevOps) by removing unnecessary waste built into these processes over the years.  But when you consider this from the perspective of Value Stream Mapping (also a part of Lean and DevOps), one of the ways to streamline an existing process is not to eliminate useless activities but also to simply speed up steps to be executed to complete the process as a whole.  This is where IT Automation comes into play.

My personal definition of IT Automation (a.k.a. IT Process Automation, ITPA, Runbook Automation) is the following:

IT Automation is the process of executing tasks with minimal human intervention to achieve a well defined result.

The advantages of incorporating IT Automation are numerous:
  • It executes much more quickly even when done sequentially
  • It can execute tasks in parallel
  • It provides consistent and repeatable results
  • It won’t mistype a command line parameter causing problems
  • Because run books defined in an automation system are self-documenting, the need for people with specialized knowledge is significantly reduced or eliminated

But I would argue that even these items are not what matters most.  What matters most is the end result, because that is what your customers want.  If I go into a fast food place and order a "number 3, medium, with a diet soda" I don't care if people or robots fulfill my order.  All I care about is getting the food I requested so that I can satisfy the need that resulted in the order (i.e. hunger).  And if I feel like I cannot get what I want from this location in a timely manner with a level of quality that I expect then I'll go to another location that can meet those requirements.

This concept extends across all industries, meaning that your end users don't care about how things get done - they just want results.  Don't believe me?  Consider for a moment the multiple corporate scandals that are happening at Uber that have recently resulted in co-founder and CEO Travis Kalanick being ousted...I mean taking an unspecific leave of absence.  In case you are unaware, Uber has taken a lot of heat for having a poisonous work environment where sexism runs rampant, the drivers are underpaid or are cheated of their ability to participate in higher rates changed by the company, etc.

Yet Uber still has a market capitalization of USD$69B.  That's B as in Billion.  For a company that owns no vehicles of its own, that number is mind boggling.  Is it justified?  That's a discussion for another blog entry.  But this much is clear:  the company itself is doing quite well when you measure success from the perspective of how many people are using Uber to get from point A to point B.

In other words, riders don't care about the significant challenges the company has at the moment.  They simply need to get to their son's baseball game, their daughter's dance recital, their customer meeting.  They only care about results and whether the company can deliver the results in a way that meets their expectations.

As long as this is what is ultimately driving our economy (Results as a Service), companies are going to do whatever is necessary to improve their ability to deliver the results including incorporating IT Automation to whatever degree is needed.  And if your company hasn't adopted this "do whatever is necessary" attitude by looking at IT Automation as a means for increasing the quality of the goods and services it delivers then it needs to wake up and smell the roses quickly before getting left behind by its peers.

Friday, May 12, 2017

Where Were You When...

Where were you when

...Hank Aaron hit his 715th home run?

...Steve Jobs introduced the first iPhone?

...Felix Baumgartner jumped from 39km in space and parachuted to Earth while televising it?

My wife and I have had this long-standing debate about whether drinks with Aspartame should be consumed.  She says no, but I say yes because I don't want the added sugar since I'm overweight as it is.  (Nevermind the options of not consuming the drink in the first place because then I'd drink beer instead and that's no better for my waistline.)  So once while consuming one of my favorite beverages - San Pellegrino Limonata - I read the list of ingredients to see which type of sweetener was present.  It was sugar.  I lost.

"Remember when there was this huge backlash about High Fructose Corn Syrup?" I asked her, in hopes of avoiding discussing the fact that I was drinking something with sugar in it.  At that point, we both acknowledged that during that backlash companies reacted in one of two ways:
  1. They fought back and tried to convince the general public that High Fructose Corn Syrup was just like sugar, didn't result in elevated risk for obesity, diabetes, etc.  We all saw the advertising campaign from the corn growers that highlighted this.

  2. They modified their recipes to use cane sugar, Agave nectar, or something else.
When talking to executives at my customers, I've often rallied behind the statement by Gartner in 2014 that companies either think like a technology company or lose their "first mover advantage."  (I like to paraphrase that as "constantly innovate or rapidly become irrelevant.")  For companies looking to avoid being this equivalent of the Titanic DevOps seems like a viable pivot, and yet this has become the veritable albatross around the neck of many CxOs who want to adopt DevOps but completely fail to do so.

What gives?  One of the tenets of DevOps is the CALMS initialism.

Lean (process engineering, that is, not the avoidance of sugary beverages)

None of these items are things that happen overnight, especially cultural support for the evolution to a DevOps mindset.  The biggest problem with the latter is the inability for organizations to overcome the way of thinking that encouraged IT silos, the "it's not my job" mentality, etc.

Think High Fructose Corn Syrup.

When the backlash against that happened, companies that were able to change the way they created their products enjoyed a huge (my guess, not backed up with empirical data of course) bump in top line revenue because this issue was "top of mind" for many consumers who were consumed with creating a more healthy lifestyle.  For the companies that stuck with the old ingredient, they certainly didn't "rapidly become irrelevant," but I can assure you that even to this day I still check the ingredients list and avoid products with High Fructose Corn Syrup in it whenever possible.

DevOps is a journey to be sure.  But the journey will pay dividends for years to come, and so it is an investment that is worth every penny of sweat capital that you will invest.

Tuesday, April 18, 2017

Use the Right Tool for the Job

Image copyright (c) by James Aiken
My wife and I have a fun dynamic: she approaches situations with surgical precision, while I tend to be more of an imprecise paintbrush like you would imagine was used in the painting you see here. One day, she chastised me one day for cutting something with a butter knife and insisted that I should be using a paring knife instead.  I argued that it wasn't needed.

Who was right?

As you can imagine, I was intentionally vague with the description of the situation above so that I could illustrate that an understanding of the context is required to answer it properly.  In this particular situation, I already had the knife out from making my daughter a sandwich for her lunchbox and had switched to cutting strawberries.  So, technically, she was correct, but I was also able to properly execute my task with the tool at hand, literally.

This loosey-goosey approach to executing a process works in some situations, but in others it should be avoided at all costs.  Would a MacGyver approach work with DevOps?  Could you slap together a bunch of unrelated tools in such a way that the proverbial "bubblegum + aluminum foil" result allows you to have an enterprise class CICD solution?  The answer is "probably not."  Yet I have found numerous organizations that attempt to shoehorn single purpose solutions like Jenkins or Chef into the role of CICD orchestrator, only to wonder what went wrong when the level of effort ends up being immense and/or yields something that either doesn't meet their expectations or isn't able to grow with them as an organization.

As with the example about cutting strawberries, context is needed here.  Many commonly used DevOps solutions are single-minded in their purpose:  Jenkins was built to be a continuous integration tool; Chef was built to be a provisioning / configuration management tool; etc.  And just like you wouldn't use bubblegum and aluminum foil to build a jet engine, you shouldn't use solutions to do things they weren't intended to do.  This includes situations where the company that produces such a solution releases a subsequent bolt-on in hopes of expanding the scope of use to include use cases that should not be considered in the first place.  (I'm looking at you, Chef.)

With continuous delivery, specifically, you need to realize that any orchestration solution needs to be able to address the following six verbs:

Who should have access to various applications and processes that are part of an organizational portfolio?  Roll-based access control should allow you to limit who has access to what so that developers on one team can't modify applications being built by other teams, or deploy an application into operational environments to which they don't normally have access.

What artifacts should be included as part of the application deployment process?  Are all artifact types supported by the solution?

Where is the application to be deployed?  Does the solution allow you to deploy across multiple environments while automatically adapting the workflow to account for environment-specific configuration differences?

When do deployments occur?  Can it be on-demand?  Scheduled via a release calendar?  Queued up so that a different function can decide when the queue should be processed?

Why are you using an enterprise class orchestration solution?  Are you still doing enterprise releases twice a year or are you looking to increase the frequency of deployments to be once a week or more frequently than that?  And...

How does an application get deployed?  How is the process defined?  How are integrations with surrounding parts of the ecosystem (e.g. ITSM solutions, etc.) accomplished?

Applying this litmus test to the commonly used solutions like Jenkins, Bamboo, etc. will show you that these solutions often excel in one or possibly two of these areas, but rarely will you find something that addresses all six in a way that allows your organization to benefit without adding risk to the operational side of the business.

The onus is on you to understand the raison d'ĂȘtre of your toolset so that you can also understand why changes may be needed.  If you are looking to expand your capabilities so that you can deliver business functionality to your end users in an expedited fashion while also putting structure around the process so that there is no risk added as a result of the increase in velocity, then you need to stick to evaluating orchestration solutions that were built for this purpose from the beginning.  This will give you the confidence to move forward with the implementation of your CICD strategy.

Tuesday, March 14, 2017

Application Development Done Right

In a previous article, entitled DevOps as the Ultimate Panacea?, I described how developing code without thinking about the current needs of the end user as well as the future needs once they've become accustomed to using your application ends up not only frustrating them but also can result in customer churn and ultimately lower revenues.  In this article, I'd like to describe something simple that I came across today that shows a definite degree of effort to do quite the opposite.

Recently, we had a severe snowstorm, one with blizzard-like conditions, which is unheard of in central New Jersey.  Being responsible adults, my wife and I went to the grocery store to stock up on essentials (read:  chips, chocolate, etc.) in case we get stuck at home.

As we were ringing up our order, the cashier mentioned to us that the store has a mobile application.  Since both of us are in technology oriented professions, we were skeptical about the need for a grocery store mobile application.  But then the cashier told us two things that immediately caught our ear:

  1. The application will allow us to search for a specific item and, if the location where we shop carries the item, it will also tell us in what aisle and where in that aisle the item will be located.

  2. We can associate digital coupons with the application so that we don't have to worry about collecting those strips of paper that spew out whenever we scan our loyalty card at other grocery chains, much less keep them organized, etc.  All we need to do is scan a single QR code at the register; the appropriate coupons are consumed and the savings automatically applied to our bill.

These two features are enough for us to justify the 25 minute drive to this particular chain, which is something we've only done once every two months at best in the past.  This is in spite of the fact that there are two major chains (without digital capabilities like the two items mentioned above) currently within 5 minutes of our house currently.

Although it's possible for these capabilities to have simply "sprung from the head of Zeus," it's more likely that the software development methodology facilitated this wonderful end result.  Implementing methodologies such as Test Driven Development and Behavior Driven Development provide a constant feedback loop to give the developers a chance to see user behaviors in near real time in order to make changes as needed.

Of course, this feedback loop is useless without a mechanism to deploy new builds of applications fast enough to keep up with the rate of change in the development of the applications in question.  This is where release automation comes into play.  A fully implemented, fully automated CICD process is essential for ensuring that companies can develop at the "speed of change" so that they aren't overtaken by their competition.

While our grocery bill won't do much to add to the bottom line of this particular grocery chain, if you multiply the effect it's had on us by the number of people like us who are hearing about this for the first time, you can see how this could have an impact over time.  And this is possible only because someone took the time to consider the shopping experience; how it could be improved in a very real way for their customers; and then provided the necessary structure internally to give the development teams the ability to fully realize their vision.

Monday, March 6, 2017

It's Easier to Fail at DevOps than it is to Succeed

Slippery when wet
Since the term DevOps was coined in Belgium back in 2009, it is impossible to avoid the term whether in discussions with colleagues or in professional trade magazines.  And during the years while this movement has gained momentum, many things have been written to describe what elements of a DevOps strategy are required for it to be successful.

Yet in spite of this, there is an interesting data point worth noting: not many organizations feel there is a need for DevOps.  In a Gartner report entitled DevOps Adoption Survey Results (published in September 2015), 40% of respondents said they had no plans to implement DevOps and 31% of respondents said they hadn't implemented it but planned to start in the 12 months after the survey was conducted.

That left only 29% who had implemented DevOps in a pilot project or in production systems, which isn't a lot.

"Maybe it's because there truly isn't a need for DevOps," you say.  While that may have been true if DevOps were around in the beginning of last decade, the consumerization of IT and other types of "instant gratification" technology advances would dictate otherwise.  In fact, in a 2014 presentation entitled CEO Resolutions for 2014 — Time to Act on Digital Business, Gartner analyst Mark Raskino told a group of CxOs in various industries that (paraphrased) they need to either constantly innovate, or they will rapidly become irrelevant.  All it takes is one stumble to be overtaken by their competitors who recognize the need to think like a technology company whether or not they are one.

Let's drill down a bit.  Even though DevOps means far more than application release processes, Agile development methodologies have changed the landscape of software development such that the promote and release functions are now often the bottleneck.  It is here that automation can have the biggest impact, yet many organizations haven't addressed this to its fullest extent.  In a report by IDG Research entitled Market Pulse Research: The State of DevOps (published in August 2013), 36% of respondents said that their release processes were completely manual and 53% said they were only partially automated.  The kicker is that they all recognized that automated application release is a key enabler to the successful implementation of a DevOps strategy.

What is the real problem here?  It would seem that many organizations are looking for ways to successful achieve the nirvana of DevOps when they should instead focus on how to avoid failure.  They are charging forward without protecting the flanks, and as a result they are getting hamstrung.

What are some of the reasons why DevOps can fail to take hold?  While there is hardly the same quantity on the pitfalls to avoid as there is on what it takes to be successful, Cognizant published a great whitepaper containing six key things to watch out for when embarking on your DevOps journey.  These items are on pages 2 and 3, and are a "must read" even if you're already immersed in implementing DevOps at your organization.  Another great article published in Computer Weekly discusses the business and technology challenges when implementing DevOps.  From the article, "for enterprises entrenched in the old way of software development, adopting a DevOps style of working isn't going to be easy for CIOs without buy-in from the whole IT department."

I could not agree more.  Focusing on the goal is fine, but for something that requires such a huge shift in the way multiple departments work it needs to be recognized that there are many more ways to fail than there are to succeed.

Friday, January 13, 2017

DevOps as the Ultimate Panacea?

Truth without love is cruel, and love without truth is foolish. - Sam Leung

Those of you who follow me on Twitter (@foolomon) know that I tweet industry news relating to DevOps and other topics (such as Information Security, IoT, etc.).  Based on the sheer number of articles that I come across but do not tweet about, you would be justified in believing that DevOps is still the darling child when it comes to marrying application-based functionality with the business value it should be aligned with.

"What if I told you," Morpheus might ask, "that DevOps is not the panacea you think it is?"

"What, what?" you exclaim.  "I thought DevOps is the be-all, end-all of application development!  'Continuous delivery' is the way to go, man!"  Bear with me while I explain myself.

Recently, I read an article in Forbes that said something quite profound: "people don’t want to buy a quarter-inch drill bit; they want a quarter-inch hole."  DevOps is the drill bit in this analogy; it is the means by which the hole is created, which is represented by the application being deployed to production.  The point that I'm trying to make is that, like ITIL was in the 90's, people are putting too much emphasis on DevOps while forgetting that the ultimate goal is to develop an application that does what the users want.

In other words, don't forget to do your homework before writing a single line of code for the upcoming sprint.  Otherwise, you'll end up with an application that does everything imaginable except inspiring your users to actually use the application.

As an example, consider my favorite navigation application, Waze.  Realize that I use this exclusively for my GPS needs while driving in spite of the fact that I have Google Maps, and the base iOS map application on my phone.  However, there are a few things about this application that annoy me to no end, most notably the fact that it will send me through every side street imaginable if that results in an arrival that is 15 seconds faster than it would have been if I stayed on major streets and/or highways.

What they failed to imagine is that each time a driver has to make a turn, the drive becomes a bit more irritating especially when you're already on a perfectly good road heading in the same general direction.  Multiple this by 10 turns during a 20 minute drive and you can understand the frustration that people can feel using the application during their drives.  Worse, excessive turns makes it much more difficult to remember the route they took, meaning that they have a perpetual dependency on using the application whenever they drive.

When you frustrate your users they start looking for alternatives.  For me, that alternative is spending time on Google Maps to familiarize myself with routes to common destinations so that I no longer need to use Waze.  For others, it may be to use a different application entirely in spite of the fact that they may arrive a few minutes later than they would have using Waze.  Etc.

"So what?" you ask.  "You're talking about a free application for my phone."  True, but consider the business analog: applications are meant to provide a standardized way of accomplishing a specific task.  The moment someone feels the need to deviate from that by not using your application you increase the risk of a lower quality or potentially incorrect result.  This can adversely impact your organization's productivity as corrective measures must be taken on a case-by-case basis as well as affect the bottom line because of lost revenue, higher operational costs, etc.

In short, DevOps is a tactical play in that it guides the execution of an application development strategy.  What it will not do is determine what those applications should be doing, and it is this activity that is the raison d'ĂȘtre for application development in the first place.  Do your homework to make sure you are solving the problem and not simply providing a solution, and you will enjoy success as those applications have a positive impact on your organization's productivity and financial well-being.