Fincode and DevOps Summit

This blog is based on 3 days of presentation and debate at 2 events Daysha attended at the end of March 2018.

Fincode which as the name suggests was primarily attended by Fintech companies including larger organisations like Morgan Stanley, Lloyds and BBVA.

The other event was DevOps Summit which was a one day event and included financial and non financial attendees.  These events included workshops and panel discussions. Daysha ran one of the workshops at Fincode in partnership with XebiaLabs.

There is a comparable Fincode blog for 2017.

Beyond the summary below are 4 sections headed Business, Culture, Technology and Organisation.

Each comment can be backed up with notes from the organisations who presented at these events and these are available if you email info@dayshaconsulting.com and specify the comment you require evidence for.

It should be noted that not all presenters agreed with one another and therefore what is presented herein are majority opinions which are subjective.

Summary

  • More organisations are more progressed on their DevOps journey in 2018 vs 2017. 
  • More tier 2 companies are pursuing DevOps and Agile transformation as they see the opportunity to outpace tier 1 players.
  • Larger SI’s are now endorsing DevOps but struggle to align existing customer contracts with future DevOps delivery models.
  • The business case for DevOps is well accepted BUT each organisation will need to articulate this clearly supported by a CxO if there is to be company wide acceptance for change.
    • Customer facing changes focus on value
    • Back office change focus on cost savings
  • HR plays a vital role as organisational and process re-engineering are required.
  • Outsource is an impediment to agile transformation.
  • Cloud is here to stay.
  • SaaS is growing in popularity very quickly and is no longer seen as shadow IT.

Business

  • Older establish financial brands have woken up and are learning fast. They are embracing business transformation driven by a recognition that their processes were designed to suit internal ways of working, and not the way customers wish to engage them. 
  • New and younger customers are required by older Banks to drive digital engagement. Millennials compare prices/products online and relationship selling has lost relevance.
  • In the space of 12 months we are seeing legacy brands that last year were asking what is DevOps are this year executing pilots as they look to scale.
  • Real scale challenges are starting to emerge.
  • More than one organisation observed that e-engagements with B2C customers leads to a heightened expectation on the customers part that response will be instant at best or prompt at worst.
  • One leading insurer printed 260,000,000 pages of paper and sent 20,000 letters in 2017. These letters are mostly returned as scanned attachments to email. This stresses back office processes which need to be lean and automated to cope with an increased pace and heightened expectation from their customers.
  • Innovation is being democratised. There is new thinking on innovation and changes to thinking on project funding. Models such as Adobe Kickbox provide anyone in an organisation with increasing levels of funding starting at $1,000 to bring ideas forward. If the $1,000 yields results the individual can apply for the next level of funding which is $5,000 and so on up the funding levels. 
  • With DevOps and innovation models like Kickbox, the business can start thinking differently.  Instead of funding one idea at a cost of 100K to bring to market, why not have 20 ideas at a cost of 5K each. This is Minimum Viable Innovation. 
  • As organisations de-silo they are more open to sharing with and learning from non competitors.
  • Open for very large organisations (10,000+) means active exploration of what good looks like. For example capital markets business units look to retail or one country looks to another country.
  • New ways of engaging the business are emerging. For example feature flag releases mean the business doesn’t have to wait for up to 6 months for what it requires. If there is poor implementation of a feature, that feature can be withdrawn not the entire release.And if the business knows it can have lots of releases .. then it wont get tetchy about what is and is not included or indeed what it can remove.

 

Changing role of Project Management

  • As organisations try to come to terms with DevOps, pre-existing project funding and management models collide with concepts such as MVP.
  • More and more large fintech organisations are organising around Product.
  • PM’s depending on their existing skills, domain knowledge and capacity for growth can think about different ways to add value. The Product Owner role is best suited to business SME’s but some PM’s if they have been working in one domain for some extended period could be suited to this role.
  • Product Manager … a role that spans multiple Product Owners to coordinate several scrum teams may also be suited to PM’s that have Program Management capability.
  • The business is increasingly looking for Portfolio Management and this is a role existing PM’s can fulfill as an element of Product Management. Continuous Planning is now viewed as a good solution.

