Tag: architecture

Lessons Learned as an architect

1. negotiation and political skills are sometimes, and most often, more important as an architect than technology skill
2. It’s all about the data
3. The world’s best architectures are not the perfects ones, but rather the feasible ones.

What is software design?

Our plan, our design is the complete source code.

Neil Ford One of the reasons Software is so complex is we don’t have any constraints like the real world. So we don’t have any limits on what we can do.

Quotes

"The final goal of any traditional engineering activity is some type of documentation."

"When the design effort is complete, the design documentation is turned over to the manufacturing team"

Fixing a manufacturing defect in from a factory is expensive and costly. Much effort is put into place to eliminate defects before the final goods are created. In software, compiling (manufacturing the software) is so cheap, that it’s cheaper to manufacture (compile) the software and test that the item matches our expectations. This is analogous to planning a pre-manufacture rigor found in the manufacturing industry.

In the software world we are in the world of bits not atoms. This makes making changes over time much easier than in the world of atoms.

The plan in the manufacturing world is the source code in the software world.

"Given that software designs are relatively easy to turn out and essentially free to build, an unsurprising revelation is that software designs tend to be incredibly large and complex." – Jack Reeves

Each piece of software is a handcrafted piece. We don’t have the componentization that the real-world has.

In traditional engineering, plans are engineered up front large amounts of time and money are invested to get it right before it’s implemented. In software, manufacturing is so cheap, that we can create it up front and then test to ensure that it’s implemented correctly.

"Software may be cheap to build, but it is incredibly expensive to design." – Jack Reeves

You want to architect for change. This does not mean you want to have mass abstractions. This means pithiness and keeping is simple. If you can make changing architecture less expensive to do, it gives your flexibly of evolving your application over time.

Software always becomes iterative. You will always need to change or fix the software. The difference is how tight your feedback loop is. In waterfall it might be a long drawn out process, in agile it’s short a short feedback loop.

Architecture also becomes iterative. No one architecture/approach can solve every problem. Understand why things work, not mechanics of what things are doing.

Separate goals from approaches.

Architecture isn’t an equation to be solved; it’s a snapshot of a process. It’s always in flux, it’s always changing, a perfect architecture always fails when it meets the real world.

Architecture is coupled to process (especially, continuous delivery). It is coupled to the technical solution and to the process. This is what makes architecture so difficult.

Course outline The 3 area’s of software architecture

1. Application
   • Techniques for change
   • patterns & anti-patterns
   • tools & documentations
2. Integration
   • overview
   • architectural styles
3. Enterprise
   1. introduction to enterprise architecture

Architecture cross-cutting concerns

• Soft Skills
• Continuous Delivery
• Understanding large codebases

Soft Skills

Expectation of an Architect

1. Analyze technology, industry, and market trends and keep current with those latest trends.
2. Analyze the current technology environment and recommend solutions for improvement.
   • Look at the full life-cycle of the project. It is the responsibility of the architect to make sure it works. This includes thinks like process and continuous delivery.
3. Ensure compliance with the architecture.
   • This is an ongoing responsibility of an architect.
4. Having expose to multiple and diverse technologies, platforms and environments.
5. Possess exceptional interpersonal skills, including teamwork, facilitation, and negotiation
6. define the architecture and design principles to guide technology decisions for the enterprise.
   • Don’t dictate specific technology choices.
7. understand the political climate of the enterprise and be able to navigate the politics.

Architecture Aspects

• Leadership and communication
• technical knowledge
• business domain knowledge
• methodology and strategy

Continuous Delivery – "Fast, automated feedback on the production readiness of your application every time there is a change — to code, infrastructure, or configuration" **** Software is always in a production ready state. Any change will trigger a build. This includes software patches on a server or stalling new software on the server.

• integrate early and often
  • The longer you put it off, the worse it gets at an exponential level.
  • At one point in history, people would go off and create their own bits of software. After a short, or sometimes longtime, they would return and try to integrate the different pieces. More often than, not, the pieces were very difficult, if not impossible to put together. It would often take months to put all the pieces together on a big project.
• As with most things in software, the longer you put it off, the harder it gets.
• Continuous Delivery is the final stage of CI.

continuous delivery ideal

• software is always production ready
• deployments are reliable and commonplace
• everyone can self-service deployments
• releases occur according to business needs, not operational constraints

What does good look like? What are characteristics are good, what characteristics are bad?

Design and Architecture – Big ‘A’ Architecture. How do different parts of the system communicate with each other. What is our security? What is our persistence strategy? Design are things that are closer to the code. How the system interacts with devices is Architecture.

What are the principles of Evolutionary Architecture?

1. Last responsible Moment
   • Delay decisions as long as you can, but no longer
   • Maximizes the information you have
   • Minimizes technical debt from complexity
   • Decide early what your drivers are, and prioritize decisions accordingly
   • Evolutionary, neither emergent nor based on guesswork
