Modernization Hub

Modernization and Improvement
System Architecture: Strategy and Product Development For Complex Systems

System Architecture: Strategy and Product Development For Complex Systems

– [Lois] Hello and welcome to the MIT System Design
and Management program’s systems thinking webinar series. Welcome to over 500 people
from all around the world. We are very pleased to have you join us for Dr. Bruce Cameron’s presentation today on system architecture strategy
and product development for complex systems. Please note two quick items. One is that you’ll receive
a link to the slides and the recording later this week, and the other is there will be a Q&A after Dr. Cameron
finishes his presentation. Please type your questions directly into the chat
section addressed to all. And with that, we turn
it over to Dr. Cameron. – [Dr. Cameron] Thanks Lois. This is Bruce Cameron from MIT, and today we are very excited to be doing the virtual
launch of our book, “System Architecture: Strategy
and Product Development “for Complex Systems.” This is the result of
20 years worth of work, in the MIT System Architecture Lab, and we’ve devoted a lot
of the last four years to bringing this book out to the market. Brief background on myself, I run the System
Architecture Lab here at MIT, I teach in the Sloan School of Management, as well as in the School of Engineering and specifically I
teach in the SDM program for our system architecture course. I’m also the founder of a consulting firm, called Technology Strategy Partners. Let me start by saying system architecture is a, as we’ve seen it,
a very powerful idea. When we began to write this book, we observed that many of our co-workers, many of our students, many of our clients, actually had a shared
recognition of this idea and understanding of this idea, but at the same time many of the people that we spoke to about this use this term in very different scopes and
in very different context. So really what I’d like
to explore with you today is what is the power of this idea, where is it used, and what are the analysis
and methodologies that we seen around it. I will say at the very outset, this is very much a science and an art. We the authors, my co-authors
Ed Crawley and Dan Selva, harbor no fantasies that
this is a linear process, that this is prescriptive, that what I’m going to show you today is going to compute the
answer for architecture, but I’m going to try and share with you what we’ve learned from our experience over the last 20 years in this field. So without further ado I
think we’ll get started. So I’m showing on the screen, a representation of
Twitter’s architecture. This was released by Twitter
a couple of years ago, it’s essentially a call diagram for the major modules of
Twitter’s architecture, and in the bottom left, you’ll see what Twitter had captured about the performance of what they call the original architecture, and then the resulting
performance of a new architecture. This was a substantial effort
that Twitter was pushing out, I don’t know if any of you had experienced at some point challenges using Twitter, but for a time Twitter
was the world’s largest Ruby on Rails installation, and given their massive growth, had begun to see challenges
to the scalability of that existing architecture. They re-engineered that architecture, as represented here on the screen, and had achieved a
reduction in response time for a number of their performance metrics. The reason I’m showing
this to get us started, is this was labeled as the
architecture of Twitter, and the question that I
wanted to start us off with is how do we show architecture? As represented here on
the the bottom left, we would understand the
term architecture to mean the old implementation
and the new implementation of Twitter’s back-end
providing services to users. Is this the right representation? Is this the only representation? I want to contrast a number of different
representations of architecture, and we’ll try and tease
out some of the differences that we see in the use of this term. So working from Twitter’s architecture to an entirely different domain, the term architecture is used in the context of product design, as well, for physical products, and here I’m showing a number of different full suspension mountain bikes, and the question that’s being posed here is how many different
architectures do we have? Is a full suspension mountain bike an architecture for a bicycle, or by contrast would we say that there are a number of
different architectures, perhaps not nine, but a number of different architectures shown on the slide here. So this term is often used comparatively, i.e. the architecture
of this mountain bike is different from the architecture
of that mountain bike. Calling out certain features of, and again we’re sort of
faced with the question here, is the architecture a
subset of the design? Is it the entire design as realized and shown in the nine pictures here? There’s something in common between Twitter’s use of the term architecture, and the use of the term with
respect to mountain bikes, but can a term that is
used as broadly as this really have have an internal meaning that can carry between these
two very different domains. So I’m showing the first of a couple of definitions that
I’d like to share with you over the course of the next hour. The first on the left-hand side is from the International
Standards Organization, calling the architecture the fundamental organization of a system. And on the right-hand side I’m showing a definition from the Open Group, which has published a number
of architecture frameworks, and I’ve highlighted
here a formal description of the system or a detailed
plan of the system, at a component level to
guide its implementation. The question that I think
this juxtaposition begs is how much detail is required in order to capture the architecture? And on the left-hand side
I’m showing a box diagram for the electrical architecture of a BMW, and on the right-hand side I’m showing a CAD representation of that
same electrical architecture. Is the full detail that’s shown in the CAD required in order to
understand the architecture? Do we have to see the finished vehicle in order to understand its architecture? Or by contrast would we
imagine that the box diagram on the left-hand side could in fact capture the the relevant
or powerful pieces of the architecture? One of the other definitions that’s very prevalent when
we went looking around in the writing of this book, we found a whole field that really thinks about
architecture as form and function. There’s a number of quotes
that all of us know, form follows function
was a famous quote given. I want to just explore that in the context of the bridge that I’m
showing on the screen here. If we think about the
function of the bridge from an external function perspective, transporting people from
one side of this river to the other side, we can also think about internal functions of the bridge, carrying load, transmitting
load, and so on. We can talk about the form of the bridge, namely that there’s a roadbed, there are a number of cables, there are two central towers. What does this description of the form and of the function tell
us about this bridge? Well if we contrast two bridges, we might we might be able to pull out some of the relevant details
of the architecture here. You know, to the first order, the form of these two
bridges is very similar. On bottom right the same that
I showed on the last diagram. Showing the top left bridge, we again have two towers
covering the span, we have a number of cables, we have a roadbed, and yet we label these two
bridges with different names, how are they different and does that relate to the architecture? While looking at them in more detail what we would understand is that suspension bridge
supports the main span using vertical cables. That is the form. If we look at the cable stay bridge, the cables are actually a diagonal, and if we were to look
into the function here we would see that in cable stay bridge the roadbed actually
carries load in compression, compression created by those cables. There are limits to cable stay bridges, there are advantages
to cable stay bridges. The advantages are that you require substantially smaller anchor
points to land on both ends, and that the physical structure of the bridge appears lighter, or the roadway looks smaller in comparison to the truss structure found beneath the roadbed
of the suspension bridge. However there are limits that the, given that the roadbed is
taking load in compression, it’s subject to buckling, and there’s only so great a span that can be spanned by
a cable stay bridge. By contrast in a suspension bridge, we can span a much greater body of water, and yet we require substantially larger anchors on both sides in order to hold tension from the main cables. So we have names for
these different bridges, at first glance you may
not have known those names. We have a similarity in form, and we actually have
similarity in function. What this example starts to demonstrate is that the mapping of
that form to function, namely whether the roadbed here carries load in compression or not, helps tell us something about the architectural differences
between these two bridges. We do not necessarily
need to know everything about the bridges in order to understand these architectural differences. So form and function can be a guide, and really the mapping of
the functions to the form is another possible
concept of architecture that I’ll continue with here. I’ve put two more definitions here. Ulrich and Eppinger is a famous
product development text, “the arrangement of functional elements “into physical blocks.” And then I’ve quoted another text here, “the whole consists of parts, “the parts have
relationships to each other “which when put together the whole “has a designed purpose and fills a need.” So I’m calling out some of the pieces and trying to build our
definition of architecture. We have form and function. We have parts and whole. We have relationships among those. And at the end of the day, from an architectural perspective, we expect to see some emergence. We expect to see this as a system, that the sum of the elements is somehow greater than those elements individually. So to illustrate this
form to function mapping, I’m going to to show a brief example here. One of the things that
we observe in the book is that many types of
transportation systems have fundamentally the same three internal processes or functions. That, you know, at some
level they all provide lifting or supporting function, that they all have a propulsion function, and that there’s always a
guiding function at some level. There are a number of different forms that we can use to
accomplish those functions, and as we sort of mix and match the forms to those three functions, we get different systems out. So if I used wheels for
lifting, propelling and guiding I would have a car. By contrast if I used wings for lifting, a jet for propelling, and a rudder for guiding I
would have a jet aircraft. If I enumerate all of the possible different combinations here, one of the powerful pieces of system architecture as a discipline is the idea that we can begin to enumerate new architectures. We can mix and match
and try to understand, are there other architectures out there, and just for interest I’ve done that with a number of other
feasible combinations of those instruments
and internal processes, and we see a variety of different types of transportation systems, ranging from a helicopter to a jet boat. So that enumeration is powerful here. Where I’d like to take the ideas, what are the feasible combinations, because clearly not all
combinations here are possible, how do we understand this mapping. In this next example, I’ve essentially done the same thing by representing functions
that a, you know, home networking, you know, how you connect to the internet at home in order to send a message, by illustrating some
of the core functions, a number of the possible forms that I can use to accomplish those, and then trying to represent the combinations of
those form and functions. Here on the slide, what I’m showing is a
representation of a network, one possible network that
would emerge from that, but here I’m trying to
explicitly illustrate, you know, how do we map these forms to functions, which ones are tagged to which ones? I’m showing the physical
layer on the right hand side, and the link layer in the middle. I have a number of circles, which are representing the functions, and boxes which are showing
operands and instruments to the terms that we use in the book to begin to sort of tease apart
the form and function idea, but I think the real power
of diagrams like these that we’ve tried to
illustrate in the book, is trying to build an understanding of how is form mapped to function, where is form mapped to function, and what does that tell
us about the architecture? Could I take for example this diagram, which arguably is pretty
complex and not easily readable, could I predict something about the behavior of the system from just this form to function mapping, or would I have to layer
on other dimensions. So one of the ways that I’ve found to try and illustrate this question is to simplify up a level, and to really ask what are the decisions that we make when we
generate architecture, can we call these key
architectural decisions out in order to illustrate the
main differences between them, rather than going through the complexity of that form and function mapping. So what I’m showing here
are two military aircraft, just for comparison. On the left I have traditional
tube and wing aircraft, with engine showing below the wing. And on the right-hand side
I’m showing a stealth bomber, which is a configuration
called the flying wing, you’ll notice it has no vertical tail, nor does it, it has what you might call an integrated fuselage. The whole body of the flying
wing is a lifting surface. So what are the key architectural features that separate these two designs? Well, we can call a number of them off, namely on the right-hand side the engines are integrated
into the fuselage, on the left-hand side they’re more modular and slung below the wing. We could call out that there’s
a tail on the left-hand side, and no discernible separate
tail present on the right. We could show that the back
edge of the flying wing is serrated, that their control surface is pointing at 90 degrees to each other, which is different from the
alignment of control surfaces on the left-hand side. And how many of these differences would I have to illustrate
in order to argue that these are different
architectures for these two planes? So we could go through a number of them. I want to actually take
this even a step further, and ask, we made decisions as to whether we were going to choose a flying wing or a tube and wing aircraft, what now happens if we decide to build a family of those
aircraft as is very common in both the civil and the
military aerospace environment. So now I’m showing two civilian examples on the left-hand side, a family of A350s that you’ll notice differ primarily in length, and on the right-hand side
a proposed Boeing design of a family of flying wing aircraft, but for civilian transport. If we ask the same set of questions, what are the architectural features that really separate these two, we start to see some
important implications for the family here. So, what is that implication? Well it is when I design a tube and wing aircraft for a family, all else being equal I have to design, generally I keep the wings common across, and in this case the A350 family, and therefore for the wings, I have to design the lift
produced by those wings to support the heaviest possible aircraft I could design to attach to those wings. Which means that in effect
those wings are over designed, or oversized for the two smaller aircraft, and that I encounter
performance compromises as a result of that, whether they be in fuel burn
or in range or otherwise. On the right-hand side, what’s interesting is
the concept of the family suggests that I cut the aircraft in half and I add center sections in, and when I do so, what we what we notice is that I’m not only adding
weight to the aircraft, but I’m actually also
adding lifting surface. There’s a synergy here, that in essence the outboard wings do not have to be as over designed for the heaviest aircraft
because they scale, the lifting surface scales with the size of what’s called here the
blended wing body aircraft. So, I made these early
architectural decisions, I’m arguing as to
whether do I have a tail, whether do I have separate
wings and fuselage or to integrate them, and then, you know, I have
some set of consequences that are incurred
downstream in manufacturing, but also from a product family perspective here as I think about subsequent designs. And the real question to the architect is how do I pull these
downstream considerations, like how will it be manufactured, and like will we design
a family of aircraft, how do I pull those up front into the architecture process and understand is this an
important architectural feature that we need to engineer in? Is this a feature that we can
save for downstream design? How do we pull those out, can we pull those out? Is really the question
that’s being posed here. So this framing of decisions
we find is very powerful, because it’s a condensed
representation of architecture, and it allows us to in a sense trade what is an architecture
at a very early stage, we don’t necessarily have
to design the whole system in order to understand
what is its performance, we can represent it as decisions, do analysis on those decisions, and then try to understand early how those decisions
interact, or are synergistic. One of the portions of the book that we spent a fair
bit of time writing on was how do we think about
architecture as decision-support? Here I’m capturing a
distinction by Herb Simon on programmed versus
non-programmed decisions. In essence programmed decisions are well-defined, can be
modeled and optimized. I’m showing a number
of examples lower down, what’s the best market strategy
for established products, given that we know which
office supplies are available, which office supplies should
we order for our needs, and on the other end of
the spectrum I’m showing what we’re calling sort of
non-programmed decisions, which are not routine decisions, and don’t lend themselves as easily to what we traditionally think
of as decision-support, or optimization. And the latter is really where we believe decisions and system architecting fall, and the endeavor that we had for this book was simply because these decisions are non-routine doesn’t
mean we can’t capture them. How do we work to capture them? In what areas can we capture them? And in what areas does this remain a human decision process, a management decision process? So we introduce framing of
architectural decisions, and I love this quote
from Daniel Kahneman, the Nobel prize-winning psychologist, “we have no reason to expect
the quality of intuition “to improve with the
importance of the problem,” was certainly a lesson that I learned in my personal experience. And the question becomes what support can we bring to that? So we frame here architectural decisions as a subset of the design decisions, and those that are most impactful. I already spoke about the
form to function mapping, we’d expect there to
be important decisions as to how do we map form to function. These decisions determine
the performance envelope, they encode the key trade-offs somehow. And at the end of the day, we would expect that making one choice on an architectural decision
versus making another, should lead us to
architecture and products that are fundamentally
different from each other. So whether I choose to
power the front wheels or the rear wheels of a car, I would expect a very different
layout of the vehicle, I would expect a very
different performance trade-off to be taking place. How do these architectural
decisions help us in the process of developing
a product or system? Well we have two sort of tests
for architectural decisions. The first is does this decision have a strong influence on its metrics? Is it, in a sense, do we see sensitivity if I choose a front-wheel
drive layout for my car, do I see substantially
different fuel economy? Do I see substantially
different structural weight for the vehicle? And by contrast there’s a
connectivity element here. So if I make this architectural decision, and then I want to change it later on, do we expect there’d be
substantial rework to change it? Is this a decision that
I can make downstream without regard for other decisions? So thinking again about a car, the choice of cloth versus leather seats is not an architectural
decision, you know. There is an impact on a metric, cost, the leather seats are more expensive. However, regardless of whether I choose a front-wheel drive, or rear-wheel drive or an all-wheel drive
architecture for the vehicle, I can make that cloth vs.
leather seats decision far downstream in the design. It is not tightly coupled. And we believe that
architectural decisions do display this connectivity
or this coupling. So I’m going to walk through an example to try and illustrate these two and talk about architectural decisions in the context of the Apollo program. I think it’s arguably before the advent of system architecture as a discipline, as a field, as a term that people used, and I want to ask what are the differences in the possible architectures
that were available. Can we characterize the
architecture of Apollo. This was some work that
we did here at MIT. We looked at nine possible
architectural decisions for, in essence, going to the moon, and we asked the question
could we replicate the Apollo decision, as
a historical case study? There’s a number of
decisions that were clear to the folks making these
decisions at the time, notably when I first
launch into earth orbit, do I pause and rendezvous
with another spacecraft called earth orbit rendezvous? When I go to the moon, do I descend directly
on to the lunar surface or do I go into lunar orbit? While I’m in lunar orbit,
if I’m in lunar orbit, do I have any rendezvous that require me to meet up with another
portion of my spacecraft? And so on. So those decisions are listed here, and I want to explore
what are the connectivity, what is the sensitivity in
the coupling between them. I’ve shown here a picture of John Houbolt, who is known as the father of
the architecture for Apollo. He was an engineer working for NASA, who had advocated this lunar
orbit rendezvous approach of separating the spacecraft into a module that would stay in lunar orbit and a separate module that
would go down to the surface. What’s interesting when you look at the history of this program, is that there was two years in which, almost largely prior to
Kennedy’s announcement, NASA churned on possible architectures, possible decisions
about going to the moon. There was an enormous amount
of design work that took place, but there wasn’t necessarily
a speed of progress in those two years, and
that when you look at, there was a decision process to choose lunar orbit rendezvous, even though it is a risky
idea to try and meet up and then mate two spacecraft
in orbit around the moon, there were a number of fuel advantages and other advantages
that happened from that. Once this decision took place, the architecture sort of unfolded, that the design process really accelerated the rate at which the engineers were able to build technical detail into the design, it really accelerated. So this was very much a sort
of crux point for the program, the making of this decision. When we go back and
historically analyze this. what was interesting to us was, and we enumerated many
different possibilities, many different combinations
of those potential decisions, like do we meet up in earth orbit, do we meet up in lunar orbit. And then we ranked them on two axes here. One, initial mass in low earth orbit, which is called IMLEO on left-hand side, essentially much mass you
have to put into orbit. And the second on mission
success probability, or you can see that as riskiness, with the utopia point being
in the bottom-right here. And what’s interesting about the exercise, was that we found there were essentially three main architectures that
really dominate this space. There are architectures that involved what Wernher von Braun had
proposed, a direct mission. In the Monopoly sense this is do not stop, you know, continue past go, collect your $200 and proceed
further along the board. This was go directly to the lunar surface, do not stop in lunar orbit on your way, and those have in fact a
maximum success probability, but are also the heaviest architectures. We see a whole bunch of architectures that are really Apollo-like, that involve lunar orbit rendezvous. And then we see a number of architectures, like the ones that were considered by the Soviets at the time. Minimum mass, minimum crew,
one crew to the surface instead of two as was used
by the Apollo program. It’s interesting that this result was not baked into the analysis that we ran, but somehow three dominant
architectures arose, which happened to be the
three dominant architectures at play in the 1960s when
this space race was going on. So, I mentioned earlier that there are sensitivity and connectivity when we look at architectural decisions. What I’m showing here is a representation we have in the book about how do we make architectural decisions? In what order should we make
architectural decisions? And what I’m arguing is that decisions that are both sensitive, i.e.
on which our metrics depend, and decisions that are strongly connected to other decisions, should be made first, before
decisions that are sensitive, i.e. have a big impact on our metrics but are weakly connected to others, and that overall, we
should save those decisions that are insensitive and
weakly connected till last. Like the cloth vs. leather
example that I gave. So what does this tell us about how we might have sequenced the set of architectural decisions for Apollo? So if I use a model and I
plot degree of connectivity and the sensitivity of those,
of the two main metrics, what we came out with was a possible organization of
architectural decisions. So, what’s interesting is this choice of do we do a lunar orbit
rendezvous or not percolates to the top as a very connected
and very sensitive decision. We then have three other decisions, sort of decision pairs that are made. Do we depart directly from the
moon from the lunar surface, and do we arrive directly to
the lunar surface or do we not, and as well as crew and
fuel choices that we make for the different vehicles. So this is a representation
of a possible sequence for the decisions of the program, the question that we’re sort of asking with this historical case study is, if we had the ability to
look at these decisions, to compare their combinations, and help reduce the summary could we have, would we have structured
the program differently? Would this list of decisions
tell us which problems to tackle first and which
problems to tackle later on? So this really I think gives
rise to the opportunity that’s presented from system architecture, which is, you know,
that today we, you know, we build complex and increasingly
unprecedented systems, there’s very active
questions when we do so. Will they meet stakeholder needs? Will they evolve with
time, or will they die as with past architectures
and past designs? And what we assert is that
well architected systems do, well architected systems
give the design program a fighting chance to
succeed with the design, to succeed in the market and really to generate competitive advantage. Decisions taken early in the program do not ensure its long-term success, but they can certainly
handicap its success, and get the architectural
decisions for a program wrong and we see in a number
of past case studies that are written up in the book where the program never
really had a fighting chance. That they didn’t manage to make use of the synergies available, of the the real leverage
points of the architecture. On the right-hand side
I’m showing two examples that I’ve been fortunate to be involved in and we had contributors
help us with in the book. On the top-right Dr. Carlos
Gorbea contributed from BMW, some excellent work on the comparison of different architectures
for a hybrid vehicle, that was at the heart of
BMW’s decision to pursue the i sub-brand. And on the bottom-right
I’m showing an oil platform which is an example of a
system that we had studied from an architectural
perspective to try and understand what are the key architectural decisions, particularly in icebound environments. Would you design an oil
platform differently in an icebound environment, and is that somehow core to its design? So as we think about architecture, one of the other sort of
features of architecture that comes up frequently is how
complex is the architecture? How complicated is our representation? I’m showing nobody’s dream
of a server room here, what I’m calling a complicated network, and just visually it’s, you know, it’s hard to
understand what’s going on here, because there’s so much going on. This is certainly complex,
but it’s also complicated in a sense that it’s
not easily understood. It may be a very
high-performing server room or architecture, but how
complicated do we need to make it, is there an opportunity to
simplify that representation? So we talk in the book
about apparent complexity, or how complicated a system is. So complicated systems are
hard for people to understand, now complex systems involve functionality that is
difficult to deliver, but we actually try
and separate these two, that we believe one of
the roles of the architect is to reduce the complicatedness of the system representations, that the architect is there
to invest in complexity, obviously, to develop new
features and functionality, but to explain those to members of the rest of the corporation, to users, to the manufacturing environment in a way that tries to reduce
how complicated it looks. So if I contrast that
against another server room where I have tightly bundled cables, we might imagine that , you know, performing changes on
this second server room would be easier, that
it would be also easier for people to understand how
to put a new one together. So is this graphical
representation I’m showing, is this real, this is something
that we can implement. You know by contrast I’m
showing here a picture of the cockpit of the Concorde, and the number of dials and
switches in this cockpit is enormously complex,
question is, is it complicated? Did I need all of this complexity in order to deliver the
astounding performance that the Concorde offers? Now there’s a whole set of user interface design questions here, but I’m really just using
this as a metaphor to ask how much of this complexity
that’s inherent here was really required to
deliver the functionality that the Concorde delivered. And one of the things
that we’ve come to observe about architecture is good architecture helps make complex
things, complex endeavors less complicated. And they do that partially through the form and function
lens that I illustrated, there’s very much a question
how do we represent entities and their relationships, and there’s really a
question of emergence here, can we simulate, can we predict
something about architecture and the performance of a system from a set of early decisions? What is our ability to
understand downstream how this architecture will perform? Is there an opportunity to trade early? We found a number of
systems in which there was, and this is really sort of
at the core of the book. I want to speak briefly about
the role of the architect. I love this quote from Abraham Lincoln, “some single mind must master, “else there will be no
agreement in anything.” The role of the architect,
there are four parts in our new book and we
devote an entire part here to how do we manage the architecture process. How do we understand
roles and responsibilities as viewed through the
lens of architecture. What does this suggest
about, among other things, how we make corporate strategy decisions with respect to the architecture, if we’re expecting that our architecture is going to give us a competitive
advantage in the market. We call out three key roles
of the architect in the book, one of the most prominent early on being the architect reduces ambiguity for the design team by interpreting, working with and setting bounds around corporate strategy decisions and technology insertion decisions. Downstream of that, the architect is a central player in encouraging creativity
and in guiding the team as to how broad a set
of solutions to seek. And then I think one of
the real pivotal roles for many of the well-known architects that we’ve had the
privilege of working with, that really distinguish
them is their ability to manage the complexity of
the architecture downstream, to produce representations
to articulate decisions so that people can
contribute different pieces to the architecture without
without losing sight of what the total purpose
of the architecture is. And I’m showing on the slide here, a substantial corporate
decision that BMW took to exit F1 as they perceive
macroeconomic trends really in favor of entering the BMW, what became the BMW i
brand, a fuel-efficient set of vehicles, the i3 for city driving, the i8 as a representation
of what a sports car could be that was not compromising performance and yet was delivering
substantially better fuel economy. And then on the bottom graphic there, this resulted in an enormous investment in carbon fiber for BMW, how did those downstream
implications of manufacturing carbon fiber at scale, how are those represented
early on in the choice of this architecture, how did they get pulled back upstream to understand where they
were going to trade off against the other corporate
strategy decisions. This is really one of the
key roles of the architect, in our opinion. I’m going to conclude with a couple of points on patterns and styles. Because one of the things when we were looking at writing this book, and people asked us was
what are the patterns for good architecture? What patterns do they display, or is there a style of architecture that’s been more successful in the market than other markets? We’re going to illustrate these with Earth Observation example, which is a number of satellites that NASA was at a time proposing. Some of which have been
implemented, others not, to survey the atmosphere
and surface of the earth. What can we learn about patterns and styles architecture from this? One of the patterns
that we observe is that architecture problems often take the form of trying to subdivide a
number of known elements. So if I had in this case six instruments that I wanted to put in orbit, how do I choose how many
satellites I put them up with? Do I put them up with three?
Do I put them up with four? If I choose three, how do I sub-segregate the instruments into satellites? We call this the partitioning pattern, and in the book we actually introduce this as one of the what we believe are six canonical
patterns in architecture. One of the things that comes up in the partitioning pattern is what we’ve called the style here, and I’m calling it here monolithic style versus the fully distributed style. And thinking about those instruments that I showed on the previous chart, we can think about putting them all on one spacecraft, and there’d be a number of advantages, that we’d be taking measurements at exactly the same time
and probably same location, however I’d be producing
an enormously complex and potentially complicated spacecraft, versus I could think on the
other end of the spectrum, putting all of those instruments
on individual satellites. There’s a set of synergies
and a set of repulsive forces or interferences that take place there. This is one of the
tensions in architecture that we call out as a style, and one of the things that we
observe is great architects have the ability to understand what are the central
tensions in architecture, and to call them out, represent
them for decision making. On the next slide here I have illustrated the number of other what we call patterns, we believe there are at least six patterns that take place in sort of
architectural decision making. Decision option I had really spoken to from the Apollo example that
we have a set of decisions like do we rendezvous in
lunar orbit, yes or no. And then I showed the partitioning example as given a set of elements, how do I subdivide them
in the example given, how do I put them on different spacecraft, how many spacecraft do I put them on? These decisions, we see a
number of different ways to represent these decisions, and the last portion of the book is really devoted to
exploring what are the areas in which these types of decisions are well encoded for decision support, where we can expect some science
from system architecture, that we could run a model and try to understand how the
decisions can be sequenced. And where’s the boundary with the art of system architecture, where decisions are not easily
set up along these lines and what guidance do we offer? The book has a number of case
studies that talk through past system architectures
from the perspective of the architect, where
we try and call out where’s the science and
where is the art in this. I want to leave you with three
thoughts here from this talk. The first is that architecture
can be an explicit choice. It is not always, and we really, I think, prefer to succeed by design
rather than from luck. For many complex systems there’s this idea that we can’t control a complex system, and I think this book is
really a counter to that. What are the opportunities to frame architecture is a choice. And then if we do so, how do we make architectural
decisions early? How can we sequence them? How can we think about them? Regardless of whether I develop a model to support that activity, the decision representation
from a management perspective is a very powerful one. And then the final thought I
wanted to leave you with was if system architecture is really charged with making complex
systems less complicated? And that in my experience,
and I’ve had the good fortune to work with a number of architects over the course of my career, and over the course of writing this book, the great ones are really
called out as an explicit role, and see themselves in a position to manage the complexity of the representations and to manage the
architecture of a process. Not leaving it to chance. So I’m going to conclude with that. I’d like to thank many
of the people who made this book for us a reality. I have the good fortune to have a number of them with
us today on the call, and for those of you that are interested, we have a number of
contributors to the book, but where you can read more about it, but I’d really just like
to take the opportunity to thank all of the people who helped make this a reality for us. So I’ll stop there and invite questions that have been gradually
accruing in the chat window. – [Lois] Okay, Bruce. Excellent presentation, says Mark Simon. And folks are also
commenting on your book. However, the chat questions are
really more of a discussion. I have copied them and
sent them to you by email. Wonderful discussions
from Keith Chamberlain and Steve Spear and a
number of other folks, but I’m not quite sure how
to go about doing a Q&A here, since much of this is, much of what people have
entered are comments. So if anybody has any
questions or comments, please enter them into the chat section while Bruce is able to
scan what I’ve sent him, and then we can proceed from there. When you enter your question, please address it to everyone. Oh, here’s a question that was
a source of much discussion. How is architecture
fundamentally different than engineering? – [Dr. Cameron] And that’s a question that we got all the time in the class that I teach here at MIT on architecture. I think that I dispute the
premise of the question, in the sense that I believe
that architecture is a part of engineering, it doesn’t have to be
fundamentally different from, but doing architecture
right means broadening its scope beyond engineering, and some considerations as well. That if we if we treat architecture as only a technical
endeavor set by some inputs from the marketing team, that we’re really at risk of missing out on the opportunity to
engage with early customers, to engage with thought
leaders in marketing and in corporate strategy to work together to understand what the opportunity is from an architectural perspective, and also what are the
constraints that the architecture is going to impose on our
ability to go to market, on our ability to generate a product line from a given architecture. So I don’t think the two are fundamentally different or separate, I think there is a big separation between architectural
decisions and design decisions. Architectural decisions are made early, are very sensitive to the metrics, and are very connected to
the rest of the design, whereas design decisions in many places are less connected and less sensitive. But I think it’s really, it has to be a part of engineering, and it also has to be a broader set of considerations as well. – [Lois] Great, thank you. From Julian Johnson,
who asks are you aware of quality function deployment, otherwise known as QFD? – [Dr. Cameron] Yes, absolutely, and this is mentioned in the book. QFD has really, I would say,
taken off in the last 25 years, starting from some early days here at MIT. One of the central premises of QFD is that we can map between
the features of the system, and yeah I think that’s a powerful idea that’s sort of tagged in the
book for where it applies, but just also the broader idea, that architecture is a mapping
between form and function, and I think draws on
some of the early work that was done in QFD and
aspires to build on it. – [Lois] Great. Jean who asks how does your book address software architecture? – [Dr. Cameron] That’s
an excellent question. One of the opportunities that we saw, and also one of the great challenges of writing this book is could
we say anything meaningful that would be really worth people’s time, for a concept that is used so broadly across different disciplines. You know, when we talk about architecture, there’s actually more people with the title software architect then I think there are with
the title system architect when we did the analysis for the book. We believe there are
shared sort of concepts between hardware and software. The book is our attempt to bridge those, and understand what is
underlying and common, but by doing so and working
in that general environment we necessarily have to leave
behind some discussions from concepts in software architecture that really didn’t carry
over into hardware, and also vice versa. So they’re, sort of interesting
to me in the process was there were a number of the early ideas that we had about managing
decomposition as a choice and abstraction as a choice, which are actually much more prevalent in software architecture, and a lot less prevalent in hardware. So the book was shaped to try and communicate that as best we could. But I welcome your feedback on, the product is sort of completed now. Did it meet needs? I welcome your thoughts on the software architecture
content that is in the book. – [Lois] Great. Bruce, the questions are pouring in here. Let’s see. What is, this comes from Guillaume Dupres. What is the method you recommend for finding an architecture? Is SADT the best one? And where do you stop? – [Dr. Cameron] That’s a great question, and I think one that we were trying to ask early on in the presentation, you know. How much do we need to
represent in architecture? Is the architecture, does it have to be the whole of the system you know, the product or the system
as it is seen in completion? Or can it be some sort of lighter or sort of abstracted
representation of that? I think the book is really an attempt to try and call out what are
the underlying principles at work in the number
of different methods. So SADT, or structured
analysis and design technique, is one of many out there. If I’m remembering right, this is something that
led into IDEF0 exercise, another sort of
representation of architecture that’s very much tied
to the TOGAF definitions that I showed later on. Our interest was not so much in promoting a particular representation, because they have different strengths and weaknesses in a sense. But in trying to communicate
what we’ve learned about when you would choose which ones, and in what scenarios
in which representations are more powerful than others. I’m happy to take the question offline, but it’s a very valid one. Where does architecture
stop and can we determine, did we get the right architecture before we finish the product design. – [Lois] Great. And speaking of taking a question offline, there are many, many
questions still unanswered from the chat question. I want you folks to
know that there will be in addition to an email including the link to the webinar recording and the presentation slides, will be Dr. Cameron’s email address, too. So if he doesn’t get to your question in the next few minutes, please feel free to contact him by email. That will all be sent to
you by the end of the week. Next question is from Carlos Morales. What are some meaningful metrics to evaluate candidates
for system architecture? – [Dr. Cameron] That’s
a wonderful question, Carlos is a good friend
of mine chiming in here. You know, the discussion
of how do we measure system architecture is I
think an important one, and it’s also a pretty nebulous one. When we started this activity, one of the things we observed is that the idea of architecture had some pretty nebulous boundaries. Nebulous boundaries make
it hard to do measurement. So what are the ways that
we thought about this in the book are what are the possible sort of
categorizations of measurement, that you know for example
in the Apollo example I show two, one being
risk as a measurement of the architecture and another one being the mass launch to low earth orbit. Later on in the book we
give some guidance about, you know, how can you put the architecture in your metrics in a loop
to understand which ones, which of your metrics really help you differentiate between architectures, versus which metrics
when you evaluate them don’t give you any differentiation. And until we wrote that into
the contents of the book, I think I’d be remiss to
say that there was anything sort of central across architectures that I can say any architecture should. You know, beyond the, I think, the really broad
suppositions of architecture should be elegant in some manner. Architecture should evolve easily. Architecture should be
easily manufactured. You know this idea of DFX, design for X, where X can be
manufacturing, supply-chain, safety, et cetera. There’s a whole field that thinks through a number of different dimensions on which you could think about design. I think that really all applies here to architecture as well, but at the end of the day
we have to ask the question which of these metrics
help us differentiate between possible architectures, and so can help us make an
architectural decision early on. – [Lois] Great, thank you. Bruce, will you have
about five more minutes? – [Dr. Cameron] I’m happy
to stay on for questions as they arise here. – [Lois] Okay, great. Generally we have ourselves
about five minutes left for the series. Again, folks, you’ll be
able to contact Bruce through the email address that
we provide if your question doesn’t get answered today. This is from Rodrigo. Does your book connect system architecture with system dynamics? – [Dr. Cameron] That’s a great question. I actually, when I worked
for NASA many years ago, system dynamics was
actually the modeling tool that we were using at the time to forecast the budget for the program, as well as its likelihood
of technical completion. We actually don’t spend much time in the book on system dynamics, not for lack of interest or experience. I think that the two
are very complimentary, and we have some diagrams
in the book that, from my experience I
guess just percolate in, based on system dynamics
and the associated sort of systems thinking
and thinking about systems as feedback. But it’s not something
we’ve actively incorporated, nor is it something that we’ve actually spent some time modeling. So it’s certainly an
opportunity from my perspective. You know, system dynamics has definitely answered questions in the field as to what gives rise to competitive advantage, and you can think about
how does architecture, how does having a strong
architecture, whatever that means, enable market success. You can think about modeling that from a system dynamics
perspective, certainly. But not something we explicitly cover in the book at this time. – [Lois] Okay. Another
question about the book. This is from Jason Silvette. Does the book cover what architects need in the absence of any data or precedent? In other words, how do you
make good architecture choices about a novel design or new market? – [Dr. Cameron] Yeah, it’s
certainly a challenge. I can call that architecting in a vacuum, if I wanted to be facetious about it. One of the things we didn’t
spend time talking about, which I am sharing on the slide here, is the idea of emergence
that we cover in the book, but I think it’s a much broader idea about how is the sum greater than the parts? You’re thinking about how
do you predict emergence, is really the question you’re asking. How do I predict it,
especially in a vacuum where we have unprecedented systems. And really the three
ways that we talked about are either we have precedent available, we have some ability to
experiment with the system, or we have some either physics-based or other dynamics that we can model. In the absence of that I think is the real art of system architecture. How do you reason through? One of the great examples from my career, I was fortunate to meet Joe Gavin, who was the system architect for the lunar excursion module, the LEM that went down to the lunar surface. Joe talked about there
was enormous uncertainty in the depth of the lunar regolith. We didn’t know if it
was a couple millimeters or if it was three meters that
we were going to sink into. So we engineered all of this
travel into the suspension, because we had no idea how the surface would in a sense react. We got some sense of that when
we started to send probes, but there was a lot of
uncertainty in that process. I want to be true to your question and try not to give, you know,
canned guidance about this. But thinking about the architecture phase as an explicit sort of feedback process, where we’re going to
test out some concepts. We’re going to do experimentation
and modeling if possible, is a helpful one rather than the sort of traditional product
development process idea, of where we presume linearity. We presume that we make decisions. We carry those decisions forward. We do not revisit them, and we work towards
increasing system definition in very uncertain environments. It’s often helpful in our experience to spend some time thinking about what does the architecture
of this system look like, what are many possible architectures, and then to work from there. – [Lois] Great. From Matt Alexander. What do you think of using patterns that span different industries? Are there any tips or
best practices you see? – [Dr. Cameron] That’s a good question. This idea of patterns
is a very powerful idea, but it’s also a challenging idea in that we think as
framed the problems are, the patterns are very
broad so by their nature they would sort of span
different industries. But we haven’t done any,
against the patterns we haven’t tried to match them up to, up against industries in
the sense of which patterns will occur more often
in different industries. I think that’s definitely a, I’m just thinking about it on the fly, achievable work. A lot of the time that we spent was sort of how can we use your
novel machine learning tools? How can we use existing
algorithms to develop, to try and solve the types
of programmed decisions or problems that could supplement the wisdom of the architect and therefore allow them to focus on the more sort of non-programmed content or diffuse problems that
need more human reasoning because we don’t have the
same tools to tackle them. But I haven’t actually spent
some time thinking about it. In case you can’t tell, I’m an aerospace engineer by training, I’ve been fortunate to work in a number of different markets over the course of my career, from finance to NASA to heavy
equipment and automotive, but I haven’t actually
spent time thinking about which patterns would apply
more in which industry. So, with your permission I’ll
take that question offline spend some time thinking about it. – [Lois] Great. The last question that
we have time for today, and I apologize that we
don’t have more time, is from Kella Kapeli who asks what matters most for
executives or decision makers, how architecture helps decision making, especially the cost and how can architecture
help decision making. Especially the cost. In many cases. It’s a little rough there. – [Dr. Cameron] Yeah, Kella Kapeli, I’m sure I’m butchering your name, but I appreciate the question. I think it’s a premise of the book, I think it’s something difficult to prove. So we asserted in the book, and I say this in chapter one, your system architecture, the idea of system architecture
is really an assertion. Can we prove that there’s leverage early in the design process? I think we could. Can we prove the counterfactual, that if we didn’t undertake a
system architecture process, or an executive decision
consultation process, or a corporate strategy
plus architecture process early on that we would have achieved a different result in the market? Often difficult to determine
the counterfactual, you’re really into case
studies at that stage. But I think the real premise of the book is that there is some
subset of these decisions that you need to surface, and that, really, you
know, I love the saying, decision makers make decisions. The question is how does the architect surface those decisions for
executive consideration. Something we spend a lot of
time thinking about in the book. But at the end of the day
difficult to prove its impact. So I think our attempt was really to write down what we knew, and to use that as an engagement point to see what other people thought, and what their experience was with executive decision
making around architecture. – [Lois] Great. Bruce, thank
you on behalf of MIT and SDM, for a fantastic presentation. Thank you all for your questions
and your discussion points. I just would like to remind you that we will be sending out an email with Dr. Cameron’s email address, slides, and a recording of this presentation. We’ll also include info
on our next webinar, which is May 18th and will be delivered by Professor Dick Larson. It’s on how to plan for
workplace disruption in the presence of the flu. So those of you who are interested, and also would like to plan now for any contingencies needed in
the fall, please join us. Again, thank you Bruce, thank you everyone for your questions and participation and have a great rest of the day.

Leave a Reply

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