I spent two days at the O’Reilly Software Architecture Conference in NYC last week meeting and learning from some world class software architects. As I often find at conferences, my favorite part was meeting and chatting with some really impressive and interesting people. There is so much value in pulling people together that are all working on similar goals– we all have so much to learn from each other.
I’ve put together my thoughts and learnings from three of my favorite talks at the conference.
Adam Tornhill (Empear) — Software (r)evolution: A crystal ball to prioritize technical debt
With software becoming more and more complex, technical debt is becoming a more universal problem for development teams. Modern systems can consist of million lines of code and multiple development teams, resulting in an environment where the holistic overview of the system is lost and everyone is focused on their own projects and features.
Adam’s theory addresses the possibility of combining the intelligence of all individual programmers and making decisions based on data from how the organization as a whole actually interacts with the code. The method addresses not only problematic code, but also the effects of the social dimensions of the teams working on the software– the process and the people behind the technology. In looking at software in this way it is easy to prioritize the parts of the system that benefit from improvements, detect social and organizational issues and ultimately make practical decisions on how to reduce your technical debt that are based in data.
Michelle Brush (Cerner Corporation) — Migrating an architecture across batches and streams
Michelle gave pragmatic advice from her experience migrating Cerner’s HealtheIntent platform across batches and streams. The platform grew up as a batch system where processing occured hourly and some data even landed only daily or monthly, but the batch world was mostly forgiving and predictable.
When Cerner developed the need for a near-real-time system, they shifted their Hadoop data processing pipeline to a streaming one using Storm and Kafka. As a result, the architecture team had to rethink everything from the technology and process (support, monitoring, alerting, performance measurement) to the people (team structure and associate onboarding).
The pragmatic nature of Michelle’s talk made it super valuable and easy to learn from her experience– this talk is definitely worth checking out for yourself!
Matt Stine (Software Architecture Radio) — An architect’s guide to evaluating cloud services: 10 things to consider
Now that we’ve established that the cloud isn’t a fad, software architects are faced with the challenge of evaluating various cloud services and determining whether or not they are suitable for their company.
Matt simplified this process into 10 simple criteria that can be used to evaluate any cloud service:
- Economics: price and cost / unit of billing
- Applicability to business case
- Resiliency requirements
- Scalability requirements
- Security requirements
- Regulatory requirements
- Degree of provider lock-in
- Required “undifferentiated heavy lifting”
- Differentiating features
- Available tooling
From these criteria he demonstrated the process of building a simple scorecard with a weighting system based on your technology and team. There is never going to be one right decision around these options, but the decision process can be simplified across teams given these important criteria.