2. Architect and develop for evolvability
   • Sensible breakdown of functionality
   • Consider data lifecycle and ownership
     • Who has access to it
     • How long should we keep it.
   • Appropriate coupling
     • Coupling is inevitable
       • Two systems that must communicate, there has to be coupling.
   • Lightweight tooling and documentation
   • Develop for Evolvability
     • Software internal quality metrics focusing on each of change
       • You don’t want to optimize for understanding code, you want to optimize for understanding code
       • OnceI have these metrics, how to I focus my attention on making a piece of code more evolable.
       • Look for change hotspots
       • Measure continually, focus on trends.
         • Gives visibility into changes and software evolution
   • Reversibility
     • Change that decision later down the road.
3. Postel’s Law
   • How systems communicate with each other.
   • Be conservative in what you send, if you put it out there people will use it, because you are now committed.
   • Be liberal in what you receive. If you only want a phone number, but receive the entire address. Only validate the phone number. You don’t want to be sensitive to changes that don’t impact you.
   • Use version numbering when you have to break a contract.
4. Architect for testability
   • If you think about testability in your architecture, the side effect is a well architected system. Things that tend to make your system hard to tests also tend to make it hard to change and maintain.
   • Single Responsibility Principle – Example: Messaging infrastructure used for messaging, not business logic. Testing business logic embedded in Messaging is hard. Separate the two and test business logic outside the message infrastructure.
   • Map your business components to the business concepts. When the business requests changes, in a business concept if your components are similarly mapped the change will be less impactful.
   • Automated build and deployments is an essential underpinning
5. Conway’s Law
   • Organizations design system reflecting their communication structures
   • Broken communications imply complex integration
   • Silos often result in broken communication
   • If you don’t want your product to look like your organization, change your organization (or your product)

Techniques for implementing evolutionary architecture

• Database Refactoring
  • Decompose big change into series of small changes
  • Each change is a refactoring/migration pair(or triple of you include access code)
    • This should be easy, but data gets dirty overtime making it difficult.
  • Changes compose in the same way functions compose
  • And of course, version control the changes
  • And apply in the various environments during promotion
• Continuous Delivery
  • Automate environments and configuration
    • Is the underpinning that makes everything works.
  • Automate builds and deployments and use continuous integration
  • Automate testing at all levels
  • Deployments should be boring!!
  • Just because you CAN release at any time, doesn’t mean you HAVE to
• Choreography
  • How different parts of the system works together as opposed to orchestration
  • Scripted outcomes and vision
  • Individuals perform to the vision without a conductor
  • Distributes authority about interactions
  • Introduces new kinds of failure scenarios
• Contract Testing
  • Acceptance tests at the systems interface
  • Documents assumptions made
  • Maximizes parallel independent work
  • Used in congestion with Postel’s Law
  • One traditional role of Enterprise Architect

Evolutionary Architecture

• Define your architectural fitness function
  • Must think about this upfront
    • What is most important to you
      • What is your security threat landscape?
      • What are your scaling requirements?
      • What are your performance requirements?
      • What are the things you can’t compromise on?
• Delay your decisions as long as you can
• Understand various forms of technical debt
• Implement evidence based re-use.
• Create and maintain the testing safety net

Book Recommendations

• Patterns of Enterprise Architecture
• Enterprise integration PAtterns
• Craft of being a Architecture
• Data Architecture

Rebecca Parsons – Publishing a book on

Technical debt is some drag on your development process because of some technical issue.

Trisha Gee

Anti-Patterns

Bad Code Reviews

A bad code review is a review that makes the person feel bad about the code they just spent hours working on.

We are human beings; instead of saying this is wrong, offer reasoning and suggest another direction.

Code reviews are about learning, collaboration, and conversation to improve the product, the company, and the people.

Book Recommendations

• Delusions of Gender: How Our Minds, Society, and Neurosexism Create Difference
• Programmed Inequality: How Britain Discarded Women Technologists and Lost Its Edge in Computing
• Invisible Women: Data Bias in a World Designed for Men
• 97 Things Every Java Programmer Should Know
• Head First Design

Mark Richards

Software Architecture Styles

Architecture Styles vs. Architecture Patterns

Architecture Styles is a general strategy to an architecture. One or more architecture patterns can be used within an Architecture Style. Architecture Styles may also be hybrids. For example, an event-driven architecture may be made up of small components and with their data sources and deployed independently. This would be a microservice event-driven architecture.

Sonya Natanzon

The Role of the Software Architect

The Three Skills Architects must have

People

The architect must be an influencer. Value proposition, explaining the solution, and selling your ideas.

Conway’s Law. Org structure influences application structure. The lines of communication influence the application structure.

Growing new leadership. A lot of the time, this means training people.

Knowledge sharing.

Delegate to others and support others as they work through the problems. You can’t take on all the work yourself.

Create room for experimentation and have tolerance for mistakes.

Technical

