Archive for DevOps

Are DevOps practitioners really Sysadmin or coding ninjas or just plain Grey?

Within my time working and researching DevOps, I started seeing a clear pattern that some very, very switched on people were doing a lot of really cool things and this was something that really inspired me to bring #DevOps to the SAP world. At the start of the journey, I looked at the practitioners of DevOps and saw this crack team of people who are able to move mountains with their exceptional skills and processes. Despite everything these people tell us, about it being about a complete organisational and conceptual change about the management of the IT landscape, you still see these exceptional people. Being a big fan of Babylon 5, the practitioners of DevOps initially started out in my head as being like the Rangers or the Anla-shok. The deeper down the rabbit hole you go though the more you realise that this is a complete and dangerous fallacy, because it is not about small band of special forces fighting from outside the system.

People traditionally identify with things more readily if they can relate them to their own experiences or to something that means something to them. Which is why when I discounted the Anla-shok equivalence I had wrongly applied, I couldn’t shake the Babylon 5 connotations. Upon reflection, through my knowledge of the B5 Universe, I came across something which started to make sense. The Grey Council of the Minbari, which seemed a much closer approximation for a number of reasons.

1. They have several castes, Worker, Religious and Warrior. IT also has many castes which can be defined, in fact probably 1000s of them, but an easy one for me is Development, Applications and Infrastructure.

2. The Council speaks as one to the outside world, despite internal disagreements. When IT departments speak externally, it should be with a unified voice – transparency is important and can be reflected without detracting from the decision being communicated.

3. Each caste has it’s own language, but in order to communicate effectively in everyday life, all 3 languages must be used. The same way in IT, each of the 3 areas of IT I listed above have their own languages, but to understand the full breadth, depth and scope of IT within a company, you must use and understand all 3 languages.

4. Technology is a tool to be used appropriately, it is not the end. The Minbari are the most technologically advanced of the ‘younger’ races, they live in harmony with their technology. They recognise that technology drives a great many things but also that there are times when technology is not appropriate. People should look to use the right technology to fit their purpose, for example, the Minbari use a fighting staff, the Denn’Bokto great effect when other races use plasma or laser or projectile based weapons in close quarters. A similar example in IT is the use of administration scripts to quickly pull a snapshot view of things. Like the fighting staff, it is easier than manually finding the information (like fighting with fists) or using a complex monitoring system (like a laser cannon).

5. They do their presenting in the style of a Stand-up/Morning Prayers. Not a big one, but I like the parallel that information is presented, judged and decided upon as a standing exercise.

This is not a perfect analogy and there are places where it lets itself down, mostly because Babylon 5 is a fictional series and we live in the real world which is much more complex and rich in experiences, but I think it works pretty well as a basic illustration. The only problem is finding non-IT people who liked Babylon 5 to try this analogy out on :-)

Let me know what you think in the comments section – I am happy to be told I am completely wrong as long as you offer a counter argument :-)

FacebookDeliciousPosterousDiggTwitterStumbleUponShare

#SAPAdmin or #DevOp – either or both

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 Devops means to me 

 DevOps and Agile Operations

What DevOps is not

FacebookDeliciousPosterousDiggTwitterStumbleUponShare

Switch to our mobile site