Overview of Rhino Research

Why Rhino Research?
Rhino Research is devoted to improving the state of software practice. We do this by using our industrial and academic roots to give you the freshest and most practical advice in classes and during consulting engagements.

Our clients
We have taught classes for many kinds of clients, ranging from regular Information Technology shops, to huge internet shops, to NASA.

The good news is that software architecture is no longer a black art and the field has consolidated on a set of shared ideas as its foundation. Temperament and aptitude help, but it is now possible to teach developers the essentials of architectural design. The bad news is that mainstream developers are just now starting to become aware of these ideas, yet the scale and complexity of systems has been steadily increasing year after year.

Here are some insights to our philosophy:

  • Risk-driven architecting. You can do just enough software architecture by focusing on risks and choosing corresponding design techniques. Your designs will vary in detail depending on how risky each area is for this project, perhaps deep on security but light on auditability.
  • Democratic approach. Our courses are for developers and architects. Architecture is a kind of software design that all developers should understand, not just architects.
  • Emphasis on engineering. Our courses are on how to design software, not on how to facilitate meetings. Soft skills are a compliment to design skills, not a substitute for engineering know-how.
  • Practical advice. You will learn techniques that work in practice and learn anti-patterns to watch out for.

Software Architecture and Design Courses at Rhino Research

Course participants will leave with a coherent mental framework of software architecture, helping them to reconcile business needs with implementation issues, identify risks, and successfully design systems.

Courses

We offer a set of interlocking classes designed to suit your needs. The shorter the course, the more general the intended audience. Combining the two 3-day architecture courses yields the same content as the 5-day marathon course. Splitting the training is recommended so that participants have an opportunity to try out the new techniques (and generate questions) before the advanced material.

Course Length % Lecture Audience Content
Dine and Discover 90 min 100% Fully general What and why of software architecture
Essence of Software Architecture 1 day 90% Mostly general Dine and Discover + a tour of how architecture is done
Software Architecture with UML 3 day 60% Engineers Essence of architecture + simplified how-to + exercises
Advanced Software Architecture 3 day 60% Engineers Adds realistic wrinkles + advanced techniques
Software Architecture Marathon 5 day 60% Engineers Combined Introduction + Advanced courses
Software Design 3 day 70% Engineers Module and component design (not architecture)

The lectures in the 3- and 5-day courses contain a running example and comprise about 60% of course time. The remaining 40% are in-depth exercises designed to reinforce key concepts.

Here’s a review of a class in Houston.

Video: Lecture on Intro to Software Architecture

This lecture, recorded at the University of Colorado Boulder in September 2012, is an introduction to the major concepts of software architecture. The audience consisted of 70 seniors majoring in computer science. It is based on material taken from the book Just Enough Software Architecture.

Most developers have no formal eduction in software architecture, yet a system’s architecture has a big influence on its success. Software architecture has been intensively researched for more than twenty years now and studying it will help you do a better job of designing systems, give you names for the concepts and patterns, and help you choose between competing designs.

Conceptual Models of Software Architecture

Earlier this year, I gave talks at the GOTO Copenhagen and GOTO Amsterdam conferences. A few folks at the conferences called it "the dandelion talk" because there is an example in the middle of my conceptual model of how to get rid of dandelions in your yard. Of course the real idea is that conceptual models of architecture can help you become a better software engineer -- the difference between the 20-year-old version of yourself and the older, master-builder version of yourself. This is perhaps my favorite of all the talks I've given, so I hope that you enjoy it too.


GOTO Copenhagen talk on conceptual models of software architecture

(Opens on InfoQ website; no easily embeddable video -- but going to their site gives you both the video and the slides)

Architecture Hoisting - video of Atlanta talk

I presented my work on Architecture Hoisting last week in Atlanta. The big idea is that software often relies on global design constraints (guiderails) to achieve its qualities (e.g., reliability, security).

But you've really only got two options for ensuring those guiderails: (1) developer vigilance and (2) architecture hoisting. In the small (say inside of a data structure), using vigilance to keep an invariant is possible. In the large, architectural guiderails (self-imposed constraints that simplify the software) are much harder to ensure, as the recent remote exploit in Google Chrome (a use-after-free bug) illustrates.

The other option, architecture hoisting, has not been widely recognized so this talk gives it a clear definition, shows examples of it in use, and discusses its applicability and trade-offs.

Abstract: Software architecture focuses on quality attribute requirements, such as scalability or performance, that are overall properties of a system. This talk describes Architecture Hoisting, a a design technique where the architecture ensures an intensional design constraint (i.e., a guiderail) to achieve a global property. Discussed examples include the NASA JPL Mission Data System, Enterprise Java Beans, and the Apache Portable Runtime.

Talk on expressing architecture in code: AgileRoots 2010

This talk that I delivered at AgileRoots 2010 was recently posted (or at least I recently learned it was posted). It's one of my favorite talks to deliver and the topic is important for all developers since writing code that expresses your design intent is hard but so very helpful for everyone who must read it later (including you!).

Abstract: Because of Eric Evans' Domain Driven Design, agile developers are familiar with embedding their domain models in their code, but architecture and design remain hard to see from the code. How can we improve that? This session presents a new agile technical practice, an architecturally-evident coding style, that lets you drop hints to code readers so that they can correctly infer the design and architecture. It builds upon ideas like Kent Beck's Intention Revealing Method Name pattern and provides a set of lightweight coding patterns and idioms that let you express your design intent in the code.

Praise for my book Just Enough Software Architecture


This book reflects the author’s rare mix of deep knowledge of software architecture concepts and extensive industry experience as a developer. If you’re an architect, you will want the developers in your organization to read this book. If you’re a developer, do read it. The book is about architecture in real (not ideal) software projects. It describes a context that you recognize and then it shows you how to improve your design practice in that context.

Paulo Merson, Visiting Scientist at the Software Engineering Institute, and practicing software architect

Video: Intro to Software Architecture and the Risk-Centric Model

In case you were wondering what my book on software architecture will be like, you can now see the video that describes its basics. This talk was given at a joint session of the Denver IASA and the Agile Denver groups on 16 November 2009. The topic is the Risk-Centric Model of software architecture, which helps you answer the question, "How much architecture/design should I do?"

The first 17 minutes of the talk are a quick summary of software architecture; the remainder describes the Risk-Centric Model.

Here is a direct link to the video, in case you cannot see it embedded here:
An Introduction to Software Architecture and the Risk-Centric Model from George Fairbanks.

Syndicate content