Sanjeev Sharmahttps://sdarchitect.wordpress.com
My thoughts on #DevOps, Software #Architecture, #Agile Development, Innovation, Technology, Life...Thu, 19 Feb 2015 20:33:24 +0000enhourly1http://wordpress.com/https://secure.gravatar.com/blavatar/889ed47864211b5fb6c2962efa83d0ff?s=96&d=https%3A%2F%2Fs2.wp.com%2Fi%2Fbuttonw-com.pngSanjeev Sharmahttps://sdarchitect.wordpress.com
My sessions at IBM InterConnect. Come learn with me.https://sdarchitect.wordpress.com/2015/02/19/my-sessions-at-ibm-interconnect-come-learn-with-me/
https://sdarchitect.wordpress.com/2015/02/19/my-sessions-at-ibm-interconnect-come-learn-with-me/#commentsThu, 19 Feb 2015 20:33:08 +0000http://sdarchitect.wordpress.com/?p=527]]>IBM InterConnect starts on Monday (Sunday for many tracks). I am already in Vegas for internal meetings/enablement and a looking forward for the show to start. I have a packed agenda with sessions everyday. The rest of the time will all be spent meeting you – our customers. If you are there at InterConnect, hit me up. Want to grab a coffee, send me a message thru the IBM Event App. Any free time I have, I will be hanging out in the DevOps Zone at the expo. I am also doing book signings of my DevOps For Dummies book on Monday and Y=Tuesday evenings. Come say Hi.

MY SCHEDULED SESSIONS (Please double check the official schedule for any last minute changes):

I will be live Tweeting from InterConnect. Follow me – @sd_architect. Hope to post a few blogs too while I am there.

]]>https://sdarchitect.wordpress.com/2015/02/19/my-sessions-at-ibm-interconnect-come-learn-with-me/feed/0sdarchitectIBM InterConnect – The largest DevOps conference ever!https://sdarchitect.wordpress.com/2015/02/16/ibm-interconnect-the-largest-devops-conference-ever/
https://sdarchitect.wordpress.com/2015/02/16/ibm-interconnect-the-largest-devops-conference-ever/#commentsTue, 17 Feb 2015 04:22:12 +0000http://sdarchitect.wordpress.com/?p=523]]>IBM InterConnect is next week! It is IBMs premier conference focussed on all aspects of the IT Industry – Cloud, Mobile, Analytics, Internet of Things – you name it! I will of course be there for DevOps. With literally 100s of sessions dedicated to DevOps, this is the largest DevOps conference ever!

I have multiple sessions I will be delivering. You can find details here.

I will be live-tweeting from InterConnect. Follow me @sd_architect for continuous updates. I plan to spend a lot of time in the DevOps zone at the expo. If you are there, stop bye, say Hi and pick up a copy of the 2nd Edition of my DevOps For Dummies book!

The world is Hybrid. Organizations adopting DevOps are building Delivery Pipelines leveraging environments that are complex – spread across hybrid cloud and physical environments. Adopting DevOps hence required Application Delivery Automation that can deploy applications across these Hybrid Environments.

‘An approach to Application Delivery that applies Lean principles to accelerate feedback and improve time to market’

What does this mean? In a nutshell it implies that DevOps is a set of principles and practices that enables an organization to make their delivery of applications ‘lean’ and efficient, while leveraging feedback from customers and users to continuous improve.

What do you ‘continuously improve’? Three things:

The application being delivered

The Environment of the application being delivered

The process by which the application (and its environment) is delivered

The ‘continuous improvement’ of the application and it environment comes from the feedback mechanism. As the application is continuously delivered, customers or customer surrogates (if the new feature delivered cannot be made available to the customer) can use the application delivered and provide feedback on the application’s functionality and behavior. This feedback can be used to improve both the application itself and also the environment it is delivered on, in the next iteration. The application’s features can enhance, added to or removed, based on the feedback. The Environment can be enhanced or re-configured if is not enabling the application to perform as expected or unable to deliver the performance Service Level Agreements (SLAs) agreed upon.

The third area of improvement – that of improving the process of delivering the application is where the crux of DevOps lies. How does one continuous make the process of delivering the application more lean and efficient – continuously improve it.

Looking at delivery processes to continuously improve them is not a new approach. Lean Manufacturing and the Japanese manufacturing approach called Kaizen have been applied to improving factory processes for decades. DevOps is now taking these Lean approaches and applying them to Application Delivery. Agile development practices applied some of these principles to development and testing. DevOps applies them to end-to-end application delivery – from ideation to production.

Continuous Improvement – where to begin?

To begin applying lean principles to application delivery processes one first needs to identify where the ‘fat’ is that can be reduced or completely eliminated. Lean thinking leverages a technique known as ‘Value Stream Mapping’ to identify these areas of ‘fat’ or inefficiencies. While one can carry out an extensive ‘Value Stream Mapping’ exercise to analyze one’s application delivery processes in detail over a multi-week engagement with experts in the space, a simple and quick approach is to take some time to map your delivery pipeline and look for ‘bottlenecks’ in how the delivery pipeline operates. New requirements, enhancement requests and bugs to be fixed go in from one end of the delivery pipeline. Code running in production comes out from the other end. How efficiently does this pipeline operate? What bottlenecks are there which can be eliminated or at least minimized? Where is the ‘waste’ that can be reduced?

