Agile Coaching Capability

•November 14, 2015 • Leave a Comment

Yesterday, during the last day of Construx Software Executive Summit 2015,  Lyssa Adkins presented, Developing Your Staff’s Agile Coaching Ability.  The talk validated my view that Agile Coaches are key to the uptake of agile.  Many organisation believe they can send staff on 2 day Scrum course, get the certification, and immediately see the benefits.  This mindset is utterly wrong.  The change from Command-Control to an embracement of agile values doesn’t happen overnight.  Agile coaches are key to aiding team to move into the new world.  I’ve not read Lyssa’s book, Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, but will do shortly as I’m expecting it to be good based on the talk yesterday.

Lyssa’s “Developing an Internal Agile Coaching Capability” offer an interesting read:

organizations need solid Agile Coaches to help establish the deep, institutional capability required to become a truly agile organization. Team agility is a first step, but ultimately withers without organizational agility. Organizational agility requires an agile coaching capability to establish self-organized teams (a new organization innovation), as well as a new form of agile leadership amongst management, and a re-thinking of organizational structures, policies and culture.

One of the key points in the above extract from Lyssa’s paper is “re-thinking of organizational structures”.  In my view, many organizations attempt to be agile at the team/project level, but the organizational structures around them remain in the old world (managers, leaders, C-Level’s, HR, etc) which effectively become impediments in the organisation adoption of agile.

This leads nice to agile leaders, and the need for such individual who have:

the chief responsibility is to increase flow, minimize waste, and see (and help others see) the larger system.

A lack of agile leaders and coaches will constrain the ability to embrace agile.  Without C-Level embracements of agile leadership, organizations will suffer challenges on the road to embracing agile.  Managers and leaders need to re-think their roles and responsibilities in an agile world.

Adopting Microservices

•November 14, 2015 • Leave a Comment

Few useful articles worth reading before you venture down the latest buzzword road:

  • An operations model for Microservices
  • Adopting Microservices at Netflix: Lessons for Team and Process Design
  • Adopting Microservices at Netflix: Lessons for Architectural Design
  • Building microservices with Spring Cloud and Netflix OSS, part 1
  • Building microservices with Spring Cloud and Netflix OSS, part 2
  • Building Microservices, part 4. Dockerize your Microservices

Speed is important from the perspective of code complete to production (DevOps etc).  Versioning needs a strategy from day 1 if each microservice team is deploying on a different release schedule.

LIQUi|> Quantum Simulator and More

•November 14, 2015 • Leave a Comment

Microsoft Research has released LIQUi|> on github that offers:

LIQUi|> is a software architecture and toolsuite for quantum computing. It is currently being developed and will include programming languages, optimization and scheduling algorithms, and quantum simulators. Ultimately, LIQUi|> will be used to translate a quantum algorithm written in the form of a high-level program into the low-level machine instructions for a quantum device.

