Architecture, according to the book (which draws from other sources as well), is:
Software architecture is the high-level part of software design, the frame that holds the more detailed parts of the design.
S. McConnell, Code Complete, second edition. Redmond (Washington): Microsoft Press, 2004.
Now that’s out of the way, let’s talk about how we can make sure that the architecture that’s laid out for our projects is good, since that’s what this chapter is all about. If your architecture is off at this stage, you’ll have to make the changes when you’re in the construction stage… That makes them a lot more difficult to solve, because you’ll likely have to move other things that you’ve already built around as you make the changes.
If you’re working on a system that was architected by someone else, you should be able to find the important components without a bloodhound, a deer-stalker cap, and a magnifying glass.
S. McConnell, Code Complete, second edition. Redmond (Washington): Microsoft Press, 2004.
The important parts of your architecture should be clearly visible. If it’s not clear why a class or component exists, or why it was chosen over other alternatives, then it’s possible it needs to be better defined.
Architectural Components
I was originally going to outline the different components and give a few details on each, but then I realized I’d mostly just be paraphrasing the book. Since there’s no need to do that, here’s a list of the architectural components, along with some of my associated thoughts.
- Program Organization
- Major Classes
- Data Design
- Business Rules
- User Interface Design
- Resource Management
- Security
- Performance
- Scalability
- Interoperability
- Internationalization & Localization
- Input/Output
- Error Processing
- Fault Tolerance
- Architectural Feasibility
- Overengineering
- Buy vs. Build Decisions
- Reuse Decisions
- Change Strategy
- General Architectural Quality
Now, it seems to me that a lot of these, such as the User Interface Design, depend a lot on the type of development that you’re going for. If you’re developing in a waterfall-style approach, then it’s great to have it fully defined upfront. However, I think that most modern software development occurs much more iteratively – so perhaps these should all be thought of in shorter iterations.
If you’re developing using an ‘agile’ approach, it seems like it’d make sense to have these things laid out at the beginning of a sprint. But it all depends on the approach you’re using. I know I’ve never used a strict agile methodology, so you have to apply this where you see fit.
This is covered a bit in the ‘Change Strategy’ point, but I still don’t feel like it fully addresses more iterative development approaches. It’s possible I’m just missing something, though.
Conclusion
Anyway, the point is that for any development, you definitely should have at least a basic architecture in place. Even if you’re developing iteratively, think through the things in the list above so that you can define an overview of the system before you put your fingers to the keyboard & start coding.
It shouldn’t look as if the problem and the architecture have been forced together with duct tape.
S. McConnell, Code Complete, second edition. Redmond (Washington): Microsoft Press, 2004.
Leave a Reply