Skip to Content
Author's profile photo Chris Kernaghan

#SAPAdmin or #DevOp – either or both. #Devops Series

My last blog post explored my desire to increase my skill set to become more of a DevOp to help me to support current systems and also the new hybrid architectures which are entering our workplaces. I started a 2nd post to describe to people unfamiliar with DevOps what it is and what it is not – during the post I realised that I should really be describing in terms of #SAPAdmin, hence the title. 

#SAPAdmin was 1st described, as far as I am aware, by Tom Cenens as a way of connecting the various Administrators within the SAP community – by reputation we are not the most social of bunches in the world :-). Although it is a great idea, I know that it has not seen as much traction as either Tom, Martin English and I would have liked.  I think that part of the problem has been a lack of direction in terms of what it stands for, and I feel that using the core concepts of #DevOps – we can bring that direction and purpose into the #SAPAdmin  ethos and provide a more coherent entity for admins to get behind. 

So lets get stuck in with a quick breakdown of what #DevOps is and what it is not 

1.  DevOps is noun which describes a person and a philosophy/methodology of supporting an IT landscape.

As a person, it is an individual who understands both infrastructure and code to enable them to support their applications and also bridge the gaps created by support silos.

As a methodology, it aligns itself with Lean and Agile and so embeds with the smaller team and faster deployment model of projects as opposed to the traditional waterfall life cycle support model.

2. DevOps has a useful memonic – CAMS

  • Culture – this is critical to the whole thing, the culture of the participating teams must embrace openess
  • Automation – Why spend an hour on a daily task when you can spend two and have the results e-mailed to you every day
  • Measurements – how can you improve if you do not measure, everything!
  • Sharing – why write a script to check if your SAP system is up, go on the internet and find one. If one does not exist, then write it – but you MUST put it on the internet for others to find, pay it forward.

3. DevOps is not about just automation

Although automation plays a massive role in DevOps, through it’s emphasis on Event processing, KPI measurement etc… The real benefit in DevOps is for people to bridge the gaps in the Silos, something Basis admins/consultants traditionally do very well. This does however exact a price upon the practitioner, the requirement to keep learning and keep applying what they have learnt – it does not, will not and cannot stop.

4. DevOps is not a job title

DevOps is way of thinking and working, through sharing and collaboration you and the teams you work with create a culture that brings the best from yourselves and because you share as a team, it enriches the ecosystem in which you work.

5. It is not handing Developer keys to Basis admins, or giving Root access to developers

We each have a skill set with strengths and weaknesses, a DevOp is a person who is an all rounder with most technologies and is able/willing to work in the grey areas to get the work done. So Developers do not usually get Root access without a good reason or the proven ability to actually be trusted. Similarly a Basis admin does not get the right to deploy code to Production for the same reasons and the same validation requirements. DevOps work in the grey spaces between the silos

6. DevOps is not an end run around IT

DevOps is not a way for guerilla IT to enable people to bypass process, I would say that the use of measurement and automation enables IT departments to make better use of it’s information in Structured and Unstructured data sets to create things like Change controls and documentation. You know the things that are necessary to run a good solid service, that take forever to create and get approved and then never really get updated again. DevOps uses the principles of Lean and Agile applies them to process and documentation.

7. DevOps is not a reaction to a technology problem but a business problem

DevOps enable businesses and core IT to move faster in implementing and support technology/applications as quickly as Agile projects deliver them. This is absolutely vital in this age of outsourcing, a good solid DevOps team can run and support a service for a client ensuring that the contextual information that so often gets lost when working remotely is maintained.

We have all seen SAP embrace and encourage the principles of Lean and Agile, providing accelerators and advice to adopters. I believe that this is a great time to start to apply the lessons our organisations have learnt in terms of Agile and Lean projects to our staid and overly complicated silo’d support structures. 

As DevOps we have a massive advantage over other software/systems administrators – we have 2 products that are open, extensible, stable and free to build a DevOps service around

  • Solution Manager 7.1 – the structured data component of the landscape providing all measures and KPIs and something which can be closely aligned to the business and it’s processes
  • SAP Streamworks – the collaboration tool which through Web Services can/should be able to be extended to work with Solution Manager

Let me know what you think of applying the concepts of DevOps to the SAPAdmin community

Reference Links

What is the DevOps thing anyway

What Is This Devops Thing, Anyway?

What Devops means to me

DevOps and Agile Operations

What DevOps is not

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member


      In addition to the comments I left on your blog, I did have one other thought. Could be useful for creating a sapadmin activity that would provide a space for sharing ideas and building community?

      Count me in to assist in moving the ball forward as I can.


      Kevin Grove

      Author's profile photo Chris Kernaghan
      Chris Kernaghan
      Blog Post Author


      I am not sure Streamwork would be a great place to host an activity as it is an invitation  based space - here on SCN it is open so anyone can contribute, unless I have missed something in how to setup a space in Streamwork.

      There is nothing to stop us setting up a space for works in progress, perhaps we should consult someone like Oliver and Mark F on the best place to start this.



      Author's profile photo Uwe Fetzer
      Uwe Fetzer

      Hi Chris,

      had the same idea to embed Streamwok into the Solman a couple of years ago as Google Wave died (e.g. ChaRM). Unfortunatelly Streamwork still cannot be integrated seamless like Wave.

      Maybe we can build something on Codeexchange. Any ideas already?


      Author's profile photo Chris Kernaghan
      Chris Kernaghan
      Blog Post Author


      I like the idea of using a collaboration space to manage in progress unstructured data better, Solution Manager is not a good place to manage unstructured data - like a lot of document repository systems. Then being able to link that back to Solution Manager once it is completed.

      Because Solution Manager 7.1 is very extensible there must be a way to use Webservices to provide this functionality



      Author's profile photo Martin English
      Martin English

      I have had (a very brief) look at extending the "Business Process Operations" (see ) tool in solution manager; It was a while ago, and I'm not sure how far it went 🙂

      If I find anything, I'll start documenting it here (on SDN)