The Smile-IT Blog » April 2014

Monthly Archives: April 2014

Mind: DevOps isn’t a role model!

This blog post (“How ‘DevOps’ is Killing the Developer”) airwaves a bit at the moment. It reached me right at some really cool, breakthrough conversations on how DevOps will lead change of culture and role perception … and it fully truly nailed the opposite of those highly positive talks. To say it in the words of one of the commenters: “I couldn’t disagree more!” I even would go as far as to consider it dangerous!

Why?

Because the post reflects a totally wrong perception of DevOps! The article claims that DevOps would transform the role and responsibility of a particular person – a developer in this case. I would be surprised if literature really postulates this – the change of a role. DevOps is the transformation of HOW things are done, not WHO does it. Firstly, you have to lay the basis for a DevOps company transformation. Do developers change their expertise by that? No. Do OPS guys do? Neither. BUT: They do get closer together, get better understanding for each others challenges.

Secondly: The post misses another highly important – maybe the most important – investment along with DevOps introduction: Automation! Along with the cultural change, you’ll have to invest in automation of processes for artefacts which would formerly have taken you days and weeks to create/setup/deploy/run.

90°

So – let’s be clear here: DevOps isn’t the change of a role! DevOps is a 90° turn of a modus operandi. The whole movement derives from manufacturing where the importance lies in getting rid of any blocker in a production pipeline. Neither would a continous production change the role of the screwmaster (to name just anything) nor would DevOps change that of a QA expert or buildmaster … or – well: developer (as exemplarly taken here)!

The article is dangerous in another aspect: It claims developers to concentrate on development and nothing else. It is – but – another important aspect of DevOps as a cultural tranformation: To bring understanding for everybody else’s responsibility in the process to everybody. And thereby encourage Automation even more to take its place in it all. This importance is totally missed out in the post!

Bottom line

Let’s be crystal clear on a few things with DevOps:

  • It’s a cultural and organizational change; not a role and responsibility change for single individuals
  • It is a 90° turn of a modus operandi. It turns vertical silos of responsibility and action into horizontal pipelines/chains of continous work-flow
  • It’s a way to create role and responsibility awareness throughout the whole chain of collaborating individuals
  • And it surfaces the need of Automation to support cultural and process transformation, stability, security, repeatability, speed, continuity, …

There’s – however – a really positive DevOps-supporting aspect in that post: It does indeed drive discussion into a good direction … just browse through the comments there … 😉

 

( This post was also published in the official Automic company blog: http://blog.automic.com/devops-not-a-role-model )

 

Published by:

3 things to consider when creating a new SaaS product – Automic blog post

You want to create a new product. At the same time you want to create a new delivery model – e.g. Software-as-a-Service (Saas) – for your new product.

Of course – these days – you also want to create a new pricing model for your product. And you want to increase delivery speed while maintaining product quality, of course, as high as it always was.

Ultimately you also want to keep the consistent flow of upgrades, patches, and hotfixes, for your existing enterprise product landscape intact.

Challenging? Yes. Impossible? No.

 

1. Deal proactively with the risk of technical debt

Creating something of this complexity within such a short timeframe can easily lead to artefacts being developed that play together well in the first place but never ever scale to the extent that an enterprise ready product would need to.

A clear architectural separation of concern between entities while at the same time keeping focus on a concise end-to-end architecture for all building blocks is key for avoiding technical debt right from the beginning.

One approach of achieving that focus is, of course, to invest heavily into upfront creation of architecture and design specifications.

However, this approach might just not serve the goal of a short time-to-market sufficiently.

Hence, the only way of maintaining the path and thereby reducing technical debt is to create just enough specs to form the boundaries within which a team of brilliant technologists can quickly develop the MVP – the minimal viable product – to be pushed out and at the same time stay focused on the path of the broader goal.

2. Be DevOps from the beginning

One might consider the creation of a new product within a new delivery model (like SaaS) to be just another product development.

Here at Automic we have a lean product development process in place based on agile patterns and already tailored to our customers’ needs with regards to fast change request and hotfix delivery.

However, approaching SaaS with this speed instantly surfaces the need of something new in that space. Hence – along with a concise architecture specification – you need to create not only a DevOps oriented tool chain but at the same time a DevOps culture between the involved organizational units.

DevOps – if implemented end-to-end – changes your delivery, maintenance and operations pipeline completely. Developers are challenged by the fact that their deliverables are instantly deployed to a QA system, test engineers change their focus from testing to end-2-end test automation in order to support automated production deployments and operations start to deal with an application centric rather than a system centric view onto their environments.

Setting the stage by creating a DevOps funnel from the very beginning is key to delivering not only the MVP but also its constant continuous enhancements.

3. reate a consistent architecture model of Automation and Orchestration

Having a solid enterprise ready SaaS-ified product in place is a major challenge in itself.  Creating a solid delivery framework of support services for operations and business processes clearly adds a significant level of complexity.

The cornerstone of this is a strong Automation layer defining its capabilities into clearly separated building blocks for the respective purposes (e.g. customer instance management, component packaging, user provisioning, etc.). Put them into the entities they clearly belong to.

Do not put capabilities (logic, functionality) into a building block or component that actually serves a different purpose. Create small functional entities within the Automation layer and orchestrate them into a support service for a well-defined purpose within the framework.

Holding these paradigms high during the minimal viable design process as well as during the rapid – somehow prototype-like – creation of the MVP will later allow you to decouple and re-bundle entities along the path of scaling your building blocks and your entire delivery framework. Of course, a strong Automation product tremendously eases achieving this goal.

Are you involved in creating a SaaS product? What have you learned from the experience? We’d be keen to get your thoughts in the comments below.

 

( This post was also published in the official Automic company blog: http://blog.automic.com/3-things-to-consider-when-creating-a-new-saas-product )

 

Published by:
%d bloggers like this: