Last week I had the opportunity to “attend” ArchConf (virtually). Of the sessions I attended, Venkat Subramaniam’s presentation of “Building Evolutionary Architectures” was easily the best and combined an engaging and enthusiastic style with useful content. David Sietz’s “Data as a Service (DaaS)” presentation was also very good and applicable for my needs. Aside from that, Joshua Smith and Laine Minor from RedHat were probably the most entertaining/fun/funny.

If you’re interested, here are my notes for each session I attended and took notes for :). Replays (for attendees only)

Architecting Cloud Native Applications

Nathaniel Schutta – 3/5

Main Takeaway: In order to successfully implement micro-services they must have consistent/good monitoring

• Responsible Micro-Services ebook
• Beware of developers implementing technologies/languages/patterns for “resume driven design” reasons… not for the right reasons.
• Shared servers are a liability
• The 12 Factor App: Best Practices in Cloud Native Applications and Microservices
• You can consider a service a function because you can spin the number of instances down to zero
• Quality Attributes/Requirements = Non Functional Requirements (NFR)
  • Personally I would really like to see us start using “Quality Attributes” or “Quality Requirements” instead of NFR.
• The 7 Software “-ilities” You Need To Know
• Architecting For the -ilities
• Architecture Requirements are Ilities
• You have to consider what ility attributes are important for which stakeholder, and what decisions that results in.
• Evolutionary architecture book
• microservice = anything that can be re-written in 2 weeks or less
  • I really like this definition and goal.
• high cohesion, low coupling
• A Modular Monolith might be a better approach in certain situations. A modular monolith is a software design approach in which a monolith is designed with an emphasis on interchangeable (and potentially reusable) modules.
• If you have to ask what something is (a tech, language, platform), you don’t need it.
• Monitoring is vital to a thriving microservice arch
• The Four Golden Signals for Monitoring Distributed Systems: latency, traffic load, error rate, saturation
• Circuit Breaker Pattern

Paved Roads – Architecting for Distributed Teams

Nathaniel Schutta – 4/5

Main Takeaway: Any alert someone gets should be informative and actionable. Otherwise, put it on a dashboard or report.

• Even when we’re in person we’re still communicating remotely (sending IMs, Texts, etc)
• Fitness function = todo list from arch to devs
• Review boards don’t work!
• Just because we can measure it does NOT mean it matters
• If everything is an option, nothing is an option
• Look into spring cloud contract
• Temporal fitness function = essentially a reminder (ex: Review this code in 1 year)
• Keep track of non-decisions/non-goals too (i.e. we don’t care about X because…)
• Fitness functions should be visible and reviewed at least annually.
• If you’re going to get an alert it needs to be informative AND actionable. Just informative goes on a dashboard or report.
• Look into building a “radar”
• thoughtworks.com/radar

To Hug or to Strangle: Tips for Dealing with Monolith Pain

Laine Minor & Josh Smith – 3/5

Main Takeaway: Consider “hugging” (applying micro-service best practices) legacy apps that are too big to strangle

• pain = the thing that prevents you from doing the part of your job you came/want to do
• pain = mental load of things you know are not as they should be
• You get an architecture whether you plan for it or not
• Long time between delivery is a BUSINESS problem
• Biggest benefit of microservices is clean lines
• Option 1: strangle, then hug
• Option 2: hug, then strangle
• Hugging = applying microservice best practices to a monolith (monitoring, etc)

Developer To Architect

Nathaniel Schutta – 3/5

Main Takeaway: Review boards and heavy handed governance doesn’t work.

• Consequences can be positive and negative
• Maximizing one minimizes another
• Governance in most orgs is heavyweight, high ceremony… and it does NOT work
• SLA vs SLA. The A matters and it indicates a consequence. If there is no consequence its an SLO (Objective)
• A reform most often advances via indirection
• It’s not just about the tech. It’s the relationships
• Portfolio architect provides high-level architectural and software engineering expertise to managers and technical staff.
• Domain architect : the way he describes it is essentially what we describe as a digital architect
• Specifically mentioned TOGAF as a “meh” certification

Sifting Technologies – Separating the Wheat From the Chaff

Nathaniel Schutta – 3/5

Main Takeaway: Consider implementing architectural briefings

• Education isn’t something you finish
• Attention is like real estate. they’re not making any more of it.
• Architectural briefing: why, how, where should/n’t we use
• Not just how much does the thing cost, but how much does it cost to use it (dev, maint, hardware, etc)?
• Speed reduces risk
• There’s a difference between a dead tech vs a mature one
• Developers are like cats. They’ll push back just on principle.

Building Evolutionary Architectures

Venkat Subramaniam – 5/5

Main Takeaway: Postpone decisions until the last possible moment because it’s possible YAGNI and doing so lessens the considerations for reversibility. Keep all code as simple as possible.

• UFD = Up Front Design
• Now that we’re “Agile” we’re not doing enough UFD (nor big UFD)
• Power point architects = dangerous
• Scrum master was never intended to be a title, else there’s no such thing as a self organizing team
• “adaptive planning” and “feedback driven development” are the most important words for Agile
• Rate all features/stories by business value and architectural impact
• Goal should be delivering value. Not using a particular tech.
• People confuse unfamiliar w/ complex
• People confuse familiar with simple
• reversibility = the ability to back out of a decision (less expensive)
• postpone decisions until the last responsible moment
• YAGNI = You Aren’t Gonna Need It
• parsimony = the most minimal solution. Ask “do we have to” for everything
• triangulate = implement 1 way, then another, and abstract common code to Base class
• Don’t START with an abstraction. Refactor into it.
• Postel’s law = be generous about what you receive and conservative about what you send
• Good reuse comes from repeated active use
• Be ruthless in minimizing dependencies including libraries and frameworks
• http://www.agiledeveloper.com/downloads.html

