Architecture

  • 37 Things One Architect Knows About IT Transformation: I read this & quite enjoyed it, in part because Hohpe is an engaging writer & he picks on big organizations a lot. But note the "About IT Transformation" in the title. Much of the material here is about how to get big old-economy companies to adopt more agile methods of work, and only tangentially about architecture – except inasmuch as he views the Chief Architect as a key agent of change. (Reviewed by Mike Gunderloy)
  • Building Evolutionary Architectures: There are a lot of good points here about how to build large software systems that can withstand business change - though more of the points seem to be about what NOT to do. The actionable advice is a somewhat smaller piece of the book. The best part is the reminders that monoliths are not always bad; there are tradeoffs to be made. Ford has sweeping experience across many software trends, and it's nice to see microservices placed in the broader context. (Reviewed by Mike Gunderloy)
  • Building Maintainable Software
  • Design It!: I enjoyed this introduction to software architecture, while recognizing that it's clearly one architect's view and that there are a lot of conflicting definitions in the field. This one at least was refreshingly close to the software design activities I already know from a career of programming, rather than being an "enterprisey" muddle of vague generalities. (Reviewed by Mike Gunderloy)
  • Guerilla Capacity Planning: An introduction to capacity planning in a land of fast change and imperfect information - though note that for Gunther "fast" is a 3-month planning horizon, so it's hard to integrate this into the agile world. Focuses mainly on basic scalability laws, the difference between the parallelizable portion of the work and the rest, and shows applications in a variety of areas from program decomposition to internet scaling. Lots of math interspersed with smartass comments, the latter helpfully collected in an appendix so you don't have to wade through the math. (Reviewed by Mike Gunderloy)
  • Just Enough Software Architecture: A good introduction to the practice of software architecture for any reasonably-seasoned developer. The key takeaway here, and a point that Fairbanks hammers on early and often, is that the amount of modeling you should do is proportional to risk. There are no points for endless reams of documentation that no one ever reads in pursuit of "completeness." He uses mostly (the simpler parts of) UML to demonstrate basic modeling concepts, and provides plenty of standard tools to get started. I don't know a better text for the budding architect. (Reviewed by Mike Gunderloy)
  • Patterns of Enterprise Application Architecture
  • Software Systems Architecture: A solid textbook for developers already somewhat familiar with architectural thinking. It takes a views, viewpoints, and perspectives approach. While it does have an extensive catalog of the most important artifacts in each of those categories, it also has extensive sections on the process of being an architect, from coming up with the business goals and engaging stakeholders through creating and validating the architecture. Somewhat heavy sledding in spots and not really concerned with the "agile" world but a valuable reference. (Reviewed by Mike Gunderloy)
  • Software Architecture for Developers: A developer-centric view of architecture that spends quite a bit of space exploring the tension between agile and BDUF approaches. Personally I'm a fan of more up-front design than many agile teams, which may just mean I'm getting old. In the end I appreciated the multiple perspectives on the multi-faceted architect's role here. Maybe I still have enough career time left to be an architect when I grow up. (Reviewed by Mike Gunderloy)

results matching ""

    No results matching ""