Architecture without Architects - XConf SEA 2021

00:46:22
https://www.youtube.com/watch?v=9a09cZzsTP8

Zusammenfassung

TLDREric, head of technology at ThoughtWorks Germany, presents a keynote on 'Architecture without Architects', where he challenges traditional views of software architecture by comparing it to gardening instead of construction. He emphasizes the evolving nature of software systems, arguing that architecture is an ongoing process. Eric asserts that developers should be aware of the implications of architectural choices, and that visualizations and frameworks should not overshadow the ultimate goal of delivering user value. Through fitness functions, architects can guide and measure the adaptability of software systems to meet changing requirements. Ultimately, he suggests architects should guide developers rather than dictate terms, leading to a more collaborative and effective development process.

Mitbringsel

  • 🌱 Architecture is an ongoing process, akin to gardening, not a one-time construction task.
  • 🛠️ Developers should understand the real implications of architectural choices.
  • 📊 Fitness functions measure the performance and integrity of software architecture.
  • 🤝 Architects should guide developers instead of imposing strict frameworks.
  • 🌍 Software systems are never truly finished; they adapt continuously to user needs.

Zeitleiste

  • 00:00:00 - 00:05:00

    The session begins with an introduction of Eric, the keynote speaker from ThoughtWorks Germany, who has 25 years of experience in technology. He advocates for Agile values and open source software, and will be discussing the topic 'Architecture without Architects'.

  • 00:05:00 - 00:10:00

    Eric begins his keynote by discussing the definition of an architect in the context of computer science, noting the complexity involved in software development beyond merely writing code. He highlights that terminology should not mislead perceptions of software architects similar to building architects, and introduces the metaphor of gardening to describe software upkeep.

  • 00:10:00 - 00:15:00

    Eric critiques the architectural metaphor, emphasizing the dynamic nature of software compared to the static nature of building architecture which can be completed. He warns against applying building industry conventions to software architecture, arguing it can lead to incorrect assumptions and practices.

  • 00:15:00 - 00:20:00

    He proposes that architects often create abstractions for developers but stresses that misunderstandings can lead to performance issues if underlying implementations are not considered. He shares illustrative examples of poor coding practices and the implications of abstractions that developers fail to comprehend, demonstrating how architecture is intertwined with development work.

  • 00:20:00 - 00:25:00

    The discussion continues with Eric rejecting traditional architect roles, asserting that modern developers should adopt these responsibilities, including design and coding practices. He encourages developers to not shy away from the implications of architectural decisions and relates it to better software quality and user experience.

  • 00:25:00 - 00:30:00

    Eric illustrates with case studies on how to measure architectural health through means like coding quality and performance metrics. He shares that traditional architectural roles are increasingly blurred with development roles, suggesting structural changes in teams to reflect this.

  • 00:30:00 - 00:35:00

    He brings in the concept of evolution in architecture by likening it to town planning, emphasizing organic growth driven by user need rather than rigid planning. Eric stresses the importance of guided incremental changes in architecture, fostering adaptability over static models of architecture.

  • 00:35:00 - 00:40:00

    In his final conclusion, Eric emphasizes that architecture is a continuous journey rather than a one-time endeavor and introduces the idea of architectural fitness functions that can be used as guiding principles for software evolution.

  • 00:40:00 - 00:46:22

    He concludes by advocating for architects to serve as guides in the software development process, focusing on helping developers navigate challenges instead of enforcing rigid structures. The session ends on a positive note with appreciation for the analogies and insights shared throughout the keynote.

Mehr anzeigen

Mind Map

Video-Fragen und Antworten

  • What is the main focus of Eric's keynote speech?

    The main focus is on the concept of 'architecture without architects' in the context of software development.

  • How does Eric differentiate between software architects and building architects?

    Eric argues that software architecture is more about ongoing evolution and maintenance, similar to gardening, rather than a fixed construction role like building architects.

  • What does Eric suggest is a better metaphor for software architects?

    Eric suggests that being a gardener is a more appropriate metaphor, as it emphasizes ongoing care and adaptation rather than one-time construction.

  • What is the significance of fitness functions in architecture?

    Fitness functions help measure the integrity and performance of software architecture, guiding evolution and ensuring systems meet business requirements.

  • How does Eric view the role of architects in software development?

    Eric believes architects should act more as guides, helping developers navigate complexities rather than imposing strict rules.

Weitere Video-Zusammenfassungen anzeigen

