Software Architecture
Software Architecture is a very broad term with many accepted usages and meanings. We will describe here the main objectives of architecture as we see them. Designing and applying software architectures is something that comes with experience, so we will avoid any attempt to provide a comprehensive how-to guide. We will give some of the basics that we use, and provide references to additional resources.
A good Software Architect will not just wheel out the latest, greatest so-called best practice. They will understand the development team, the environment, and the business objectives of the customer and development organisation, and design an architecture to meet those requirements.
Objectives of Software Architecture
- Leverage existing assets, be they existing systems, existing components that we have written, assets provided by our deployment platform(s), or third party assets that we acquire.
- Reduce the impact and cost of changes to requirements, constraints, and environment.
- Reduce the cost, variabililty, and uncertainty of development
- Manage complexity
- Provide a comfort-zone for designers and developers through consistent terminology and practices
- Provide scaleability
- Support and encourage systematic reuse
Some Ways to Meet the Objectives
- Use and document consistent patterns for, and approaches to the application of the principles of abstraction and encapsulation.
- Find third-party patterns and libraries that meet you business', team's, and environment's constraints and objectives.
- If an existing asset only has an 80% fit, and cannot be modified, then consider putting an abstraction layer around it and building the other 20% (unless you can find another cost-effective asset with a better fit)
- If an existing asset works, but has maintainability/supportability risks, then quarantine it behind an abstraction layer and use it. Then deal later with the maintainability/supportability issues through refactoring, replacement, or whatever other approaches meet your objectives.
- Consider the use of layered or service-oriented architectures. They have broad applicability to most business problems.
- Build extensible frameworks, but don't extend them until you need to. Just create the extension points with "Not yet implemented" roadblocks, so that when the extended features are needed, it is obvious where they belong. At least 85% of the effort of the current iteration should be spent on functionality that is required to meet the objectives of the current iteration or the next one or two.
Additional Resources
Online
- 'Software Architecture' Site, Carnegie Mellon Software Engineering Institute.
- 'Resources for Software Architects' site, Bredemeyer Consulting
- Eeles, P. 2001, 'Capturing Architectural Requirements', The Rational Edge, November 2001
- Fowler, M. 2003, 'Who Needs an Architect?', IEEE Software, July/August 2003
- Kruchten, P. 2001, 'Common Misconceptions about Software Architecture', The Rational Edge, April 2001
- Kruchten, P. 2001, 'The Tao of the Software Architect', The Rational Edge, March 2001
- Reed, P. R., Jr. 2002, 'Reference Architecture: The Best of Best Practices', The Rational Edge, September 2002
