Day two of the O’Reilly Software Architecture Conference began with a keynote from Christopher Grant, senior architect at The Home Depot, titled ‘Evolving toward microservices: How HomeDepot.com made the transition’. The first customer-facing web page for The Home Depot was deployed in 1996, and since this time their web presence and software application estate has grown considerably. The integration of new and old technologies and applications led to increasingly long lead times and fragile deployments. Moving to an agile way of working, defining ‘domain spaces’ of responsibility, and utilising continuous integration practices reduced this friction greatly. In 2015 The Home Depot technical team fully embraced cloud and microservices, which presented new architectural challenges.
Grant provided four key pieces of advice for successfully making major architectural changes: have a vision; understand objectives; choose what matters; and implement in stages. Further suggestions included: ‘decompose and define boundaries’ - clearly defining business products and domains (and the associated data models and people structures) help map areas of responsibility; ‘architect for change’ - attempt to anticipate future changes (where possible), move from being reactive to proactive, embrace the notion of ‘last responsible moment, and expect (but minimise) future work; and ‘implement safety’ - automate early and often, and attempt to apply in-place upgrades and greenfield work as appropriate (no one approach works with all use cases). Final recommendations that Grant has learnt from working in the field included utilising feature switches and traffic throttles in order to limit and control issues, and encourage independence between teams - don’t overly rely on central control.
When making major architectural changes: have a vision; understand objectives; choose what matters; and implement in stages
Chip Childers, VP Technology at Cloud Foundry Foundation, presented the second morning keynote, ‘Going cloud native: It takes a platform’, and argued that embracing a ‘platform’ is essential when creating ‘cloud native’ and microservice-based applications. A platform should simplify the flow of software deployment and provide development patterns and processes, manage cross-cutting concerns like security and logging, be highly automated, and scaled with ease. Applications that have been designed according to the ‘Twelve-Factor Application’ principles, or constructed as microservice systems, or have been packaged within containers, are a perfect fit for modern platforms-as-a-service (PaaS) offerings, such as Cloud Foundry, Heroku or OpenShift.
Childers stated that his recommendation to utilise a platform is “not just about tech” - the economic argument is also strong. The correct platform may help with “industrialising the craft of software development”, and the notion of ‘takt time’ was also discussed in relation to the benefits offered by standardising certain operations (such as deployment) using a platform. Takt time is derived from the German word Taktzeit, which means “the average time between the start of production of one unit and the start of production of the next unit, when these production starts are set to match the rate of customer demand”. The concluding message from Childers was that platforms provide constraints on a software system, and “the right constraints free us to be creative where it matters”
During the final opening keynote, titled ‘Let's make the pain visible’, Janelle Klein, CTO of New Iron and founder of Open Mastery, provided an overview of the ‘Idea Flow’ learning framework, which provides a strategy for measuring the friction in developer experiences and makes the problems visible. Klein proposed that the typical software development process often follows a negative repeating pattern across organisations, moving from “differing problems, to painful releases, to thrashing, and finally project meltdown”. Clearly the strategy being used must change, and we must make the ‘pain’ of software development more visible. However, there are two primary obstacles - the first is that the ‘management’ typically speak a different language than the ‘engineers’ (i.e. “the wall of ignorance” between management and development teams), and second, developers often work on improvements that don’t make a difference.
Klein proposed the issues that cause the most pain and ‘friction’ within software development are typically ‘human factors’, and not technical debt, which is often suspected.
Arguably the most difficult part of software development is “determining the right problems to be solved”, but many organisations do not have a valid strategy for approaching this issue. Quoting Richard P Rumelt, “A good strategy is a specific and coherent response to - and approach for overcoming - the obstacles to progress”, Klein asked the audience whether our current strategy to identifying and fixing the development friction/pain of “high quality code, low technical debt, easy to maintain code, and good code coverage” is the best approach? The talk concluded with a call to action to “learn and share together as an industry” in regards to making the pain of software development more visible (and manageable). Additional information on the ideas presented in this talk can be found in the Leanpub book entitled “Idea Flow: How to measure the pain in software development”
Mark Bates, founder and chief architect of Meta42 Labs, presented ‘Microservices in reverse’, and discussed his journey from building a new greenfield web-based application for a startup that used Go-based microservices and an Angular.js UI, to ultimately rebuilding the entire codebase as a Ruby on Rails monolith. The key message presented for teams developing software that will assist a company in searching for product/market fit, then do the simplest thing possible. Ego may drive developers to select the ‘latest and greatest’ technologies and architectural styles, such as microservices, but Bates found that the most important value for him was to minimise the cognitive ‘scope’ required when developing the application, as he was working on the startup in his spare time. With a RoR-based monolith, the number of moving parts and orchestration required was minimised.
As I was working on the software part time, I was keen to minimise the [cognitive] scope required when making changes. A RoR monolith was the best choice in this case
James Stewart, Director of Technical Architecture at UK Government Digital Service, presented ‘The architect as coach’. The talk began with an assertion that the era of 'big IT' is over, and now architects and developers (rather than vendors) have great power, which must be wielded responsibly. Stewart argued that due to the pervasive nature of technology throughout the public and private sectors, “software is politics now”, and accordingly architectural decisions can have wide-ranging consequence. Asking what it means to be a ‘senior technology leader’ within an organisation, Stewart stated that often your responsibilities are broader than your training, and the role is typically to see the big picture and drive organisational change in the correct direction. A key skill for this position is to know what questions to ask throughout all levels of the organisation, and also appreciate that without support from the top, transformative ambition cannot be fulfilled.
Seven key points for driving transformation were presented throughout the presentation:
- Understand the people you are influencing
- Influence the influencers - often the most senior leaders are very busy, and gaining access to influence them is difficult. However, they are typically assisted by a team, who are often easier to gain access to and influence
- Deliver value early and understand its value - strive for fast feedback
- Find common reference points and principles
- Talk their language - empathise with senior leaders, and ensure that you are presenting issues using the same vocabulary and terminology as they are
- Accept that this takes time, and you can’t be proprietorial
- Bring the team with you
More details on the O’Reilly Software Architecture conference that ran in New York City can be found on the conference website. Additional events in the O’Reilly Software Architecture Conference will take place this year in London 18th-21st October (CFP deadline 2nd May) and San Francisco 13th-16th November (CFP deadline 1st June), and the corresponding call-for-proposals web pages are now available.