Worst Case Architecture
I've spotted a (worrying) trend amongst architects over the last couple of years. Whenever designing a new system, there's a tendency to spot the potential for a change in requirements in the future that would negatively impact the system, then design that in from the start. This is what I've termed "worst case architecture". Where rather than designing a system that is either inherently flexible or cheap enough that throwing it away isn't a great loss, the architect becomes a seer, predicting what s/he thinks would have the most costly impact, and designing it in from the start. This is the cause of several problems:
- It inherently makes the system cost more as features are only ever added, never taken away
- It designs undesirable features into a system from the start
- It forces long term strategic decisions to be made based on presumptions, rather than with all the facts
- It regularly forces the company down that undesired path as ROI is needed on the expenditure
There's a great example of this I've seen in the course of my employment. The company in question's long term strategy was to migrate everything to .NET. However, there was a supposition that the current Java container would not suffice if ever the decision was made to bring in out-of-the-box Java based solutions for certain parts of the enterprise. This led to the decision to replace the NAS layer that was currently in place (and which was to be disposed of) with a full WebSphere implementation. Obviously, once that was implemented there would be a need to get a positive ROI on it, leading us down the route of buying in/developing Java systems, de-railing the long-term strategy.
I've spotted occurences of worst case architecture at all levels - small facets within applications as well as enterprise wide strategic decisions; it can crop up in the design of any system. This has led me to the following mantra whenever I'm architecting a system:
- Positive features should be designed in
- Negative features should be designed out
So, what's the alternative? As discussed in another 'Blog entry I'll be posting soon, I'm a believer in JIT (Just-In-Time) Architecture or "Architecture on Demand"... where you purposely don't design something until you hit the point of needing it, choosing rather to compartmentalise and encapsulate functionality. After all, that's one of the benefits of SOA, right? To me, a large part of the reason for having an architect is that they should have "been there and done that", or at least be able to relate to a similar situation, stopping such undesirable end-points from ever being reached, rather than expediting them!