Jekyll2020-07-12T11:48:05-07:00https://b-deepak.github.io/feed.xmlRandom musings on architecture and some fun stuff.2020-07-11T20:20:00-07:002020-07-11T20:20:00-07:00https://b-deepak.github.io/2020/07/11/the-hard-parts-of-architecture<h2 id="goal">Goal</h2> <p><img src="https://b-deepak.github.io/assets/architecture_hard_parts_summary.jpg" alt="architecture hard parts summary" /></p> <h2 id="decisions">Decisions</h2> <ul> <li>It Depends. Decisions are a trade-off!</li> <li>Why &gt; How</li> <li>Use Architectural Decision Record (ADR) <ul> <li>Title</li> <li>Status</li> <li>Context</li> <li>Decision - <strong>Justification (Technical and Business)</strong></li> <li>Consequences - <strong>Trade-offs</strong></li> </ul> </li> <li>Example:</li> </ul> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Title ---- Single consolidated payment service Context ---- A customer can use any payment type combination (credit card, paypal, store credit, and gift cards) when placing an order. Payment is required when pacing an order (synchronous activity). The payment logic can be either a single consolidated service or a separately deployed service for each payment type. Decision ---- We will use a single consolidated payment service for all payment types. Separating the services would require orchestration, which incurs both network and security latency. A single payment service will be more responsive since it does not require orchestration of each payment, therefore improving customer satisfaction when placing orders. Consequences ---- The tradeoff of this decision is that maintenance, testing, and deployment will be impacted when changes are made to any of the payment types or another payment type is added. Testing scope is increased, requiring more time for complete testing. Deployment risk is increased as deploying a single service requires deployment of all payment types. Error handling and transactions are maintained in a single consolidated service, improving overall data integrity, data consistency, and performance when errors occur. This also improves overall customer satisfaction when placing orders. The maintenance impact tradeoff was accepted by the business stakeholders in favor of better performance and data consistency when customers </code></pre></div></div> <h2 id="architecture-characteristics">Architecture Characteristics</h2> <ol> <li>Synergistic</li> <li>Ill-defined</li> <li>Numerous Categories</li> <li>Voluminous</li> </ol> <h2 id="the-9s-of-availability">The 9’s of Availability</h2> <p>Availability is usually expressed as a percentage of uptime in a given year.</p> <table> <thead> <tr> <th>Availability %</th> <th>Downtime per year</th> <th>Downtime per month</th> <th>Downtime per day</th> </tr> </thead> <tbody> <tr> <td>90% (“one nine”)</td> <td>36.53 days</td> <td>73.05 hours</td> <td>2.40 hours</td> </tr> <tr> <td>99% (“two nines”)</td> <td>3.65 days</td> <td>7.31 hours</td> <td>14.40 minutes</td> </tr> <tr> <td>99.9% (“three nines”)</td> <td>8.77 hours</td> <td>43.83 minutes</td> <td>1.44 minutes</td> </tr> <tr> <td>99.99% (“four nines”)</td> <td>52.60 minutes</td> <td>4.38 minutes</td> <td>8.64 seconds</td> </tr> <tr> <td>99.999% (“five nines”)</td> <td>5.26 minutes</td> <td>26.30 seconds</td> <td>864.00 milliseconds</td> </tr> <tr> <td>99.9999% (“six nines”)</td> <td>31.56 seconds</td> <td>2.63 seconds</td> <td>86.40 milliseconds</td> </tr> </tbody> </table> <h1 id="connascence--coupling">Connascence / Coupling</h1> <blockquote> <p><em><a href="https://connascence.io/">Connascence</a> is a software quality metric &amp; a taxonomy for different types of coupling.</em></p> </blockquote> <p>Types:</p> <ol> <li><strong>Static</strong> - name, type, meaning, position, algorithm</li> <li><strong>Dynamic</strong> - execution, timing, value, identity</li> </ol> <p>Axes of Measure:</p> <ol> <li><strong>Strength</strong></li> <li><strong>Degree</strong></li> <li><strong>Locality</strong></li> </ol> <h2 id="architectural-quantum">Architectural Quantum</h2> <blockquote> <p>An architectural quantum is an independently deployable component with high functional cohesion and synchronous dynamic quantum connascence.</p> </blockquote> <h2 id="choosing-an-architecture">Choosing an Architecture</h2> <p><img src="https://b-deepak.github.io/assets/choosing_an_architecture.jpg" alt="choosing an architecture" /></p> <h2 id="service-granularity">Service Granularity</h2> <p>Get granularity right by iteration!</p> <h3 id="drivers">Drivers</h3> <blockquote> <p><em>When should I consider breaking apart a service?</em></p> </blockquote> <ul> <li>Functionality or Domain</li> <li>Code Volatility</li> <li>Scalability and Throughput</li> <li>Fault Tolerance</li> <li>Data Security</li> </ul> <h3 id="factors">Factors</h3> <blockquote> <p><em>What factors influence service granularity?</em></p> </blockquote> <ul> <li>Database Transactions</li> <li>Data Dependencies</li> <li>Communication Pattern i.e. Orchestration (Workflow) vs Choreography</li> </ul> <h2 id="evolutionary-architecture">Evolutionary Architecture</h2> <p>An evolutionary architecture supports <strong>guided, incremental change</strong> across multiple dimensions.</p> <h3 id="fitness-functions">Fitness Functions</h3> <blockquote> <p><em>Any mechanism that provides an objective integrity assessment of some architectural characteristic(s).</em></p> </blockquote> <p>Examples:</p> <ul> <li>Cyclic Dependency Function in Code Quality Tools</li> <li>Zero Day Security Check Function in Build Pipeline</li> <li>Contract Fitness Function using <a href="https://www.martinfowler.com/articles/consumerDrivenContracts.html">Consumer Driven Contracts</a> <ul> <li>Tool: <a href="https://docs.pact.io/">Pact</a></li> </ul> </li> </ul> <p>Architecture Governance Tools:</p> <ul> <li>Java - <a href="https://www.archunit.org/">ArchUnit</a></li> <li>.NET - <a href="https://github.com/BenMorris/NetArchTest">NetArchTest</a>, <a href="https://www.sonarqube.org/">SonarQube</a></li> </ul> <h2 id="coupling">Coupling</h2> <blockquote> <p><em>Aim for <strong>High Semantic Coupling</strong> &amp; <strong>Low Syntactic Coupling</strong></em></p> </blockquote> <p><strong>Contract Types and Trade-offs</strong></p> <table> <thead> <tr> <th>Strict Contracts</th> <th>Value Based Contracts</th> </tr> </thead> <tbody> <tr> <td>Method Signatures. Ex. SOAP, gRPC etc.</td> <td>Name-Value Pairs. Ex. JSON</td> </tr> <tr> <td>better control of exact parameter passing</td> <td>requires fitness functions</td> </tr> <tr> <td>brittle architecture coupling</td> <td>requires documentation</td> </tr> <tr> <td>better documentation via type signatures</td> <td>extremely loose coupling</td> </tr> </tbody> </table> <h2 id="managing-data-in-a-distributed-system">Managing Data in a Distributed System</h2> <ul> <li>Inter-Service Communication</li> <li>Data Replication</li> <li>In-Memory Replicated Cache</li> <li>Data Domains (Shared Tables)</li> </ul> <h2 id="achieving-scalability-and-elasticity">Achieving Scalability and Elasticity</h2> <p>Patterns to leverage in Microservices:</p> <ul> <li>Cache</li> <li>Sidecar Containers with Service Mesh</li> </ul>

