Michael Nygard (author of the famous book “Release It!”) gave a talk about the steadily evolving nature of software architecture of a software system (and how to “surf on the wave of change”).
- There will be always a three-year plan for an architecture improvement program.
- But faster time to market is needed. The program will never finish because:
- The CTO gets changed
- A new technology emerges
- There is a business event (acquisition, merge etc.)
- So the three-year plan will be restarted every year until you go out of business (because you didn’t finish the architecture improvement program)
- The core problem is: The IT system change slower than the business requirements
- The best you can do are locally contextual actions!
- And accept that you’ll get not to an end state!
Recommendations for architectures without an end state:
- Embrace Plurality
- There is no single record of truth
- Epistemological challenges: We can only know what we can record.
- The model you use to view the world shapes the thoughts you are able to think (reminds me of Wittgenstein: “The limits of my language mean the limits of my world.”)
- Better approach: Multiple models of data in various systems with the possibility to get additional data (just like hyperlinks)
- This leads to multiple systems of records
- Otherwise: Who has the authority of which entries in a global object model?
- Contextualize Downstream
- “downstream”: the way from the first backend to the customer’s frontend
- Downstream systems can add information to the upstream’s data
- Beware of rich upstream models because there will be many changes downstream if these models are dependent on the upstream model and this model changes
- Better approach: Multiple objects with specialized attributes with a shared common identifier
- Enterprise architects need to spend most of their time to determine what the “shared information” are.
- This includes working out what the representations are going to be used between the various systems
- But more about the information interchange instead of defining Java versions and middleware platforms!
- Consumers have to recognize that there is an open world of information
- Business rules are contextual
- A system decides if it knows enough to process a request with the given business rules; localize the knowledge
- Argument data in upstream: You can add fields, but avoid relationships (which are highly contextual and will change often). Otherwise, there will be a large surface area of change.
- Upstream data are used in business rules that are faced towards the user. These will change more often (whereas rules about augmenting the data change the least often)
- General rule: Reduce the number of entities a system needs to know about.
- Beware Grandiosity
- Avoid enterprise modeling attempts / global object models / enterprise data models
- Most of these project start but never finish
- Problems / Challenges
- You need a global perspective (that is not available because of the contextualized systems)
- You need agreement across all you business units
- You need a talent of abstraction
- You need concrete experience in all contexts
- And a team that is smart enough, to make local decisions (with the global perspective)
- Because that’s not possible, you’ll make compromises all the time anyways (which degrades the overall quality of the global object model)
- A better approach:
- Seek compromises and subsets everybody can agree on
- Assume an open world that can be extended anytime
- Start small with tiny steps to expand the representations
- Allow lengthy comment periods (with plenty of email reminders because nobody wants to communicate)
- Advantages are, that you’re able to explore
- the (contextual) market space
- a better/concrete solution space
- Transparency: Methods, work and results must be visible
- Isolation: One group’s failure is not able to cause a widespread damage
- Economics: Distributed economic decision making: Everybody is allowed to make local decisions (=local optimizations) that are in alignment with the global goal
- Misconceptions: “Centralizing IT is a leverage”
- You’ll get budget fighting instead
- Misconceptions: “Centralizing IT is a leverage”
- Isolate failure domains
- Especially in operations: isolate our system from upstream dependencies
- Data outlives Applications
- You’ll have to migrate your data to another system
- Applications outlive Integration
- The integrations with other systems will change
- Build a hexagonal architecture: all systems are connected via explicit boundaries (this makes communication a boundary instead of a domain layer problem)
- Increase Discoverability
- Project have many things in common but you don’t know it
- Do the same things that open source projects do:
- Internal blogs
- Open code repositories
- Modern (source code) search engines
- “Internal teams should work like open source projects.”
- Beware: “Budget Culture”
- Otherwise, contributions to projects are perceived as disruptions
- Inquiries are alarming because people start to think that there is something wrong with their project
- Better: “Engineering Culture”:
- Open sharing
- Every application should have links to:
- team blog
- bug submissions
- CI server
- This can be done in a grass root organization
Overall an inspiring talk with great ideas on how to improve software development on an organizational level.
Podcast about the topic (with focus on resilience): https://devchat.tv/ruby-rogues/217-rr-architecture-without-an-end-state-with-michael-nygard
Michael Nygard – Architecture Without an End State