Always learning new technologies and ideas. And then teaching and knowledge sharing. Information hoarding doesn’t work.

Selecting a toolbox. What technologies should our company use to be successful?

4 C’s

Analytical Skills

Thought

Evolve the Big Picture – Understand the path to how we got here and then chart a path forward. Create a roadmap for the next 6 months to a year.

Champion Process – People don’t fail you; the process does. This means having code reviews, retrospectives, following best prates. The process serves the team, not the other way around. Always be looking for ways to eliminate waste, whether this means adding process or removing it.

Set Culture and Values – Build, change, and influence culture and values.

The Four Immeasurables

Near Enemy and Far Enemy

1. Loving Kindness
2. near: selfish love
3. far: ill will
4. Compassion
5. near: pity
6. far: cruelty
7. Empathic Joy
8. near: blind euphoria
9. far: jealousy
10. Equanimity
11. near: indifference
12. far: paranoia

Near Enemies of Software Architect Attributes

1. People
2. near: functional management without influence means you become a taskmaster. You don’t have buy-in from your team.
3. Tactical
4. near: Individual Contributor rarely leaves time for a broader strategy. You don’t have the time to step back and see the big picture.
5. Thought
6. near: Ivory Tower Architect – They make architecture an academic exercise without real and practical value. They get hung up on the "right way" instead of being pragmatic and shipping software.

Solution Process

Problem Definition

• problem statement
• supporting analysis
• as-is documentation

Solution Proposal

• Models diagrams and other documentation
• Technology selection
• POC’s
• Ubiquitous language definition

Implementation

• API Definition, schemas, data models
• production code
• changes to everything are done in the previous phases.

Enhancement

• Changes
• Bugs
• Maintenance

Book Recommendations

• The Five Dysfunctions of a Team: A Leadership Fable – Patrick Lencioni
• Multipliers: How the Best Leaders Make Everyone Smarter – Liz Wiseman and Greg McKeown

Nate Schutta

Thinking Architecturally

We can’t predict the future; we must decide on something concrete now and stick with it. We can’t be chasing the future. We also must plan for the future and move to technologies when it makes sense for the business. That might be because it gives us a competitive advantage or the cost of supporting our existing platform is rising.

In software, we don’t know. It’s about trial and error. Let’s try it and find out.

Every single choice has trade-offs. When someone comes to you and says, "This is the most amazing thing; it’s going to solve every problem we’ve ever had," you should immediately ask, "What are the trade-offs?" This is design, in a nutshell, this is architecture in a nutshell.

There are three answers to every computer science questions

• 42, this is the geek check to see who is in the know and well-read
• Another layer of indirection
• it depends

Balancing when to use what tool over the other is the job of the architect. There is no perfect technology.

When presenting new technologies, you should be able to answer the following questions:

1. What do you like about this technology?
2. What DON’T you like about this technology? — you should have spent enough time with this technology to understand its shortcomings. If you haven’t, why are you recommending it?

"Quality Requirements" is another way to say the "ilities", for example, Scalability, Reliability, Simplicity.

There are two ways to sell you the idea:

1. The hammer – I’m going to tell you this is a good idea
2. The ninja – I’m going to convince you that it’s your idea and it’s a good one.

Sam Newman

Microservices

The Fallacies of Distributed computing apply.

Monolith does not mean a big bad legacy system. It’s just a bigger deployment package with multiple services/domains that share their data.

Fundamentally, Microservices are a type of distributed system.

Any distributed network had the concerns of latency.

You have the concerns of consistent data. Microservices embrace this idea of a single source of truth.

One of the things that set Microservices apart from other services is it does not share its data. It owns all its data. It’s truly an encapsulated service, including its data. There is no big shared database on the backend.

The problem of partitioning is when one service can’t see another service. This happens there is a disruption in the network.

The opinions of Microservices is that each service is independently deployable and that data that mutates is stored within a service boundary.

Microservices is end-to-end functionality modeling around the aspect of the business domain.

Microservices is the first post-DevOps system.

The Monolith is not the enemy. The Monolith is not the enemy; it’s not bad. A monolith is just a different style of architecture.

Microservices is typically not a place to start but a place to end. Start out discovering your business domain by building a modular monolith. When you’ve reached your current architecture limits, and Microservices is a good fit, move to a Microservice architecture.

Not all of your services need to be Microservices.

Microservice size is not about code but about the business domain, functionality, and data. It’s also about how easy is it to create a service? The easier a service is to create, the more and the smaller the services will be.

Start off with one or two services, then add more services as you are successful with the first services. Adding microservices is not an on/off switch but a dial was to increase the volume.

Stick with, you know. Don’t overload yourself with things to learn. If you know, Go, stick with it.

The only prerequisite to Microservices is Log Aggregation.

Data is accessed and mutated via the Microservice, not directly at the data source.

Microservices is a style of modular architecture. It’s data encapsulation at a service level.

Microservices is about functional slicing at the team and architecture level. This includes the UI level also.