Only downside is that its Windows based, so if your on OSX, you need a VM :(

Ethereum Devcon – Smart Contracts and Opportunity

•November 13, 2015 • 1 Comment

This week I’d have liked to have been in two places at once.  I’m in Seattle for the Construx Software Executive Summit, but would also have liked to have been in London for the Ethereum Developer Conference, unfortunately the clone machine isn’t working :(  There are however numerous articles on the web already from Ethereum Devcon, which should allow anyone who missed the conference to “catchup”:

  • First Day
    • Of no surprise, scaling was one topic from day 1, with discussion around “hub and spoke” model, verification layers and asynchronous programming
    • Metamask demo available here.
    • Nice to see IPFS written in go.
  • Second Day
  • Third Day
  • Fourth Day
    • UBS Smart Bond (1:56:00) – smart contract, Bond Coin, benchmark contract
  • Fifth Day
    • Bank Panel discussion blockchain – UBS, Barclays, SocGen
    • Top priority areas for banking blockchain innovation:
      • Mandatory Regulatory use cases via shared ledger
        • KYC – shared “know your customrr” control process
      • Operational Efficiency/Cost Reduction (Ops and Tech)
        • Asset registry
        • Settlement (UBS interested in this area in particular)
        • Netting Pool – complicated problem to get settlement efficiency due to the current solutions of stopping time to optimise
      • Business Growth from an investment bank perspective
    • Still challenges that need work in the Smart Contract area – expect The Alan Turing Institute to aid here

.Some video’s are available here.

Two Tier Blockchain

•November 5, 2015 • Leave a Comment

Gideon Greenspan over on the MultiChain blog offer a very interested read around Smart Contract and Ethereum, “Smart contracts: The good, the bad and the lazy”.  After pulling the Ethereum run code on all miner nodes to pieces, Gideon proposes a two tier blockchain concept – the best of all worlds? :

The lower tier would be built on bitcoin-style transactions which are processed instantly and concurrently, and don’t need to wait for block confirmations. These transactions could perform simple movements of assets, including safe atomic exchanges, without resorting to smart contracts. But this lower tier would also be used as a blind storage layer for the programs and messages that represent more complex business processes, embedded as transaction metadata.

As for the upper tier, each network participant would choose which programs they want to run. Some might choose to run none at all, because they are only interested in simple asset movements. Others might execute a small group of programs that are relevant to their internal processes (with the knowledge that this group exchanges no messages with programs outside). A few might even opt for global execution, processing every message for every program, just like Ethereum. But the key thing would be that every node runs only the code it needs to.

I particularly like the smart bond reference at the end of the article – often thrown around in other texts.

May also be worth having a read at the HyperLedger blog around Smart Contracts,  Unsurprisingly, their code has dropped off github for obvious reasons – being bought by Digital Asset Holdings

Hopefully in a future posting Gideon will provide some insight into “Regulatory transparency“, and possible how MultiChain can aid on the Mifid II road

Microservies Patterns

•November 3, 2015 • Leave a Comment

Microservice Design Patterns article offer a view on the software patterns that could be used to build microservices.  Clearly the proxy and aggregator patterns offer some structure in avoiding REST microservice’s overload from a user interface perspective.

This leads nicely to Ray Nicholus “The Future of Web Development – React, Falcor, and ES6” article, noting in particular the need to keep things “simple”, avoiding the unnecessary request overhead, large number of requests, and needlessly large response payloads, which in a trading application can kill performance/latency/user experience, and thus the clients.  You won’t get much argument around React from myself, and likewise the Falcor I find sensible, since I used such concepts on a number of projects back in time (too long ago).  Webpack – agree again.  Overall a good article.

Moving on to “Do Good Microservices Architectures Spell the Death of the Enterprise Service Bus?” which provides a good list of high level challenges of Microservices.  Its nice to see Swagger mentioned around contracts.  Likewise a nice callout to in-memory data grids, and not just the classic data cache.

Microservices are independent, scalable services. A modern architecture uses a scalable platform, which allows automating deployment of different technologies / services / applications independently. Use the tool(s) of your choice to define service contracts, implement (micro)services and service discovery, automate independent and scalable deployment. Coordinate different (micro)services and react proactively in real time to events by doing event correlation in-memory. That is how you create a good microservices architecture.

One of the thorny questions that needs to be decide from a software stack perspective, is the language of choice that the microservices will be implemented in.  If we assume for this discussion that REST+JSON are used to define the microservice contract, then some may lean towards a JavaScript stack for the microservice to leverage JSON.  Others may take the Java road, and incur the DTO overhead.  Time to consider Falcor again?  Another option is to avoid the standard road, and consider Clojure.  On the Clojure road, you could leverage Prismatics Schema and compojure-api (swagger’d) to declare lightweight data contracts – code is data, data is code.  At the end of the day, the Clojure is still running on the well known two VM world (JavaScript and JVM) and similar to one of the arguments of Node.js as the server software stack, offers the developers a consistent experience from client to server, rather than requiring different skillsets/teams

Trading with Blockchain Digital Identity

•November 3, 2015 • 1 Comment

One item that appears to not be getting much web coverage (or maybe I’ve missed them) is around Blockchain Digital Identity – specifically in the corporate space.  Take the example of two banks trading on the blockchain.  Bank A has n trades working for them, Trade A1 sells/buys with Trade B1 over at bank B.  Personal digital identity is important from a trader perspective, but the actual trade on the blockchain needs to be owned by the Bank.  Therefore you actually need both Bank and Trader identify on the blockchain.  Further, if the trader leaves the bank, the bank still owns the trade on the blockchain.  If the blockchain is permissioned, its likely the trade might only be able to see their subset of (bank) trades on the block chain.

Interested if anyone is going any work in this domain. I’m not sure onename solves this?


Get every new post delivered to your Inbox.

Join 727 other followers