Recent & Upcoming Events

Derby DevOps
February 13, 2018 — February 13, 2018
Devnexus
February 21, 2018 — February 23, 2018
Greater Wisconsin Software Symposium
February 23, 2018 — February 24, 2018
O’Reilly Software Architecture Conference
February 25, 2018 — February 28, 2018
Twin Cities Software Symposium
March 2, 2018 — March 4, 2018
Spring Days Boston
March 13, 2018 — March 14, 2018
JAX Finance
April 9, 2018 — April 12, 2018
JAX DevOps
April 9, 2018 — April 12, 2018
API Conference
April 11, 2018 — April 13, 2018
Devoxx UK
May 9, 2018 — May 11, 2018

Selected Publications

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

More Talks

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.

Recent Posts

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