How to Think Like an Architect - Mark Richards

00:58:31
https://www.youtube.com/watch?v=W7Krz__jJUg

Ringkasan

TLDRThe video discusses the importance of thinking like a software architect for developers and other software practitioners. It explains that architectural thinking isn't limited to architects only but involves a perspective that helps in creating more effective software systems. Thinking like an architect involves understanding business drivers to determine architectural characteristics (e.g., performance, scalability), expanding one's breadth of knowledge beyond current expertise, and being capable of identifying and analyzing trade-offs in software architecture. The presenter uses examples such as decision-making in event-driven architecture to illustrate common trade-offs between scalability, performance, data integrity, and so on. Practical advice such as the '20-minute rule' for self-education on technical breadth is shared, and the potential pitfalls of over-evangelizing technologies, which can obscure important trade-offs, are discussed.

Takeaways

  • 💡 You don't need to be an architect to think like one, and this mindset helps build better systems.
  • 🌥️ Different people view the same problem from different perspectives, highlighting the importance of an architectural viewpoint.
  • 🔄 Everything in software architecture involves trade-offs, making decision-making complex and contextual.
  • 📊 Understanding business drivers is essential to translate them into technical requirements and architecture characteristics.
  • 🛠️ Developers should broaden their technical knowledge beyond what they know to enhance problem-solving.
  • ⏳ Adopt the '20-minute rule' to invest in expanding your technical breadth daily.
  • ⚖️ Be cautious of over-evangelizing technologies, as every tool or framework has its trade-offs.
  • 🧗‍♂️ Adopting architectural thinking can set developers on a rewarding career path without changing roles.
  • 📝 Characteristics worksheets can help identify and align architectural needs with business goals.
  • 🎓 The transition from developer to architect involves shifting focus from depth to a breadth of technical knowledge.

Garis waktu

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

    Thinking like a software architect offers developers advantages, such as building more effective systems and advancing in their careers. The speaker discusses the significance of viewing problems from an architectural perspective, using the metaphor of clouds being viewed differently by meteorologists, artists, and IT professionals.

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

    Understanding architectural thinking is essential for all developers, regardless of their role. The speaker illustrates a scenario involving message and event-driven architecture, highlighting the trade-offs between sending full payloads and key-based events, emphasizing the importance of scalability, contracts, and potential complications like stamp coupling.

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

    The speaker explains the complications of stamp coupling, bandwidth issues, and multiple systems of record in message-driven architecture. The choice between full payload and key-based events involves various trade-offs. Recognizing these allows developers to better analyze and make architectural decisions, understanding that software architecture is about trade-offs.

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

    Thinking like an architect involves understanding business drivers' importance, seeing more solutions, and analyzing trade-offs. The speaker emphasizes the need to align business needs with architectural characteristics such as scalability, availability, and performance, translating business concerns into architecture requirements.

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

    The challenge of architectural thinking involves translating business needs into architectural characteristics like fault tolerance and reliability. The speaker uses a translation engine metaphor, discussing how to identify which architectural characteristics are important and how they'd support business objectives like user satisfaction and time to market.

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

    The speaker illustrates the translation of business requirements into architectural characteristics, emphasizing the role of architects as translators. Important business-driven characteristics might emerge from domain knowledge, requirements, and conversations with stakeholders.

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

    Architecture involves a breadth of knowledge, requiring architects to be aware of diverse solutions. The speaker discusses technical breadth versus depth, encouraging expanding knowledge to understand various solutions, tools, and techniques. This can help in providing more appropriate solutions to problems.

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

    Discussing the knowledge triangle, the speaker illustrates different phases in a career's knowledge base: junior developer, senior developer, etc., with a shift from deep knowledge of fewer things to broader knowledge of more things, essential for architects to see more solutions.

  • 00:40:00 - 00:45:00

    The speaker shares methods to expand technical breadth, such as attending conferences and using resources like InfoQ and ThoughtWorks Radar. The "20-minute rule" involves dedicating daily time to learning new things, contributing to growing technical knowledge and perspective.

  • 00:45:00 - 00:50:00

    Highlighting the importance of analyzing trade-offs, the speaker emphasizes understanding that all architectural decisions involve trade-offs. Developers often know the benefits but may overlook trade-offs. Thinking architecturally means balancing trade-offs against business needs.

  • 00:50:00 - 00:58:31

    The speaker advises avoiding the out-of-context trap and over-evangelizing technology by understanding contextual relevance and being aware of trade-offs. Architects must balance emotions about technologies with objectivity. This allows for effective architectural thinking and decision-making.

Tampilkan lebih banyak

Peta Pikiran

Video Tanya Jawab

  • What is architectural thinking in software development?

    Architectural thinking involves seeing and solving problems with an architect's perspective, considering trade-offs, business drivers, and high-level solutions.

  • How can developers benefit from thinking like an architect?

    Developers can create more effective and well-built systems, make informed decisions, and accelerate their career growth by adopting an architect's perspective.

  • What are the three core components of thinking like an architect according to the video?

    Understanding business drivers, expanding knowledge breadth, and analyzing trade-offs are the three main components.

  • Why is understanding business drivers important for architectural thinking?

    Understanding business drivers helps translate them into architectural characteristics like scalability or performance, ensuring the system meets business needs.

  • What is the '20-minute rule' suggested in the video?

    The '20-minute rule' suggests spending 20 minutes daily on self-education regarding technical knowledge to broaden one's knowledge breadth.

  • Why should architects avoid over-evangelizing technologies?

    Over-evangelizing hides trade-offs associated with a technology, which can lead to overlooking potential disadvantages or context in decision-making.

  • What are architecture characteristics?

    Architecture characteristics are elements such as performance, scalability, and fault tolerance, which guide system architecture to support business needs.

  • How can technical breadth affect an architect's ability to solve problems?

    A broad technical knowledge enables architects to see more solutions to problems, leading to more appropriate and effective system designs.

Lihat lebih banyak ringkasan video

