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

[boobboo]

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