This value stream mapping identifies bottlenecks in the delivery pipeline. These bottlenecks are typically just symptoms of underlying ‘fat’ in the system. They need to be analyzed to identify root causes of the inefficiencies. This list of root causes then need to be prioritized and the top three to five identified to develop a mitigation plan. DevOps capabilities can now be applied to address them. An adoption roadmap to adopt these capabilities and the associated practices can now be developed and put in motion.

Its Continuous:

The key word in this all is ‘continuous’.

Adopting DevOps is not a step, but a journey of continuously ‘deploying improvement’ and continuously improving ones practices and culture.

]]>https://sdarchitect.wordpress.com/2014/10/17/understanding-devops-part-7-continuous-improvement/feed/0sdarchitectSlides: DevOps – Using Lean Thinking to identify and address Delivery Pipeline bottleneckshttps://sdarchitect.wordpress.com/2014/09/15/slides-devops-using-lean-thinking-to-identify-and-address-delivery-pipeline-bottlenecks/
https://sdarchitect.wordpress.com/2014/09/15/slides-devops-using-lean-thinking-to-identify-and-address-delivery-pipeline-bottlenecks/#commentsMon, 15 Sep 2014 21:12:58 +0000http://sdarchitect.wordpress.com/?p=506]]>My thoughts on how ‘Lean Thinking’ techniques can be leveraged to help identify ‘bottlenecks’ in your delivery pipeline that can be addressed by adopting DevOps.

]]>https://sdarchitect.wordpress.com/2014/09/15/slides-devops-using-lean-thinking-to-identify-and-address-delivery-pipeline-bottlenecks/feed/0sdarchitectDevOps in the Enterprise: My interview with Gene Kimhttps://sdarchitect.wordpress.com/2014/06/11/devops-in-the-enterprise-my-interview-with-gene-kim/
https://sdarchitect.wordpress.com/2014/06/11/devops-in-the-enterprise-my-interview-with-gene-kim/#commentsWed, 11 Jun 2014 17:47:21 +0000http://sdarchitect.wordpress.com/?p=503]]>At the recent IBM Innovate conference I had the opportunity to interview DevOps guru Gene Kim. Gene was there as the keynote speaker at the conference. Gene also participated on a panel, that I had the opportunity to join him on (more on that in a later post). Here is our short interview. We discussed the key trends and patterns of DevOps adoption in the enterprise:

]]>https://sdarchitect.wordpress.com/2014/06/11/devops-in-the-enterprise-my-interview-with-gene-kim/feed/0sdarchitectDevOps vs Outsourcinghttps://sdarchitect.wordpress.com/2014/06/10/devops-vs-outsourcing/
https://sdarchitect.wordpress.com/2014/06/10/devops-vs-outsourcing/#commentsTue, 10 Jun 2014 16:29:09 +0000http://sdarchitect.wordpress.com/?p=496]]>As we look at enterprises adopting DevOps (yes, enterprises are adopting DevOps, in droves), the question regarding outsourcing always comes up. Many (read: most) enterprises have at least some of their application delivery or IT operations outsourced to an external vendor. This may be the traditional ‘offshoring’ where work is offloaded to an external, offshore and usually cheaper provider; to a true supply chain model, where external and internal providers deliver components of the application delivery supply chain. Both scenarios have a significantly different impact on DevOps adoption. (Yes, I am over simplifying outsourcing, but it serves the purpose for this discussion).

Strategic Outsourcing:

This is the scenario where an enterprise decides that it is cheaper or from a business perspective, better to outsource all or part of their application delivery to another provider, which excels in that space. This decision to outsource may be done due to cost reasons or due to the simple fact that the organization believes that it does not need to have that capability in house. It is better to hire someone to deliver it. The commonest example would be a company hiring an organization like IBM to run its data centers. The organization chooses to not hire staff to run data centers. It makes sense to let IBM do it. Another example would be a retailer hiring an external vendor to build and deliver its mobile apps. Again, they may have strategically decided that these are capabilities they do not have in-house. Instead of building a new mobile team from scratch, lets have a company that provides mobile app building as a service, deliver it.

In the latter scenario, DevOps is not that much of a problem. When you outsource an entire application, you outsource the delivery pipeline too. If the entire mobile app development is outsourced, the DevOps part remains limited to ensuring that the movie app can access the back-end systems it needs to, hopefully thru well defined and managed APIs. Now in the first scenario, if you build an application in-house and deliver it to a production environment managed by an external vendor, you need to do a hand off and receive the appropriate feedback to improve continuously. If the contracts are not set in stone, a Continuous Delivery model can be managed with the external vendor partnering with the organization.

