Smart Entities Needs Agile Design

Bill Schmarzo By Bill Schmarzo October 6, 2016

While on vacation, I had a most interesting conversation with my niece’s husband, Jason Jensen.  Jason is a leading architect and president of Wannemacher Jensen Architects.  Jason’s firm specializes not only in innovative design, but knows how to turn innovative design into practical use.  In our family, you can’t have a conversation without talking about big data and the impact that data and analytics has on every aspect of the world (by the way, our political discussions are doozies).

One point that came up in our conversation was how important it was to ensure that the building was designed upfront to support “smart”; that is, how do ensure that the physical entities (smart schools, hospitals, buildings, factories, etc.) are designed in a way that facilitates the execution of the actions recommended by the analytics (for more background, see the blog “Internet of Things: “Connected” Does Not Equal “Smart””). Bottom-line: agile design is necessary support the creation of smart entities.

For example, you can’t expect to create  a smart school if the design of the school does not support the dynamic reconfigurations necessary to support different teaching, tutoring, counseling, work group, musical, athletic and community needs.  I was trying to think of a cute tagline like “data-driven design” when in reality it is “agile design supports the execution of smart.”

For example in the design of a smart classroom, according to Jason, the first step in creating a smart school is to divorce teachers from their classroom ownership.  In designing a smart classroom, the classroom is no longer defined by the teacher who occupies the classroom.  Instead, the students and the type of learning and teacher-to-student interactions that are occurring in that space define the smart classroom.  If a classroom subject requires small workgroups, then teacher creates a group study area.  If the classroom subject requires individual lessons, then the classroom needs to be able to be morphed into a study area with various seating options where the students can define their optimal learning environment.  The analytics need to uncover individual student behaviors and insights that can be used to make recommendation such as:

  • In what sort of learning and physical environment does that individual student work best given the subject matter and the teacher’s teaching style?
  • What classwork usage patterns in that sort of learning environment are most effective for which students?
  • What chair works best for the individual student given their study and learning patterns? For example, a child with attention deficit can improve focus just by sitting on a ball that forces a slight balancing.

The school needs flexibility, transparency, and furniture variation to accommodate the various education and study needs of the teachers and the students (see Figure 1).


Figure 1: Smart Schools Require Agile Design


In the school example, the designer and architect would want to create an agile layout that allowed the teachers, administrators and custodial staff to custom tailor the learning and meeting spaces to meet the specific needs of every student, student-teacher, class room and workgroup interactions around specific subject matters.  Design constructs such as rolling desks, smart whiteboards, video conferencing, and movable walls could all be dynamically reconfigured based upon what the data said was the optimal design given the workgroup, subject and task at hand.  And this would be true of other buildings such as office buildings, manufacturing plants, distribution centers, restaurants, retail stores, coffee shops, gymnasiums, etc.

Enter the Actuators

Which brings us to the important concept of “actuators.”  I first heard the term “actuator” from Peter Burris of Wikibon[1].  Peter used the term to describe the entities that turn the analytic recommendations into actions in an Internet of Things scenario. Think about an embedded processor interacting with the motor in a wind turbine to adjust the angle, yaw and speed of the blades to optimize energy production given current weather, wind, precipitation and energy market conditions.  Think about an embedded processor in a car that is adjusting the drag of the car in response to safety and traction concerns while driving on a wet road (especially the first rain of the year).  Think about the bucket of an excavator that automatically adjusts its digging angles and pressures given the soil composition and the optimal operating and performance conditions of that specific excavator (e.g., age of excavator, last maintenance date, recent performance metrics).  In each of these examples, the embedded processors are the “actuators” who are making the necessary operational adjustments based upon what the data and the analytics are telling the actuator.

But actuators don’t need to just be hardware and software.  Some actuators might be humans.  In the excavator example, the human operator of the excavator might need to make operating adjustments based upon changing weather conditions and unexpected discoveries in the soil (like a dinosaur bone or an alien space ship).   Smart entities need to integrate the human as an actuator into that process (maybe using new technologies such as augmented reality and virtual reality).


When creating “smart”, ensuring agile physical design – buildings, schools, fire stations, wind turbines, cars – is critical to supporting the recommendations that the analytics are making (via prescriptive analytics) and the actions that the actuators need to take to execute based upon the analytic recommendations.

Bottom-line:  upfront agile design supports the execution of smart.

[1] “Transforming to Digital Business” Peter Burris, July 29th, 2016

Bill Schmarzo

About Bill Schmarzo

Read More

Share this Story
Join the Conversation

Our Team becomes stronger with every person who adds to the conversation. So please join the conversation. Comment on our posts and share!

Leave a Reply

Your email address will not be published. Required fields are marked *