The first thing you need to know about DevOps is that it is a port­man­teau. A join­ing togeth­er of the two words — devel­op­ers and oper­a­tions — DevOps is also meant to sig­ni­fy a new com­ing togeth­er of these two work­place dis­ci­plines giv­en that they are roles that are some­times argued to be at odds with each other.

The sec­ond thing you need to know about DevOps is that it is not a dis­crete ser­vice or pack­aged prod­uct of any kind. Instead, DevOps might be more accu­rate­ly described as an amal­ga­ma­tion of cul­tur­al philoso­phies, work­ing prac­tices, and the tech­nol­o­gy tools designed to make soft­ware appli­ca­tion devel­op­ment a) more Agile and b) less painful. 

DevOps Love Factor

As a move­ment in its own right, DevOps has arisen because of an age-old prob­lem. Devel­op­ers sup­pos­ed­ly think the oper­a­tions func­tion is there mere­ly to serve their needs and pro­vide a liv­ing envi­ron­ment for the code they pro­duce. Equal­ly, the oper­a­tions teams with its data­base admin­is­tra­tors (DBAs), sys­tems admin­is­tra­tors (sysad­mins), test­ing pro­fes­sion­als, and oth­er core sup­port staff think that devel­op­ers regard them as some low­er order of human being. 

This lack of love has giv­en rise to the expres­sion: throw the appli­ca­tion over the wall. When the devel­op­ers are done with the code as far as they are con­cerned, they throw it over to operations. 

Con­tin­u­ous Devel­op­ment Has Hap­pened, All Over

But that time of wall-throw­ing care­less­ness has now passed and this is large­ly because the Inter­net hap­pened. Appli­ca­tions and data ser­vices are now con­tin­u­ous­ly online, con­tin­u­ous­ly updat­ed, con­tin­u­ous­ly inte­grat­ed, and con­tin­u­ous­ly deployed. There’s no point in throw­ing any­thing over the wall; both teams now have to live in one open DevOps space with­out the old silo mentality. 

This stark real­i­ty leads us to a new DevOps tool­chain where all teams look to plan, cre­ate, ver­i­fy, and val­i­date, pre-pro­duc­tion test, con­fig­ure, release, and con­tin­u­ous­ly mon­i­tor the tech­nol­o­gy being cre­at­ed. As well as an increased use of automa­tion, good DevOps is argued to be char­ac­ter­ized by small but fre­quent updates (once again this is Agile with a cap­i­tal A) where many appli­ca­tions are bro­ken out into defined microser­vices. This way, DevOps tools can enjoy a more mod­u­lar and gran­u­lar lev­el of care and every­body (includ­ing the users) cans start to feel the love. 

A Prac­ti­cal Guide to DevOps for SAP

Despite a cer­tain lev­el of hype, DevOps has real­ly made an impact and is wide­ly argued to be here to stay. Small won­der then that SAP has now worked with Basis Tech­nolo­gies to pro­duce ​“A prac­ti­cal guide to DevOps for SAP” as a 22-page whitepa­per that is free to down­load here.

For those inter­est­ed in a prac­ti­cal guide to the prac­ti­cal guide, ASUG has dis­tilled and decon­struct­ed the thought lead­er­ship in this white paper.

Prob­a­bly the biggest admis­sion SAP has made here is to say that with­out DevOps in place, deploy­ing even small changes to increas­ing­ly com­plex SAP sys­tems will take a huge amount of time. This is due to out­dat­ed devel­op­ment-and-test process­es, long release cycles, and sta­bil­i­ty risks. 

SAP is of course a busi­ness appli­ca­tions com­pa­ny. We also see the com­pa­ny will­ing to inte­grate busi­ness users into the process of DevOps itself. With­out DevOps we expe­ri­ence messy real­i­ties such as the use of basic spread­sheets to man­age SAP trans­ports (a pack­age used to trans­fer data from one SAP instal­la­tion to anoth­er). We also expe­ri­ence man­u­al regres­sion test­ing and a gen­er­al lack of under­stand­ing between appli­ca­tion and code depen­den­cies, all of which are ulti­mate­ly linked to user require­ments. It is, obvi­ous­ly, a bad place to be. 

