>> Good news we're back with
another episode of Armchair Architects,
the Azure Enablement Series.
That's an ongoing conversation with Eric
and Woolley two of the smartest architects I know.
This episode, we're going to dig into something super interesting.
We're going to talk about the relationship between
simplicity and architecture so join us.
[MUSIC].
>> Hey, so welcome back to another episode of
Armchair Architects as part of the Azure Enablement Show.
In the last topic,
we were talking a little bit about how to become an architect,
and the thing that kept on coming up for us was
questions around simplicity and complexity,
and I would really love to dive in with my colleagues here,
Uli and Eric, into that question.
If you folks are up for it,
I want to start to dive into the role of simplicity in
architecture because I suspect
it's really fun to toss off things
like I'll make it as simple as possible,
but no simpler, and drop the mic and walk
away but I suspect there's more to it.
Can we talk a little bit about simplicity?
Is that your primary goal?
Is that a secondary goal when you're designing architectures?
Is that not a goal at all,
what's the role of simplicity
when you're architecting like your architect?
>> I think to me, it's more of
a philosophy or a pervasive thread that
you often have to revisit at every stage when you're asking,
as Woolley said before, the why questions.
If you're like me from an architecture perspective,
you're visualizing the way
that these solutions might fit together,
and then you're asking yourself
whether it's in your brain or if it's on paper,
or in your favorite architecture diagramming tool.
It is this as simple as it needs to
be or is it overly complex and can I reduce it further?
Am I providing too many knobs and bells and whistles?
Can I create a more coarse-grained API interface across
my microservice architecture and that way I
can actually make it easier on the people that have to consume it?
To me, it's something that you visit and
revisit critically all throughout the architect journey.
>> I would add to this and David,
you will appreciate this being an operations person.
Simplicity is a question that
you should ask from multiple dimensions.
Eric mentioned the developer pieces
in terms of technical simplicity,
of course, grained access
versus fine-grained access, and so forth.
I also look at and have the notion of what happens if stuff
breaks at 3 AM in the morning and
the developer isn't available to debate the code.
How do you tell an operations person how to deal with the system,
and the more complex the system is,
the more hard it is to effectively go and bring it back
online or make sure that the customers can
successfully complete the operations, and so for me,
simplicity also has to do with, stuff bricks,
what happens and then the last piece of that which goes in
the similar vein is if I have to
update the solution, how do I do this?
How many things to have to touch to update
the capabilities that I'm building
out and the more things I have to touch,
the more complex it is, and therefore,
the likelihood of failure is much higher than if I keep it simple.
>> I remember one of
my favorite talks was given by Casey Rosenthal,
in which he was discussing the notion of necessary complexity.
You're saying, okay, cool,
I build something and it runs on my laptop.
That's cool but that's not really what you need.
You need to put it on somewhere else, and really,
if you want to make sure that it doesn't fall over,
you want two of them, and so,
making redundancy has unnecessary complexity cost to it whereas,
if you'd like it's simpler but we all
agree that two of them is better than one
but I also have not met an architect who doesn't recognize that,
going from one to two is
a really big leap sometimes when it comes to
architectures or one to five,
is even bigger, but one to two job.
Is there a way of because the thing that's tricky
about this is when you're
talking about features the thing that's tricky here is,
is it possible to retain simplicity
even though the incentives are to add features?
How do you do that?
>> I think it's a scale or a spectrum,
almost an imaginary slider, and in one way,
if you slide it into the more I'll call it the
fine-grained approach higher technical complexity,
but more control for consumers of
that particular service or application over capability.
If you slide it the other way,
you get probably a much better user experience
that's more tightly integrated,
but you give up some of that exposed control capabilities,
and it's the things that
many developers might want so if you're an ISV,
you probably do want to think about what
your API surface is going to look like
for consumers of that particular service.
Also, I would advise that you have to think about
the way in which your consumers, your customers,
or your organization will consume
your components think about what code they will have to write
that you're forcing them to write based on the API surface and
the other solution architecture that you're
building versus the code that they want to write.
In other words, is your API a delight to consume,
or is it really tough because you have to spend a ton of
time stitching together solution components,
utilizing surgical code,
and making the integration really difficult and not consumable?
>> What do you mean by surgical code?
I just want to stop you right there.
What does surgical code mean?
I've not heard that term before.
>> To me, a surgical code is any type
of integration between components that
require a significant amount of wiring
up of those components so that they can talk to each other.
Everything related to identity and access management to
course green or find green API service capabilities.
The more powerful I guess an individual components API is,
the more you're going to have to do to get
that API to talk to another API or talk to your service.
>> I guess but I'm still stuck on this notion that
says everybody wants more features, everybody wants it,
the next revision to be whatever in its work that it
didn't have prior very seldom are people done everything's cool.
How do you deal with that not done and
yet not more complex every step of the way,
because otherwise, it seems
to imply that the world tends towards complexity,
and is that true?
Is that an existential truth
that I should just get over right now?
>> No more functionality does
not automatically mean more complexity.
It means more surface area potentially
from an API perspective like Eric talked
about but if you are providing a consistent model,
so let's define what is an API these days.
On the one side, you have
a rest interface that most likely follows
open API standards from
a shape perspective and exposure perspective.
What used to be called swagger,
that's now called Open API,
and that's certainly one API surface
that you want to think about, and again,
more APIs means a little bit more complexity
but because the API follows
a certain standard open API, it's fairly straightforward.
As a user of this API will be able to go and say,
that's another capability that I have that these guys now
provide but because it's
the same API shape, it's fairly straightforward.
The second type of API that's becoming,
I think standard as well is event-based exposure.
You effectively have a reactive,
which is the risk-based API,
and a proactive or observable API where
the system raises an API call
through technologies like Azure Event Grid or similar,
and effectively somebody then says,
I'm interested in that event, and again,
that's just more event surface,
but the consumption is structured and simple.
From that perspective, yes,
it's more complicated because it's richer,
but it's not more complicated
because the consumption is straightforward and easy.
If you would say, hey,
I have APIs, I have a event,
and the APIs have different structure.
You would use let's say,
instead of rest-based APIs only you also throw
in some older technologies like soap and
just throw some other stuff in where instead of you using
consistently JSON and those things you throw in,
this has XML, this is JSON,
this is a CVS file then gets complicated.
For me, consistency is one part of the art of simplicity.
>> I'm thinking back to our last discussion,
which we were talking about how to become an architect,
and it made me think
about how we talk about simplicity and complexity.
Obviously, it's not binary.
This is not either simple or complex.
But do we have the right words?
Like when you walk into a room and you want to tell somebody,
gosh, that seems complex,
do we have any terms or ways of talking
about this is more or less complex besides more or less complex?
Are there ways to say that in
a slightly less subjective manner when we say how complex it is?
How do you describe complexity is what I'm asking?
>> Yeah. One thing that we are
really pushing hard on right now in
the Azure world is concept count.
How many concepts do
you as a person that's participating in the technology,
or is trying to use the technology,
have to understand in order for you to use it?
If the concept count goes over five,
most people are opting out because it's too complicated.
Ideally, you have one major concept,
maybe two or three,
but that's about it,
and most people just don't have the patience or the time to
really understand five or more concepts in a single solution.
For me, complexity is almost linear with concepts counts.
Effectively how many concepts do you have in that solution?
If it's too much, it's getting too hard.
>> What's an example of a concept?
I want to hear what you have to say, Eric,
but I just want to make sure that I'm clear
on what's an example of a concept?
>> I already talked about two concepts.
On the one side you have an API,
and the other said you have an event.
>> I see. Great.
>> Those kind of things, those are concepts.
But then you throw in,
let's say if you are like Eric,
in the IoT world,
you throw in, there's a device that you have to think about.
That's a necessary concept and important concept in IoT.
But now you have three, that's still okay.
But how many more can you add before the solution gets too complex
for people to really grasp and put
their head around and use it consistently,
which is really what you want?
For me, concept count below five
is an important simplicity element.
>> The term I've heard used is cognitive load,
but concept count sounds really close.
Well, it looks like you wanted to say
something Eric and I cut you off,
because I just wanted to get some clarity.
>> No, these are all great points.
A couple of random thoughts that I think
really apply here are like I think of architecture like fractions.
Your goal is to reduce them to the lowest common denominator.
Whether looking at it in terms of concept counts
or going back to that nagging feeling of is this simple enough.
The way to do this to justify it
as well is that you can't just go out and say,
this is my simple architecture,
I've solved it, stamped it, and it's done.
In many instances, you have to actually
show other architects that you've completed the thought.
In many cases you'll actually have to be like, well,
I considered this approach
and these other approaches and these opponents,
but I rejected them based on these concepts,
and the rejection is that I deliberately chose not to
engage with these other alternatives because I was focused on
simplicity or integration of design.
Or maybe I went more complex,
but there was a really good reason why I did that.
The other thing I'll say is we oftentimes, as architects,
begin to think that we're the only person
around that can solve this problem,
and as a result, we have to create something new.
Even things that I've created before.
This is new, this is fun.
This is something I can create.
Reusing things is the hallmark of a great architect.
Looking around and saying what's been done.
Whether it's the well architected framework on our side or others
or something that you've done or a colleague of yours have done,
beginning the conversation with what patterns, what paradigms,
what architectures exist that I can reuse before I invent,
I think is something that's important.
>> That's a really important point, Eric,
because there's another dimension on simplicity versus complexity.
We always assume that solutions get built and then it's done.
That is obviously not true.
We have solutions that are running on mainframes since 30 years,
and they still get maintained. They get updated.
You have code bases on Windows that
are 20 years old and they get updated.
Being able to update a solution,
not just from a components perspective that you depend on,
but your own code,
requires you to also be not necessarily simple,
but keep it as simple as you possibly can
because you might not be around to explain what was going on.
You might have moved on from the company or the solution,
and so some other person has to now go in and understand, oh,
this is what this person meant when he designed or
she designed this capability and so forth.
For me, operational perspective and maintenance perspectives are
something that are often
overlooked by people that just design and build solutions,
because sometimes they're not around when things go haywire or
things have to move forward with new capability and so forth.
For me, that's another set of
aspects I would throw into this conversation.
>> Well, this is one of the reasons why I
initially had some questions
about the term well architected framework,
because often when you think of architect, you think, oh,
I heard an architect, they told me how to build
the thing and they designed the thing, they built it,
and then they walked away because
you don't have the architect knocking at your door going,
hey, would you like to architect some more?
The conclusion I came to is,
is that the key thing is staying in a well architected state.
That's one of the things that architects can do,
is they can keep you in that state because
for very many reasons
that we won't go into. But let's pretty go on.
You can drop out of that state of feeling well architected,
and it's interesting to me to hear you discuss
architectural not only as building things,
but also like they might walk into a room and help you
simplify what you're seeing
on the whiteboard that already exists,
and that sounds really cool.
One of the things that Uli said a moment ago
was about operations and
was this question about trying to keep things running,
which segues us nicely into
something else that I know we want to talk to you about,
which is what to do in the situations where you've got
architectures and applications and
services that have to be running all the time,
and that's a really tricky question.
As per usual, I have to ask you to like,
don't you think we should talk about that?
Should we do that next?
>> I think that's a great idea.
>> Cool. Well, then with that,
I want to thank all you for watching us.
I'm hoping you'll join us for the next episode, which now,
you know is going to be about with
the Armchair Architects as part of the Azure Enablement Show.
[MUSIC]