Dapatkan akses instan ke ringkasan video YouTube gratis yang didukung oleh AI!
Teks
en
Gulir Otomatis:
  • 00:00:00
    [Music]
  • 00:00:12
    you don't have to be a software
  • 00:00:16
    architect
  • 00:00:18
    to think like a software architect
  • 00:00:21
    and this gives you several advantages
  • 00:00:24
    first
  • 00:00:26
    a more effective and well-built system
  • 00:00:29
    even as a developer
  • 00:00:31
    and also a good head start on a really
  • 00:00:35
    fun and rewarding career path so that's
  • 00:00:38
    what I want to show you in this Keynote
  • 00:00:41
    you don't have to be an architect to
  • 00:00:43
    think like an architect but what does
  • 00:00:44
    that even mean
  • 00:00:46
    so I want to start by showing you
  • 00:00:49
    these clouds what are these
  • 00:00:53
    well they're clouds
  • 00:00:55
    but it's very fascinating that because
  • 00:00:59
    to different people
  • 00:01:01
    these clouds represent different things
  • 00:01:04
    to a meteorologist
  • 00:01:07
    they look up at the sky at those clouds
  • 00:01:09
    and they see all the cloud types and
  • 00:01:11
    they know what the weather patterns and
  • 00:01:12
    what to expect maybe as an artist you
  • 00:01:16
    look up at those same exact clouds and
  • 00:01:19
    you're picturing a beautiful dramatic
  • 00:01:21
    scene
  • 00:01:23
    of course all of us are nit
  • 00:01:26
    so when we look up at the sky and see
  • 00:01:28
    those clouds yeah we kind of think of
  • 00:01:31
    cloud-based deployments The Internet of
  • 00:01:33
    Things
  • 00:01:35
    what does this mean
  • 00:01:38
    when I showed you those clouds
  • 00:01:41
    everybody sees them
  • 00:01:43
    with a different eye
  • 00:01:45
    a different perspective
  • 00:01:48
    and that's what I want to show you about
  • 00:01:50
    architectural thinking
  • 00:01:53
    what does it mean to think like an
  • 00:01:55
    architect to to see a problem
  • 00:01:59
    with an architect's eye an architect's
  • 00:02:02
    point of view
  • 00:02:04
    well we're going to answer that question
  • 00:02:05
    and that's what my keynote is all about
  • 00:02:08
    first want to actually just show you why
  • 00:02:12
    thinking like an architect is important
  • 00:02:14
    regardless
  • 00:02:17
    of your role
  • 00:02:20
    so let's say we're in a situation where
  • 00:02:23
    we're doing some messaging or events
  • 00:02:25
    driven architecture and what you see
  • 00:02:28
    here on the far right hand side is an
  • 00:02:31
    order placement service and it's going
  • 00:02:33
    to send a message to payment and
  • 00:02:36
    inventory and so once I place an order
  • 00:02:39
    I have to pay for it and we have to
  • 00:02:41
    decrement inventory and of course we
  • 00:02:42
    have a database
  • 00:02:43
    and so you have a choice to make as a
  • 00:02:46
    developer hmm
  • 00:02:49
    well when I send that order
  • 00:02:51
    should I include all of that order
  • 00:02:54
    payload all 45
  • 00:02:57
    different attributes
  • 00:02:59
    or
  • 00:03:00
    should I only send just the key because
  • 00:03:04
    with a full day to payload of course I
  • 00:03:06
    insert the data I send all of that
  • 00:03:09
    message over
  • 00:03:10
    and payment and inventory have all the
  • 00:03:12
    data now
  • 00:03:14
    but I wonder I've got another Choice
  • 00:03:17
    what about key based you see I still if
  • 00:03:21
    I'm processing that order I still insert
  • 00:03:23
    that order into the database but now I
  • 00:03:26
    only send the key out in that message or
  • 00:03:30
    event
  • 00:03:31
    well payments and inventory both receive
  • 00:03:33
    that but now they have to query the
  • 00:03:35
    database in order to get the information
  • 00:03:37
    they need
  • 00:03:40
    so what do we do
  • 00:03:42
    well let's see obviously says the
  • 00:03:45
    developer the full event payloads the
  • 00:03:48
    right choice because we get much better
  • 00:03:50
    scalability and performance
  • 00:03:54
    I don't have to go to the database this
  • 00:03:56
    is one of the ways of creating scalable
  • 00:03:58
    systems and high performance systems
  • 00:04:02
    so this is the Clear Choice
  • 00:04:05
    yeah says the architect but um but what
  • 00:04:08
    about what sort of contract are you
  • 00:04:11
    going to use is it going to be a strict
  • 00:04:13
    contract with a schema or are all 45 of
  • 00:04:16
    those attributes going to be a loose
  • 00:04:18
    contract with just something like Json
  • 00:04:19
    are you going to pass an object in that
  • 00:04:22
    message
  • 00:04:23
    um and how are you going to manage it
  • 00:04:25
    how are you going to version it
  • 00:04:27
    when you make changes because you don't
  • 00:04:29
    want to break everything
  • 00:04:31
    oh yeah that's right yeah and what are
  • 00:04:34
    you going to do about stamp coupling and
  • 00:04:36
    bandwidth issues that are going to occur
  • 00:04:38
    with this and the developer says what
  • 00:04:41
    are you talking about
  • 00:04:44
    stamp coupling as a form of coupling
  • 00:04:46
    where you pass all of the information to
  • 00:04:50
    a particular service but it only uses a
  • 00:04:53
    few pieces of it maybe even one or two
  • 00:04:55
    attributes that's called stamp coupling
  • 00:04:57
    and two problems occur change and
  • 00:05:01
    bandwidth issues let me show you what I
  • 00:05:03
    mean if I change this contract
  • 00:05:06
    and change a field that payments and
  • 00:05:09
    inventory are not using well of course I
  • 00:05:12
    have to change
  • 00:05:13
    but that might facilitate a change in
  • 00:05:16
    payment and inventory as well even
  • 00:05:19
    though I don't care about that field
  • 00:05:22
    that's what stamp coupling is about but
  • 00:05:25
    there's also bandwidth issues because
  • 00:05:26
    you see that entire order is 500 KB
  • 00:05:32
    so 500 KB is being sent to both payment
  • 00:05:35
    and inventory payment only needs 350 KB
  • 00:05:40
    inventory only needs 50 KB
  • 00:05:43
    so I'm unnecessary unnecessarily
  • 00:05:46
    utilizing bandwidth I don't need
  • 00:05:50
    cloud-based environments this could get
  • 00:05:53
    quite expensive
  • 00:05:56
    oh and there's another problem by the
  • 00:05:59
    way
  • 00:06:00
    um and of course at this point the
  • 00:06:02
    developer starts getting really
  • 00:06:03
    frustrated but it keeps going what about
  • 00:06:05
    multiple systems of record because if
  • 00:06:07
    you're passing the entire payload of
  • 00:06:09
    that message over there that means every
  • 00:06:11
    one of you
  • 00:06:13
    have a copy of that
  • 00:06:15
    and you're not even looking at the
  • 00:06:17
    database where the true system of record
  • 00:06:18
    is so if I make changes to that order
  • 00:06:21
    it may be everywhere you might not have
  • 00:06:23
    the latest copy so that might produce
  • 00:06:25
    data Integrity issues as well
  • 00:06:28
    oh
  • 00:06:30
    you know so the developer says hmm you
  • 00:06:33
    know these are really good points
  • 00:06:36
    you know you've kind of convinced me
  • 00:06:37
    maybe a key based event payload would be
  • 00:06:42
    better
  • 00:06:42
    I mean after all I wouldn't have to
  • 00:06:44
    worry about stamp coupling it's a single
  • 00:06:47
    name value pair so there's really no
  • 00:06:49
    well there's still a contract but I'm
  • 00:06:51
    never going to change that I don't have
  • 00:06:53
    bandwidth issues I don't have stamp
  • 00:06:54
    coupling
  • 00:06:56
    and you're right I have a single single
  • 00:07:00
    system of record I get better data
  • 00:07:02
    Integrity you know you make really good
  • 00:07:03
    points maybe I should use the key based
  • 00:07:06
    and what happens
  • 00:07:08
    the developer now comes along or the
  • 00:07:10
    architect comes along and says yeah but
  • 00:07:12
    what are you going to do about
  • 00:07:12
    scalability and performance now
  • 00:07:15
    this is why thinking like an architect
  • 00:07:18
    is important
  • 00:07:20
    because of our first law of software
  • 00:07:23
    architecture
  • 00:07:24
    and that is that everything in software
  • 00:07:27
    architecture is a trade-off
  • 00:07:30
    and being able to think like an
  • 00:07:32
    architect and see things with an
  • 00:07:34
    architect's eye allows you to better
  • 00:07:37
    analyze these kind of trade-offs to
  • 00:07:40
    actually make the right decision to find
  • 00:07:42
    and seek out
  • 00:07:44
    those pros and cons
  • 00:07:47
    okay
  • 00:07:49
    so let's come back to thinking like an
  • 00:07:51
    architect what's involved in thinking
  • 00:07:53
    like an architect being able to apply
  • 00:07:57
    architectural thinking
  • 00:07:59
    to your daily job
  • 00:08:01
    regardless of your title or role
  • 00:08:06
    it really involves Three core things
  • 00:08:10
    the first is regardless of your role to
  • 00:08:14
    be able to understand the importance of
  • 00:08:17
    those business drivers in the
  • 00:08:18
    translation
  • 00:08:20
    to whatever those architectural
  • 00:08:21
    characteristics are
  • 00:08:23
    do you need High scalability
  • 00:08:26
    do you need High availability high
  • 00:08:28
    performance High agility High
  • 00:08:30
    responsiveness
  • 00:08:32
    what are those attributes or
  • 00:08:34
    characteristics of the architecture that
  • 00:08:36
    are important because we are
  • 00:08:38
    implementing
  • 00:08:39
    that architecture we should probably
  • 00:08:41
    know those
  • 00:08:43
    number two thinking like an architect is
  • 00:08:46
    also expanding your breadth of knowledge
  • 00:08:51
    to be able to see more solutions
  • 00:08:54
    to the problem
  • 00:08:57
    and also thinking like an architect is
  • 00:09:00
    being able to identify and analyze
  • 00:09:03
    various trade-offs these are the three
  • 00:09:06
    main components of actually seeing a
  • 00:09:09
    problem
  • 00:09:10
    with an architect's eye
  • 00:09:13
    as opposed to a developer's eye oh you
  • 00:09:15
    still have to see things with a
  • 00:09:17
    developer's eye of course especially
  • 00:09:18
    when you're faced with a particular
  • 00:09:20
    algorithm or problem or design problem
  • 00:09:22
    within your code
  • 00:09:24
    but it's also seeing the problem
  • 00:09:26
    architecturally as well let's take a
  • 00:09:29
    look at all three of these and see how
  • 00:09:31
    they all work and let's take a look at
  • 00:09:32
    what are the most foundational pieces of
  • 00:09:35
    what it means to see things like those
  • 00:09:37
    clouds with an architect's eye because
  • 00:09:41
    this is what the business is concerned
  • 00:09:45
    about
  • 00:09:45
    regardless of the type of system that
  • 00:09:48
    you're building
  • 00:09:50
    the business is concerned about things
  • 00:09:52
    like user satisfaction time to Market
  • 00:09:54
    competitive Advantage mergers and
  • 00:09:56
    Acquisitions Regulatory Compliance all
  • 00:09:59
    of these things are big concerns of
  • 00:10:01
    theirs
  • 00:10:02
    thinking architecturally
  • 00:10:04
    is translating these concerns
  • 00:10:07
    into exactly what the architecture needs
  • 00:10:11
    to support this is our language
  • 00:10:14
    we translate those into things like oh
  • 00:10:16
    fault tolerance reliability
  • 00:10:18
    recoverability responsiveness
  • 00:10:20
    performance availability
  • 00:10:23
    and that's what we need to build into
  • 00:10:25
    the architecture
  • 00:10:28
    to support those business needs
  • 00:10:30
    that's seeing it with the architect's
  • 00:10:32
    eye
  • 00:10:33
    but there's a problem here
  • 00:10:36
    because it's a problem of being Lost in
  • 00:10:38
    Translation
  • 00:10:40
    you see language of an architect is
  • 00:10:42
    talking all about fault tolerance
  • 00:10:45
    the language of the business is talking
  • 00:10:48
    all about user satisfaction
  • 00:10:50
    and the problem is
  • 00:10:52
    these two rarely meet because no one
  • 00:10:54
    knows what anybody's talking about
  • 00:10:57
    and this involves another aspect of
  • 00:11:00
    thinking architecturally
  • 00:11:02
    that brain of an architect
  • 00:11:05
    becomes like a translation engine
  • 00:11:08
    so if this is that important which it is
  • 00:11:12
    because these architectural
  • 00:11:14
    characteristics
  • 00:11:15
    become the foundational aspect of any
  • 00:11:19
    system or product
  • 00:11:22
    so if we don't know these
  • 00:11:25
    how can we possibly build a system how
  • 00:11:27
    can we possibly make decisions
  • 00:11:31
    okay so you've convinced me yeah we need
  • 00:11:33
    to know these but how do I know which
  • 00:11:35
    ones I mean I've never really thought
  • 00:11:37
    about this and I'd really like to as a
  • 00:11:39
    matter of fact on Monday when I kind of
  • 00:11:41
    go back to work I might want to start
  • 00:11:42
    thinking about these so where do they
  • 00:11:44
    come from
  • 00:11:45
    they come from one of three places
  • 00:11:48
    a lot of times they come just from the
  • 00:11:51
    domain
  • 00:11:52
    I mean the business domain for example
  • 00:11:55
    we're building a new stock trading
  • 00:11:57
    system to buy and sell stock
  • 00:12:00
    well I don't need
  • 00:12:02
    to go through a lot of analysis to know
  • 00:12:04
    that system has to be fast
  • 00:12:07
    high performance
  • 00:12:10
    High data integrity
  • 00:12:13
    so sometimes we could just extract these
  • 00:12:15
    from the nature of our business a lot of
  • 00:12:18
    times they're in requirements or user
  • 00:12:21
    stories but the user story does not
  • 00:12:23
    State we require High elasticity no the
  • 00:12:27
    user story looks like this we have to
  • 00:12:28
    support 20 to 200 000 concurrent users
  • 00:12:31
    and everything in between and it could
  • 00:12:33
    be immediate need
  • 00:12:35
    so those requirements or user stories
  • 00:12:38
    are not spelling out that exact illity
  • 00:12:42
    or architecture characteristic it's up
  • 00:12:44
    to us to interpret and know what that is
  • 00:12:47
    but it's interesting
  • 00:12:49
    in almost every system or product I've
  • 00:12:52
    worked on
  • 00:12:53
    the most valuable place
  • 00:12:56
    to find out what's important is actually
  • 00:12:59
    just using your ear and listening to the
  • 00:13:02
    business
  • 00:13:05
    let's actually do this this will be fun
  • 00:13:07
    so here's an example
  • 00:13:10
    thinking architecturally is that trans
  • 00:13:12
    translation engine that we have in our
  • 00:13:14
    mind
  • 00:13:15
    so let's say that the business says oh
  • 00:13:18
    yeah user satisfaction is absolutely the
  • 00:13:20
    most important thing we build our
  • 00:13:23
    company on user satisfaction
  • 00:13:25
    so what happens
  • 00:13:27
    we translate that to a characteristic
  • 00:13:30
    now this one's easy user satisfaction
  • 00:13:33
    ability
  • 00:13:35
    is it funny you could take any word and
  • 00:13:37
    just add the word illity after it and
  • 00:13:39
    all of a sudden you've got a new
  • 00:13:40
    characteristic
  • 00:13:41
    how about markability
  • 00:13:44
    hmm wonder what that means well that
  • 00:13:47
    one's easy too because I love drawing on
  • 00:13:49
    slides I love drawing on whiteboards and
  • 00:13:51
    so markability is the ability to like a
  • 00:13:54
    lot of drawings
  • 00:13:56
    there was one particular client
  • 00:13:58
    engagement I was on where we had fun
  • 00:14:01
    making up architecture characteristics
  • 00:14:04
    we would take the characteristics of
  • 00:14:07
    somebody on the team
  • 00:14:08
    and use their name and make an entity
  • 00:14:10
    for example take the person on the team
  • 00:14:13
    I mean who is the glue on the team I
  • 00:14:16
    mean they just bring everything together
  • 00:14:18
    so if we needed high amiability that
  • 00:14:21
    means we need High cohesion we need this
  • 00:14:23
    system to work together uh maybe you've
  • 00:14:26
    got somebody
  • 00:14:27
    um sebastiani who's maybe a a
  • 00:14:29
    perfectionist everything has to be
  • 00:14:32
    absolutely perfect
  • 00:14:33
    well that's sebastiani ability
  • 00:14:36
    the ability to have everything
  • 00:14:37
    absolutely the highest level of data
  • 00:14:40
    integrity and correctness in that system
  • 00:14:41
    it's kind of a fun exercise you should
  • 00:14:43
    try it you can make up any word but it's
  • 00:14:46
    not really user satisfactionability no
  • 00:14:49
    this requirement or need comes into our
  • 00:14:52
    translation engine
  • 00:14:54
    and out comes all those things the
  • 00:14:57
    architecture needs to support
  • 00:14:59
    performance agility so that we get bug
  • 00:15:03
    fixes Fast Fixed fast things like
  • 00:15:06
    scalability availability security
  • 00:15:08
    testability so we don't introduce bugs
  • 00:15:10
    recoverability so I don't lose my work
  • 00:15:12
    these are all things that make users
  • 00:15:15
    happy
  • 00:15:16
    and if our architectures don't support
  • 00:15:18
    these users will not be happy this is
  • 00:15:21
    that whole thing about seeing a
  • 00:15:23
    particular problem
  • 00:15:25
    with an architect's perspective
  • 00:15:27
    how about time to Market
  • 00:15:30
    that's the most important thing
  • 00:15:32
    so we feed that into our little
  • 00:15:33
    translation engine
  • 00:15:36
    and out comes all the things that the
  • 00:15:38
    architecture needs to support
  • 00:15:40
    maintainability testability
  • 00:15:42
    deployability these are things that we
  • 00:15:46
    as not only architects
  • 00:15:48
    but Developers
  • 00:15:51
    need to focus on
  • 00:15:53
    that's what we need to support
  • 00:15:55
    let's do one more mergers and
  • 00:15:57
    Acquisitions oh boy yes we're we're
  • 00:16:00
    constantly acquiring new companies
  • 00:16:02
    okay that one's easy resume ability yes
  • 00:16:05
    because my job will be replaced okay now
  • 00:16:08
    like I said you can make up any word
  • 00:16:12
    no we feed this in and what do you
  • 00:16:14
    suppose it's interesting think about
  • 00:16:16
    this one for a second
  • 00:16:18
    mergers and Acquisitions undergoing very
  • 00:16:20
    heavily in your company constantly
  • 00:16:23
    buying up other companies merging with
  • 00:16:25
    other companies you're an architect
  • 00:16:26
    you're a developer
  • 00:16:29
    what's on your mind about this let's
  • 00:16:31
    just Ponder this one for a little bit
  • 00:16:33
    hmm
  • 00:16:34
    would that matter
  • 00:16:38
    yeah it would
  • 00:16:40
    as a matter of fact a lot of things are
  • 00:16:42
    we leveraging standards it's going to
  • 00:16:44
    make it easier for us to communicate
  • 00:16:45
    with other systems that we have to
  • 00:16:47
    interoperability how open or closed are
  • 00:16:51
    our systems how scalable are they
  • 00:16:53
    because if we merge with another company
  • 00:16:56
    we possibly have just doubled
  • 00:16:59
    our customer base
  • 00:17:01
    think about that can our Systems Support
  • 00:17:04
    that extra customer load that extra user
  • 00:17:08
    load the capacities in our database
  • 00:17:10
    connection pools virtual machines
  • 00:17:14
    that's a big one on that
  • 00:17:17
    all right so this is one of those kind
  • 00:17:20
    of translation engines one of the
  • 00:17:22
    reasons this is so important
  • 00:17:23
    it's because these these characteristics
  • 00:17:26
    when we see these help us qualify and
  • 00:17:29
    make decisions this is the star rating
  • 00:17:32
    chart from our book fundamentals of
  • 00:17:33
    software architecture
  • 00:17:35
    and we can kind of utilize this if
  • 00:17:39
    and only if
  • 00:17:41
    we know
  • 00:17:43
    our characteristics
  • 00:17:46
    which architecture style should you use
  • 00:17:48
    microservices of course no
  • 00:17:52
    which of these eight should you use
  • 00:17:55
    I I I I don't know what can I base that
  • 00:17:58
    on oh what's important to you oh
  • 00:18:01
    scalability is exactly what we need we
  • 00:18:04
    have to be highly scalable
  • 00:18:06
    well this kind of chart using
  • 00:18:09
    qualitative analysis allows us to kind
  • 00:18:11
    of look for the areas that have five
  • 00:18:13
    stars that means it's really well
  • 00:18:15
    supported if the architecture doesn't
  • 00:18:18
    support scalability
  • 00:18:21
    it doesn't matter how much you do from a
  • 00:18:24
    physical operational standpoint
  • 00:18:27
    you won't be able to scale
  • 00:18:30
    so consequently we look at this chart
  • 00:18:32
    and say huh which architectures tend to
  • 00:18:34
    scale better than others and we find of
  • 00:18:36
    course micro Services event driven and
  • 00:18:39
    space-based architecture
  • 00:18:42
    are really good choices
  • 00:18:44
    the layered architecture with one star
  • 00:18:46
    is not
  • 00:18:48
    how do we know this
  • 00:18:50
    architectural thinking
  • 00:18:53
    being able to see a problem and this is
  • 00:18:56
    what an architect sees
  • 00:18:58
    I don't see class Styles I don't see
  • 00:19:00
    methods I don't see algorithms design
  • 00:19:03
    patterns oh what I see floating in front
  • 00:19:06
    of my face are all of these
  • 00:19:08
    characteristics and those are my driving
  • 00:19:10
    forces to make decisions
  • 00:19:14
    now a resource that you could actually
  • 00:19:15
    use oh and by the way yeah let's do
  • 00:19:17
    another one let's say that's constant
  • 00:19:19
    Simplicity we're a startup
  • 00:19:22
    don't have a lot of money
  • 00:19:25
    we don't want to add a lot of complexity
  • 00:19:27
    at the very very start of our life as a
  • 00:19:30
    company
  • 00:19:31
    those are our most important things
  • 00:19:35
    we do qualitative analysis We compare
  • 00:19:37
    the quality of one thing to another and
  • 00:19:40
    we find hmm
  • 00:19:41
    I'm guessing maybe we shouldn't do micro
  • 00:19:44
    Services first maybe let's start with a
  • 00:19:48
    monolith
  • 00:19:49
    any one of these three and then migrate
  • 00:19:52
    as soon as we find out if this idea is
  • 00:19:54
    going to work and we start growing
  • 00:19:56
    yeah these are guidelines these are
  • 00:19:58
    guide posts
  • 00:19:59
    so one of the tools that I could offer
  • 00:20:02
    you that you can use is this
  • 00:20:04
    characteristics worksheet and this is
  • 00:20:06
    what I use at work
  • 00:20:08
    this is what I use on my Consulting
  • 00:20:11
    engagements to help identify these
  • 00:20:14
    driving forces
  • 00:20:16
    so you can download this from my website
  • 00:20:18
    under resources and it's in PDF
  • 00:20:20
    PowerPoint and keynote format change it
  • 00:20:23
    if you want to that's fine but this
  • 00:20:26
    allows you to start looking at and by
  • 00:20:28
    the way that there's three pages because
  • 00:20:29
    they show definitions I show definitions
  • 00:20:31
    of each of these kind of core
  • 00:20:33
    characteristics and I also have a lesson
  • 00:20:36
    lesson 112 on my software development
  • 00:20:38
    our software architecture Monday to show
  • 00:20:41
    kind of how this works anyways it's a
  • 00:20:44
    really useful tool for starting to say
  • 00:20:46
    you know I think I'd like to start doing
  • 00:20:48
    that I'd like to start thinking like an
  • 00:20:51
    architect and I'm going to see if I can
  • 00:20:53
    come up with what characteristics on the
  • 00:20:55
    current product I'm working on are
  • 00:20:58
    important and are we really supporting
  • 00:21:00
    those
  • 00:21:01
    and do we have the right architecture in
  • 00:21:03
    place guess what by doing those three
  • 00:21:05
    things
  • 00:21:06
    you know what you all are doing
  • 00:21:09
    exactly the same thing an architect
  • 00:21:12
    would do
  • 00:21:14
    thinking like an architect you don't
  • 00:21:16
    have to be an architect to think like an
  • 00:21:19
    architect
  • 00:21:20
    so here's the bottom line of this part
  • 00:21:22
    one right here
  • 00:21:23
    you cannot and this is what I maintain
  • 00:21:26
    you cannot do this
  • 00:21:29
    create an architecture
  • 00:21:32
    unless you have these
  • 00:21:35
    otherwise how are you going to make a
  • 00:21:38
    decision
  • 00:21:40
    what's needed this looks like an
  • 00:21:42
    interesting design but does it satisfy
  • 00:21:44
    the needs of the application the domain
  • 00:21:47
    and The Business
  • 00:21:50
    all right that's
  • 00:21:51
    part of thinking like an architect
  • 00:21:53
    having those foundational aspects that
  • 00:21:56
    drive all the rest of your decisions
  • 00:21:58
    even at an implementation level knowing
  • 00:22:02
    these and knowing that scalability is
  • 00:22:04
    that important and qualifying it will
  • 00:22:07
    allow you to think about the designs of
  • 00:22:09
    your code
  • 00:22:10
    with scalability in mind as well or
  • 00:22:13
    availability or fault tolerance
  • 00:22:15
    okay
  • 00:22:17
    the next part though about thinking like
  • 00:22:19
    an architect is expanding what's known
  • 00:22:21
    as our technical breadth the amount of
  • 00:22:24
    things we know
  • 00:22:26
    because as an architect you see a
  • 00:22:28
    problem
  • 00:22:29
    I have to see and visualize in my mind
  • 00:22:32
    the possible solutions
  • 00:22:34
    but what if you only know one particular
  • 00:22:37
    solution it might not be the right one
  • 00:22:40
    so it turns out that this is called a
  • 00:22:43
    triangle of knowledge and there are
  • 00:22:45
    three types of knowledge that exist in
  • 00:22:47
    the world let's scope it down to
  • 00:22:49
    technology knowledge that would be a lot
  • 00:22:51
    better
  • 00:22:52
    um well way up here at the top
  • 00:22:55
    is the stuff that you know
  • 00:22:57
    these are things you do every day you
  • 00:22:59
    know them so well that you could
  • 00:23:01
    actually get up on stage here
  • 00:23:03
    and talk about them it'd be a little
  • 00:23:05
    scary but you could
  • 00:23:07
    but right below that is a bigger area of
  • 00:23:10
    knowledge called the stuff that you know
  • 00:23:12
    that you don't know
  • 00:23:15
    this means you know or are familiar
  • 00:23:17
    about something
  • 00:23:19
    but you have no idea how to use it
  • 00:23:22
    um close your programming language is a
  • 00:23:24
    good example I'm sure most if not all of
  • 00:23:27
    you have heard about closure it's a
  • 00:23:28
    programming language that uh boy you
  • 00:23:31
    gotta love parentheses if you're going
  • 00:23:32
    to use it it usually uses the atomic
  • 00:23:34
    transactional memory all this kind of
  • 00:23:35
    stuff
  • 00:23:36
    but how many of you can code
  • 00:23:39
    enclosure not it that's a good example
  • 00:23:43
    of something that you've heard of that
  • 00:23:44
    you know that you know nothing about but
  • 00:23:47
    you're familiar with it
  • 00:23:48
    but the biggest area of knowledge that
  • 00:23:51
    exists is this bottom large Blue Area
  • 00:23:54
    this is the stuff that you don't know
  • 00:23:57
    that you don't know
  • 00:23:59
    this is all the possible solutions tools
  • 00:24:03
    products patterns that would be the
  • 00:24:06
    perfect fit perfect fit for what you're
  • 00:24:08
    doing and you don't even know it exists
  • 00:24:12
    so one of the
  • 00:24:15
    well I'll call it a game of life
  • 00:24:19
    is to take stuff that you've never ever
  • 00:24:23
    heard of that bottom area of the
  • 00:24:25
    triangle stuff that you don't know that
  • 00:24:27
    you don't know
  • 00:24:29
    and move it into the stuff that you know
  • 00:24:32
    you don't know
  • 00:24:35
    how do you do this talk with people say
  • 00:24:37
    oh I haven't heard of that before what
  • 00:24:39
    is it and now you suddenly have it in
  • 00:24:42
    your second level of knowledge
  • 00:24:44
    it's going to conferences like this
  • 00:24:47
    and challenging yourself to say well I'm
  • 00:24:49
    a react programmer so I'm going to do
  • 00:24:51
    all react talks
  • 00:24:53
    now the proper way to take advantage of
  • 00:24:57
    conferences like this is to attend a
  • 00:25:00
    talk of something you've never heard of
  • 00:25:03
    it's fantastic way to learn about a
  • 00:25:06
    possible tool a technique a solution
  • 00:25:09
    that you may not use now
  • 00:25:12
    but it's in your brain
  • 00:25:15
    and you'll pull it out sometime and say
  • 00:25:16
    wait a minute I remember I was at gids23
  • 00:25:20
    and I remember I was walking along in
  • 00:25:22
    the the exposition Hall there and I was
  • 00:25:25
    like what is this product okay that's a
  • 00:25:27
    two or three minute conversation
  • 00:25:29
    you have now taken something that you
  • 00:25:31
    didn't know that you didn't know and say
  • 00:25:34
    oh now I know what it does
  • 00:25:36
    okay then
  • 00:25:39
    either something because we are all
  • 00:25:41
    technologists that pique your interest
  • 00:25:43
    something that you get really excited
  • 00:25:45
    about or your boss says starting next
  • 00:25:47
    week we shall be using closure oh
  • 00:25:50
    that's when you take something that you
  • 00:25:52
    know you don't know
  • 00:25:54
    and you move it into something now that
  • 00:25:57
    you know
  • 00:25:58
    but there's a cautionary tale here
  • 00:26:00
    everybody
  • 00:26:02
    watch out for this top part of the
  • 00:26:05
    triangle
  • 00:26:06
    because the stuff you know is the stuff
  • 00:26:09
    you have to maintain
  • 00:26:12
    and if you like working 24 hours a day
  • 00:26:15
    if you don't have kids if you have no
  • 00:26:17
    life and no friends don't worry about it
  • 00:26:20
    but if you do
  • 00:26:22
    you can't do it all because if you don't
  • 00:26:25
    maintain that it suddenly trickles down
  • 00:26:28
    like teardrops all the way back down
  • 00:26:31
    into something that now you know you
  • 00:26:33
    don't know
  • 00:26:34
    about 10 years ago it was mostly
  • 00:26:36
    programming in the Scala language I
  • 00:26:39
    started the Boston Scala users group
  • 00:26:41
    that's all I was doing at client sites
  • 00:26:43
    with Scala I loved it
  • 00:26:46
    that was 10 years ago
  • 00:26:48
    now
  • 00:26:50
    I would be lucky to be able to start a
  • 00:26:53
    scholar class file it's something I
  • 00:26:55
    chose not to maintain so it dripped back
  • 00:26:57
    down so just a cautionary tale be
  • 00:27:00
    careful okay
  • 00:27:01
    well let's do an interesting exercise
  • 00:27:04
    because of this
  • 00:27:07
    the stuff you know
  • 00:27:09
    is called technical depth
  • 00:27:12
    we all need technical depth including me
  • 00:27:17
    a seasoned architect
  • 00:27:19
    we all need technical depth but that's
  • 00:27:22
    stuff you know plus the stuff that you
  • 00:27:24
    know you don't know is considered
  • 00:27:26
    technical breadth
  • 00:27:28
    and here's the key point
  • 00:27:31
    thinking like an architect
  • 00:27:33
    starting to make more effective
  • 00:27:36
    decisions
  • 00:27:38
    create better software systems
  • 00:27:41
    and start propelling your career
  • 00:27:43
    into that Tech lead and into that
  • 00:27:46
    architect position
  • 00:27:48
    means to exactly Focus right here
  • 00:27:53
    and that's hard
  • 00:27:55
    it means focusing
  • 00:27:57
    on technical depth with a sacrifice I'm
  • 00:28:00
    sorry technical breadth
  • 00:28:02
    with a little bit of a sacrifice of
  • 00:28:04
    technical depth
  • 00:28:05
    start broadening your horizons okay
  • 00:28:10
    well let's actually play this game
  • 00:28:12
    what we're going to do is we're actually
  • 00:28:15
    now that we understand this triangle of
  • 00:28:16
    knowledge let's have some fun with it
  • 00:28:19
    let's take a look at the brain
  • 00:28:22
    of a junior developer
  • 00:28:24
    then let's take a look inside the brain
  • 00:28:26
    of a senior developer
  • 00:28:29
    then we're going to take a look inside
  • 00:28:30
    the brain of a junior architect
  • 00:28:33
    and finally a senior architect
  • 00:28:35
    this is going to be an amazing journey
  • 00:28:38
    so now that we understand that levels
  • 00:28:40
    are trying the levels of knowledge let's
  • 00:28:42
    open up the brain
  • 00:28:44
    to a junior developer
  • 00:28:46
    this is what a junior developer's
  • 00:28:48
    knowledge triangle looks like typically
  • 00:28:50
    notice what is the biggest part of this
  • 00:28:53
    triangle
  • 00:28:54
    it's the stuff that you don't know that
  • 00:28:57
    you don't know sure I am a Java
  • 00:29:00
    developer what do you do Java
  • 00:29:03
    what do you know Java
  • 00:29:05
    okay
  • 00:29:07
    notice my technical breadth is pretty
  • 00:29:11
    small
  • 00:29:12
    and that's fine that's appropriate
  • 00:29:14
    because as a junior developer I am hired
  • 00:29:17
    for my technical capability
  • 00:29:20
    on that particular technology
  • 00:29:23
    this is good this is what it should look
  • 00:29:25
    like but what happens are you ready
  • 00:29:27
    watch this as we move from a junior
  • 00:29:30
    developer to a senior developer
  • 00:29:34
    did you notice what happened to the
  • 00:29:35
    triangle
  • 00:29:36
    I want to do that again because this is
  • 00:29:39
    going to start morphing like this wait a
  • 00:29:40
    minute let me go backwards one
  • 00:29:42
    are you ready watch the shape of the
  • 00:29:45
    triangle here we go Junior developer
  • 00:29:48
    starts going into a senior developer
  • 00:29:49
    five or six years experience
  • 00:29:52
    and what do you notice happen
  • 00:29:54
    the stuff you know
  • 00:29:56
    increases
  • 00:29:58
    multiple platforms multiple languages
  • 00:30:00
    multiple patterns multiple tools
  • 00:30:01
    multiple techniques multiple Frameworks
  • 00:30:03
    the list goes on
  • 00:30:05
    and as a matter of fact that you notice
  • 00:30:07
    what part of the triangle got smaller
  • 00:30:10
    the stuff you know you didn't know that
  • 00:30:12
    you didn't know
  • 00:30:13
    but notice our technical breadth
  • 00:30:16
    still not strong
  • 00:30:19
    and that's okay
  • 00:30:21
    because we are focused on a technology
  • 00:30:24
    solution to a problem
  • 00:30:26
    but you get that big break
  • 00:30:29
    and all of a sudden now
  • 00:30:31
    yes your first opportunity as an
  • 00:30:33
    architect
  • 00:30:34
    you become a junior architect
  • 00:30:37
    you ready I'm going to transfer now this
  • 00:30:39
    is what your brain starts to look like
  • 00:30:42
    did you notice what happened as you move
  • 00:30:44
    into and step into
  • 00:30:47
    an architect position
  • 00:30:49
    what happened
  • 00:30:50
    you sacrificed some of that stuff you
  • 00:30:54
    know
  • 00:30:55
    that expertise
  • 00:30:57
    to broaden the stuff that you know you
  • 00:31:01
    don't know
  • 00:31:02
    as an architect you're starting to look
  • 00:31:04
    at 10 different caching Technologies not
  • 00:31:08
    just redis for example what are the
  • 00:31:13
    different caching tools and Technologies
  • 00:31:14
    what do they support what are the pros
  • 00:31:16
    what are the cons oh I may not know how
  • 00:31:19
    to code at any of these that's fine
  • 00:31:21
    but as an architect I know the
  • 00:31:23
    trade-offs of each of these hey which
  • 00:31:25
    one would probably be the most
  • 00:31:27
    appropriate solution for our particular
  • 00:31:29
    problem
  • 00:31:31
    now final Journey you start
  • 00:31:34
    developing your careers in architect you
  • 00:31:37
    start getting that senior architect kind
  • 00:31:39
    of position that Enterprise architect
  • 00:31:40
    and this is what your knowledge triangle
  • 00:31:43
    now starts to look like
  • 00:31:45
    notice we haven't done much with our
  • 00:31:47
    technical depth
  • 00:31:49
    but we've significantly broadened the
  • 00:31:51
    stuff that we know we don't know
  • 00:31:55
    so this is kind of one of those key tips
  • 00:31:59
    tricks to managing
  • 00:32:02
    your entire career
  • 00:32:04
    regardless of where you are in it
  • 00:32:08
    did you just graduate from school
  • 00:32:10
    cool focus on the technology that you're
  • 00:32:13
    interested in that's all you should do
  • 00:32:16
    and you could use this transition
  • 00:32:18
    to kind of map out where you should
  • 00:32:21
    probably be in these various knowledge
  • 00:32:23
    pieces
  • 00:32:24
    well Mark this is absolutely fabulous
  • 00:32:28
    this is really cool
  • 00:32:30
    I wish I had as much time as you
  • 00:32:33
    to be able to go research and do stuff
  • 00:32:35
    and kind of learn things I don't know ah
  • 00:32:38
    yeah no I'm stuck 12 hours a day coding
  • 00:32:41
    Java
  • 00:32:42
    ah let me show you how to do this
  • 00:32:45
    so isn't it interesting if we look at
  • 00:32:47
    the difference between a developer's
  • 00:32:49
    head and the way they see things and an
  • 00:32:52
    architect's head
  • 00:32:53
    and the way they see things
  • 00:32:55
    it's all about that middle area
  • 00:32:59
    the more you know
  • 00:33:01
    about stuff you don't know
  • 00:33:04
    the more you're going to be able to find
  • 00:33:07
    solutions to problems that are the most
  • 00:33:10
    appropriate solution
  • 00:33:13
    okay
  • 00:33:14
    so how do you do this
  • 00:33:16
    how do you start gaining that technical
  • 00:33:18
    depth
  • 00:33:20
    this is exciting
  • 00:33:22
    well what are the ways to do it is a
  • 00:33:24
    conferences like this or just start
  • 00:33:27
    going
  • 00:33:28
    to some of these resources that are free
  • 00:33:32
    and let me show you three that I
  • 00:33:33
    typically use the first one I go to
  • 00:33:36
    quite often is a info queue infoq.com
  • 00:33:41
    uh now I'm going to show you this in a
  • 00:33:43
    little bit but every uh about two times
  • 00:33:46
    a week I get an email with all these
  • 00:33:48
    different things that are trending all
  • 00:33:49
    these different Technologies
  • 00:33:51
    um it's a really really good go-to place
  • 00:33:54
    for architecture for all these kind of
  • 00:33:56
    things
  • 00:33:58
    technology you name it uh the second
  • 00:34:00
    place that I sometimes go to are the
  • 00:34:02
    d-zone ref cards now not necessarily
  • 00:34:05
    d-zone
  • 00:34:07
    um in my experience d-zone is kind of
  • 00:34:09
    Hit or Miss but the ref cards are really
  • 00:34:12
    useful because I don't have a lot of
  • 00:34:14
    time when I was in college back in the
  • 00:34:17
    turn of the century
  • 00:34:20
    uh I did not have time to read War and
  • 00:34:23
    Peace or Homer's Iliad or Odyssey I had
  • 00:34:27
    other things to do hang out with my
  • 00:34:28
    friends just go hiking around and stuff
  • 00:34:30
    so what did I do
  • 00:34:33
    I leveraged something called Cliff Notes
  • 00:34:35
    now here's Monarch notes but these were
  • 00:34:37
    little booklets
  • 00:34:39
    that just gave you a summary the
  • 00:34:42
    highlights of those epic novels yeah I
  • 00:34:45
    could I could read that in an afternoon
  • 00:34:47
    and so
  • 00:34:51
    so that's what I did most of the time
  • 00:34:53
    now I'm going back and reading all those
  • 00:34:56
    wonderful epic novels but at the time I
  • 00:34:58
    wasn't interested
  • 00:35:00
    and so those little tiny booklets Cliff
  • 00:35:03
    Notes Monarch notes really helped me to
  • 00:35:06
    participate in the class to really gain
  • 00:35:08
    the understanding of those books without
  • 00:35:10
    having all the details that I didn't
  • 00:35:12
    really care about
  • 00:35:13
    oh what did I just describe
  • 00:35:17
    ref cards
  • 00:35:19
    yeah these are two to six page cards
  • 00:35:21
    that talk about a particular technology
  • 00:35:24
    just the right exact level
  • 00:35:28
    for me as an architect
  • 00:35:30
    say what is it why is it here what are
  • 00:35:34
    the good things and what are the bad
  • 00:35:35
    things about it yeah so those are those
  • 00:35:38
    are pretty useful to gain that technical
  • 00:35:40
    knowledge without having to go too deep
  • 00:35:42
    oh you can study what hazelcast is all
  • 00:35:44
    about you don't have to go and code it
  • 00:35:46
    you can understand uh different
  • 00:35:48
    languages you don't have to go and code
  • 00:35:50
    them
  • 00:35:51
    you just have to understand what they do
  • 00:35:53
    why they're there how do they
  • 00:35:55
    differentiate themselves from all the
  • 00:35:57
    other 25 programming languages I could
  • 00:35:59
    choose right now yeah another place to
  • 00:36:01
    go
  • 00:36:03
    is a thoughtworks technology radar which
  • 00:36:06
    by the way just came out Tuesday this
  • 00:36:08
    comes out twice a year all these are
  • 00:36:10
    free
  • 00:36:11
    this whole stuff is all available to you
  • 00:36:14
    and the thoughtworks technology radar
  • 00:36:16
    twice a year are most of the luminaries
  • 00:36:20
    in the field Neil Ford is one of those
  • 00:36:21
    James Lewis Martin Fowler I mean these
  • 00:36:24
    are folks who have a pulse on the
  • 00:36:26
    industry
  • 00:36:27
    they show you what things are trending
  • 00:36:29
    what things aren't
  • 00:36:31
    it's a really great resource now here's
  • 00:36:34
    a little test for all of you go to the
  • 00:36:37
    thoughtworks radar you think oh I I
  • 00:36:38
    don't need that I already know what's
  • 00:36:40
    happening in the field I already know
  • 00:36:41
    everything I know everything
  • 00:36:44
    I will guarantee you
  • 00:36:46
    they'll show 20 things that are trending
  • 00:36:48
    in the industry I will guarantee you
  • 00:36:52
    maybe you've heard of four of those
  • 00:36:56
    yeah what a humbling experience it's
  • 00:37:00
    like this is something they're saying to
  • 00:37:02
    adopt and I've never heard of it
  • 00:37:04
    what is that that's something that I
  • 00:37:07
    don't know that I don't know
  • 00:37:08
    I probably should know it
  • 00:37:11
    not be an expert but just know it these
  • 00:37:13
    are three really good resources oh
  • 00:37:15
    there's a lot of other good resources to
  • 00:37:17
    use as well but these are just three I
  • 00:37:18
    can offer up to you
  • 00:37:20
    now I can go back and say huh
  • 00:37:23
    what do these look like well let me show
  • 00:37:25
    you the three levels of knowledge now
  • 00:37:27
    this might be a little hard to see on
  • 00:37:29
    the screen here but this is uh I'm going
  • 00:37:30
    to zoom in but this is a snapshot of my
  • 00:37:32
    email and this is let me Zoom it in just
  • 00:37:35
    a little bit
  • 00:37:36
    um this is what it looks like so when I
  • 00:37:38
    get my email it has a black a dark
  • 00:37:40
    header line
  • 00:37:41
    with a laundry list of buzzwords
  • 00:37:47
    and I look at that I take a look at that
  • 00:37:48
    and all of a sudden I start to see
  • 00:37:50
    things like oh plastic arm what is that
  • 00:37:55
    plastic arm is it like
  • 00:37:57
    an actual arm it's plastic
  • 00:38:00
    I've never heard of that before ha
  • 00:38:02
    something that you don't know that you
  • 00:38:05
    don't know
  • 00:38:05
    bottom level of the triangle
  • 00:38:08
    it happens to be
  • 00:38:10
    fabric based microchips
  • 00:38:13
    for all sorts of haptic sets and all
  • 00:38:15
    this really cool stuff okay how about
  • 00:38:17
    this
  • 00:38:18
    um solid.js well we can ignore that
  • 00:38:21
    right because every day another new
  • 00:38:23
    JavaScript framework comes out so just
  • 00:38:25
    forget that yeah yeah never mind yeah so
  • 00:38:27
    that that's that's Way Beyond all three
  • 00:38:30
    levels of knowledge that's stuff that
  • 00:38:31
    you could throw away okay that's the
  • 00:38:33
    trash can okay but all this other stuff
  • 00:38:35
    Apache Pinot what does that mean the
  • 00:38:38
    Apache Foundation is now making wine
  • 00:38:40
    Apache Chardonnay is really good
  • 00:38:44
    but Apache Sauvignon is also buried yeah
  • 00:38:47
    what in the world's Pino it's there
  • 00:38:49
    um stuff like this you know uh AWS
  • 00:38:52
    proton oh yeah we're we're an AWS shop
  • 00:38:54
    what's proton
  • 00:38:56
    I I I I don't know should we be using it
  • 00:38:59
    I don't know these are things you've
  • 00:39:02
    never heard of this is the value of
  • 00:39:05
    these resources you see a buzzword
  • 00:39:07
    that you've never heard of before
  • 00:39:10
    spend a couple of minutes to see what it
  • 00:39:12
    is
  • 00:39:14
    that's all you need to do
  • 00:39:16
    and now all of a sudden you say
  • 00:39:18
    proton where were you six months ago oh
  • 00:39:22
    it's been out longer than that where was
  • 00:39:24
    I six months ago
  • 00:39:25
    if they would have solved all our
  • 00:39:27
    problems we could have shaved five
  • 00:39:29
    months off our project that's the value
  • 00:39:32
    of architectural thinking of expanding
  • 00:39:35
    that breadth of knowledge
  • 00:39:40
    mark
  • 00:39:41
    this is really cool
  • 00:39:43
    but I don't have time for this
  • 00:39:46
    I wish I had as much time as you to kind
  • 00:39:48
    of just click on these and peruse these
  • 00:39:51
    and all this well let me give you a
  • 00:39:53
    little secret I don't either
  • 00:39:56
    I work between 12 and 15 hours a day
  • 00:39:59
    seven days a week
  • 00:40:00
    I don't have time for this
  • 00:40:02
    so here's my technique I kind of created
  • 00:40:05
    something
  • 00:40:06
    called what well at least what I call
  • 00:40:09
    the 20 minute rule
  • 00:40:12
    and here's what I do
  • 00:40:15
    I spend 20 minutes a day
  • 00:40:18
    just 20 sometimes more but at least 20
  • 00:40:21
    minutes a day
  • 00:40:25
    on me on my career on myself
  • 00:40:29
    to expand my technical breadth
  • 00:40:33
    oh I may go to info queue I may just
  • 00:40:35
    create a list of words I've never heard
  • 00:40:37
    of and that's going to queue up for
  • 00:40:39
    tomorrow which I may look at two or
  • 00:40:41
    three of those
  • 00:40:42
    now here's the other secret though
  • 00:40:47
    when do you do this
  • 00:40:48
    oh launch that'd be a good time yeah how
  • 00:40:51
    many of us get to take lunch seriously
  • 00:40:53
    no yeah after after work this would be a
  • 00:40:57
    good time to do it uh-huh
  • 00:40:59
    yeah how many of you have families
  • 00:41:01
    yeah you get home after a hard day and
  • 00:41:03
    your spouse goes here I'm going out
  • 00:41:07
    and you look at your child and go what
  • 00:41:09
    did you do today
  • 00:41:10
    yeah you're not going to spend 20
  • 00:41:12
    minutes learning about proton no
  • 00:41:15
    here's the trick
  • 00:41:17
    first thing in the morning
  • 00:41:20
    now
  • 00:41:21
    let me qualify that
  • 00:41:23
    what's the very very first thing you do
  • 00:41:26
    when you wake up in the morning and but
  • 00:41:27
    by the way I'll answer that first you
  • 00:41:30
    get that blessed cup of coffee or tea
  • 00:41:33
    yes
  • 00:41:34
    okay what's the very very very next
  • 00:41:38
    thing you do
  • 00:41:39
    when you sit down at work whether it be
  • 00:41:41
    at your home office or whatever
  • 00:41:44
    email check email and your day is over
  • 00:41:49
    you start getting involved it's like oh
  • 00:41:51
    it's like oh no I've got a meeting in 10
  • 00:41:53
    minutes oh we've got a production outage
  • 00:41:54
    right there oh yeah never okay so
  • 00:41:58
    my day looks like this I get that
  • 00:42:00
    blessed cup of coffee or tea
  • 00:42:04
    and then I spend 20 minutes enjoying
  • 00:42:07
    that nice hot beverage well I work on me
  • 00:42:12
    my career
  • 00:42:15
    my architectural thinking my technical
  • 00:42:17
    breath
  • 00:42:18
    if I could spend 30 awesome but 20 is
  • 00:42:21
    good
  • 00:42:22
    most articles are designed for seven or
  • 00:42:24
    ten minutes my videos of software
  • 00:42:27
    architecture Monday on purpose are 10
  • 00:42:28
    minutes so you can do other things
  • 00:42:30
    during the 20-minute rule as well try it
  • 00:42:33
    out
  • 00:42:34
    try it out because if you can't spend 20
  • 00:42:37
    minutes in the morning on yourself
  • 00:42:41
    then there's other problems that we need
  • 00:42:43
    to discuss I'll be in the speaker's
  • 00:42:45
    Lounge after the thing
  • 00:42:51
    well there's one other aspect so give it
  • 00:42:53
    a try give it a try download that
  • 00:42:56
    architecture characteristics worksheet
  • 00:42:58
    give it a try just see if you can start
  • 00:43:00
    to think about what are the
  • 00:43:02
    characteristics that's architectural
  • 00:43:04
    thinking
  • 00:43:06
    um expand your technical breath
  • 00:43:08
    these are easy things that are free
  • 00:43:11
    okay there's one more element that we
  • 00:43:13
    can talk about and that's analyzing
  • 00:43:15
    trade-offs this is another thing of
  • 00:43:17
    thinking like an architect I need to
  • 00:43:19
    channel my friend Rich hickey who
  • 00:43:22
    created closure
  • 00:43:23
    and here's a quote that's quite
  • 00:43:25
    controversial but it's quite funny and
  • 00:43:28
    sometimes sometimes quite true and he
  • 00:43:30
    says this
  • 00:43:33
    developers know the benefits of
  • 00:43:35
    everything
  • 00:43:36
    and the trade-offs of nothing
  • 00:43:39
    and I've seen it I mean it's not always
  • 00:43:41
    true I have worked with development
  • 00:43:43
    teams and developers who do know about
  • 00:43:46
    trade-offs
  • 00:43:47
    but a lot of us get excited about a
  • 00:43:49
    particular technology a framework a tool
  • 00:43:52
    a language
  • 00:43:54
    and we only see the good stuff we don't
  • 00:43:56
    see the bad stuff
  • 00:43:58
    yeah so let's see about analyzing
  • 00:44:01
    trade-offs because this is another way
  • 00:44:02
    of thinking like an architect okay
  • 00:44:05
    so here's our first law again and we
  • 00:44:07
    keep bringing this up because it's so
  • 00:44:09
    important
  • 00:44:10
    everything in software architecture is a
  • 00:44:13
    trade-off
  • 00:44:14
    and the structural aspect of software
  • 00:44:17
    architecture and the structural aspect
  • 00:44:20
    of Building Systems
  • 00:44:21
    there are no best practices
  • 00:44:26
    how can you possibly say you should all
  • 00:44:28
    focus on performance
  • 00:44:30
    oh we don't care about performance no
  • 00:44:33
    that's not a best practice you should
  • 00:44:34
    always use microservices yeah we're a
  • 00:44:37
    small startup shop
  • 00:44:38
    I mean challenge yourself
  • 00:44:40
    Neil and I have that's how we came up
  • 00:44:42
    with the law yeah now I qualified it to
  • 00:44:45
    say the structural aspect because there
  • 00:44:47
    are some best practices in architecture
  • 00:44:50
    one of them
  • 00:44:52
    always collaborate with your development
  • 00:44:55
    team and stakeholders yeah if you don't
  • 00:44:57
    it'll fail
  • 00:44:58
    yeah that's a best practice but it's the
  • 00:45:00
    process part of architecture I use
  • 00:45:03
    architecture decision records to justify
  • 00:45:05
    my architecture decisions that's a best
  • 00:45:08
    practice
  • 00:45:09
    but within a structural aspect
  • 00:45:12
    no there's none
  • 00:45:14
    so follow-up question in our second book
  • 00:45:17
    architecture the hard parts and that is
  • 00:45:20
    okay then
  • 00:45:22
    so what happens when there are no best
  • 00:45:23
    practices
  • 00:45:25
    this everybody is why architecture is
  • 00:45:29
    hard
  • 00:45:33
    it's because
  • 00:45:34
    we don't have that many guideposts
  • 00:45:36
    because it's all 100 contextual
  • 00:45:40
    so how do we make decisions this is one
  • 00:45:43
    of the things an architect does this is
  • 00:45:45
    architectural thinking analyzing
  • 00:45:47
    trade-offs well not surprisingly how did
  • 00:45:50
    them do we make a decision A or B uh
  • 00:45:54
    I guess we could flip a coin no I have a
  • 00:45:56
    better idea understand the business
  • 00:45:58
    drivers first
  • 00:46:00
    what's important to the business and
  • 00:46:02
    they say time to market the most
  • 00:46:05
    important thing we've got a lot of
  • 00:46:06
    important things but that one's way up
  • 00:46:08
    at the ceiling
  • 00:46:09
    all right all right so we understand
  • 00:46:11
    that do you remember the first section
  • 00:46:14
    what do we do with that information
  • 00:46:17
    yeah exactly doesn't matter if you're
  • 00:46:19
    not an architect
  • 00:46:21
    you say huh so they need speed to Market
  • 00:46:23
    well I wonder what that means that kind
  • 00:46:25
    of translates to architectural
  • 00:46:27
    characteristics about maintainability
  • 00:46:30
    testability the ease of incompleteness
  • 00:46:32
    of testing and also deployability the
  • 00:46:35
    ceremony of deploying our software the
  • 00:46:37
    frequency and the overall risk
  • 00:46:40
    it's all three of these that give us
  • 00:46:42
    time to Market oh it doesn't matter how
  • 00:46:44
    fast you can find the change and make it
  • 00:46:46
    as a developer if it takes you six weeks
  • 00:46:48
    to test
  • 00:46:50
    good luck
  • 00:46:53
    if you're wondering by the way
  • 00:46:56
    um
  • 00:46:57
    if you don't believe me about these
  • 00:46:58
    three
  • 00:46:59
    what is the fastest possible way
  • 00:47:02
    in the world to get your changes
  • 00:47:04
    released to your customers fastest way
  • 00:47:07
    in the world
  • 00:47:11
    don't test
  • 00:47:13
    make the change release make the change
  • 00:47:15
    release make change release
  • 00:47:18
    yeah is that time to Market
  • 00:47:20
    no that's killing your company
  • 00:47:24
    yes so the point is it's all three of
  • 00:47:27
    these we need that ease of and
  • 00:47:29
    completeness of testing because as we
  • 00:47:30
    move faster we want to make sure we're
  • 00:47:33
    not introducing more and more and more
  • 00:47:34
    and more bugs into the system we will
  • 00:47:37
    lose it doesn't matter how fast we can
  • 00:47:39
    be it's all three of these
  • 00:47:41
    we take this information
  • 00:47:43
    and then we do this huh
  • 00:47:46
    I have a decision to make what do I do I
  • 00:47:49
    look at the pros and cons
  • 00:47:51
    and I try to boil them down and simplify
  • 00:47:54
    them
  • 00:47:55
    and this is what it ends up to be
  • 00:47:57
    performance versus maintainability
  • 00:48:00
    that's what it boils down to single
  • 00:48:03
    service three services single Services
  • 00:48:04
    faster three services this is gives us
  • 00:48:07
    better maintainability pick one it's
  • 00:48:09
    almost like cap theorem we can't really
  • 00:48:10
    do both of these
  • 00:48:12
    well how do we make a choice obviously
  • 00:48:14
    performance
  • 00:48:15
    oh I better not get on that soapbox
  • 00:48:18
    thank God pre-optimization of
  • 00:48:20
    performance could even be a keynote oh
  • 00:48:22
    boy yeah because think about it as a
  • 00:48:24
    developer
  • 00:48:25
    we want things to be fast
  • 00:48:28
    that's what our primary focus is on our
  • 00:48:30
    mind
  • 00:48:30
    that's seeing things with a developer's
  • 00:48:32
    eye a developer's perspective we want
  • 00:48:35
    fast code
  • 00:48:38
    seeing things with an architect's eye
  • 00:48:40
    says yeah we got to make our code fast
  • 00:48:43
    but hold on a second
  • 00:48:45
    what's most important to the business
  • 00:48:48
    well if we can tie them back to the
  • 00:48:51
    architecture characteristics we see that
  • 00:48:53
    maintainability is actually on that list
  • 00:48:56
    and if we tie it back to the business
  • 00:48:58
    need we see that time to Market would be
  • 00:49:01
    much better if I can make maintainable
  • 00:49:03
    code in other words break apart my
  • 00:49:05
    services
  • 00:49:06
    and so do you see
  • 00:49:08
    by going backwards now
  • 00:49:10
    I can actually make a decision and say
  • 00:49:14
    that's why we're going to break apart
  • 00:49:16
    our services
  • 00:49:18
    it's going to be slower
  • 00:49:20
    but time to Market is more important to
  • 00:49:22
    the business
  • 00:49:23
    that's what the architecture has to
  • 00:49:25
    support that is modern trade-off
  • 00:49:28
    analysis this is now seeing decisions
  • 00:49:31
    that you need to make with an
  • 00:49:33
    architect's eye and architect's point of
  • 00:49:35
    view
  • 00:49:36
    okay well let's try this out
  • 00:49:39
    let's actually show I want to show you a
  • 00:49:41
    couple of tips the first pro tip is this
  • 00:49:44
    watch out for something called the out
  • 00:49:46
    of context trap as a matter of fact this
  • 00:49:48
    is out of context anti-pattern when
  • 00:49:51
    we're starting to analyze trade-offs
  • 00:49:53
    let me show you what I mean
  • 00:49:55
    so
  • 00:49:56
    I'm wondering of a query I can't decide
  • 00:50:00
    whether I should use a shared library or
  • 00:50:03
    a shared service
  • 00:50:05
    for all my shared functionality this is
  • 00:50:07
    a developer decision something a
  • 00:50:10
    developer is probably going to make
  • 00:50:12
    where do I put all of those calculators
  • 00:50:14
    that are shared all of my utilities my
  • 00:50:17
    utility.cs my utility.java my utility.py
  • 00:50:20
    what do I do with all that code hmm
  • 00:50:24
    well I don't know oh wait a minute I
  • 00:50:27
    just attended gids23 and I attended this
  • 00:50:30
    keynote about analyzing trade-offs
  • 00:50:33
    that would be a good start
  • 00:50:37
    so let's actually do this
  • 00:50:39
    so what I'm going to do is create a
  • 00:50:41
    scorecard
  • 00:50:42
    and I'm going to start looking at the
  • 00:50:44
    pros and cons of each of these
  • 00:50:46
    so
  • 00:50:47
    heterogeneous code that's the first one
  • 00:50:49
    which works better well heterogeneous
  • 00:50:52
    code does not work well with shared
  • 00:50:54
    libraries because if I've got five
  • 00:50:56
    platforms I've got five copies of that
  • 00:50:59
    shared Library five copies of the code
  • 00:51:01
    but with a shared service
  • 00:51:04
    doesn't matter if you're even in a
  • 00:51:05
    Mainframe call me it's in one place
  • 00:51:08
    oh score one for shared service ah but
  • 00:51:12
    what about high code volatility our code
  • 00:51:14
    changes all the time
  • 00:51:16
    well in a shared Library what's going to
  • 00:51:18
    happen
  • 00:51:19
    I'm going to continue to version until I
  • 00:51:21
    reach that Max version number that's
  • 00:51:22
    supported and all of you even if you're
  • 00:51:25
    not using the utility are going to have
  • 00:51:27
    to retest and redeploy
  • 00:51:29
    and rebuild
  • 00:51:31
    every single week
  • 00:51:34
    that's a lot of churn oh that's not
  • 00:51:36
    going to work but what happens with a
  • 00:51:38
    shared service that code changes all the
  • 00:51:40
    time yeah it just changed the podium
  • 00:51:42
    yeah I just changed the podium yeah you
  • 00:51:44
    guys all just use it
  • 00:51:47
    okay what about the ability to version
  • 00:51:49
    things though
  • 00:51:52
    shared library now has a check mark this
  • 00:51:55
    gets a plus one yeah it's hard diversion
  • 00:51:58
    runtime changes
  • 00:52:01
    but I converge in a dll or a jar file or
  • 00:52:04
    a gem
  • 00:52:05
    that's not hard
  • 00:52:07
    actually it is
  • 00:52:08
    fallacy number nine of distributed
  • 00:52:10
    computing
  • 00:52:12
    what about overall change risk
  • 00:52:14
    yeah if I make a change to that Podium
  • 00:52:16
    that's our shared service right there
  • 00:52:17
    and I really messed something up
  • 00:52:21
    I've just now broken every single one of
  • 00:52:23
    you
  • 00:52:24
    because it's hard to version that's a
  • 00:52:26
    runtime change in production once I
  • 00:52:29
    deploy that service all of a sudden boom
  • 00:52:31
    boom boom boom everybody's like hey why
  • 00:52:33
    are you all leaving the uh tutorium uh
  • 00:52:36
    oh because that change made the speaker
  • 00:52:38
    go away and uh and also you can't hear
  • 00:52:41
    me is or the microphone and so it's a
  • 00:52:44
    lot more risk
  • 00:52:46
    But Eric but with shared libraries I
  • 00:52:49
    have backwards compatibility I have
  • 00:52:50
    agility
  • 00:52:51
    then cat needs a change immediately okay
  • 00:52:53
    then cut type type type here you go
  • 00:52:55
    version 2.3.4 done
  • 00:52:58
    I gave that to him just now
  • 00:53:01
    the rest of you YouTube 2.4.2
  • 00:53:05
    backwards compatibility and Agility
  • 00:53:08
    because now we have to start now all
  • 00:53:10
    changing at some point but what about
  • 00:53:13
    the operational characteristics things
  • 00:53:15
    like performance things like fault
  • 00:53:17
    tolerance scalability
  • 00:53:19
    these are all bad in a shared service
  • 00:53:24
    at this Podium fell to the ground no
  • 00:53:26
    longer available neither are any of you
  • 00:53:29
    yeah all of a sudden if all of you and I
  • 00:53:32
    think I did this yesterday on stage here
  • 00:53:33
    all of a sudden ask me a question all at
  • 00:53:35
    once
  • 00:53:36
    I'm going to get overwhelmed and just
  • 00:53:38
    curl up on the stage and to a ball and
  • 00:53:41
    start crying
  • 00:53:42
    um yeah these are the problems it's
  • 00:53:44
    going to be slow to go all the way from
  • 00:53:46
    the front there especially with all
  • 00:53:47
    these Pathways to ask me a question if
  • 00:53:50
    you want to ask me a question to
  • 00:53:51
    communicate with me you have to actually
  • 00:53:52
    come onto the stage and shake my hand
  • 00:53:54
    that's going to take forever
  • 00:53:57
    not with a shared Library
  • 00:54:00
    do you see a clear winner here
  • 00:54:04
    yeah count up the check marks and we
  • 00:54:07
    find this is why using a shared library
  • 00:54:11
    is a best practice
  • 00:54:15
    hopefully now you know I'm teasing
  • 00:54:18
    because there is no such thing as a best
  • 00:54:20
    practice
  • 00:54:21
    this everyone is an anti-pattern
  • 00:54:25
    avoid it like the plague this is called
  • 00:54:29
    the out of context trap what's my
  • 00:54:31
    context me Mark Richards personally this
  • 00:54:35
    is my context well we have Services
  • 00:54:37
    written in four different languages so
  • 00:54:39
    we're using polyglot programming and
  • 00:54:41
    we're not really concerned about
  • 00:54:42
    performance or scalability no our
  • 00:54:45
    biggest issue and our product right now
  • 00:54:47
    is managing changes
  • 00:54:50
    to Shared functionality that occur
  • 00:54:52
    frequently that's my problem
  • 00:54:55
    oh what happens if we go back to the
  • 00:54:57
    scorecard
  • 00:55:00
    that's plus two to zero
  • 00:55:04
    yeah that's how we make the choice
  • 00:55:07
    we apply the context
  • 00:55:09
    and now a shared service is better even
  • 00:55:12
    though it has more X's I don't care
  • 00:55:14
    about those X's now a lot of you
  • 00:55:17
    probably use scorecards and you do
  • 00:55:19
    waiting so you say well this one's
  • 00:55:21
    weighted higher than this one well go
  • 00:55:23
    ahead and do that but if you don't care
  • 00:55:25
    about it wait it at zero
  • 00:55:28
    and then count it up because it has no
  • 00:55:30
    bearing for our context
  • 00:55:33
    so that watch out for this kind of of of
  • 00:55:35
    problem okay here's another Pro tip
  • 00:55:40
    but this one's hard
  • 00:55:43
    try to avoid not try to avoid there is
  • 00:55:46
    no try it's do or not do
  • 00:55:49
    avoid over evangelizing any particular
  • 00:55:52
    technology framework solution something
  • 00:55:56
    you found
  • 00:55:58
    we get all excited about something oh I
  • 00:56:02
    found I found grpc Google's remote
  • 00:56:05
    procedure call
  • 00:56:06
    it's the best thing I've ever seen I
  • 00:56:08
    could get 10 times more than 10 times
  • 00:56:11
    better performance in our system our
  • 00:56:13
    system's too slow I found the solution
  • 00:56:15
    grpc oh 10 times performance increase it
  • 00:56:19
    is it's wonderful it's exciting it's
  • 00:56:21
    great
  • 00:56:22
    try to avoid that
  • 00:56:25
    why
  • 00:56:26
    because of the first law of software
  • 00:56:29
    architecture everything in software
  • 00:56:31
    architecture
  • 00:56:32
    is a trade-off
  • 00:56:34
    and the problem is
  • 00:56:36
    you all get very excited about it and
  • 00:56:38
    what have I just done by evangelizing
  • 00:56:42
    I have just hidden
  • 00:56:44
    all of the trade-offs
  • 00:56:46
    and they're there
  • 00:56:48
    no one's finds them no one sees them no
  • 00:56:51
    one knows they're there because we're
  • 00:56:52
    all excited because I evangelized
  • 00:56:54
    something I got excited about it I made
  • 00:56:56
    you excited about it
  • 00:56:58
    this is a very dangerous thing you know
  • 00:57:02
    why architects
  • 00:57:04
    are always grumpy
  • 00:57:05
    they always have a frown they're always
  • 00:57:08
    walking around like this
  • 00:57:10
    because we can't get excited about
  • 00:57:12
    anything
  • 00:57:13
    because everything has a trade-off it's
  • 00:57:15
    a very depressing place to be yes oh
  • 00:57:20
    all right
  • 00:57:21
    um
  • 00:57:22
    so that everyone is architectural
  • 00:57:24
    thinking that's seeing things with an
  • 00:57:28
    architect's eye an architect's point of
  • 00:57:30
    view which will help you start
  • 00:57:33
    accelerating your career
  • 00:57:35
    into kind of that architect position
  • 00:57:37
    because you're already acting the role
  • 00:57:40
    you're already doing it
  • 00:57:42
    get the practice now
  • 00:57:44
    before all of a sudden you get handed
  • 00:57:47
    the golden keys of architecture and say
  • 00:57:50
    I'm not sure what I'm supposed to be
  • 00:57:52
    doing here and now I'm way over my head
  • 00:57:55
    practice it now but even if that's not
  • 00:57:58
    your career aspiration
  • 00:58:00
    maybe you want to know what we stay a
  • 00:58:01
    developer that's cool too
  • 00:58:03
    but now using this stuff you can create
  • 00:58:06
    more effective
  • 00:58:07
    and more efficient
  • 00:58:09
    and more correct
  • 00:58:11
    software Solutions as a developer
  • 00:58:16
    all right wonderful well thank you all
  • 00:58:19
    so much
  • 00:58:20
    thank you
  • 00:58:20
    [Music]
Tags
  • software architecture
  • architectural thinking
  • trade-offs
  • business drivers
  • technical knowledge
  • software development
  • career growth