Goal

2020-07-03T09:18:00-07:002020-07-03T09:18:00-07:00https://b-deepak.github.io/2020/07/03/raising-financially-responsible-children<p>This are some of the golden nuggets from an excellent financial independence podcast by <a href="https://html5-player.libsyn.com/embed/episode/id/7539545/height/90/theme/custom/autoplay/no/autonext/no/thumbnail/yes/preload/no/no_addthis/no/direction/backward/render-playlist/no/custom-color/87A93A/">JL Collins, Jane Collins, and Doug Nordman</a>.</p> <h2 id="grocery-matters">Grocery Matters</h2> <p>Once in a while, let your kids pay for grocery in cash to make them understand how money exchange works.</p> <h2 id="allowance">Allowance:</h2> <p>Give your kids allowance and “advise” them to save at least 50% in savings. The older they grow the more they would appreciate their savings balance. Carefully monitor the other 50% spent to determine the type of expenses and don’t step on their freedom entirely.</p> <h2 id="nature-vs-nurture">Nature vs Nurture</h2> <p>Put faith and trust your kids. Lectures do not work, trust does!</p> <h2 id="need-vs-want">Need vs Want</h2> <p>When buying something, question whether it is a need or a want? Make them understand the difference and why frugality always pays off in the longer run.</p> <h2 id="pseudo-401k-for-kids">Pseudo-401k for Kids</h2> <p>Match up their savings contribution every month just like a regular 401k. This will plant the importance of retirement savings when they start earning.</p> <p>This also teaches the power of Compound Interest at an early age. For example, telling your 6 year kid to save for 10 years allows him/her to pay for their car at 16, is mind-blowing to them.</p> <h2 id="more-tips">More Tips</h2> <p>Model your own behavior, kids copy their parents for 90% of learnings. Conversations will matter only 10%.</p> <p>Let them make mistakes. Let them learn from failing at home (a safer place) with their money.</p> <p>For a paid subscription model to monitor expenses, checkout famzoo.com. (<em>Disclaimer: I am not a customer and have not personally used this app</em>)</p> <h2 id="budgeting-formula">Budgeting Formula</h2> <blockquote> <p><strong>A dollar per week X kid’s age</strong></p> </blockquote> <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>$1 X 1 week X 6 year old = $6/week = $24/month Now help them with their budget: Spend $12 on their discretionary things like toys, candies, books, videos etc. Save the other $12 in an interest savings account, match their contribution. </code></pre></div></div> <h2 id="additional-resources">Additional Resources</h2> <p><a href="https://vanguardblog.com/2019/05/31/talking-to-your-kids-about-wealth-how-when-to-begin/">Vanguard’s Age-appropriate Discussions </a> - Amazing reference based on children’s age and maturity levels.</p> <table> <thead> <tr> <th> </th> <th> </th> <th> </th> <th> </th> </tr> </thead> <tbody> <tr> <td><strong>Learning the basics (ages 5–18)</strong></td> <td>Focus on heritage and family traditions.</td> <td>Introduce the concept of “spend, save, give.”</td> <td>Assign chores to instill the value of hard work.</td> </tr> <tr> <td><strong>Applying concepts (college years)</strong></td> <td>Provide experiences to understand assets vs. liabilities.</td> <td>Teach budgeting and saving.</td> <td>Understand financial concepts such as investment principles.</td> </tr> <tr> <td><strong>Expanding their scope (mid- to late 20s)</strong></td> <td>Provide deeper education on investing, family businesses, and real estate.</td> <td>Understand charitable giving options such as donor-advised funds and foundations.</td> <td>Begin to hold family meetings to discuss these topics and to assess everyone’s understanding.</td> </tr> <tr> <td><strong>Mentoring &amp; understanding the whole picture (30s)</strong></td> <td>Do a deep dive into concepts such as wills, trusts, and mortgages.</td> <td>Understand the financial institutions involved in the broader family picture.</td> <td>Provide activities to focus on the transfer of leadership from parents to the next generation.</td> </tr> <tr> <td><strong>Preparing for leadership transition (40s &amp; beyond)</strong></td> <td>Discuss the wealth transfer process and wealth purpose for the family.</td> <td>Integrate estate planning discussions with multiple generations.</td> <td>Decide on and communicate future plans, including how assets will be divided (e.g., to family members, charities, or both).</td> </tr> </tbody> </table>

