Recent & Upcoming Events

More Talks

Software developers often long to upgrade their careers by becoming software architects. But many don’t realize that although the job title suggests a work day focused on technical decision making, the reality is quite different. Over two days, Nathaniel Schutta details the skills you need for success in the real world, where communication trumps coding, as he walks you through what it means to be a successful architect.

Selected Publications

New software technology appears every year. Like clockwork, another language, library, pattern, or approach will arrive on the scene with plenty of hype and developer enthusiasm. As someone whose job requires making architectural decisions, you need to evaluate these new technologies with an eye toward the inevitable tradeoffs before deciding if a new framework or language is right for your project.
Thinking Architecturally, 2018.

Part of what defines an application as cloud native is an application and management style described by the 12 factors. While these seem simple at first, each of them just the top of the iceberg of recommendations. Coté plumbs the depths with Nate Schutta to see what’s under the waterline. They also discuss where state is in this stateless model and how it’s managed.
Pivotal, 2018.

In this episode of the O’Reilly Programming Podcast, I talk with Nathaniel Schutta, a solutions architect at Pivotal, and presenter of the video I’m a Software Architect, Now What?. He will be giving a presentation titled Thinking Architecturally at the 2018 O’Reilly Software Architecture Conference, February 25-28, 2018, in New York City.
O’Reilly Media, Inc., 2017.

Nathaniel Schutta explains why an architect’s job is to be a storyteller. Architects are essentially the Rosetta Stone of an organization, providing translation services (or, as some would call it, the elevator between the executive suite and the development floors). The challenge lies in not only crafting a compelling message but doing so for wildly disparate audiences.
O’Reilly Media, Inc., 2017.

Developers focus on functional requirements, but once you step into the architect role, your world is increasingly inhabited by the ‘-ilities’—the nonfunctional or quality attributes of a software system. But which ‘-ilities’ matter and which don’t? Nathaniel Schutta explores approaches to architectural problems and explains how to best document the inevitable decisions we arrive at.
O’Reilly Media, Inc., 2017.

This week I have the opportunity to sit down with Nate Schutta. We had a fascinating conversation about the history and current state of Javascript along with it’s evolution. We also dive into the evolution necessary to grow as a software engineer.
No Fluff Just Stuff, 2017.

Being a software architect is more than just possessing technical knowledge. It’s about thinking like an architect, being a leader, and understanding the architectural elements, patterns, and styles necessary to create effective software architectures. In this Learning Path, learn the essential skills you need to be effective in this role.
O’Reilly Media, Inc., 2016.

Do your diagrams truly visualize the software your team has to make? Do they actually guide development? Or have you become the dreaded “white board architect,” the pie-in-the-sky scribbler of useless boxes and arrows? Software architect Nathaniel Schutta erases those lousy sketches and replaces them with the diagrams you need: concept, context, component, deployment, sequence, security, and disaster recovery.
O’Reilly Media, Inc., 2016.

You’re giving a talk on a subject you know inside and out and your audience is staring at their cell phones. You’re boring your audience. Maybe you could use some help. In this fast paced humorous video, presentation pros Neal Ford and Nathaniel Schutta provide that help. They’ve spent thousands of hours giving talks at seminars around the world and even more hours listening to bad ones. They’ve used this experience to de-construct “The Presentation” into a set of patterns and anti-patterns. What are patterns and anti-patterns? They’re simply names (often funny ones) for the building blocks of good presentation practices (patterns) and the stumbling blocks of bad ones (anti-patterns). Ford and Schutta offer concrete instruction in how to plan your presentation, handle a wide variety of presentation types, manage your audiences, and deal with constraints and surprises
O’Reilly Media, Inc., 2016.

Becoming a software architect is a longed-for career upgrade for many software developers. While the job title suggests a work day focused on technical decision-making, the reality is quite different. In this video, software architect Nathaniel Schutta constructs a real world job description in which communication trumps coding.
O’Reilly Media, Inc., 2015.

Do your diagrams truly visualize the software your team has to make? Do they actually guide development? Or have you become the dreaded “white board architect,” the pie-in-the-sky scribbler of useless boxes and arrows? Software architect Nathaniel Schutta erases those lousy sketches and replaces them with the diagrams you need: concept, context, component, deployment, sequence, security, and disaster recovery.
O’Reilly Media, Inc., 2015.

Presentation Patterns is the first book on presentations that categorizes and organizes the building blocks (or patterns) that you’ll need to communicate effectively using presentation tools like Keynote and PowerPoint.
Addison-Wesley Professional, 2012.

Abstracts

By now, just about every organization has at least a phalanx or two in the “Cloud” and it is, understandably changing the way we architect our systems. But there is a lot of confusion around cloud native, 12 factors, modular monoliths, serverless…how does a busy technologist make sense of it all? Despite what you may have read on the Internet, there still are no silver bullets - just a set of tools that we need to apply at the right time in the right place. In this talk we will survey the various options today’s application teams have at their disposal looking at the consequences of various approaches. We will clear up the buzzword bingo giving you a solid foundation as you take your cloud native journey.