Technology

 

  • Metrics…a second generation of metrical measurements is emerging as cycle times reduce. For example the number of times a release breaks or length of time to build. More data means deeper understandings of component fragility, engineer productivity likelihood of outages. Smarter organisations triangulate their SDLC metrical data to ensure there is no ‘gaming of the system.’
  • Database is hard. Very hard and when trying to move to serverless its a showstopper.
  • There is clearer thinking on new target architectures. Companies are trying to strangle monoliths into microservices as a route to cloud. There is evidence of ops leading this thinking and the challenge is to merge ops rigour, dev productivity and business process innovation for optimal results.
  • Regulated organisations are now saying they can deploy 80% of their data in public cloud and be audit compliant.
  • There is clear evidence that companies who want to scale are abandoning in house and home grown SDLC automations for COTS alternatives.
  • It is also equally clear that as orgs scale they are adopting a ‘standard’ tool chain which flies in the face of the agile manifesto to let teams select their own tools.
  • Smarter companies encourage innovation on their standard tool chain and time box efforts and measure improvement. DIY is therefore permitted within boundaries.
  • DevOps implementations are from a central hub. In spite of the agile manifesto which says teams should place people ahead of process and tools at least 3 organisations who presented identified the need to build centralised expertise to disseminate knowledge/tooling etc to remote branches. Remote however has local staging and ability to go/no go on releases and provides local support.
  • This is evidence of lack of available DevOps skills to implement more federally but not necessarily a lack of willingness to do so in the medium term.

Culture and Org Structures

  • Financial organisations understand that their own culture can be a problem. They need to have more openness and a millennial friendly working environment that can attract younger people who will build what the younger generation want.
  • Persuading business people to engage as Product Owners is not easy. Agile teams trying to engage the business bump into Project Portfolio approaches that want to plan years in advance when agile teams want to plan just the next release.
  • Organisation structure is an impediment to new ways of working. Intellectually everyone knows you need a team to be pulled from silos to get to ‘done’. Existing silos and more informal fiefdoms mean new team structures are very difficult to impose.
  • Faux structures such as guilds are emerging.
  • A new role, DevOps Champion, is being formalised by some companies.
  • Legacy is by far the biggest impediment to progress. Older people nearer to retirement have to be managed correctly. These folks tacit knowledge is an essential element of emergent design processes. These processes can be energising for more experienced staff once they believe its not a waste of time but you may have to show them it works elsewhere.
  • Reward systems based on more power equating to more direct reports need to be superseded by promotion models based on incrementing value add. This implies new measurement systems to compensate people in a different manner than the existing career plans and contracts of employment. HR engagement is critical.
  • Several organisations are moving office and re-organising office space to bring about situations where biz, dev and ops teams sit adjacently. Other organisations are organising around product to achieve the same objective. Some organisations are creating more informal space, more open space with set aside quiet spaces for more concentrated work.
  • When older more established organisations decide to change how they work, they are not afraid, change is something they are experienced at. They start with training their own leadership to introduce servant leader models and strategies to empower teams. There is a belief that this approach will reduce cost of management. They anticipate high levels of attrition (up to 30%) and build this estimate into their transformation budgets.
  • A second generation of DevOps mgt is appearing. Hitherto there was no experienced IT Mgt for DevOps. Now some of the early adopters are losing their senior people to organisations that are just starting their journey. These people are worth watching as they are correcting their first generation errors and should be able to accelerate DevOps journeys with higher quality if the business will let them. This is down to strong leadership and clear business vision.
  • Manual testers are being trained to become test automation experts and this brings them closer to the work that development is doing.
  • Organisations that have outsourced are realising that if they wish to change they must either insource or ensure partners work to simple templates that conform to new ways of working. This can include tools and processes and in turn if there is an insource plan at some point in the future this approach makes it easier to achieve.
  • Co-lo is an essential element of a change program and if you cannot co-lo then at least form teams from countries in adjacent time zones.
  • Organisations with aging monoliths are increasingly in search of reduced downtime as a means to drive business case for investment in DevOps.

Much confusion abounds on how to integrate support (ITIL) processes into a DevOps environment. The latest edition of the DevOps Foundation does now cover this.

  1. Agent models work well to bring together people and artefacts that can to swarm on problems via chatops.
  2. If support calls are increasing, slow down production and fix problems before resuming.
  3. If support calls are increasing revisit staging to ensure fewer bugs make it into prod.
  4. DevOps teams own code into prod and beyond. Levels of engineering expertise(L1,L2,L3) are less relevant.
  5. Support should focus on monitoring and troubleshooting  ie proactively anticipate problems rather than react.
  6. Automation of alerting and artefact collection relating to incidents is a noticeable new trend and this means ‘bots’ that can engage users and then span repo’s/knowledge bases etc.

 

 

Leave a Reply

Your email address will not be published.