Core Software Design Principles

Venkat Subramaniam – 4/5

Main Takeaway: Have the courage to postpone doing things, and when you do, keep it DRY

• DRY = don’t repeat yourself
• Violating DRY results in duplication of effort, not just duplication of code
• Manual testing is a violation of DRY
• Manual deploy is a violation of DRY
• Effort: now > later -> postpone, now == later -> postpone, now < later -> eval probability of needing it
• We need to have the courage to postpone doing things
• SRP = single responsibility principle
• SLAP = Single Level of Abstraction Principle
• Then use the Compose Method Pattern to combine same level SLAPs
• OCP = open close principle
• Software modules (functions, classes, etc) must be open for extension but closed from modification
• LSP = Liskov Substitution Principle
• Inheritance should only be used for substitutability and not for reuse
• DIY = Dependency Inversion Principle -> class should not depend on another class. Both should depend on abstraction or interface.

Cloud Integrations and Data Architecture for Enterprise Applications

Rohit Bhardwaj – 3/5

Main Takeaway: The API should come first. Or, when implementing an API for an existing implementation, don’t model the API on the internal workings of the system.

• Application EA -> define our objects, what things they are part of, and the relationships between them
• Applications interact with domains and data flows between them
• Orchestration services should always queue requests and process/respond async
• Lambda is basically serverless (functions)
• You might consider using topics/queues for each service instead of load balancer
• https://github.com/robertmrk/docker-cometd-demos
• Check out CometD
• Use a correlation id to sync across systems
• API comes first! Then the implementation.
• schema.org
• MDM data cleansing: normalize data formats, replace missing values, standardize values, map attributes
• Identify sources (producers and consumers of master data) -> collect and analyze metadata -> appt data stewards -> implement data gov program and council -> dev MD model and choose toolset -> Design infra, generate and test MD -> Modify producing and consuming -> implement maint process

Modeling for Architects

Nathaniel Schutta – 2/5

Main Takeaway: The value in the artifact is not in the artifact itself. It’s in the conversation it facilitates.

• If the team can’t understand it, they can’t build it
• It’s ok to throw out or deprecate a diagram
• The value in the artifact is not in the artifact itself. It’s in the conversation it facilitates.
• Component diagrams, deployment diagrams, and sequence diagrams are most common

Architectural Awareness: Engineering Super-skill

Ken Sipe – 3/5

Main Takeaway: Question everything. Don’t be afraid of a little chaos or of making mistakes

• Hardest part of architecting is being aware
• awareness = awareness or perception of a fact
• chaos breeds creativity
• Dryfus model: novice, advanced beginner (most people in IT industry), competent, proficient, expert
• you get what you tolerate
• shame and fear are toxic
• We shouldn’t loosely couple everything. We should have it in the right places.
• Team strengths: empathy, vulnerable/humble, collaborate/communicate, ability to share vision.
• Is your process intentional or not?
• “scrum but…” = I want all the benefits but don’t want to pay for it
• Why are we doing ..x..? Should we do something else? Is it working?
• context matters… and context could be foreign
• embrace inconsistency
• dependencies matter
• it’s a mistake to worry too much about scalability from the start, but also to not think about it at all.

Architectural Resiliency

Jeremy Deane – 4/5

Main Takeaway: Need to have ownership to have accountability, and ownership needs to be end to end.

• Threat Modeling book
• openmastery.org
• promote accountability/ownership. No orphans
• Correlate activities. use a tracking id/correlation id
• Do synthetic transactions
• Look into “data dog” for dashboarding
• Cloud hosting should be multi-region
• Security Resiliency: Secure by default, defense in depth, least privilege
• Event sourcing
• Postel’s Law – Be conservative in what you send, be liberal in what you accept
• Bulkheads. Limit failure exposure.
• Validate your input. Sanitize your output.
• Need to have end to end ownership
• https://prezi.com/mb-vcfp-cry8/architectural-resiliency/

Architectural Trade-offs

Jeremy Deane – 4/5

Main Takeaway: Be aware that there’s a trade off (negative) to any choice you make.

• RBAC = Role Based Access Control (ex: AD, Prism)
• ABAC = Attribute Based Access Control (context based policies. ex: location based, etc)
• Feature Toggles tend to result in technical debt
• Blue green results in unnecessary releases
• orchestration causes coupling and dependencies
• choreography has complexity and needs monitoring
• Need to understand the requirements and your domain!
• Cloud providers tend to be “sticky”. Hard to get out of.

How to Technology Good – Tips for Implementation at Scale

Laine Minor & Josh Smith – 2/5

Main Takeaway: For good or bad, metrics (or data if you prefer) are needed to promote any tech

• Metrics help build understanding, certainty, and trust
• Until you have metrics it’s a non-starter

Data as a Service (DaaS)

David Sietz – 5/5

Main Takeaway: Publish data changes to your topics, have microservices consume the data as needed, and version as necessary.

• Data model changes are expensive
• Use a NoSQL db
• Version all data coming in
• Provisioning data: real time, self guided flow, variable load, parallel
• Publishing data: real-time, variable endpoints, variable load, managed access
• Use a business lens: risks, rewards, volatility
• ROI is not always monetary
• Last Responsible Moment (LRM)
• There’s nothing wrong with copying data as long as you understand the intent and retention
• Build your data marts at the last responsible moment

Please remember to subscribe to the newsletter or feed to stay up to date!

Disclaimer: Thoughts and opinions are my own, and do not reflect the views of any employer, family member, friend, or anyone else. Some links may be affiliate links, but I don't link to anything I don't use myself.