Defining Software Architecture
Prof. Cesare Pautasso
http://www.pautasso.info
[email protected]
@pautasso
Who is a software architect?
Facilitate Communication
Software Engineering Lead
- Excellent Software Engineering Skills
- Promote good development practices
- Solve the hard problems
- Lead technical development team by example
- Understand impact of decisions
- Defend architectural design decisions
- Plan and manage software releases
Technology Expert
- Know and understand relevant technology
- Evaluate and influence the choice of 3rd party frameworks, components and platforms
- Track technology evolution
- Know what you do not know
Risk Management
- Estimate and evaluate risks associated with design options and choices
- Document and manage risks, making the whole team aware
- Prevent disasters from happening
Software Architecture and the Software Development Lifecycle
Waterfall Model
- Requirement Analysis
- Design
- Implementation
- Testing
- Maintenance
Bridge the Gap
Think Outside the Box
Peter Cripps
Evolutionary Model
John Reekie, Rohan McAdam
Agile Unified Process
Scott Ambler
Avoid Big Upfront Design, just enough Architecture
System Lifecycle
John Reekie, Rohan McAdam
Defining Software Architecture
Architecture vs. Code
Grady Booch
- Every system has an architecture
- Some architectures are manifest and visible, many others are not
- A system's architecture ultimately resides in its executable code
- A system's architecture may be visualized and represented using models that are somehow related to the code
Architecture vs. Technology
Grady Booch
- A given technology only serves to implement some dimension of an architecture:
- The network is part of the architecture
- The database is part of the architecture
- The .NET framework is part of the architecture
- J2EE is part of the architecture
- Architecture is more than just a list of products that are used in a project
- Technology shapes an architecture, but a resilient architecture should never be bound to all of the technologies that form it (technology changes too fast)
Architecture vs. Design
Peter Cripps
Basic Definition
N. Taylor et al.
- A software system’s architecture is the set of
principal design decisions made about the system. - It is the blueprint for a software system’s construction and evolution
Design Decisions
Design decisions cover all aspects of the system:
- Structure
- Behavior
- Interaction
- Deployment
- User Interface
- Implementation
Principal Design Decisions: the "important ones" depending on the goals of the stakeholders
Design Decisions
- Decisions are made over time
- Decisions are changed over time
- Decisions depend on other decisions
- Decision are made by more than one person
Modeling Architecture
Grady Booch
- Static:
- Structure
- Decomposition
- Interfaces
- Components
- Connectors
- Dynamic:
- Behavior
- Deployment
- Patterns
- Design Process:
- Constraints
- Rationale
- Dependencies
- Quality Assurance
- Team Organization
- Target Audience
- Technical Developers
- Marketing/Customers
- Management
Can this skeleton fly?
Prescriptive vs. Descriptive
N. Taylor et al.
Green Field Development
At the beginning, systems designed and implemented from scratch only have a prescriptive architecture
Brown Field Development
Systems developed reusing existing components already have a descriptive architecture (and may have an empty prescriptive architecture)
Architectural Degradation
Causes of Architectural Drift
N. Taylor et al.
From Drift to Erosion
N. Taylor et al.
Entropy
Architecture or Code First?
George Fairbanks
Architecture Hoisting
George Fairbanks
- Design the architecture with the intent to guarantee a certain quality of the system.
- Developers can focus on coding the functionality while the architecture design constraints achieve the guaranteed non-functional requirements.
- Examples:
- Security: place sensitive data behind the firewall
- Scalability: make critical components stateless
- Persistence: use a database
- Extensibility: design/reuse a plug-in framework
Presumptive vs. Reference
George Fairbanks
- A Presumptive Architecture is the default architecture for a given application domain.
- Architects need to justify variations from it
- Example: 3-Tier architecture for Web applications
- A Reference Architecture is predefined for a given application domain with explicitly defined variation points.
- Architects can choose among many reference architectures and need to justify their choice
Solution vs. Product
Olaf Zimmermann
A solution architect solves the problems of one customer by designing a solution architecture made of multiple products that are integrated and reused as components
A product architect designs one product architecture that can solve the problems and satisfy all the requirements of multiple customers
M-Architecture vs. T-Architecture
Luke Hohmann
Marketing Architecture
- Describe how to market and sell (business model, licensing model) the system to customers
Technical Architecture
- Prescribe how to build deploy and configure the system (styles, patterns, components, connectors)
The $10000 boolean flag
Marketing Architecture
2 "different" Products:
Technical Architecture
- For multiple “products” there can be a single technical architecture and a single codebase.
- Simple Configuration Flags can be used to switch between the different M-architectures perceived by customers
Art or Science?
Grady Booch
- The “artistic” part of software architecture is minimal
- Creativity, Originality and Aesthetics are less valued than Feasibility, Viability and Fitness to a purpose.
- Even the best architects copy solutions, styles and patterns that have proven themselves in practice, adapt them to the current context, improve upon their weaknesses, and then assemble them in novel ways with incremental improvements.
- An architectural process can be established with intentional artifacts, clear activities, and well-defined project management milestones
Science or Art?
Grady Booch
- There exists only a modest body of knowledge about software architecture
- Scientific and analytical methods are still lacking - those that do exist are hard to apply in practice
- There is no perfect design: architecture involves the management of extreme ambiguity and contradiction
- Experience counts: the best architects are grown, not born
References
- George Fairbanks, Just Enough Software Architecture: A Risk Driven Approach, M&B 2010
- Richard N. Taylor, Nenad Medvidovic, Eric M. Dashofy, Software Architecture: Foundations, Theory and Practice, John-Wiley, January 2009
- Luke Hohmann, Beyond Software Architecture: Creating and Sustaining Winning Solutions, Addison-Wesley, February 2003
- Ian Gorton, Essential Software Architecture, Springer, April 2006
Use a spacebar or arrow keys to navigate