DevOps in SAP on the oth­er hand seeks to get all teams (devel­op­ers, oper­a­tions, the busi­ness func­tion, and all oth­er relat­ed stake­hold­ers) to per­form what has been called a ​“Shift Left.” This sug­gests repo­si­tion­ing our whole stance when it comes to build­ing soft­ware so that we can build qual­i­ty into all appli­ca­tions from the very start.

A Con­tin­u­ous Soft­ware Life­cy­cle, With a Caveat

As this pre­vi­ous­ly men­tioned con­tin­u­ous mod­el now gov­erns our approach to soft­ware and DevOps dri­ves the pow­er behind the con­tin­u­ous soft­ware life­cy­cle, can we get to a point where things move almost too fast? No, says SAP, ​“It’s impor­tant to under­stand that con­tin­u­ous deliv­ery doesn’t mean that every change is deployed to pro­duc­tion as soon as pos­si­ble. It means that every change is proven to be deploy­able at any time as needed.” 

As DevOps now starts to affect the SAP devel­op­ment life­cy­cle, the com­pa­ny reminds us that DevOps will mean dif­fer­ent things to dif­fer­ent peo­ple. But what­ev­er depart­ment a per­son sits with­in, they will inevitably start to feel the pos­i­tive affect of the automa­tion that dri­ves much of DevOps. 

But SAP warns while DevOps con­cepts are uni­ver­sal, com­mon automa­tion tools, they are not suit­able for use in SAP envi­ron­ments because of its spe­cif­ic archi­tec­ture. This is why the com­pa­ny has worked with the DevOps toolset from Basis Technologies. 

There’s a lot to digest here, but in brief we can sum­ma­rize some of the oth­er aspects of DevOps cov­ered in this offer­ing. SAP spends a lot of time talk­ing about how objects and code depen­den­cies need to be locked down (or very care­ful­ly tracked), as com­plex SAP sys­tems may be con­fig­ured dif­fer­ent­ly in sep­a­rate world regions. A lot of DevOps con­cen­trates on change activ­i­ty and break­ing down siloed bar­ri­ers so that every­body knows what is hap­pen­ing. Peer reviews are fun­da­men­tal to this process, togeth­er with plan­ning and ret­ro­spec­tive meetings. 

An SAP Mantra: Sta­bil­i­ty Is King

SAP wants ASUG mem­bers to think about DevOps and start think­ing about imple­ment­ing some of all of the approach detailed here. But, at the same time, SAP does not want you to a) break your cur­rent sys­tems or b) start to imple­ment new DevOps-cen­tric work­ing prac­tices and automa­tion con­trols with­out first ful­ly assess­ing their effects on production. 

“Sta­bil­i­ty is king,” has long been an unof­fi­cial mantra in many SAP envi­ron­ments. ​“DevOps can main­tain required sys­tem sta­bil­i­ty while pro­vid­ing the means to deliv­ery change far more often,” the white paper states.

The end result of embrac­ing SAP DevOps is intend­ed to cre­ate a pos­i­tive human impact. As flaky as this may sound, we do know that DevOps orig­i­nat­ed from two divi­sion­al silos and their inabil­i­ty to work with each oth­er effec­tive­ly. The con­cepts pre­sent­ed here are bet­ter for devel­op­ers, bet­ter for oper­a­tions, and bet­ter for all oth­er peo­ple at every stage of the devel­op­ment life­cy­cle. In DevOps we see that every­one takes respon­si­bil­i­ty for their part of total IT sys­tem health, from the users back­wards and upwards through the IT stack. 

The end result of suc­cess­ful DevOps is less down­time, faster soft­ware deliv­ery mech­a­nisms, and a sig­nif­i­cant reduc­tion in work­load effort for every­body with process automa­tion now doing the heavy lift­ing and repet­i­tive task man­age­ment where it can. As the water­fall method of devel­op­ment is dry­ing up and the new era of con­tin­u­ous devel­op­ment is upon us, DevOps can steer us down this new channel.