Today our world is full of things that are “as a service” - infrastructure, containers, platforms, software…and of course functions. With developers just now wrapping their heads around application platforms and containers, what are they to make of functions as a service? How does a busy developer cut through the hype and make sense of the world of serverless, Kubernetes, Spring Cloud Function and all the rest? This talk will clear up the confusion! We examine Riff, a FaaS built atop Kubernetes. We will discuss where functions and serverless fits in your world, and how you can get started with some simple demos. Though functions aren’t a silver bullet, they are an important part of the development toolbox; this talk saves you from the buzzword bingo to give you a solid foundation of the FaaS landscape.

Software developers are seemingly on a perpetual path to discover the one true technology to unite them all. And yet there are no golden hammers, there is no one size fits all solutions. Instead we have to carefully weigh the pros and cons of our options and in some instances take the least worst approach. Rather than continue down this trail of disappointment, we need to embrace the and not the or. There can only be one does not in fact apply to software.

Nathaniel Schutta explains why an architect’s job is to be a storyteller. Architects are essentially the Rosetta Stone of an organization, providing translation services (or, as some would call it, the “elevator” between the executive suite and the development floors). The challenge lies in not only crafting a compelling message but doing so for wildly disparate audiences. (The pitch you give your developers will not go over well with the executives, for instance.) While we may not want to adopt iambic pentameter anytime soon (though who knows, that might encourage more people to read our various artifacts), we must consciously think about the story we are telling.

Becoming a software architect is a longed-for career upgrade for many software developers. While the job title suggests a work day focused on technical decision-making, the reality is quite different. In this workshop, software architect Nathaniel Schutta constructs a real world job description in which communication trumps coding.

As a developer, your focus was squarely on the “functional requirements” aka the business capabilities your application must meet. But once you step in the architect role, you discover a world inhabited by “the ilities” otherwise known as the non functional or quality attributes of a software system. But how do we know which ilities matter and which ones don’t? And much as we may want to turn every knob up to 11, many ilities are inversely related - maximize one and you by definition minimize another.

Development teams often focus on getting code to production losing site of what comes after the design and build phase. But we must consider the full life cycle of our systems from inception to deployment through to sunset, a discipline many companies refer to as site reliability engineering.

Back in the day, it used to be so simple. Our projects had a main.js file that contained a few hundred lines and every so often the corporate communication department would ship out some new CSS files. But now things are not quite so easy. With more and more single page apps containing thousands or hundreds of thousands of lines of JavaScript, we’re going to need a bigger boat.

By now I bet your company has hundreds, maybe thousands of services, heck you might even consider some of them micro is stature! And while many organizations have plowed headlong down this particular architectural path, your spidey sense might be tingling…how do we keep this ecosystem healthy?

If you’ve spent any amount of time in the software field, you’ve undoubtably found yourself in a (potentially heated) discussion about the merits of one technology, language or framework versus another. And while you may have enjoyed the technical debate, as software professionals, we owe it to our customers (as well as our future selves) to make good decisions when it comes to picking one technology over another.

Rich Hickey once said programmers know the benefits of everything and the trade offs of nothing…an approach that can lead a project down a path of frustrated developers and unhappy customers. As architects though, we must consider the trade offs of every new library, language, pattern or approach and quickly make decisions often with incomplete information. How should we think about the inevitable technology choices we have to make on a project? How do we balance competing agendas? How do we keep our team happy and excited without chasing every new thing that someone finds on the inner webs?

Recent Posts

I’m very excited to announce my latest book project, Thinking Architecturally, is now available! My thoughts on being an architect, dealing w/ change, etc. If you’ve attended one of my talks in the last few years, you will recognize some of the material. The reception has been beyond my expectations and I am delighted by the responses I’ve received from people that have read the book. If you are interested in perusing the material, it is a free download from the Pivotal Resource center.

CONTINUE READING

Part 4 of my “Responsible Microservices” series went live yesterday! Should that be a Microservice? Part 4: Independent Scalability In the first part of this series, we laid out a set of principles to help you understand when microservices can be a useful architectural choice. We promised follow-up pieces describing each of the factors in more detail. In the fourth post of the series, we explore independent scalability. Let’s take a quick spin in our hot tub time machine and head back to an era before cloud, microservices and serverless computing.

CONTINUE READING

Part 3 of my “Responsible Microservices” series went live earlier this month! Should that be a Microservice? Part 3: Independent Life Cycles In the first part of this series, we laid out a set of principles to help you understand when microservices can be a useful architectural choice. We promised follow-up pieces describing each of the factors in more detail. In the third post of the series, we explore independent life cycles.

CONTINUE READING

Part 2 of my “Responsible Microservices” series went live last week! Should that be a Microservice? Part 2: Multiple Rates of Change In the first part of this series, we laid out a set of principles to help you understand when microservices can be a useful architectural choice. We promised follow-up pieces describing each of the factors in more detail. Here’s the first of such posts; let’s explore multiple rates of change.

CONTINUE READING

I wrote a post summarizing some advice that Matt Stine and I used with a client… Should that be a Microservice? Keep These Six Factors in Mind You’re writing more code than ever before. The trick is knowing what should be a microservice, and what shouldn’t. These days, you can’t swing a dry erase marker without hitting someone talking about microservices. Developers are studying Eric Evan’s prescient book Domain Driven Design.

CONTINUE READING

Contact