This are some of the golden nuggets from an excellent financial independence podcast by JL Collins, Jane Collins, and Doug Nordman.

2020-06-27T15:16:00-07:002020-06-27T15:16:00-07:00https://b-deepak.github.io/2020/06/27/software-architect-tips-contd-soft-skills<ul> <li><a href="#meeting-tips">Meeting Tips</a></li> <li><a href="#leadership-tips">Leadership Tips</a></li> <li><a href="#team-structure">Team Structure</a></li> <li><a href="#negotiation-skills">Negotiation Skills</a></li> <li><a href="#architecture-boundaries">Architecture Boundaries</a></li> <li><a href="#remember-3-cs-of-architecture">Remember 3 C’s of Architecture</a></li> </ul> <h1 id="meeting-tips">Meeting Tips</h1> <p>Prepare diligently in advance to make your case (esp. for important meetings)</p> <h1 id="leadership-tips">Leadership Tips</h1> <ul> <li>Keep it simple, concise and tailor context to the stakeholders</li> <li>For Complex Diagrams - Make a high level and then “peel the onion” by separate the components in separate slide/zoom-in</li> <li>Be pragmatic, yet visionary</li> <li>Aim for success, not perfection</li> <li>Lead by example, not by title. Contribute hands-on but communicate the amount of commitment in advance to business stakeholders. Don’t lose the perception of being an architect.</li> <li>Share the credit</li> <li>Be decisive and justify the decision.</li> <li>Stay positive and get along with people</li> </ul> <h1 id="team-structure">Team Structure</h1> <ul> <li>Make yourself available</li> <li>Conway’s Law</li> <li>Solution: <ul> <li>Inverse Conway’s Manuever - Create Cross Functional Teams</li> <li>Build products, not projects</li> <li>Leverage <a href="https://thoughtworks.github.io/pacto/patterns/cdc/">Consumer Driven Contracts</a> for internal integrations</li> </ul> </li> </ul> <h1 id="negotiation-skills">Negotiation Skills</h1> <ul> <li>Gather as much information from requirements before entering a negotiation</li> <li>If all else fails, pivot to cost and time factors</li> <li>Demonstrate your findings</li> <li>Techniques <ul> <li>Architectural trade-off based on functional and non-functional requirements</li> <li>Developer Buy-in</li> </ul> </li> </ul> <h1 id="architecture-boundaries">Architecture Boundaries</h1> <ul> <li>Define architecture and design principles</li> <li>IMP: <strong>Justify</strong> your decisions and <strong>Communicate</strong>!</li> <li>Guide the team. Examples: <ul> <li>Libraries/Framework choices</li> <li>Pattern Governance</li> <li>Defining Scope</li> </ul> </li> </ul> <h1 id="remember-3-cs-of-architecture">Remember 3 C’s of Architecture</h1> <ul> <li>Collaboration</li> <li>Communication</li> <li>Clarity</li> </ul> <hr />

