INTRODUCTION
As Chief Enterprise Architect at VISA, Ryan has an impressive track record working in senior architecture roles with a big emphasis on creating products and teams that are focused on delivering customer value.
Progressing from software engineering into architecture, Ryan took the time out to provide insights into Enterprise & Cloud architecture.
VINTAGE
The importance of Enterprise Architecture (EA) in an organisation is widely debated.
How important do you classify EA in a technology environment?
RYAN:
While there are many takes on what EA should or shouldn’t be or if it even should exist, I believe strongly that any organization that builds or even buys and maintains software needs some group to think of the technical organization holistically.
When you are talking about the many, many systems that facilitate our businesses today the complexity grows exponentially over time.
This complexity must be understood by a group that can reason about the impact each component has on the whole.
This often requires deep and varied technical knowledge as well as strong business acumen.
These skills are often what we have over time used as indicators if someone is a good candidate as an Enterprise Architect.
The ability to think systemically about an entire enterprise while also understanding many of the finite details that often have widespread implications to an organization.
What you call this group is not at all important. What is important is that you have it whether formally or informally within an organisation.
VINTAGE:
Cloud Native Architecture. What is it? And what are the benefits?
RYAN:
Cloud native architecture is really just comprised of a set of current and evolving best practices for architecting software in a way that fits the cloud operating model.
While the cloud brings so many benefits that it has become table stakes for any business hoping to compete today, it also brings many new and unique challenges.
An example that I encountered early on that many have heard of if not encountering it directly is the so-called “noisy neighbour” scenario when running on cloud infrastructure.
This is when you provision an instance in your cloud provider that unbeknown to you, happens to live on a physical host with an application that is consuming more than its share of resources.
This had a direct impact on some of my early systems and we had to home-grow tools that could run load tests on newly provisioned hardware to verify the health.
While this is better these days it is still something you need to consider.
In addition to this there are many other impacts to running on the cloud such as latency being introduced by the many calls that a distributed architecture needs to make or unexpected network degradation that leads to communication failures.
These all are scenarios that must be accounted for in the cloud and are what has spawned the “cloud native” architecture movement.
VINTAGE:
How important is building the right DevOps culture?
RYAN:
You will find many, many articles these days espousing DevOps and indicating that it is about this tool or that tool or this process or that.
For me, DevOps is all about culture.
This culture is based in communication and rapid feedback loops.
This communication is facilitated by forming teams that are fully independent by way of having representation from each part of an organization including product and project management, QA, and security in addition to the “dev” and Ops” that are baked into the name.
By building this culture you will uncover so many inefficiencies in your software delivery together and can work to resolve them together.
While this often means that tooling can provide help, it is not required to building a DevOps culture.
Now, my own personal mantra when it comes to DevOps in relation to my team is that we must automate everything we can.
The reasons are many but a few that I have personally encountered through several DevOps journeys to date are below:
• We reduce repetitive work and free up our key resources to innovate
• Automation greatly reduces the amount of human errors in the delivery process.
• We make software delivery a reliable and predictable (mostly) process.
VINTAGE:
Finally, are there any books, podcasts, blogs you would recommend?
RYAN:
There are many as I like to gain insights from many different viewpoints. Some of my favourites are below.
Books
Start with Why by Simon Sinek – This should be the foundation of every organization. If you can start with why you are doing something you can better articulate the road to success.
Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim – This should be required reading for every technology leader today. It outlines the quantitative results of four years of research into how to measure software delivery performance.
The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford – Groundbreaking work that really kicked-off the DevOps movement in America.
The Manager’s Path by Camille Fournier – For technology-focused professionals, the journey to being a people manager is difficult as the traits that make great managers really flies in the face of what often makes great engineers.
War and Peace and IT by Mark Schwartz – This again should be essential reading for any technology leader or individual that aspires to be. I could say the same for any of Mark’s books!
Microservices patterns by Chris Richardson – This book lays out many of the best architectural patterns (to date) for building cloud native software.
Podcasts
• InfoQ
• Software Engineering Daily
• Software architecture Radio (very sporadic but all great content)
• Thoughtworks
• Masters of Scale
Blogs
• Hackernoon
• A16z
• AWS well-architected
• Martin Fowler
• Codingthearchitecture
• Better Programming
VINTAGE:
Thank you so much for taking the time to speak to us Ryan.
The architecture community will take great insights from this interview.
