Five things we learned from the O’Reilly Software Architecture Conference 2015.
Last week, I had the opportunity to see the first Software Architecture Conference spring to life after a winter of preparation. Software architects, with or without the official title, swarmed the halls learning from speakers and attendees alike. I count myself among the people who were learning. Many notions about this profession and skill set have become clearer to me and I’m already planning to keep the content coming. I’m also in the early stages of developing out the next Software Architecture Conference (spring 2016).
Within this piece you’ll find my takeaways and lessons learned from the event. I expect these initial impressions to both shape our upcoming exploration of software architecture and be shaped by continued shifts within software architecture.
The O'Reilly Radar Podcast: Neal Ford on the changing role of software architects and the rise of microservices.
In this episode of the Radar Podcast, O’Reilly’s Mac Slocum sits down with Neal Ford, a software architect and meme wrangler at ThoughtWorks, to talk about the changing role of software architects. They met up at our recent Software Architecture Conference in Boston — if you missed the event, you can sign up to be notified when the Complete Video Compilation of all sessions and talks is available.
Slocum started the conversation with the basics: what, exactly, does a software architect do. Ford noted that there’s not a straightforward answer, but that the role really is a “pastiche” of development, soft skills and negotiation, and solving business domain problems. He acknowledged that the role historically has been negatively perceived as a non-coding, post-useful, ivory tower deep thinker, but noted that has been changing over the past five to 10 years as the role has evolved into real-world problem solving, as opposed to operating in abstractions:
“One of the problems in software, I think, is that you build everything on towers of abstractions, and so it’s very easy to get to the point where all you’re doing is playing with abstractions, and you don’t reify that back to the real world, and I think that’s the danger of this kind of ivory-tower architect. When you start looking at things like continuous delivery and continuous deployment, you have to take those operational concerns into account, and I think that is making the role of architect a lot more relevant now, because they are becoming much more involved in the entire software development ecosystem, not just the front edge of it.”
The O'Reilly Data Show Podcast: Erich Nachbar on testing and deploying open source, distributed computing components.
When I first hear of a new open source project that might help me solve a problem, the first thing I do is ask around to see if any of my friends have tested it. Sometimes, however, the early descriptions sound so promising that I just jump right in and try it myself — and in a few cases, I transition immediately (this was certainly the case for Spark).
I recently had a conversation with Erich Nachbar, founder and CTO of Virtual Power Systems, and one of the earliest adopters of Spark. In the early days of Spark, Nachbar was CTO of Quantifind, a startup often cited by the creators of Spark as one of the first “production deployments.” On the latest episode of the O’Reilly Data Show Podcast, we talk about the ease with which Nachbar integrates new open source components into existing infrastructure, his contributions to Mesos, and his new “software-defined power distribution” startup.
Ecosystem of open source big data technologies
When evaluating a new software component, nothing beats testing it against workloads that mimic your own. Nachbar has had the luxury of working in organizations where introducing new components isn’t subject to multiple levels of decision-making. But, as he notes, everything starts with testing things for yourself:
“I have sort of my mini test suite…If it’s a data store, I would just essentially hook it up to something that’s readily available, some feed like a Twitter fire hose, and then just let it be bombarded with data, and by now, it’s my simple benchmark to know what is acceptable and what isn’t for the machine…I think if more people, instead of reading papers and paying people to tell them how good or bad things are, would actually set aside a day and try it, I think they would learn a lot more about the system than just reading about it and theorizing about the system. Read more…
Andrew Hinton on making context understandable, smart devices, and programming literacy.
I sat down with Andrew Hinton, an information architect at The Understanding Group and author of the recently released O’Reilly book Understanding Context. Our conversation included a discussion of information architecture’s role in the context of the IoT, the complexities of context, and the well-debated “everyone should learn to code” argument.
Context, information architecture, and experience design
Information architecture (IA) has always been a critical part of creating great products and services, and many would argue that, until now, it hasn’t been given the attention or respect it deserves. The need for thoughtful IA is increasing as we enter the multimodal world of IoT. Whether you call yourself an Information Architect or Designer, you need to care about context. Hinton offers up this hidden motivation for writing Understanding Context:
“I’ll confess, the book is a bit of a Trojan horse to kind of get people to think about information architecture differently than maybe the way they assume they should think about it.”
I followed up with Hinton via email for a bit more on how we need to view IA:
“People tend to assume IA is mainly about arranging objects, the way we arrange cans in a cupboard or books in a library. That’s part of it, but the Internet has made it so that we co-exist in places made of semantic and digital information. So when we create or change the labels, relationships, and rules of those places, we change their environment. Not just on screens, but now outside of screens as well. And, to me, the central challenge of that work is making context understandable.”
Understanding is what designers should be striving for as the backdrop for products.
Editor’s note: this post originally published on Medium; this lightly edited version is republished here with permission.
About 10 years ago, I worked on a project for a new system for people with diabetes. We talked with many people who had diabetes or who helped educate diabetics. I even wore an insulin pump around for several days. In short, we were building up subject matter knowledge and empathy for the people we were designing for. During this user research phase, many of us (myself included) started to have actual nightmares that we had diabetes. I remember once looking at my toes, wondering if the tingling I was feeling was the onset of diabetes. (It wasn’t — probably just my foot was asleep.) We’d empathized to the point where we really identified with diabetics and their problems, which are considerable. We had so much empathy for them, in fact, that for several weeks, we couldn’t solve the problem. It seemed intractable, given what we knew about the condition and the state of technology at the time.
It wasn’t until we were able to step away from the diabetics’ perspective and become less empathetic that we were able to come up with a product concept. We needed distance — a psychic removal — in order to really assess the problem and take action to change it. In other words, we had to act like designers, which meant we had to be more objective, to sit outside and to the left of the problem space. As this experience taught me, too much empathy can be as crippling as too little.
The O'Reilly Radar Podcast: Matt Nish-Lapidus on design's circular evolution, and designing in the post-Industrial era.
In this week’s Radar Podcast episode, Jon Follett, editor of Designing for Emerging Technologies, chats with Matt Nish-Lapidus, partner and design director at Normative. Their discussion circles around the evolution of design, characteristics of post-Industrial design, and aesthetic intricacies of designing in networked systems. Also note, Nish-Lapidus will present a free webcast on these topics March 24, 2015.
Post-Industrial design relationships
Nish-Lapidus shares an interesting take on design evolution, from pre-Industrial to post-Industrial times, through the lens of eyeglasses. He uses eyeglasses as a case study, he says, because they’re a piece of technology that’s been used through a broad span of history, longer than many of the things we still use today. Nish-Lapidus walks us through the pre-Industrial era — so, Medieval times through about the 1800s — where a single craftsperson designed one product for a single individual; through the Industrial era, where mass-production took the main stage; to our modern post-Industrial era, where embedded personalization capabilities are bringing design almost full circle, back to a focus on the individual user:
“Once we move into this post-Industrial era, which we’re kind of entering now, the relationship’s starting to shift again, and glasses are a really interesting example. We go from having a single pair of glasses made for a single person, hand-made usually, to a pair of glasses designed and then mass-manufactured for a countless number of people, to having a pair of glasses that expresses a lot of different things. On one hand, you have something like Google Glass, which is still mass-produced, but the glasses actually contain embedded functionality. Then we also have, with the emergence of 3D printing and small-scale manufacturing, a return to a little bit of that artisan, one-to-one relationship, where you could get something that someone’s made just for you.
“These post-Industrial objects are more of an expression of the networked world in which we now live. We [again] have a way of building relationships with individual crafts-people. We also have objects that exist in the network themselves, as a physical instantiation of the networked environment that we live in.”