Meeting Tips Leadership Tips Team Structure Negotiation Skills Architecture Boundaries Remember 3 C’s of Architecture

2020-06-07T10:24:24-07:002020-06-07T10:24:24-07:00https://b-deepak.github.io/jekyll/update/2020/06/07/software-arch-tips<blockquote> <p><em>“Architecture is about the important stuff. Whatever that is” - Ralph Johnson</em></p> </blockquote> <ul> <li><a href="#circle-of-knowledge">Circle of Knowledge</a></li> <li><a href="#build-your-own-radar">Build Your Own Radar</a></li> <li><a href="#leverage-checklists">Leverage Checklists</a></li> <li><a href="#6-steps-in-refactoring-an-architecture">6 steps in refactoring an architecture</a></li> <li><a href="#cost-benefit-analysis">Cost Benefit Analysis</a></li> <li><a href="#architectural-decision-records-adrs">Architectural Decision Records (ADRs)</a></li> </ul> <h1 id="circle-of-knowledge">Circle of Knowledge</h1> <ul> <li><strong>SYK</strong>: Stuff You Know</li> <li><strong>SYKYDK</strong>: Stuff You Know You Don’t Know</li> <li><strong>SYDKYDK</strong>: Stuff You Don’t Know You Don’t Know</li> </ul> <script src="https://cdnjs.cloudflare.com/ajax/libs/mermaid/8.5.2/mermaid.js"></script> <div class="mermaid"> pie title Knowledge &amp; Learning "SYK" : 25 "SYKYDK" : 25 "SYDKYDK" : 50 </div> <h1 id="build-your-own-radar">Build Your Own Radar</h1> <p><a href="https://www.thoughtworks.com/radar/how-to-byor">How to BYOR</a></p> <p><a href="https://github.com/thoughtworks/build-your-own-radar">Github: BYOR</a></p> <h1 id="leverage-checklists">Leverage Checklists</h1> <blockquote> <p>List not the obvious but rather what’s not obvious!</p> </blockquote> <h1 id="6-steps-in-refactoring-an-architecture">6 steps in refactoring an architecture</h1> <ol> <li>Root cause analysis</li> <li>Determine changes needed</li> <li>Create business case</li> <li>Build refactoring plan</li> <li>Create timeline and estimates</li> <li>Present to business</li> </ol> <h1 id="cost-benefit-analysis">Cost Benefit Analysis</h1> <p>The <a href="https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=513476">CBAM</a> process consists of the following steps:</p> <ol> <li>Choose scenarios and architectural strategies.</li> <li>Assess quality attribute benefits.</li> <li>Quantify the benefits of architectural strategies.</li> <li>Quantify the costs and schedule implications of the architectural strategies.</li> <li>Calculate the desirability of each option.</li> <li>Make architectural design decisions</li> </ol> <script src="https://cdnjs.cloudflare.com/ajax/libs/mermaid/8.5.2/mermaid.js"></script> <div class="mermaid"> flowchart LR A(Business Goals) --&gt;|Define| B(Software Architecture \n-ilities &amp; NFRs) B --&gt; D(Benefits) B --&gt; E(Cost) D --&gt; F{Assess} E --&gt; F F --&gt; G(Selection) </div> <h1 id="architectural-decision-records-adrs">Architectural Decision Records (ADRs)</h1> <blockquote> <p><a href="https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records">Lightweight Architecture Decision Records</a> is a technique for capturing important architectural decisions along with their context and consequences.</p> </blockquote> <ul> <li> <p><strong>ADR (Simple)</strong></p> <ul> <li>Sections: <ul> <li>Title</li> <li>Context</li> <li>Decision</li> <li>Status</li> <li>Consequences</li> </ul> </li> <li><a href="https://github.com/joelparkerhenderson/architecture_decision_record/blob/master/adr_template_by_michael_nygard.md">Template</a></li> <li>Examples <ul> <li><a href="https://github.com/alphagov/govuk-aws/tree/master/doc/architecture/decisions">here…</a></li> <li><a href="https://github.com/arachne-framework/architecture">and here…</a></li> </ul> </li> </ul> </li> <li> <p><strong>MADR (Options &amp; Pros/Cons)</strong></p> <ul> <li>Sections: <ul> <li>Title</li> <li>Context</li> <li>Decision</li> <li>Considered Options</li> <li>Outcome/Consequences</li> <li>Pros/Cons</li> </ul> </li> <li><a href="https://github.com/joelparkerhenderson/architecture_decision_record/blob/master/adr_template_madr.md">Template</a></li> <li><a href="https://adr.github.io/madr/template/0000-use-markdown-architectural-decision-records.html">Example</a></li> </ul> </li> </ul>

“Architecture is about the important stuff. Whatever that is” - Ralph Johnson