After attending SAP Teched 2013 in Las Vegas, I noticed a few things which are frustrating and worrying in equal measure, I have spoken at TechEd several times now on several subjects - although they have a common theme, DevOps and several concepts within DevOps.
DevOps as a movement is a few years old now, and is approaching maturity within the wider IT community, although it still surprises me how few people within the SAP community have heard of it (I include SAP as a company and an ecosystem). Some of the largest companies in the world use these practices to improve their development and operations practices to massive effect - a recent report reflected DevOps practices had saved Development and Operations costs by 17% and increased quality of deployments by 21%. This is impressive, although it does take time and investment to realise these gains and requires some mental gymnastics for some.
DevOps counts companies like - Facebook, Etsy, Google, Amazon, Flickr, Twitter, IBM, SAP (Internal IT), HP as followers of the methodology which is centred around culture, communication, change and tools in equal measure. Below is a list of areas that companies typically address when using DevOps principles.
1. Infrastructure - should be deployable through tools and pre-defined configurations
2. Code - should be version controlled in a repository which is updated on a commit by commit basis
3. Testing - should automated as much as possible with nightly/weekly build tests
4. Change - should be automated, pushing released changes from Dev to QAS for testing and QAS to Prod to go live
5. Tools - common tools should be used and deployed across all the teams
This leads to a number of short hand statements
1. Infrastructure as Code - Systems administrators, should be able to define their infrastructure artefacts as code - this makes server builds and configurations repeatable, auditable, sharable and consistent
2. Using common tools creates common language which creates common culture - when teams use the same tools they communicate better, for example it is better for the SAP Basis team to use Tivoli for system monitoring because the Operations teams, Database teams, Operating systems teams all use it - in doing this you create a common language and culture. Similarly, using ChARM within Solution Manager also produces the same result between the Developers, the Technical team and the Support Teams, because they are looking at the same data, in the same format, using the same terms which creates common language and understanding
3. Don't break the build - doing automated testing every night/week (using tools like Selenium, eCATT, HPQC, Rational) ensures that code standards are kept high, and anyone who breaks the build should buy a failcake or wear something embarrassing
4. Continuous Integration pipeline - a logical construct which maps development changes through a process into testing and then into Production.
There are areas within DevOps where SAP is way ahead of the game - for example
1. Change management, within the main ABAP, JAVA, BObj layers SAP has a massively mature change management system - they can be and should be proud of that fact.
2. Solution Manager, many people will mock me for this, but I can defend the concept if not the execution - Solution Manager is a DevOps' wet dream
- It can monitor and record pretty much anything with in the SAP application and infrastructure landscape
- It manages change throughout the SAP application landscape
- It is a central configuration management database, recording the versions and patch levels for every connected application
- It has a reporting tool and reporting content build into it
I feel a well set up and configured Solution Manager is an amazing tool to have within an organisation practising DevOps.
Where I feel SAP is letting itself and it's customers down is in 3 main areas
1. Little integration with existing infrastructure automation or configuration management tools - Yes SAP has products like LVM, but these are not Enterprise products - that is to say they are not used across silos. DevOps demands common tools to create common language, this means tools like Cisco ITPA, IBM Tivoli, OpsCode Chef, PuppetLabs' Puppet. It also means SAP providing an API to extend products like LVM, SWPM and SUM the same way it does with it's business applications - failure to do so would be discriminatory given the enablement spoken of in favour of developers so often within SAP.
2. Little integration or documentation on working with existing web world automated testing frameworks - Typically if you said automated testing to SAP customers, they would reply HPQC or IBM Rational or SAP TAO. Now if you said automated testing to an non-SAP person, they would use words like Selenium, Cucumber, HPQC or IBM Rational, which is interesting. As SAP encourages customers to use platforms like HANA, NetWeaver Cloud, SAPUI5 and adoption rates increase, the requirement to use bulky testing applications like HPQC or Rational decreases as the Web world already has built flexible and agile testing frameworks for themselves which are easily shared, reused and adapted.
3. Not talking openly about their own efforts in these areas through their "SAP Runs SAP" marketing brand - it may surprise you to know that a lot of these concepts are already being used within SAP already, internally within their IT organisation, for example
(presentation link http://devopscon.com/wordpress/presentation/continuous-delivery-at-sap-it/)
- SAP Uses OpsCode Chef for Infrastructure as Code definition and automated deployment
- SAP Uses JUnit and Selenium for functional testing
- SAP uses Atlassian Bamboo for Continuous integration
These are great things, it shows leadership in a grass roots culture which matches and builds upon the current Developer enablement focus within SAP, but I could not find anyone willing/capable to speak about them this week in Las Vegas, this included both senior management and people on the show floor.
This lack of capability to talk to these items concerns me, I know SAP is a large organisation and there are many pieces to it, but it also has a massive culture of "It wasn't invented here" in many places - so I am writing this open letter to a number of people within SAP, people like bjoern.goerke , michael.golz , jeff.anders ,janko.budzisch, markus.winter and martin.heisig - please continue to work with these products and develop capabilities in them so we can use them across our enterprises to create a common language and culture amongst our peers in the wider world.
You (SAP) have strived to make it easier for non-SAP developers to come into our ecosystem using common methodologies, like Agile, common tools like Eclipse, encouraged the use of version control systems like GitHub for platforms like HANA and the HANA Cloud platform to improve sharing. Surely it is not a stretch for the Technical teams to want to have the same experience because box hugging/manual processing does not scale. In order to meet and exceed the expectations of organisations in their quest to "Run better" we must create repeatable and shareable end to end automated processes the same way developers did - but they did it with your help and support which does not appear to be as focussed on technical enablement in the same way it has been for developers.
Most of the companies and tools that I have mentioned above are either already your partners or do not compete with you in any way, but complement you - there is no need to redesign the wheel, to create an SAP version of something which already exists - you (SAP) did not do it for your development tools, rather you used both existing tools (Eg Eclipse) or extended your own tools to provide web world capability (HANA XS engine).
I feel that this is a brilliant inflection point for SAP, the developer enablement process is gathering momentum and there have been valuable lessons learnt from it in terms of engaging outside of SAP as well as inside it. bjoern.goerke brings with him a wealth of experience in developer and Agile practises which can be applied and encouraged within SAP's internal organisation to help define SAP Administration technology strategy as part of it's "SAP Runs SAP" tag line - after all SAP IT faces the same technology challenges as it's customers.
Thank you for your time and I look forward to your comments.
- SAP Managed Tags:
24 Comments
