Architecture for the future

Winfred Peereboom, w.peereboom@vnumedia.nl

Imagine this

You are in charge of the architecture

What are the requirements

A website for selling shoes

Site can handle a lot of traffic

Marketing must have good traffic insight

Connected to the backoffice for orders

Good uptime

Vague requirements…….. As always, we developers say

Many difference in definition of architecture

Information architecture

Application architecture

Software architecture

TheoryScalability

Modifiability

Simplicity

Reliability

Performance

Software Architecture in Practice by Len Bass, Paul Clements, Rick Kazman, Ken Bass.

Practice. Make our technology stack

Should do the job…

Conclusion so far..Theory is to vague to make a good selection in components

Just pick some hot stuff doesn’t feel good

Will I be really ready

for the future?

Still got some questions..

Who is going to maintain the components?

Do I really need so much functionality

What is the time schedule for this to implement?

How do I get everything under control?

Problems that you just don’t want to have

Let’s keep close to the facts

Development team

Sysadmin

Organization

Important criteriaMeet concrete requirements (if they are there)

Stable and in Repository

Knowledge available (documentation, best practises, internal/external development)

Learning curve for a component

Is the technology proven for my goal

How much do I use of the component functionality

The component selection

Meet recuiremtns

Stable version

Repository

Documentation

Accepted by developers

Internal indept knowledge

Sysadmin can maintain

External developers available

Proven technology

Hadoop, Hive -/+ - + - - - +/- - -Filelogging -/+ + + + + + ✔

VNU Media issues with Hadoop

No failover for Hadoop’s namenode

From PHP hard to append to Hadoop filesystem

Architecture for the near future

Things to keep in mind

There can be requirements that needs “state of art” components or even unstable, but be very very careful.

Focus on abstraction in code, so you can change

Keep track of updates of your components during development

Don’t let business requirements instantly change your mind about a component

Never stop experimenting with new tools and components, maybe it can make your architecture better in the future.

It’s better to create an architecture that lasts

for one year, than trying to create an

architecture that lasts for ten years.

Stefan Priebsch