Lessons Learned as an architect
- negotiation and political skills are sometimes, and most often, more important as an architect than technology skill
- It’s all about the data
- The world’s best architectures are not the perfects ones, but rather the feasible ones.
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
- Application
- Techniques for change
- patterns & anti-patterns
- tools & documentations
- Integration
- overview
- architectural styles
- Enterprise
- introduction to enterprise architecture
Architecture cross-cutting concerns
- Soft Skills
- Continuous Delivery
- Understanding large codebases
Soft Skills
Expectation of an Architect
- Analyze technology, industry, and market trends and keep current with those latest trends.
- 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.
- Ensure compliance with the architecture.
- This is an ongoing responsibility of an architect.
- Having expose to multiple and diverse technologies, platforms and environments.
- Possess exceptional interpersonal skills, including teamwork, facilitation, and negotiation
- define the architecture and design principles to guide technology decisions for the enterprise.
- Don’t dictate specific technology choices.
- 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