We are robots – what managers of DevOps teams really want
Back in 1978, when Kraftwerk performed their “we are robots” song, I hadn’t even started my professional career yet. During my career as developer and in software quality assurance
(starting in 1992) testing was very costly and often needed manual tasks.
The idea of being assisted by robots in programming and testing has become more common in the last few years. But till then unit-testing and regression-tests were a troublesome business.
Here you can watch a typical Kraftwerk performance of that time:
https://www.youtube.com/watch?v=S2dULojeh7Y
The approach of that time to make this kind of electronic music was revolutionary. Kraftwerk as a band were 4 buddies.
2 buddies
If we look at a typical DevOps approach there are parts which are done by the DEV side and others which are processed by the OPS side. These 2 sides aren’t naturally born enemies but should also be buddies.
See the following figure to get an overview of the different phases, that are part of a typical DevOps tool chain. The left side is typically seen as the DEV’s responsibility, the right side belongs to OPS.
Between plan, code, build, release and deploy there is the test automation phase, for which it should be easy for an assistant or servant to do the appropriate work. If all the tests are passed and everything is fine, my part of a “wave” (several sprints) or “sprint” should be marked as deployable. Until that time all that is left is wishful thinking.
Reality-Check
In April 2016 SAP announced the availability of the SAP Focused Solutions. It was the first time at the SAP Solution Manager Education Summit 2016 – late in that year – where the idea of SAP using DevOps and a scaled agile approach was presented to a wider audience. I wrote about the Solution
Focused Build in the blog post https://blogs.sap.com/2018/04/03/sap-focused-build-how-to-get-more-flexibility-and-agility-in-your-sap-projects/. Flexibility and agility with SAP methods were the main topics there. There is a test planning and kind of execution automation build-in SAP Solution Manager. Changes are recorded, test cases that need to be retested are recognized. But it’s up to you to do the right tests. Automatic testing, supported by assistants could serve here.
2 more buddies
Automatic testing and SAP Focused Build could be two more best buddies. E.g. for CI/CD.
Continuous-Integration (CI)
If I think about “continuous-integration” (CI), which is part of any agile approach and even SAPs preferred way – in environments outside of SAP – I can see some serving solutions like Jenkins.
Isn’t it interesting that this company has chosen a servant as their logo?
Kraftwerk states “Ja tvoi sluga” which is Russian, meaning “I’m your servant”.
The advantages of such a toolset – serving you – could be:
… build and test your software projects continuously
(source: https://wiki.jenkins.io/display/JENKINS/Meet+Jenkins)
… continuous integration (CI) and continuous delivery (CD)
… making it easier to integrate changes to projects.
This is the more sophisticated approach I’ve been searching for in the SAP world.
Beyond automation
Never underestimate the availability of the right toolsets. But be aware of all the other pillars of a successful DevOps approach named in the CALMS framework. The abbreviation CALMS starting with the “C” means Cultural change (C), automation (A) in testing, release-management, building, deploying (A), Lean methodologies (L), Measurement and KPIs (M) and sharing (S).
Please see my blog post https://blogs.sap.com/2018/03/01/keep-calms-and-do-mindful-sap-devops/.
Let me just emphasize the different point of views in a DevOps optimization approach again.
The perspective of a developer – DEV side
As a programmer I wish to have everything retested automatically, after I finished my coding.
The song-text by Kraftwerk goes on like …
“… We’re programmed to do anything, and anything you want is done.”
Please imagine, that the robot will do the regression tests automatically. That would be a dream coming true!
The perspective of an operator – OPS side
Only stable parts of a release – ideally without the toil of building and integrating –
should be imported into the production environment – or even better as a trial rehearsal into a
pre-production system before. See google’s view on toil:
https://landing.google.com/sre/book/chapters/eliminating-toil.html.
(e.g. manually running a script that automates some tasks).
At least the perspective of a manager
As a manager I should do everything, which is under my control to let go. To give trust to the team and to ensure that the team has all the abilities at hand to decrease manual effort for test-scripting. In the end I want to sleep well, also during deployment times.
About trust
” … Trust is the foundation of DevOps …” (original quote by Dirk Lehmann) here
https://blogs.sap.com/2018/06/19/trust-is-the-foundation-of-devops/ . And he is absolutely right.
It would be much easier for me – as a manager – and also the team, if we could rely on servants, which care about the consistency of our software application. And therefore earn that necessary
trust by quality and stability.
DEV#OPer’s dream
Being a Dev#Oper, it would be my dream, that my managers can sleep well, because there is trust in the Dev#Oping team, based upon …
- Tests will be processed automatically based on historical behaviour of my system
- The deployment won’t break the productive system
- All my mission-critical processes will work as before – after a successful deployment
- The deployment will be stopped, if an error or unforeseen situation is detected in
re-testing - Due to the DevOps approach the quality at the end of the “continuous delivery pipeline” will become better and better
The Solman can do it. Turn it ON again!
To be honest, maybe there has to be some additional tools for the automatic regression-testing.
Hi Achim
Nice writing, as I've seen before coming from you.
In my opinion, SAP should open up more in terms of the Focused Solutions and provide the training for DevOps coaching outside of SAP as well.
I recently showcased Focused Build by getting a system up and running on Amazon AWS, fixing the configuration because it wasn't really working end-to-end and then demo'ing / showcasing it to the customer. The customer is a MaxAttention customer and decided they want to now implement Focused Build. So I was thinking, great, mission accomplished. I do see benefits in the concept and I believe in what DevOps can bring to the table as well. I was excited to go and do this and guide the customer along the way.
The result was that I cannot implement is myself because it's a MaxAttention customer, SAP has to do it otherwise it wouldn't be for free (MaxAttention customers don't have to pay for the add-on of Focused Solutions).
That sucks to be honest, I do all the "pre" work and then I get told I cannot be part of the implementation. The customer would like to include me but SAP sais "nope, against our rules". If I would do the implementation instead, the customer would have to pay licenses for Focused Build.
Second thing is I cannot get the specific training for DevOps coaching because it's only available for SAP internals.
So why would I be promoting Focused Build in the end? Most of my customers are MaxAttention customers. So in the end, it doesn't make sense for me to put any more effort into this topic unless SAP changes something, unfortunately.
I can only hope that SAP comes with a better, nicer solution that is cloud based (and can still serve on-premise) and makes the right moves there to enable the community to use and deliver the solution to the customer.
Best regards
Tom
You read my mind Tom !.. The entire concept of Focused Build offering for Max Attention customers is a flawed logic to be honest and upfront. I already faced the same situation as yours twice. According to my take, Max Attn Customers are not liking the idea of calling SAP for setting up their Focused Build just so that they can get the license free of cost. Customers are thinking why should they burn up MaxAttn days for setting up this when they could do it themselves with internal resources or (with external consultants like me !) .
The "if's & but's" associated with Focused Build offering is doing more damage than helping the cause. As you rightly said, SAP needs to open up more on Focused Build offering and I see the much coveted 'Focused Build Circle' partners are not helping much either. I was expecting more realtime use cases and customer stories by now on Focused Build. I do not see much momentum at all on this front.
I would love to see more contents here in SCN on how customers used Focused Build 'as-it-is', how they adopted with customization for their flavor of project management (hybrid agile, waterfallish agile..etc).
To be honest, if a customer asks me as of today, "Hey Vivek, should we go for Focused Build for our upcoming projects?" .. my reaction at this date would be present a poker face and I am not 100% sure whether by saying yes, will it really worth pushing around the project managers and PMO team at all.
I am sincerely hoping SAP revisits the offering concept of Focused Build for MaxAttn and Ent Support customers alike and make it more logical and reasonable.
Best Regards,
Vivek
Many thanks for your appreciated comment Vivek Hegde
Hi Vivek
You have probably seen it already. At SolEd last week, SAP announced a number of things:
SAP Cloud ALM: a SAAS based ALM solution that could potentially support on-premise by 2020 (focus is first on delivering ALM to SAP cloud solutions)
SAP Focused Solutions will become "free of charge" and "free to implement yourself" by 2020 so that opens up the opportunity/perspective although it's still a one year wait until we reach that point basically. But at least it is something.
So now I can pursue getting the educational content out in the open as soon as possible as my next "mission" to pursue.
Best regards
Tom
great news Tom Cenens
Thank you very much Tom Cenens
#PYLONS