Upload
iasa-uk
View
86
Download
0
Embed Size (px)
DESCRIPTION
Iasa UK Ignite presentation from Chris Cooper-Bland, Endava
Citation preview
Chris Cooper-bland
10/09/2012
Architecting – Possible?
In most projects, even agile, you have to do some formal Architecture, the question is how much?
Just Enough Architecture
If you don’t, you might end up with
the Vasa
Sank on maiden voyage of less than 2Km – added new deck after hull had been built
Want to avoid BUFD – or being sick
But can you know how much is “Just enough”
*Making decisions
*Documenting decisions
*Communicating decisions
The key activities in doing Architecture
Each project is different
What factors in a project influence the amount of these activities needed
* Spoke to architects – not those ones
* Looked at some papers/books e.g. Royce
Informal Research identified following factors
a large number of distinct functions mean more time should be spent on developing a loosely coupled, highly cohesive set of components.
Functional requirements
The more challenging the constraints, such as: cost control, schedule, resourcing, team distribution, means the architecture needs to be more explicitly understood for planning.
Business constraints
The presence of mandated technologies means these must be explicitly accommodated in the architecture.
Technical constraints
The more challenging the performance, scalability, and the distribution of the system are means there are greater architecturally significant risks which need to be addressed early in the project.
Runtime qualities
Things like maintainability and portability must be addressed before development starts in earnest otherwise extensive re-factoring will be required.
Non-runtime qualities
The larger the team means the architecture must be clearly documented to prevent misunderstandings
The size of the development team
The newer the system, either form a technology or business perspective means that there will be greater emphasis on prototyping.
The novelty of the system
the process being followed may mandate architectural activities and artifacts, this may be a customer requirement.
The method being followed
the longer the anticipated lifetime of the system the more cost effective spending time on defining and describing the architecture becomes
Target lifetime of the system
Group into
*Size and Longevity
*Complexity Factors
The factors work together -
Size and Longevity
System Complexity
Loads of Architecture
*Making decisions
* Documenting decisions
* Communicating decisions
- to impact on the architecture activities
Two projects with different factors
Can we visualise this?
Thank-you!
Discussion …