Erhalten Sie sofortigen Zugang zu kostenlosen YouTube-Videozusammenfassungen, die von AI unterstützt werden!
Untertitel
en
Automatisches Blättern:
  • 00:00:00
    So next we have our keynote speaker
  • 00:00:03
    who's joining us from Hamburg, Germany, probably
  • 00:00:07
    as the first thing for his Friday, since I hope
  • 00:00:10
    is sunny over there for his morning.
  • 00:00:12
    So he's Eric, head of technology for ThoughtWorks Germany,
  • 00:00:17
    and throughout Eric's 25 years in technology
  • 00:00:20
    he has witnessed the rise and sometimes
  • 00:00:23
    the fall of many technologies.
  • 00:00:26
    Always curious, he seeks to understand
  • 00:00:28
    the potential of these new technologies
  • 00:00:31
    while trying to figure out how to apply hard
  • 00:00:34
    won experience and proven practices.
  • 00:00:37
    He's also an advocate of Agile values and open source
  • 00:00:42
    software.
  • 00:00:43
    So today he will be providing our keynote speech,
  • 00:00:47
    architecture without architects.
  • 00:00:50
    What a wonderful name, I'm so curious to know
  • 00:00:52
    how this is possible.
  • 00:00:54
    And let's give a warm welcome to Eric for the closing
  • 00:00:58
    keynote of today.
  • 00:01:04
    So hello, thank you very much for the warm welcome,
  • 00:01:07
    and let's dive straight into the topic.
  • 00:01:09
    I'm happy to hear that the title piqued your interest,
  • 00:01:12
    I hope I can satisfy and explain what we are talking about
  • 00:01:17
    and why it can actually make sense
  • 00:01:18
    as you alluded to because it is not totally obvious how
  • 00:01:22
    that can work.
  • 00:01:23
    To start let me share my slides, which
  • 00:01:28
    you should hopefully see now.
  • 00:01:30
    MALE MODERATOR: Yes we can.
  • 00:01:31
    ERIC: Good
  • 00:01:32
    MALE MODERATOR: Very good.
  • 00:01:33
    Cool.
  • 00:01:34
    So architecture without architects.
  • 00:01:37
    Let's start to talk about architects
  • 00:01:40
    to kick this off really.
  • 00:01:42
    What is an architect?
  • 00:01:43
    And I guess in computer science, which
  • 00:01:45
    is a relatively young discipline we are borrowing words,
  • 00:01:48
    we're taking metaphors, we're taking terms
  • 00:01:50
    from other disciplines to describe
  • 00:01:52
    better what we are doing.
  • 00:01:54
    And there was one thing, I guess many of us recognize,
  • 00:01:57
    in writing software it wasn't just writing code
  • 00:01:59
    at a very early stage already.
  • 00:02:01
    30, 40 years ago there was more than just
  • 00:02:03
    writing a few lines of code to solve a business problem.
  • 00:02:06
    And we're looking for a term, and a term
  • 00:02:08
    that had been applied in other disciplines
  • 00:02:10
    as well was this metaphor of architecture.
  • 00:02:14
    Sometimes, and I know this at least [AUDIO OUT]
  • 00:02:19
    the real building architects aren't even that happy
  • 00:02:21
    about other people calling themselves architects.
  • 00:02:24
    So they really want to make sure that we call ourselves
  • 00:02:26
    at least software architects or something
  • 00:02:28
    to distinguish from the true architects.
  • 00:02:31
    But nonetheless, I think it is important to briefly look
  • 00:02:34
    at what real architects are doing.
  • 00:02:35
    And if you look at that picture, the architect
  • 00:02:38
    is the one with the white helmet.
  • 00:02:40
    He's the one who's drawing the plans.
  • 00:02:43
    He's actually not really drawing the plans
  • 00:02:45
    he's actually the one who probably
  • 00:02:47
    did the broad strokes designs.
  • 00:02:49
    The plan that we're seeing in the hands
  • 00:02:51
    here were probably done by structural engineers,
  • 00:02:53
    by other people.
  • 00:02:55
    And these plans if you look at them, they are super detailed,
  • 00:02:59
    you can see the physical size and the picture of that plan.
  • 00:03:02
    But what is also and I guess this
  • 00:03:03
    is intuitively clear to all of us but not often talked about,
  • 00:03:08
    when you look at those plans and in the detail
  • 00:03:10
    you will see that they are very low level of abstraction.
  • 00:03:14
    For example, if you look at the skyscraper
  • 00:03:16
    in the background that has 10, 20, 30 storeys,
  • 00:03:19
    it has multiple similar windows.
  • 00:03:21
    But in these architectural plans we
  • 00:03:23
    don't have those abstractions that we
  • 00:03:25
    take for granted when we write software.
  • 00:03:27
    If you want 10 stories you're probably
  • 00:03:29
    drawing 10 stories in the plan.
  • 00:03:32
    Probably also because each story is
  • 00:03:33
    a little different for practical reasons.
  • 00:03:36
    But also when you have windows, you
  • 00:03:38
    don't have a for loop in the plan that says,
  • 00:03:40
    this window 20 times, you draw the same window 20 times.
  • 00:03:45
    So what we're really seeing here is
  • 00:03:47
    when we look at that picture, that plan is much more
  • 00:03:51
    detailed, it's almost like precise instructions of how
  • 00:03:54
    to build something which is, when you think about it,
  • 00:03:57
    more akin to how we write code.
  • 00:04:00
    This is more really like constructing the computer
  • 00:04:03
    to do something.
  • 00:04:04
    And maybe that's not completely surprising then when
  • 00:04:07
    we think what do we call the phase when the software,
  • 00:04:10
    when the source code is compiled and made ready for deployment
  • 00:04:14
    on production system, we call it the build.
  • 00:04:17
    So basically, what we are doing for a long time with the source
  • 00:04:21
    code we are writing but now increasing the odds
  • 00:04:23
    with infrastructure as code, we are doing the same things,
  • 00:04:26
    those plans, we are creating the plans.
  • 00:04:28
    The actual building phase is done entirely by the computer.
  • 00:04:33
    When you think about it that way you come to the realization
  • 00:04:36
    that what these people are doing is exactly what the software
  • 00:04:40
    developers are doing.
  • 00:04:42
    So the people who are programming or writing
  • 00:04:44
    the source code, the infrastructure people writing
  • 00:04:46
    the infrastructure as code scripts and other descriptions,
  • 00:04:50
    they are the ones who are doing the plans,
  • 00:04:51
    they're not the building people.
  • 00:04:53
    So in many ways this metaphor is really quite misleading.
  • 00:04:57
    Also if you think about the real world,
  • 00:04:59
    an architect is more like a business analyst.
  • 00:05:01
    He's talking to the customers, he's
  • 00:05:03
    finding out what they need.
  • 00:05:04
    He's not the one writing the detailed plans.
  • 00:05:08
    It is all interesting already but I
  • 00:05:10
    think the biggest issue with the metaphor
  • 00:05:12
    is that the term architect in the building industry, what
  • 00:05:17
    we--
  • 00:05:17
    the connotations are there for most people
  • 00:05:20
    who are not completely in the IT industry all the time.
  • 00:05:23
    The architects are focused on the construction phase.
  • 00:05:26
    When the building is finished, when the tenants have moved in,
  • 00:05:30
    the architecture is done.
  • 00:05:32
    But that's not the case.
  • 00:05:33
    If you think about your enterprises, your businesses,
  • 00:05:36
    how much does something really change?
  • 00:05:38
    I would argue it changes a lot, it's never really finished.
  • 00:05:41
    This skyscraper at some point will be finished.
  • 00:05:44
    You're not going to add 20 new stories to it.
  • 00:05:46
    You're not going to change the ground floor.
  • 00:05:48
    You're not going to change the shape.
  • 00:05:50
    You're not going to change the color and all these things,
  • 00:05:52
    the materials.
  • 00:05:53
    But that's precisely what we do with software.
  • 00:05:55
    So we have to be really, really careful
  • 00:05:57
    that we're taking these metaphors,
  • 00:05:59
    that we don't mentally put ourselves into the wrong state.
  • 00:06:03
    That we take what we intuitively know
  • 00:06:05
    from the world about building architecture
  • 00:06:08
    and apply that thinking, accidentally almost,
  • 00:06:11
    to our perception of what we do with software because it
  • 00:06:14
    will mislead us.
  • 00:06:17
    This is a known problem.
  • 00:06:19
    This has been a problem for many years,
  • 00:06:21
    I've actually used this picture even 10 years ago.
  • 00:06:24
    And one thing that I have seen is
  • 00:06:26
    that some people have said, what are better metaphors?
  • 00:06:29
    And one thing that struck me over the years is this one.
  • 00:06:32
    Some people have said, I feel more like a gardener.
  • 00:06:35
    Yes, every now and then I'm planting new plants,
  • 00:06:39
    but the vast majority of time I'm
  • 00:06:41
    actually looking after the existing garden.
  • 00:06:44
    I'm looking after the plants that were there many years ago.
  • 00:06:48
    The plants are also changing, I need
  • 00:06:49
    to have a plan of how the change of the-- sorry, the change
  • 00:06:53
    of the plants over time actually makes my garden look like,
  • 00:06:56
    makes the business that I have about maybe growing crops
  • 00:07:02
    or so, how that actually works.
  • 00:07:03
    And also what is part of that metaphor is to say,
  • 00:07:07
    let's weed out some old plants.
  • 00:07:08
    Plants wither and die, we have to have a plan for that too.
  • 00:07:11
    And I think this is a much better metaphor
  • 00:07:13
    if you think about it.
  • 00:07:14
    Also, I mean I've been involved with a lot of strategic IT,
  • 00:07:18
    if you look at where the budgets are usually
  • 00:07:20
    spent in enterprises, the vast majority
  • 00:07:23
    is on maintenance and not so much on what
  • 00:07:25
    is often even called R&D. But the architectural metaphor
  • 00:07:30
    really focuses only on one thing.
  • 00:07:32
    The question is, why don't we call ourselves gardeners?
  • 00:07:35
    I've seen a few people do that, very, very few.
  • 00:07:39
    I really think it's a very simple answer, oh, we're
  • 00:07:42
    creating for prestige.
  • 00:07:43
    Architect is a much more prestigious title
  • 00:07:45
    and we identify ourselves much more
  • 00:07:47
    with being an architect than with a gardener.
  • 00:07:50
    But if you're talking about the honesty of what we're really
  • 00:07:53
    doing, I think this is much closer to the work
  • 00:07:57
    that we are doing.
  • 00:07:58
    And by the way I'm not encouraging
  • 00:07:59
    you to change your job titles if your job
  • 00:08:01
    title is architect to gardener.
  • 00:08:03
    It can be a thought provoking thing
  • 00:08:05
    to do to start this conversation.
  • 00:08:07
    I think we have to accept that is what we call it,
  • 00:08:09
    but I do believe we need to be aware of the bias.
  • 00:08:13
    And this is-- I'm going to present you four conclusions.
  • 00:08:16
    This is the first conclusion, architecture
  • 00:08:18
    is a tricky and to a certain extent even dangerous metaphor.
  • 00:08:21
    You have to be mindful of what connotations you are arising
  • 00:08:25
    and be mindful that you might set yourselves off
  • 00:08:28
    in a way of thinking that might not
  • 00:08:31
    be the best way of thinking when it
  • 00:08:32
    comes to complicated software systems.
  • 00:08:36
    I believe you want to check.
  • 00:08:38
    Ah, sorry.
  • 00:08:39
    I just saw check message, I just wanted to make sure
  • 00:08:41
    that there were no questions.
  • 00:08:43
    I would encourage you anyway to ask those questions on Slack.
  • 00:08:47
    I will be joining select after I finish the talk
  • 00:08:49
    and I'm happy to stay on for a while, half an hour
  • 00:08:52
    or longer to answer many of your questions.
  • 00:08:55
    So moving back to the actual presentation.
  • 00:09:00
    Now that we talked about architect the term
  • 00:09:02
    and what it means for us, let's talk about what the architects
  • 00:09:05
    are actually doing.
  • 00:09:08
    And one thing that I've seen quite a bit
  • 00:09:09
    is architects are creating abstractions.
  • 00:09:13
    They're saying, as an architect my role is not
  • 00:09:16
    to be in the code.
  • 00:09:17
    Oftentimes you hear people saying, I get my hands dirty.
  • 00:09:20
    By the way, interesting, that sounds like the gardener
  • 00:09:23
    metaphor again, right?
  • 00:09:24
    But what I've often seen is that architects are saying,
  • 00:09:27
    I want to talk about creating frameworks so developers can't
  • 00:09:30
    make mistakes, or in a more trusting environment
  • 00:09:34
    so developers are more productive.
  • 00:09:36
    We create these common frameworks,
  • 00:09:38
    we create these abstractions that other people
  • 00:09:40
    can build upon.
  • 00:09:42
    I would argue that's not a bad idea, abstractions are good.
  • 00:09:44
    Without abstractions nothing in computer science
  • 00:09:47
    would be where it is today.
  • 00:09:49
    But again, we need to be conscious that the abstractions
  • 00:09:52
    and what we are doing with the term
  • 00:09:53
    abstractions are well understood.
  • 00:09:56
    This year is, in pseudocode, an example from a real engagement
  • 00:10:00
    that I worked on many, many years ago.
  • 00:10:02
    The idea here really was, if you think
  • 00:10:04
    about a website that presents images that need to be tagged.
  • 00:10:07
    So a tag could be something like a building,
  • 00:10:10
    could be tagged to Singapore, could be tagged to people,
  • 00:10:13
    right?
  • 00:10:13
    So the images needed to be tagged,
  • 00:10:16
    and there was a functionality in the admin
  • 00:10:18
    part of the application to see which
  • 00:10:20
    of the tags that were created in the taxonomy were not used.
  • 00:10:25
    And this was the code--
  • 00:10:26
    as I said, this is pseudocode-- but that
  • 00:10:28
    was the code that was written.
  • 00:10:29
    So you're iterating in the foreach loop of all the tags
  • 00:10:33
    and then you saying, tag.images.count.
  • 00:10:36
    I'm going from the tag to the images,
  • 00:10:38
    and if the count is zero, obviously the image is not used
  • 00:10:41
    and then I'm sticking the tech into the collection
  • 00:10:43
    of unused tags.
  • 00:10:46
    This is implemented in a high level programming language,
  • 00:10:48
    the images are stored in some data store,
  • 00:10:51
    let's for the sake of the argument
  • 00:10:52
    assume it's a relational database,
  • 00:10:54
    and we can see here it's obviously
  • 00:10:57
    some object relational mapping technology that is being used.
  • 00:11:00
    But do you-- can you imagine immediately
  • 00:11:02
    what is happening here?
  • 00:11:03
    Let's take a tag that is probably used quite a bit,
  • 00:11:06
    like news, or Singapore.
  • 00:11:08
    So tag.images will trigger a load of all the images that
  • 00:11:12
    belong to the tech into memory.
  • 00:11:14
    Then in memory the collection is being counted very quickly,
  • 00:11:17
    of course, the algorithm decides the count is 20,000
  • 00:11:20
    and not zero and moves on.
  • 00:11:23
    But effectively, while doing this
  • 00:11:25
    you are bringing the entire database into memory.
  • 00:11:29
    The person who wrote the code wrote the right code
  • 00:11:31
    from a programming perspective but they
  • 00:11:34
    were unaware of the abstraction underneath.
  • 00:11:37
    They saw the abstraction and they programmed according
  • 00:11:39
    to the rules that the abstraction presented
  • 00:11:42
    but did not realize what they were doing.
  • 00:11:44
    Luckily we had performance tests that
  • 00:11:46
    very quickly showed the issue.
  • 00:11:48
    And by the way, in later years when we revisited stories
  • 00:11:51
    like these, people said, oh yeah,
  • 00:11:53
    but that was because this was more procedural,
  • 00:11:55
    today everything is better because we
  • 00:11:56
    use functional programming.
  • 00:11:58
    And to be honest with you, this is again pseudocode,
  • 00:12:01
    maybe slightly closer to Java in a more functional approach.
  • 00:12:04
    I'm creating a stream of all the tags
  • 00:12:06
    and I'm using a filter and an anonymous function
  • 00:12:09
    but you see it's the same problem,
  • 00:12:11
    t.images.count, same thing.
  • 00:12:13
    I'm writing idiomatic code in the abstraction
  • 00:12:16
    that I'm operating on, do malfunctional programming,
  • 00:12:20
    and still the underlying implementation
  • 00:12:23
    of that abstraction still kills me if you will.
  • 00:12:26
    Because t.images still eagerly loads-- sorry,
  • 00:12:29
    lazily loads all the data into REM.
  • 00:12:31
    I still need to understand.
  • 00:12:33
    The programming paradigm at that level of abstraction
  • 00:12:35
    doesn't help me, the problem really
  • 00:12:37
    is in the implementation of the abstraction.
  • 00:12:41
    Another example, a real world example.
  • 00:12:43
    This was from a financial institution.
  • 00:12:46
    A quote here is a quote for a possible deal.
  • 00:12:50
    Code message as you can see in the top line
  • 00:12:52
    was a Java object in that case and the developers
  • 00:12:55
    could work on that level.
  • 00:12:56
    That was built on an abstraction layer that converted that code
  • 00:12:59
    message into some format on another abstraction layer that
  • 00:13:03
    made that into a message, on the message bus.
  • 00:13:05
    The message bus was implemented somehow.
  • 00:13:07
    There was another abstraction layer
  • 00:13:09
    before it hit the operating system, and then at some point
  • 00:13:11
    it hits the networks in the operating system
  • 00:13:14
    canal, Linux most likely.
  • 00:13:16
    And what do we see here?
  • 00:13:17
    That is what the interface definition of the network is.
  • 00:13:20
    And what's happening now is you have a very high level
  • 00:13:22
    of abstraction.
  • 00:13:23
    You have that quote message where
  • 00:13:25
    you can say, what currency, what instrument am I
  • 00:13:27
    trading at the very top.
  • 00:13:30
    And then at the very bottom, you have this number, MTU,
  • 00:13:34
    the maximum transfer unit, 1,500 bytes on ethernet normally.
  • 00:13:38
    And what was essential for this trading system
  • 00:13:40
    was that it was fast, but it meant
  • 00:13:43
    all the messages needed to fit into a single packet
  • 00:13:46
    on ethernet.
  • 00:13:47
    So at the moment, you don't notice
  • 00:13:50
    that, you change one field in the quote message on the Java
  • 00:13:53
    level, you're adding one instance variable.
  • 00:13:56
    And now the serialize-- to all these layers of abstraction,
  • 00:14:00
    the serialized message format goes from 1,480 bytes to 1,540.
  • 00:14:07
    You don't think about that at all
  • 00:14:08
    when you're dealing in the Java land.
  • 00:14:10
    But on the network level you've now split the packets
  • 00:14:13
    and you're creating a huge issue because you
  • 00:14:15
    need to reassemble the packets, you need to look at sequence,
  • 00:14:18
    and so on.
  • 00:14:19
    So again, you really, really cannot forget about how
  • 00:14:22
    your abstraction is implemented, and if you talk about
  • 00:14:25
    architecture as saying creating abstractions,
  • 00:14:27
    that's a good thing.
  • 00:14:29
    But to say we create abstractions and nobody
  • 00:14:31
    needs to know what happens underneath, that is
  • 00:14:33
    a very, very slippery slope.
  • 00:14:37
    Another thing, another story.
  • 00:14:39
    I was working with a large company, maybe some of you
  • 00:14:42
    recognize the visual identity, windows phones aren't really
  • 00:14:45
    a thing anymore.
  • 00:14:46
    But what we were building, we were
  • 00:14:47
    building the API for all of these applications, places.
  • 00:14:51
    Like the restaurant that you see there in London.
  • 00:14:54
    How many stars does it have?
  • 00:14:55
    Where are the restaurants on the map?
  • 00:14:57
    Or if I said, for example I'm limiting this to restaurants
  • 00:15:01
    of a specific cuisine, I only see
  • 00:15:04
    the restaurants of that cuisine, or in the case as you can
  • 00:15:07
    see in the middle in the search there,
  • 00:15:08
    I want to have dining here.
  • 00:15:10
    So this application running on mobile phones,
  • 00:15:12
    you can see at the bottom running on websites,
  • 00:15:15
    on photo reviews and so on, that needs an API at the back end.
  • 00:15:19
    And how do you build this?
  • 00:15:21
    We have a lot of theory around REST,
  • 00:15:23
    around hypermedia as the state--
  • 00:15:26
    as the engine of application state and so on.
  • 00:15:29
    There's a lot of theory, they're maturity models.
  • 00:15:31
    We were aware of all of them, and yet we consciously
  • 00:15:35
    and knowingly violated them on an architectural perspective.
  • 00:15:39
    This is, and you can actually see probably
  • 00:15:41
    from the screenshot, how old the browser is.
  • 00:15:43
    Again, this is many years ago and he was already a problem--
  • 00:15:47
    not a problem, a point of discussion back then.
  • 00:15:49
    So this is the real search result. If I did REST,
  • 00:15:53
    I would not do most of this.
  • 00:15:54
    I would probably-- you can see this
  • 00:15:56
    at the very bottom, the results have items,
  • 00:15:59
    and at the very bottom, you see the type and the type
  • 00:16:03
    is here correctly, I would argue,
  • 00:16:05
    is a hyperlink, so you can get actually
  • 00:16:06
    more information about the type of the response, and then
  • 00:16:09
    the href, where is the response?
  • 00:16:11
    This should be where I can find the search results.
  • 00:16:14
    This would be proper REST.
  • 00:16:15
    And what have we done, we have included information
  • 00:16:19
    like the icon, doesn't belong there.
  • 00:16:21
    The icon would belong to the resource of the actual search
  • 00:16:24
    result, it is hyperlinked at the bottom.
  • 00:16:27
    We've included some information about the vicinity,
  • 00:16:30
    you can see that agreeing towards the bottom.
  • 00:16:32
    Like where is it in Berlin, why would that
  • 00:16:34
    be in the search results?
  • 00:16:35
    The search results shouldn't include
  • 00:16:37
    that if you follow REST, that should not be in there.
  • 00:16:40
    Even worse, if you look further up, in the result,
  • 00:16:43
    we've repeated the position that was given to the server.
  • 00:16:48
    Why would we repeat that?
  • 00:16:49
    Because it makes it easier for the applications.
  • 00:16:52
    What we've also done is the distance.
  • 00:16:54
    Why would we include the distance in meters?
  • 00:16:57
    Normally that can be calculated.
  • 00:16:59
    You have the geolocation of the user in the client application,
  • 00:17:02
    the server tells you where the place is, why would we
  • 00:17:06
    do the calculation?
  • 00:17:07
    Why did we do it?
  • 00:17:08
    We wanted that API to gain acceptance.
  • 00:17:11
    We wanted people to use the API and we
  • 00:17:13
    wanted that they didn't have to go to Wikipedia
  • 00:17:15
    and look at the formula how to calculate distance
  • 00:17:18
    between to lat longitude paths, and wanted
  • 00:17:21
    to do the work for them.
  • 00:17:22
    Similarly, we included the category.
  • 00:17:24
    Because again if you think about it,
  • 00:17:25
    if the map that I showed you, if here for example
  • 00:17:28
    this is a bar or pub, if you want
  • 00:17:30
    to show different icons on a map,
  • 00:17:32
    you quickly have a one class end problem.
  • 00:17:34
    You do the search and if you follow true REST,
  • 00:17:36
    the information would only be hidden, hidden.
  • 00:17:39
    Would only be in the actual results,
  • 00:17:41
    you would not only do the one search,
  • 00:17:43
    you would do for each of the search results,
  • 00:17:45
    do a specific request to find out more information.
  • 00:17:48
    And that is clearly unacceptable for the user.
  • 00:17:51
    So what I'm trying to say here is that we have ideas,
  • 00:17:53
    and I'm not saying they're wrong,
  • 00:17:55
    we have ideas about architecture,
  • 00:17:57
    but we need to understand what is
  • 00:17:58
    more important is user experience of the system we are
  • 00:18:01
    building and we have to judiciously deviate
  • 00:18:05
    from architectural principles.
  • 00:18:06
    We have to understand why they are there,
  • 00:18:08
    we shouldn't just recklessly throw them overboard
  • 00:18:11
    or say we don't care.
  • 00:18:13
    But they don't rule.
  • 00:18:14
    What rules is in the end user experience.
  • 00:18:16
    And having a search result include
  • 00:18:18
    those items, like we display them
  • 00:18:19
    on the map within two seconds, is way better than doing pure
  • 00:18:24
    and clean and REST by the book and take half a minute
  • 00:18:27
    to show the user the results.
  • 00:18:31
    That means, of course, and that's my second conclusion,
  • 00:18:34
    architecture and development cannot be separated.
  • 00:18:37
    You have to understand what the impact is
  • 00:18:42
    when you're implementing the architectural pattern.
  • 00:18:45
    You can't just sit there and say,
  • 00:18:46
    the architecture says we need to have REST.
  • 00:18:49
    Look at the book about REST, look about the maturity model
  • 00:18:53
    and implement it that way and follow that to the letter.
  • 00:18:56
    You have to understand the developmental impact.
  • 00:18:59
    And I would go even further in the example I shared with you,
  • 00:19:01
    we also did some actual measurement of how it performed
  • 00:19:05
    in the real world and we noticed on the 3G and nowadays LTE
  • 00:19:09
    networks, it didn't make a difference
  • 00:19:11
    from a latency perspective, whether you transmitted
  • 00:19:14
    one kilobyte or 15 kilobytes.
  • 00:19:16
    So it was actually using something
  • 00:19:19
    at even a lower level on how the network stack was implemented
  • 00:19:22
    or maybe even the back end of the mobile phone network
  • 00:19:26
    that we exploited, by saying rather than sending
  • 00:19:30
    one kilobyte of search results, we
  • 00:19:32
    can enrich the search result up to a level of 15 kilobytes
  • 00:19:35
    and provide more information in the same response
  • 00:19:37
    because it doesn't increase the response time
  • 00:19:40
    and yet creates a much richer user experience.
  • 00:19:42
    So architecture was informed by something that,
  • 00:19:45
    and I showed you that on the network level as well,
  • 00:19:48
    architecture at the high level was informed by implementation
  • 00:19:51
    details on a level like, I don't know,
  • 00:19:53
    five or six abstraction layer stern.
  • 00:19:55
    So you can't separate them, you can't do architecture upfront
  • 00:19:59
    and then implement it.
  • 00:20:00
    You need to understand how you implement it
  • 00:20:02
    and then that changes your architecture.
  • 00:20:05
    I will come back to that very, very much later in this
  • 00:20:07
    talk when I'm saying that even sometimes the cloud
  • 00:20:10
    cost, the cost that you need to pay for resources in one
  • 00:20:14
    of the public cloud providers can also
  • 00:20:16
    impact the architecture.
  • 00:20:17
    And again I would argue it's the right thing.
  • 00:20:21
    But then if I'm saying architecture and development
  • 00:20:24
    can't be separated, if I'm saying architecture
  • 00:20:26
    is a dangerous metaphor, what most developers are doing
  • 00:20:29
    would be similar to what architects in the building
  • 00:20:31
    sense do in the real world, what do architects normally do?
  • 00:20:36
    And one of the things I've seen a lot is design diagrams
  • 00:20:39
    and again we have done this for many years,
  • 00:20:42
    we've looked at visualization of what was actually implemented.
  • 00:20:46
    And this here is a real example of a system.
  • 00:20:48
    This is actually a standard spring Spring Boot application
  • 00:20:51
    and what we're seeing here is the individual context,
  • 00:20:55
    and, of course you can't read this on your screens,
  • 00:20:57
    the individual white boxes are components
  • 00:20:59
    as part of the spring architecture,
  • 00:21:01
    and the black lines are showing the true dependencies
  • 00:21:04
    between them.
  • 00:21:05
    And what I would argue is that this
  • 00:21:07
    is a mess that most developers can't keep in their head.
  • 00:21:11
    The architectural diagram looks like this.
  • 00:21:14
    It was a view controller layer, business object security
  • 00:21:18
    across those two layer and data access objects at the bottom.
  • 00:21:21
    I think it's not bad to have this diagram,
  • 00:21:24
    but I think that diagram alone is not sufficient.
  • 00:21:27
    The data access objects you can see on the right hand
  • 00:21:29
    side in that more vertical box, these are all the data
  • 00:21:32
    access objects.
  • 00:21:33
    The business object is the layer at the very top of the diagram,
  • 00:21:37
    but you can see that maze of dependencies between them,
  • 00:21:40
    and that is not shown in the architecture diagram.
  • 00:21:43
    So what I would argue is you can draw diagrams,
  • 00:21:46
    and maybe somebody should draw that diagram,
  • 00:21:48
    but this is a tiny fraction of the real work,
  • 00:21:51
    and again, it is only a conceptual picture
  • 00:21:53
    that doesn't really help you very much in the majority
  • 00:21:57
    or in the face of your engagement
  • 00:21:59
    when you're building the software.
  • 00:22:00
    What really helps you there is the true understanding,
  • 00:22:03
    you have to diagnose what is wrong with this picture.
  • 00:22:06
    Because that picture here is so agreeable
  • 00:22:08
    that hardly anybody would object to.
  • 00:22:11
    So be a bit mindful of design diagrams that
  • 00:22:14
    are done upfront, also I would always
  • 00:22:16
    argue that at least half the time, if not more often,
  • 00:22:20
    the design diagrams that exist on the wikis,
  • 00:22:22
    on Confluence, wherever you stole them, often are outdated
  • 00:22:26
    and don't resemble what is actually implemented.
  • 00:22:30
    And these visualizations that I showed you,
  • 00:22:32
    they don't lie because they show you
  • 00:22:34
    what is actually implemented.
  • 00:22:35
    Unfortunately, the truth is often a bit more ugly.
  • 00:22:40
    So other things, design patterns.
  • 00:22:42
    I think this is a very well covered area.
  • 00:22:45
    We're not inventing many new patterns and I would argue that
  • 00:22:48
    developers should be familiar with the patterns and be able
  • 00:22:50
    to pick the patterns. , Similarly I talked about
  • 00:22:53
    frameworks.
  • 00:22:54
    Who is writing the frameworks today,
  • 00:22:56
    most of the frameworks we use are
  • 00:22:58
    being harvested from real use, be that at Google, at Facebook,
  • 00:23:01
    at some of the Silicon Valley giants, other organizations.
  • 00:23:04
    They're usually open source software
  • 00:23:05
    that we are pulling in.
  • 00:23:07
    And again, should an architect really
  • 00:23:09
    make the choice what framework to use,
  • 00:23:11
    or should that be the developers to understand
  • 00:23:12
    the constraints of the actual implementation much better,
  • 00:23:15
    especially bearing in mind what I said earlier
  • 00:23:18
    that the implementation of the framework
  • 00:23:20
    needs to be known that the abstraction is good,
  • 00:23:23
    but you need to understand how it is implemented.
  • 00:23:26
    Other artifacts that go into the process.
  • 00:23:28
    I'm not talking about the artifacts that come out
  • 00:23:30
    of the build that get deployed, I'm
  • 00:23:32
    talking about the artifacts that go
  • 00:23:33
    into the software development process, other code.
  • 00:23:36
    And I like that idea.
  • 00:23:37
    A Lot of people that I've seen have
  • 00:23:39
    called themselves coding architects
  • 00:23:42
    to emphasize the fact that they're also writing code.
  • 00:23:44
    That they live with the consequences of their designs.
  • 00:23:47
    That they don't stop at the diagram with the four boxes
  • 00:23:50
    I showed you, but that they understand the consequence
  • 00:23:52
    and understand the diagram that I also showed you
  • 00:23:55
    with the hundreds of lines and hundreds of boxes
  • 00:23:58
    that are connected by all those lines.
  • 00:24:00
    I like that idea.
  • 00:24:01
    Code is an important artifact, but if you
  • 00:24:03
    are coding architect, you could also
  • 00:24:05
    say you're an architecting developer.
  • 00:24:07
    I think it becomes one and the same thing really.
  • 00:24:09
    And then, of course, tests.
  • 00:24:11
    Tests are hugely important artifact.
  • 00:24:13
    If you ask me what is the best thing you
  • 00:24:15
    can do to become a better IT organization
  • 00:24:17
    I would say test automation.
  • 00:24:19
    But again, here the tests need to be done hand
  • 00:24:21
    in hand between developers and people
  • 00:24:24
    who wear a hat of quality assurance.
  • 00:24:26
    I don't think you should outsource this
  • 00:24:28
    and I think hardly anybody would agree or would
  • 00:24:31
    say that is the role of software architects to write tests.
  • 00:24:35
    So, that brings me to maybe the most controversial
  • 00:24:38
    of my four conclusions.
  • 00:24:39
    And that is, most of what architects
  • 00:24:41
    have done traditionally should be
  • 00:24:43
    done by developers, or by tools, these visualization tools,
  • 00:24:47
    or maybe not at all.
  • 00:24:50
    I let that sit with you for a second.
  • 00:24:56
    And so, but why do we have such a fascination with architects?
  • 00:25:04
    As I said one this clearly, and I apologize for saying it so
  • 00:25:07
    bluntly, but clearly prestige.
  • 00:25:09
    There's an idea that there's a career path.
  • 00:25:11
    That once you hit a glass ceiling as developer,
  • 00:25:13
    you have to become an architect to progress in your career.
  • 00:25:17
    But I think there's something much, much deeper in this.
  • 00:25:21
    And that has to do with the idea of how we human beings
  • 00:25:24
    talk about evolution and how we think about complex systems.
  • 00:25:29
    I guess many of us know how evolution works,
  • 00:25:32
    we actually see with the COVID pandemic at the moment
  • 00:25:34
    how that virus also evolves over time.
  • 00:25:37
    There's a lot of fascinating things
  • 00:25:38
    we can even remind ourselves.
  • 00:25:40
    But I often got reminded of it when I look at say--
  • 00:25:44
    when my son was younger and we went to the zoo
  • 00:25:46
    and we saw monkeys in the zoo and I
  • 00:25:48
    knew 90% of the DNA of a chimpanzee
  • 00:25:51
    was the same as our DNA.
  • 00:25:53
    It is hard to imagine, sometimes it feels a bit odd too,
  • 00:25:55
    doesn't it?
  • 00:25:56
    It feels uncomfortable.
  • 00:25:58
    Then when I talk about evolution,
  • 00:26:00
    you've seen the picture of that man on the picture for a while
  • 00:26:03
    now, this is not Charles Darwin.
  • 00:26:05
    It is actually a person called William Paley,
  • 00:26:07
    and he lived way before Charles Darwin.
  • 00:26:10
    The reason why I have him here is
  • 00:26:12
    he wanted to prove that God exists.
  • 00:26:15
    And he came up with this idea and he
  • 00:26:16
    said, if you walk along a country path
  • 00:26:20
    and you stumble across the mechanical watch,
  • 00:26:23
    what would you think?
  • 00:26:24
    Where did this watch come from?
  • 00:26:26
    Did it, poof, just come into existence
  • 00:26:29
    or did America have to do this?
  • 00:26:31
    And he was arguing that because these watches don't just
  • 00:26:35
    appear out of nowhere, there needs to be a maker.
  • 00:26:38
    And his line of argument then continue to say,
  • 00:26:41
    if something as complex as a human being exists,
  • 00:26:44
    it also doesn't just come into existence,
  • 00:26:46
    there needs to be a maker who created that complex organism.
  • 00:26:49
    And that of course was then his conclusion
  • 00:26:52
    that God must exist because who else would
  • 00:26:55
    have created the human beings.
  • 00:26:56
    There are many flaws in this argument
  • 00:26:57
    I don't want to debate, but I think
  • 00:26:59
    the underlying idea is clear, as humans
  • 00:27:01
    we are uncomfortable with complex systems just appearing.
  • 00:27:05
    We believe there needs to be some unified single force
  • 00:27:09
    behind it to create these systems.
  • 00:27:11
    This is in popular culture.
  • 00:27:13
    I mean this is from The Matrix movies.
  • 00:27:15
    They have The Architect even who is behind all
  • 00:27:17
    of this, The Architect.
  • 00:27:19
    This is just such so ingrained in us
  • 00:27:21
    that we believe that must be the case.
  • 00:27:24
    But I have hope for you.
  • 00:27:25
    It's a metaphor I've used for a long time also, town planning.
  • 00:27:30
    I think this makes it very clear to many people.
  • 00:27:34
    A town, and this is a model of London, a relatively
  • 00:27:37
    contemporary model of London.
  • 00:27:39
    That is a complex organism if you will.
  • 00:27:42
    A complex achievement of human civilization.
  • 00:27:45
    And it didn't just spring into existence.
  • 00:27:47
    It evolved over several thousand years.
  • 00:27:50
    And of course, nobody can say that whoever founded Rome,
  • 00:27:53
    you could argue whether it was the people who
  • 00:27:55
    lived there first or maybe the Roman Empire
  • 00:27:57
    2000 years ago when they formally founded whatever
  • 00:28:01
    formally means in that case, whenever they formally founded
  • 00:28:04
    London, they didn't plan, they didn't
  • 00:28:06
    have a plan for what London would
  • 00:28:07
    look like 2000 years later.
  • 00:28:10
    They came up with something that worked for them at the time,
  • 00:28:13
    of course they were visionary enough to think
  • 00:28:15
    ahead a little bit of how it could possibly evolve,
  • 00:28:18
    but nobody can tell me that they knew what it would
  • 00:28:20
    be needed 2000 years later.
  • 00:28:22
    And yet we have a complex and reasonably functioning city.
  • 00:28:27
    You could always argue traffic jams are a pain,
  • 00:28:30
    maybe you could do something about the traffic jams,
  • 00:28:32
    but I would even argue and I've seen those, for example--
  • 00:28:35
    I lived in Australia for a while,
  • 00:28:36
    if you look at Canberra which is a planned city, that
  • 00:28:38
    doesn't solve the issue.
  • 00:28:40
    More lanes to a highway will just attract more traffic.
  • 00:28:43
    So what we are arguing is that a functioning
  • 00:28:45
    system like a city of London could be created over time,
  • 00:28:50
    it evolved.
  • 00:28:51
    The cool thing though is, there are
  • 00:28:53
    some things we can learn if we accept this town planner
  • 00:28:56
    metaphor from the town planners.
  • 00:28:58
    Because they do have rules, they didn't
  • 00:29:00
    say precisely what needed to go where, but they have rules.
  • 00:29:03
    They are talking about say something like a conservation
  • 00:29:05
    area.
  • 00:29:06
    An area where old houses exist and they must stay that way.
  • 00:29:10
    You can see some parks here, these are protected,
  • 00:29:13
    you can't just change them.
  • 00:29:14
    You can't put an industrial factory
  • 00:29:17
    in the middle of a residential area,
  • 00:29:19
    there are these so-called zoning laws.
  • 00:29:21
    But even then, what we've seen over time
  • 00:29:24
    these zoning laws are changing.
  • 00:29:26
    For a while, there was a big segregation.
  • 00:29:27
    Offices in one part of the city and then leafy suburbs
  • 00:29:30
    where people would live.
  • 00:29:31
    We're seeing how as we learn more
  • 00:29:34
    and how fashions change that is also changing.
  • 00:29:37
    Now we're trying to get more apartments back into the area.
  • 00:29:40
    We want to move offices a bit farther out.
  • 00:29:42
    So even though we have rules at a higher level,
  • 00:29:45
    even those rules evolving over time.
  • 00:29:48
    But in the remainder of my talk, I
  • 00:29:50
    want to go a bit more into those rules,
  • 00:29:52
    into what we can learn from the town planners.
  • 00:29:54
    But maybe before I do that, the fourth and final conclusion
  • 00:29:58
    that I want to present, architecture
  • 00:30:00
    is mostly or probably even exclusively
  • 00:30:03
    an ongoing activity.
  • 00:30:04
    It is unlike the building architecture,
  • 00:30:07
    an upfront thing that happens in the construction phase.
  • 00:30:10
    The construction phase of most IT landscapes
  • 00:30:13
    is never finished if you talk about enterprises, if you talk
  • 00:30:16
    about all sorts of other areas.
  • 00:30:18
    Maybe one small niche case that I'm aware of are video games.
  • 00:30:23
    These are sometimes often finished, many of them anyway.
  • 00:30:27
    You write them, you sell them, maybe a few patches,
  • 00:30:29
    downloadable content, but they are mostly finished.
  • 00:30:32
    That's an exception.
  • 00:30:33
    But for most of the IT, and I guess most of you
  • 00:30:35
    work in enterprise IT, I would argue
  • 00:30:37
    that you don't have a construction
  • 00:30:39
    phase like with a skyscraper and then you
  • 00:30:41
    use a phase where that is being used.
  • 00:30:45
    So coming back to this idea of town planning,
  • 00:30:49
    of having a large complex system that evolves over time, that
  • 00:30:51
    adapts to the needs of its users, the inhabitants
  • 00:30:54
    of the city, e-commerce and so on, how would that look like?
  • 00:30:58
    Let's talk about microservices.
  • 00:31:01
    If we talk about architecture, oftentimes you have people,
  • 00:31:06
    you have architects who then say,
  • 00:31:07
    I want to focus on the macroarchitecture.
  • 00:31:10
    And it starts off innocently.
  • 00:31:13
    Somebody says REST, HTTP, JSON, and I talked to you at length
  • 00:31:17
    about what REST does actually mean when
  • 00:31:20
    you talk about implementation.
  • 00:31:21
    But what happens then is OK, the people
  • 00:31:23
    who are writing the microservices
  • 00:31:24
    are saying, well, sure HTTP, JSON,
  • 00:31:27
    we put some end point on our microservices, all done.
  • 00:31:31
    But then the slippery slope starts.
  • 00:31:35
    Then you start getting to pictures like this.
  • 00:31:38
    People are saying I don't care about the microarchitecture,
  • 00:31:40
    well, what's happening inside the microservices?
  • 00:31:42
    Hopefully, they're not building frameworks
  • 00:31:44
    that must be used across all microservices.
  • 00:31:47
    But the architects are then saying,
  • 00:31:48
    I want to look at the macroarchitecture,
  • 00:31:50
    and then categorizations appear.
  • 00:31:51
    Like that service E that I have in here, the ecoservice.
  • 00:31:56
    That's a backend for frontend, because I suddenly
  • 00:31:59
    have a mobile interface and it doesn't
  • 00:32:00
    want to call the different services, like what I told you,
  • 00:32:03
    violating RESTs for example.
  • 00:32:05
    Or we have services G and F, they
  • 00:32:07
    are different type of service, they only provide data
  • 00:32:10
    to other microservices.
  • 00:32:11
    A, B, C, and D are still normal microservices.
  • 00:32:14
    But then we have API gateways, we have the user interface
  • 00:32:19
    layer, and so on.
  • 00:32:20
    And suddenly, the entire debate and the entire argument
  • 00:32:23
    is happening on that level, but in the end
  • 00:32:26
    this is the wrong level because what we really
  • 00:32:28
    care about is implementing business functionality.
  • 00:32:31
    If we get stuck in arguing is this the backend service,
  • 00:32:34
    is service F, should there be purple on the diagram,
  • 00:32:37
    or in this turquoise color?
  • 00:32:38
    Then we're having all these fruitless discussions
  • 00:32:40
    that I guess many of us have been involved In,
  • 00:32:42
    and are so frustrating because we're not solving business
  • 00:32:45
    problems with that.
  • 00:32:46
    We are debating at a high level architectural concerns
  • 00:32:49
    that don't really help us achieve the goals.
  • 00:32:51
    Of course it is aware, I'm not saying
  • 00:32:54
    you should not know what a backend or frontend pattern is.
  • 00:32:57
    I'm not saying you shouldn't talk about reuse of data access
  • 00:33:00
    layers, I understand that.
  • 00:33:02
    What I'm saying is the conversations
  • 00:33:04
    we're having shouldn't be focused around that.
  • 00:33:07
    You should reduce all of that to the minimum background noise.
  • 00:33:11
    You should probably have a guild, you should have people--
  • 00:33:13
    you should have people focusing on architecture that
  • 00:33:15
    are implementing the services.
  • 00:33:17
    They should come together on a given
  • 00:33:19
    cadence, every week, every second week,
  • 00:33:22
    and debate these concerns.
  • 00:33:24
    There's much more to be heard here in that space.
  • 00:33:26
    about what those discussions can look like,
  • 00:33:27
    but it shouldn't be in the foreground,
  • 00:33:29
    it shouldn't be deemed the most important thing.
  • 00:33:31
    The most important thing is to deliver business value,
  • 00:33:34
    not pretty diagrams.
  • 00:33:38
    And ultimately, I could--
  • 00:33:39
    I debated with myself whether to put the sentence on this slide.
  • 00:33:42
    I'm only going to tell you that.
  • 00:33:44
    You should really focus on what you want,
  • 00:33:46
    and that is what your users and your business wants.
  • 00:33:49
    These diagrams focus on how to achieve it.
  • 00:33:53
    That's not unimportant as I said earlier,
  • 00:33:55
    it's not the most important thing, no.
  • 00:33:58
    So how do you focus on what you want
  • 00:34:02
    when it comes to these concerns over how to achieve it?
  • 00:34:07
    And that is the idea that has been crystallized much more
  • 00:34:11
    over recent years, and I would argue very well explained
  • 00:34:14
    in the book some of my colleagues
  • 00:34:15
    have written called Building Evolutionary Architectures.
  • 00:34:19
    And this on the right hand side of the slide
  • 00:34:21
    is their definition of an evolutionary architecture.
  • 00:34:23
    It says it supports guided incremental change
  • 00:34:26
    across multiple dimensions.
  • 00:34:27
    We've talked quite a bit, or I have talked quite a bit,
  • 00:34:30
    about incremental change.
  • 00:34:31
    Across multiple dimensions, I can
  • 00:34:33
    explain easily this is look at performance, look at security,
  • 00:34:37
    look at all the different areas, often, these
  • 00:34:40
    are called the non-functional requirements,
  • 00:34:42
    the cross functional requirements, or sometimes
  • 00:34:44
    for short, the ilities, because most of those words on ility.
  • 00:34:48
    Scalability and so on.
  • 00:34:51
    What I want to focus on going back to the town planning
  • 00:34:54
    metaphor is this word here, guided.
  • 00:34:56
    How do you guide the evolution of a complex system
  • 00:35:00
    assuming you're on board with my idea of saying
  • 00:35:02
    that these systems have to evolve,
  • 00:35:04
    that you can't plan them up front?
  • 00:35:07
    And this is something that Rebecca
  • 00:35:09
    who is one of the co-authors of the book, our CTO,
  • 00:35:14
    is probably not so surprising because she also knows
  • 00:35:16
    about evolutionary computing.
  • 00:35:19
    And what we have there are these so-called fitness functions.
  • 00:35:22
    This is a picture actually from a video game
  • 00:35:24
    but it gives you an idea.
  • 00:35:26
    What people have tried to do is with genetic programming they
  • 00:35:29
    set, there is a fitness function, and on this screen
  • 00:35:31
    you can see several of them.
  • 00:35:33
    At the top you see the budget.
  • 00:35:34
    This bridge you consume or it can
  • 00:35:36
    be built in this model, of course this
  • 00:35:38
    is the only model, for 22,000 game dollars.
  • 00:35:43
    And at the moment you can see the red car,
  • 00:35:45
    creates 64.8% of structural load on the bridge.
  • 00:35:49
    If that reaches 100% the bridge collapses.
  • 00:35:51
    So here we have two fitness functions.
  • 00:35:53
    We are saying it needs to hold the car, it can't collapse,
  • 00:35:57
    and it needs to be cheap, it needs to stay in the budget.
  • 00:36:00
    And what happened is these fitness
  • 00:36:01
    functions were then given in evolutionary computing
  • 00:36:04
    to genetic programming and the algorithm
  • 00:36:06
    would find the best solution.
  • 00:36:08
    And this was actually also used for real world bridges
  • 00:36:12
    and the bridges looked even weirder than that one.
  • 00:36:14
    And people realized there was another fitness function.
  • 00:36:16
    It needs to look trustworthy to human beings.
  • 00:36:20
    But that's beside the point.
  • 00:36:21
    The idea really is you can see in this bridge example,
  • 00:36:24
    there are different fitness functions,
  • 00:36:25
    and sometimes they're contradictory.
  • 00:36:27
    I can make a rock solid super-saver bridge
  • 00:36:29
    but I might exceed the budget.
  • 00:36:31
    The key goal is to find the trade-offs.
  • 00:36:33
    And that's exactly what we see in computer science
  • 00:36:35
    and in enterprise computing as well.
  • 00:36:38
    We have these requirements that are often
  • 00:36:41
    hard to meet at the same time.
  • 00:36:43
    One is easy to meet but multiple at the same time
  • 00:36:45
    can be tougher.
  • 00:36:47
    So this is the definition of evolutionary computing.
  • 00:36:51
    So it's this objective function that
  • 00:36:53
    summarizes how close the design solution is
  • 00:36:55
    to achieving the set of aims.
  • 00:36:57
    As I showed you with the costs, with the budget
  • 00:36:59
    for the bridge as well as the structural integrity.
  • 00:37:04
    We can vary this and say an architectural fitness
  • 00:37:08
    function provides an objective integrity
  • 00:37:11
    assessment of some architectural characteristics.
  • 00:37:13
    And that's what I said, performance, reliability, these
  • 00:37:17
    are the characteristics.
  • 00:37:19
    And I recognize that this sounds awfully abstract.
  • 00:37:22
    I guess the fitness function concept is relatively clear,
  • 00:37:24
    but how do I do this?
  • 00:37:25
    You have these concerns, you have stakeholders
  • 00:37:27
    in your business who say this thing must be up 24/7,
  • 00:37:30
    we want five nines, all these statements that come out.
  • 00:37:33
    How do you get that into a fitness function.
  • 00:37:36
    So I want to spend the next few minutes
  • 00:37:38
    to talk about some fitness functions to give you
  • 00:37:40
    an idea of what they can look like.
  • 00:37:41
    And I've chosen delivered-- there's many, many of them.
  • 00:37:44
    I've chosen the few that give you
  • 00:37:46
    an idea of the breadth to kind of spur
  • 00:37:49
    your imagination a little bit.
  • 00:37:52
    So coupling is an important one.
  • 00:37:54
    We often talk about coupling and layering.
  • 00:37:56
    This can even be and this is a true example, minus, of course,
  • 00:38:00
    the renaming of the packages, this
  • 00:38:01
    can even be done in your code.
  • 00:38:04
    There's jdepend which is a Java-based package that
  • 00:38:07
    allows you to define and you can see that in the top lines here
  • 00:38:10
    the persistence web util they're defined as packages.
  • 00:38:15
    And this is actually looking into your real code,
  • 00:38:17
    into the real implementation.
  • 00:38:19
    And then I can say in the lines further down
  • 00:38:21
    persistence is allowed to depend upon utility
  • 00:38:24
    and web is also allowed to depend on utility.
  • 00:38:28
    Then I'm saying jdepend analyse, this is why it's running,
  • 00:38:32
    and then I'm saying, is it true that my constraints are
  • 00:38:37
    matched.
  • 00:38:38
    And he have a fitness function.
  • 00:38:40
    We have an architectural principle
  • 00:38:41
    that says we don't want a dependency on web
  • 00:38:45
    and persistence, is not allowed.
  • 00:38:47
    But rather than drawing that into a diagram,
  • 00:38:49
    writing it on a wiki, we are putting that
  • 00:38:51
    into a fitness function that I can run as part of my build.
  • 00:38:56
    So here I have a very, very simple,
  • 00:38:58
    very easy to understand fitness function.
  • 00:39:00
    It would be ideal if I could show you 20 of them,
  • 00:39:03
    but time doesn't permit.
  • 00:39:04
    I'll give you a different one.
  • 00:39:05
    This is actually, and I must say this,
  • 00:39:07
    this slide is not my slide, it's purely
  • 00:39:09
    copied from public resources from Apple's Worldwide
  • 00:39:12
    Developers Conference in 2019.
  • 00:39:15
    What Apple does is it allows the authors and the organizations
  • 00:39:18
    behind applications to measure certain things in production.
  • 00:39:22
    And here what we see this is launch time.
  • 00:39:25
    How long does it take to launch a mobile phone,
  • 00:39:27
    a mobile application on your iPhone.
  • 00:39:29
    And the developers do get the data back from Apple.
  • 00:39:32
    And what you can see here is you can see the application
  • 00:39:35
    versions on the bus, from 1.0 to 1.0.8 on the right hand side.
  • 00:39:40
    And they are measuring the launch time.
  • 00:39:42
    And the fitness function here could
  • 00:39:44
    be something the launch time itself
  • 00:39:47
    but you could introduce a threshold
  • 00:39:50
    to say if that goes over 1,500 milliseconds my application is
  • 00:39:54
    not fit for purpose.
  • 00:39:55
    It takes too long and our users will abandon the application.
  • 00:39:59
    So what you're doing then is you're saying,
  • 00:40:00
    I'm measuring an objective thing.
  • 00:40:03
    How long does it take.
  • 00:40:04
    You're not even measuring this in development,
  • 00:40:06
    you're actually measuring this in production.
  • 00:40:08
    You're moving this into production.
  • 00:40:10
    And then you say, OK but isn't that irresponsible, isn't
  • 00:40:12
    that too late?
  • 00:40:13
    You could argue maybe.
  • 00:40:15
    But if it is in a small scale like here,
  • 00:40:17
    you can see oh, we maybe went overboard,
  • 00:40:19
    in the field the application takes too long
  • 00:40:21
    and you can spend the next development
  • 00:40:23
    cycle to actually improve.
  • 00:40:24
    You can put a priority on improving the load
  • 00:40:27
    time, the start up time of the application
  • 00:40:29
    and then hopefully, when version 1.0.9 comes out
  • 00:40:32
    you can actually demonstrate a clear business value, what
  • 00:40:35
    your real users are seeing, that your application is now
  • 00:40:38
    fit up for purpose again.
  • 00:40:42
    Very similarly, resilience.
  • 00:40:45
    Everybody wants to talk about resilience.
  • 00:40:47
    How do your system is resilient?
  • 00:40:50
    You're trying to break it.
  • 00:40:51
    Netflix made available the Simian Army.
  • 00:40:53
    Open source software that allows you to misconfigure and destroy
  • 00:40:57
    instances in your production environment.
  • 00:40:59
    On the right hand side, I've shown
  • 00:41:00
    you something from a software as a service
  • 00:41:02
    system called Gremlin that does something very similar.
  • 00:41:05
    The idea with chaos engineering is to stand by your words.
  • 00:41:10
    To say, I'm not only architecting a resilient
  • 00:41:13
    application, I'm demonstrating to everybody, my stakeholders
  • 00:41:16
    and everybody in production, it is
  • 00:41:18
    OK to kill a few microservices because that's
  • 00:41:21
    what could happen if Amazon loses one region,
  • 00:41:24
    but I demonstrate that it does actually work.
  • 00:41:27
    This is a metaphor for an entire talk,
  • 00:41:29
    if you've not come across the concept I'd strongly
  • 00:41:32
    advise you to read up on it.
  • 00:41:34
    The last example, oops, the last example I want to show you
  • 00:41:38
    is this here.
  • 00:41:38
    Dependency drift.
  • 00:41:40
    Many of us are using open source software packages,
  • 00:41:43
    and I mentioned that earlier, oftentimes published
  • 00:41:45
    by the Silicon Valley giants.
  • 00:41:47
    The CS Angular for example, coming out of Google.
  • 00:41:49
    And oftentimes we are in an enterprise context that
  • 00:41:52
    lives by the enterprise rules.
  • 00:41:54
    But we are taking open source software
  • 00:41:55
    that lives by the Silicon Valley rules
  • 00:41:58
    and that often is a cause problems.
  • 00:42:01
    What I'm seeing here is, this was a real world example again.
  • 00:42:05
    An application that uses version seven of Angular.
  • 00:42:08
    You can see this in many, many different places
  • 00:42:10
    here in the output.
  • 00:42:12
    You can see it uses angular animations,
  • 00:42:14
    current major version used in the engagement is
  • 00:42:18
    version seven made available from Google is version 10.
  • 00:42:24
    If you then look at the documentation,
  • 00:42:26
    you will see the version seven is not really
  • 00:42:28
    supported anymore.
  • 00:42:28
    Google only support-- I mean, this is maybe in edge case,
  • 00:42:31
    but nine and eighth are probably supported better,
  • 00:42:34
    if you were in version six you would definitely
  • 00:42:36
    have a problem.
  • 00:42:37
    So your dependencies are drifting,
  • 00:42:39
    you're drifting behind.
  • 00:42:40
    You don't spend enough time keeping up to date.
  • 00:42:42
    You think, well, we chose version seven when we started
  • 00:42:44
    the project, when we started this product, that was good,
  • 00:42:47
    never change a running system.
  • 00:42:49
    But the internet giants they change
  • 00:42:51
    and they make the improvement and security changes
  • 00:42:53
    only in the newer version.
  • 00:42:54
    So you really-- by accepting their frameworks you
  • 00:42:57
    have to accept their way of working
  • 00:42:59
    and have to stay current.
  • 00:43:00
    If you don't believe me, this is the true output
  • 00:43:04
    from that system and you can see in the top line I'm
  • 00:43:06
    running NPM audit, the node package manager,
  • 00:43:09
    and at the very bottom, you can see
  • 00:43:11
    1,854 vulnerabilities found.
  • 00:43:14
    I'm three major versions behind, I'm behind from version 10
  • 00:43:17
    to seven.
  • 00:43:18
    You could argue this is all small fry, doesn't concern me,
  • 00:43:21
    but you see also hopefully in that picture 23 of them
  • 00:43:25
    are high impact vulnerabilities, and one of them
  • 00:43:28
    is enough to cause a major data leak in your business.
  • 00:43:32
    So again, dependency drift says how
  • 00:43:34
    fit your system is to be actually secure running
  • 00:43:37
    into production.
  • 00:43:41
    So, I've shown you coupling, performance, resilience,
  • 00:43:45
    dependency drift, there are many others, I alluded to them.
  • 00:43:47
    Cloud cost, license compatibility,
  • 00:43:50
    there are so many fitness functions you can think about,
  • 00:43:52
    and I think if you will, the role of an architecture team,
  • 00:43:56
    of a team who talks about architectures, maybe
  • 00:43:58
    to think about how he can translate the ideas that you
  • 00:44:03
    have, the business requirements of your systems
  • 00:44:06
    into these fitness functions.
  • 00:44:07
    Like the town planners, they have
  • 00:44:09
    ideas about how the city should evolve
  • 00:44:11
    and they come up with these rules about how
  • 00:44:13
    the town should evolve.
  • 00:44:14
    They're not telling you how to build a building,
  • 00:44:16
    but they're telling you rules that
  • 00:44:18
    can be measured of how the outcome should look like.
  • 00:44:22
    And that brings me to the last thought of this talk.
  • 00:44:25
    Maybe if we talk about architects, maybe architects
  • 00:44:30
    are guides, like that person in the picture here with the hat.
  • 00:44:34
    He's bringing the tourists through the jungle.
  • 00:44:37
    He doesn't carry them across the river.
  • 00:44:39
    And he's probably pointing at a bird or some animal in a tree,
  • 00:44:42
    he's showing them where that animal is
  • 00:44:44
    and it is up to the people to look at it.
  • 00:44:46
    He's not climbing up the tree, carrying down the bird
  • 00:44:49
    and holding it in front of them.
  • 00:44:50
    The architects should not be, and unfortunately I've
  • 00:44:53
    heard this, they're not parents, they're not
  • 00:44:54
    protecting the people.
  • 00:44:55
    I think they should guide them.
  • 00:44:57
    And I really honestly believe these ideas of fitness function
  • 00:45:00
    in an evolving architecture are the closest
  • 00:45:03
    we've gotten to, to that image.
  • 00:45:05
    To that idea of guiding people to do the right thing,
  • 00:45:08
    but guiding the people who are up to their neck
  • 00:45:11
    in the actual implementation to guide
  • 00:45:13
    them to do the right things.
  • 00:45:16
    And that is my overall summary.
  • 00:45:25
    Thank you so much, Eric.
  • 00:45:28
    I truly enjoy your analogies.
  • 00:45:30
    Wow.
  • 00:45:31
    Next time if someone asks me what is architect,
  • 00:45:35
    I have a lot of resource to answer,
  • 00:45:37
    and I love your analogies for sure.
  • 00:45:40
    And what a coincidence, today actually in Singapore
  • 00:45:43
    we are having these [INAUDIBLE] discussions, talking
  • 00:45:46
    about all the titles, where we are saying we
  • 00:45:50
    don't have to put our official title in your name card
  • 00:45:53
    and what are some of the interesting thing
  • 00:45:55
    we like to put our name card.
  • 00:45:57
    So from gardeners to coding architects
  • 00:46:00
    to guides, wow, so many inspirations.
  • 00:46:03
    And I really love how you go down
  • 00:46:06
    to the core reality of what exactly
  • 00:46:09
    we are doing as architect and tear off all the prestige
  • 00:46:14
    layers on top of it.
  • 00:46:15
    Thank you so much for this show Eric.
  • 00:46:19
    I really, really enjoyed it.
Tags
  • Software Architecture
  • Agile Values
  • Gardening Metaphor
  • Fitness Functions
  • Ongoing Evolution
  • User Experience
  • Architects
  • Software Development
  • Complex Systems
  • Guidance