I am not trivializing the planning and collaboration that needs to be done. But if the external vendor is a true partner, this can be achieved. The enterprise in question still needs to ‘own’ the portfolio management, planning, release management and governance of the application being delivered. And yes, if the vendor is not willing to partner and/or the contracts and set in stone and cannot be amended to provide for a ‘DevOps’ style model of collaboration without lawyers getting involved – you are up the proverbial creek without a paddle. You may put away your ‘DevOps for Dummies‘ book and find one titled ‘Contract Negotiation For Dummies’.

Supply Chain:

The DevOps adoption challenge become more interesting in a supply chain model, where an entire applications delivery ’s not outsourced, but individual components are being delivered by separate providers in the supply chain. These may not all be external suppliers the enterprise has outsourced to. More than likely they will be a combination of internal and external providers. Internal providers are easier to deal with. Barring politics and lack of buy-in from senior management, one can apply the DevOps principles to get the suppliers on-board. Best practices like creating a central enterprise-wide ‘DevOps Center of Excellence’ and developing internal DevOps evangelists, go a long way in getting the required buy-in.

If you have external providers, the situation can become tricky. Multiple providers developing and/or testing individual components leads to a many to many coordination and collaboration needs. Contracts get in the way. If two providers cannot communicate directly with each other and have to always go thru you the enterprise, you have a problem. If every time you try to make a change based on feedback, as required for DevOps adoption, the vendor pulls out their contract and/or charges you a change fee, you most certainly have a problem. I recently met with a customer whose external provider for Dev – Test environments charges $10,000 for each change to the base VM image. They can’t afford to make adjustments to their environments – ‘production like environments’ are not an option.

The only solution here is to seek to get the external providers to see their value in working with you to adopt DevOps. If they see the value in the efficiencies and reduction of waste DevOps can bring to them, and allow them to deliver higher quality software in lesser time, with fewer resources, that may win them over. If however, their contracts are written in a way that faster delivery, more efficient delivery or fewer people needed hurts their bottom line, not much can be done.

Your mileage may vary

So, is outsourcing the death of DevOps? Or DevOps the death of outsourcing? Not at all. Organizations cannot have all the IT skills they need in house. They will need to bring expertise in from external vendors. Outsourcing is here to stay. The advent of DevOps and the need to collaboration, agility and responsiveness to feedback that is needed to adopt DevOps goes to say that future contracts will be written with these goals in mind. This is not an unreasonable expectation. System Integrators I interact with are seeing that already in RFPs they are receiving from enterprises looking to partner with them on a DevOps journey. This is really not an option. With all the external pressures – lowering costs, need for innovation at speed and the need to be more agile and responsive to the market is compelling enterprises to adopt DevOps. It is also compelling outsourcers to change how they evolve from suppliers to partners for their clients. DevOps, in my opinion will bring on the next generation of outsourcing.

]]>https://sdarchitect.wordpress.com/2014/06/01/slides-ibm-innovate-understanding-devops-session/feed/0sdarchitect[Slides] Keynote at CampDevOps: DevOps: Using ‘Lean’ to eliminate Bottleneckshttps://sdarchitect.wordpress.com/2014/05/21/slides-keynote-st-campdevops-devops-using-lean-to-eliminate-bottlenecks/
https://sdarchitect.wordpress.com/2014/05/21/slides-keynote-st-campdevops-devops-using-lean-to-eliminate-bottlenecks/#commentsWed, 21 May 2014 12:53:36 +0000http://sdarchitect.wordpress.com/?p=488]]>I had the opportunity to deliver the keynote address at the 1st CampDevOps in Boulder, CO, on May 20th 2014. The event was organized by devops.com, in association with GlueCon.

]]>https://sdarchitect.wordpress.com/2014/05/21/slides-keynote-st-campdevops-devops-using-lean-to-eliminate-bottlenecks/feed/1sdarchitectNew on IBM developerWorks: DevOps for mobile apps challenges and best practiceshttps://sdarchitect.wordpress.com/2014/05/17/new-on-ibm-devloperworks-devops-for-mobile-apps-challenges-and-best-practices/
https://sdarchitect.wordpress.com/2014/05/17/new-on-ibm-devloperworks-devops-for-mobile-apps-challenges-and-best-practices/#commentsSat, 17 May 2014 05:05:10 +0000http://sdarchitect.wordpress.com/?p=485]]>Leigh Williamson (IBM Distinguished Engineer, Rational Software CTO Team, Mobile Software Development Strategy) and I have co-written a paper on DevOps for Mobile Apps. The paper have been published this week on IBM developerWorks. In this paper Leigh and I introduce the challenges related to DevOps that are specific to Mobile Apps. Unless one is building a stand-alone game like Angry/Flappy Bird, ones mobile app is just a front-end to back-end services the business offers. These services may be running on a mainframe, a distributed system on-prem, in the cloud or may be offered by a 3rd party. It not atypical to see a combination of all of these. This brings a set of challenges when delivering a mobile app, all the way from planning, develop and test, deployment, to monitoring, as all these services/components are a part of the solution delivered by the mobile app. The mobile app hence cannot be delivered in isolation. DevOps Mobile Apps is really DevOps for the solution, which happens to have a mobile app as its front-end.

Our paper addresses the challenges this brings and the ways DevOps addresses them. This is a ‘Best Practices’ paper and not a product pitch.