This is the first article that shows how a team architects a software solution for a real customer. I particularly enjoyed how it starts off by thoroughly describing the problem domain and the workflow for producing high-quality pictures. With this in mind, the team was able to focus on only those architectural facets that were relevant to their problem-space as opposed to making assumptions about what the product solution will need, which would be wasteful. Figure 4-1 on page 64 pretty much sums it up.
A benefit of reading an article like this is that it introduces me to existing concepts, technologies, and tools that could be useful when architecting a future project. For example, the mention of Spring and OSGi frameworks (can be used for encapsulating & declaring module dependencies) sparked my curiosity to learn more about them. And I can consider using Graphviz and Java NIO for a current project at my job.
One of the things that stood out was that the author's team from Advanced Technologies Integration (ATI) used Lean Software development. According to Wikipedia, it is "a translation of lean manufacturing principles and practices to the software development domain." Manufacturing principles can applied in the software domain? Six months ago, I attended a Lean Six-Sigma course but the instructor was unable to provide concrete examples of how this is applied in the software world. It turns out that Lean Software Development is a form of Agile that makes use of these principles but just calls them differently. For those that are interested, here are some examples from Wikipedia:
Waste in Software Development
* unnecessary code and functionality
* delay in the software development process
* unclear requirements
* bureaucracy
* slow internal communication
Lean Software Development Tools
* Seeing waste
* Value stream mapping
* Set-based development
* Pull systems
* Queuing theory
* Motivation
* Measurements
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment