Database Reference
In-Depth Information
porate), you could implement special predicates to indicate which one is to be used in a
particular business case and when others should be suppressed. You can really dedicate
some time to these tasks so that developing and adapting your components is not so bur-
densome.
Our tactical goals have been well achieved. All that's left is to explain to your CIO why
the consolidated IT costs after three years of tactical architecting are almost equal to cor-
porate revenues.
If you think the presented scenario is a bit artificial, please suspect not. On the contrary,
some unnecessary technical details had been omitted to make it less chilling. However, we
would like to make one thing clear: we are not against tactical goals at all; they are chunks
of iterative development and essential parts of SCRUM sprints. We just believe that tactic-
al goals and benefits must be a native part of some bigger strategy; otherwise, you could
win a battle or two but lose the war very badly. The temptation to achieve your target in-
stantly by buying another magic pill is always high but usually leads to a spaghetti-like in-
frastructure. In best case scenarios, you will get a lasagna-style infrastructure if your in-
tegration efforts are consistent (another term for expensive). So now, we are going to dis-
cuss the principles that could make our strategy capable of supporting declared goals and
characteristics.
Search WWH ::




Custom Search