In a prior post I talked about how important it is to “slice the work vertically” and not to get lost in BDUF land. In general, I think architecture needs to be “right sized” to the project. A teeny app needs little or no real “architecture planning” a huge app certainly needs some. The trick is not to think you can do BDUF for real, you just hide work and make the other BDUF believers “feel comfortable”.

I am certain in my current role that people think I am “a classic agilist” ready to run off and work with no longer term vision, plan, agenda. If we do that, we will surely get into a bad place is the criticism.

• I believe that NOT writing tests
• Not acknowledging technical debt and addressing it
• Not time boxing
• Delivering infrequently to the cleints
• Inexperienced developers/ naieve assumptions

These are the primary things that make you “get in a bad place in the future”. Certainly – refactoring on the enterprise scale costs lots of $ as you are forced to change lots of nodes/ components/ layers. Limiting the scope of refactoring is very important at the enterprise level.

Blah, blah, blah – so what is this architecture business and how do we do it? I have been using this simple model:

The plinko architecture formula

• Prior art (someone did something like this in the past)
• Vision (if we had this XXX, then all these other problems would go away)
• Collective experience of the team
• Well known components (we KNOW we will be using our corporate XXX service/ component/ etc)
• +
• Development Spike (time box, rapid prototype 10 ways to solve each problem)
• =
• “Ballpark architecture”

This set of stuff defines the “buckets” at the bottom of our “plinko board”- our “ballpark architecture”. We then take our features and while we implement them, we let the parts of our solution fall into our architectural buckets. This lets us have a set of basic working models, yet our architectural implementation evolves alongside the actual problem, not in a silo!!!

I am a HUGE believer in “co-evolution” of frameworks/ architectures evolving WITH the problems they solve. Building entire frameworks and architecture models detached from real problems just delays the learning. You learn on the day you start to USE the framework/ architecture model where you were wrong, what inconsistencies you have and what you REALLY need.

So – my 2 cents is – do not build in a silo. Use the Plinko architecture formula above for your basic architecture approach….

-Chris

Comment on this post below

You must be logged in to post a comment.

You can leave a response, or trackback from your own site.