Evo Principle 6:
Evo projects will require an
open architecture - because we are going to change project ideas as often as we need to,
in order to really deliver value to our stakeholders |
Discussion:
Open architecture means 'easy to change'. This can
include many 'technological enablers', for many types of change. If you want to optimize
your product for long term performance (and consequent survival) under conditions of
change, you have to be conscious about your product architecture objectives and design
specifications.
The bad news is that this is best done initially. The good
news is that there are often add on interfaces for tired old legacy systems that do some
useful 'opening up' for you.
We have to be flexible to respond, during a project, to the
insights we get from stakeholders - the 'unexpected' requirements. We have to be able to
deliver those requirements immediately without compromising system performance. That is
what we need the open architecture for.
All systems need intelligent open architecture in the long
run. Evo projects need it in the short term - during the project. The good news is that if
you have not done the open architecture well enough - the Evo step feedback will often
force you to acknowledge your poor architecture - and you will get the opportunity to
improve the architecture immediately. If you were not motivated before, you will see the
payoff and bite the bullet.
Better to get that great architecture fairly early
than too late.
| Example: |
 |
| 'Because some design issues are cheaper to
resolve through experimentation than through analysis, Evo can reduce costs by providing a structured, disciplined avenue for
experimentation.' |
| Elaine L. May and Barbara A. Zimmer, HP Journal
August 1996. |
|
| |
| 'During December, detailed coding of the
individual modules started. But the IE3 team was still making decisions about the
overall product architecture - decisions that would not only affect the features in
the final product but also the development process itself. A team member explained, 'We
had a large number of people who would have to work in parallel to meet the target ship
date. We therefore had to develop an architecture where we could have separate
component teams feed into the product. Not all of these teams were necessarily inside the
company. The investment in architectural design was therefore critical. In fact, if
someone asked what the most successful aspect of IE3 was, I would say it was the
job we did in 'componentizing' the product.' |
| Alan MacCormack, How Internet Companies
Build Software, MIT SLOAN Management Review, Winter 2001, about Internet Explorer 3.0
development. |
|