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 …