Rockford Lhotka - Achieving Balance

Topic: How do we deal with the rate of change in technologies?
How can you have mental model to deal with the rate of change without loosing your mind?

Vendors pushes changes in technologies (e.g. WinForms replaced by WPF)
Customers also pushes changes (e.g. why can we not have better analysis capabilities? why does our client software look so bad when my phone looks so cool?, why is changes costing so much money?)

It is our job to find the path to find the path to the perfect result.

The reality is that "perfect" means "good enough".

We have a myriad of choices
- Client/server vs SOA
SOA used to create client/server systems is very expensive
- Smart client vs RIA vs Web
- ADO.NET vs DataSet vs ORM
- Code vs Workflow/modeling
- OO: Data centric vs Behavioural

The Vendors deliver new technologies and "forces" users to keep up the pace and replacing old (but working) technologies.

There are also broader things with potentially bigger impact, e.g. Oslo that predicts a whole new concept of what is involved in developing applications.

Advice: Separate the job from the Task
- Being and architect (hard)
- Architecting software (should not be hard)

Maintaining control:
- Keep the faith
Define the technical vision
Define your technical goals
Define your application goals

Align to the vision and goals

- Keep it simple
Complexity is the enemy
Silver bullets breed complexity
Technologies have a cost - make sure the benefit outweighs the cost
Avoid "golden hammer" anti-pattern
(CAB is mentioned as an example of an "overly complex" solution)

-Plan for the worst, expect the best
"Will technology X really deliver?"
"Will I have a consistent team?"

- You can't get something for nothing
Frameworks have consequences (good and bad)
Patterns have consequences (good and bad)
Architectures have consequences (good and bad)

Do your consequences align with your goals? Always assess cost versus benefit.

- Be a laggard (=someone ho stays behind)
Type A - Bleeding edge - uses beta versions
Type B - Waits for SP1 - upgrades to keep up
Type C - Waits for V3 - upgrades to maintain support

- Don't build frameworks

- Do have an architecture
This is the most critical point..
- that exists in service to vision/goals
- that anticipate future needs
- that transcends application design
- that limits options
- that provides focus and discipline

Remember: Architecture is NOT the same as design. Architecture spans applications.




My takeaway: Interesting topic, but the talk did not give much new information. The issues for architect/architecture is still the same, and no really new insight into how to manage it was given. Nice to know that others struggle with the same issues as I feel myself though :-)