Len Bass, Paul Clements, Rick Kazman
• •A thorough introduction to all aspects of software architecture •Shows how the knowledge and application of software architecture can help an organisation achieve the quality goals of its systems •The field of software architecture continues to grow, and this book is the leading introduction
I'm trying to come up with a checklist or set of questions/criteria to assess and evaluate proposed or emergent architectures (perform architectural reviews). What are the most important questions you ask when trying to plan, assess or review an architecture?
I know this is a large topic so I'd like to constrain it to a single end-to-end system and not the architecture for an entire organization.
Code Complete provides a decent starting point:
- Is the overall organization of the program clear, including a good architectural overview and justification?
- Are modules well defined, including their functionality and their interfaces to other modules?
- Are all the functions listed in the requirements covered sensibly, by neither too many or too few modules?
- Is the architecture designed to accommodate likely changes?
- Are necessary buy-vs.-build decisions included?
- Does the architecture describe how reused code will be made to conform to other architectural objectives?
- Are all the major data structures hidden behind access routines?
- Is the database organization and content justified?
- Are all key algorithms described and justified?
- Are all major objects described and justified?
- Is a strategy for handling user input described?
- Is a strategy for handling I/O described and justified?
- Are key aspects of the user interface defined?
- Is the user interface modularized so that changes in it won't affect the rest of the program?
- Are memory-use estimates and a strategy for memory management described and justified?
- Does the architecture set space and speed budgets for each module?
- Is a strategy for handling strings described, and are character-string storage estimates provided?
- Is a coherent error-handling strategy provided?
- Are error messages managed as a set to present a clean user interface?
- Is a level of robustness specified?
- Is any part over- or under-architected? Are expectations in this area set out explicitly?
- Are the major system goals clearly stated?
- Does the whole architecture hang together conceptually?
- Is the top-level design independent of the machine and language that will be used to implement it?
- Are the motivations for all major decisions provided?
- Are you, as a programmer who will implement the system, comfortable with the architecture?
I'm looking for practical knowledge with examples, e.g., what were the most painful points in an architecture you've created?
Some other points to consider:
Two good books for more ideas:
Anyone please suggest a good design and architecture book for .Net.
Is there any book I can refer to which has case studies, examples, etc. so that I can update my knowledge well in this field?
In case it's not available for .Net, please suggest in Java also.
Thanks in advance Swapna MC
Here's are a few good enterprise architecture books (based on Java, but the general concepts still apply):
A few of these patterns are a little old, but still useful to know.
If you're interested in WCF for a service-oriented architecture:
Or for framework design:
I would recommend this book: .NET: Architecting Applications for the Enterprise
Not a .net book, but the classic book here is Patterns of Enterprise Application Architecture
A good design book, period, is Martin Fowler's Patterns of Enterprise Application Architecture. Also a great design book is Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans.
Another useful book is Applying Domain-Driven Design and Patterns: With Examples in C# and .NET.
If you are interested in SOA, the true compendium of SOA was written by Thomas Erl:
I enjoyed Head First Design Patterns:
More design than architecture (obviously) but it makes heavy use of examples. Examples are in Java, btw.
Architectural approaches can vary greatly depending on what you're trying to build. I.e.- Architecting a specific software's internal's, or architecting a distributed system, etc.
For a given software program's internals, I like Patterns of Enterprise Application Architecture as a good reference.
I have also used the SEDA architectural style for some high throughput event-driven applications. The SEDA homepage has the original paper and references to other projects using this style. You might have heard of the Java Open Source projects: MULE and Apache Camel.
Also check out Enterprise Integration Patterns, which is a great companion book to PoEAA. This one pretty much helps you architect the interconnection between distributed systems. Lots of tools in this area... from XMPP to AMQP, to MULE, to JMS, etc.
And I have to suggest reviewing the REST Architectural Style since it is important in today's web software. There is a lot of material about REST, but primarily read (and reread) Roy Fielding's dissertation.
Here are some enterprise architecture books that contain case studies. They are not restricted to .Net, since at the architecture level many patterns and practices will apply irrespective of the specific platform choice:
Modern ESB Architecture for SOA By: Thomas Erl; Mark Little; Arnaud Simon; Thomas Rischbeck (Not yet published, expected 10/2009)
SOA Governance: The key to successful SOA adoption in your organization by Todd Biske (uses fictional case study)
In my point of view, design ability is harder to get than development/coding skills.
When confronting a requirement , how to design the function modules, how to construct the program architecture properly?
By the way, are there some books related?
Trial and error is the best way to see how your own designs can improve. Always look for a better solution. What mistakes did you make? What part was less flexible than it needed to be? What caused you to have to hack around a design decision you made?
Think about the implications of the design rather than purely it's flexibility and elegance. What trade offs have you made in order to make this reusable? Are you following the seperation of concerns and the single responsibility principle? Open closed principle? Do you know what these are and their implications?
Also study the work of experts in the form of design patterns.
However remember that these aren't magic bullet solutions and take everything with a pinch of salt. Use your own creativity and STAY PRAGMATIC.
I think it all comes down to experience. Being able to read a set of requirements and translate them into a good, clean, maintainable software design is one of the hardest thing in programming (imho) and you do not learn that just by reading a book. It's about trying, making mistakes, learning from those mistakes, and learning what designs have worked for you in the past or haven't.
For me, it often helps to really take my time and create a good design in UML, for example a class diagram. It often helps me identify and components that I can reuse throughout the software application, where I can use a certain design pattern, etcetera.
A few books I can recommend: Software Architecture in Practice, which is a very good book about software architecture, and Design Patterns by the Gang of Four, which is a great reference for any design patterns you might use.
Can you please suggest some books on Software Architecture, which should talk about how to design software at module level and how those modules will interact. There are numerous books which talks about design patterns which are mostly low level details. I know low level details are also important, but I want list of good design architecture book.
Please also suggest some books which talks about case studies of software architecture.
I think this is the book that came to mind when I first read this question. It talks about various architectural styles like pipes-and-filters, blackboard systems, etc. It's an oldie, and I'll let you judge whether it's a 'goodie'.
I also particularly like these two, especially the first. The second starts to dig into lower level design patterns, but it's still awesome in various spots:
I hope these are what you had in mind.
Where can you get knowledge about software architecture? One place is your experience building systems. Another is conversations with other developers or reading their code. Yet another place is books. I am the author of a book on software architecture (Just Enough Software Architecture) but let me instead point you to some classics:
That's just a short list and just because I didn't list something doesn't mean it's a bad book. If you are looking something free to read immediately, I have three chapters of my book available for download on my website.
I was just curious to know about how to become a good technical architect Or what are the things makes a Developer good architect. Please share your insights and articles.
Reading a book on C# syntax will not make you a good programmer, nor will reading a book on software architecture make you good at architecture. On the other hand, there were plenty of clever Roman engineers but any engineering student today can build things better than those Roman engineers. The difference is the knowledge that they can apply.
So where do you get knowledge about software architecture? One place is your experience building systems. Another is conversations with other developers or reading their code. Yet another place is books. I am the author of a book on software architecture (Just Enough Software Architecture) but let me instead point you to some classics:
That’s just a short list and just because I didn’t list something doesn’t mean it’s a bad book. If you are looking something free to read immediately, I have three chapters of my book available for download on my website.