Enterprise Architecture

Lets say there's a development requirement to treat data differently if a date in a db row is before May 1, 2011. Specifier swears a blood oath that that date will never change.

So you can:

if someDatabase.myDataField < 05/01/2011 ...

But if you have a little experience with specifier's blookd oaths, you know that can't be counted on so you do:

GlobalSingletonObJect file:
myGlobalSingletonObject.splitDate = 05/01/2011

In some code elsewhere:

if someDatabase.myDataField < myGlobalSingletonObject.splitDate ...

And if that same rule gets applied elsewhere, all relevant statements refer to the global object property setting, not a bunch of literals buried in code.

Okay, we all know that. Already.

But now imagine the same concept being applied to an entire enterprise architecture. So that the ability for the business to change course, speed up, and extend itself is built into the enterprise architecture design.

This kind of scalability can be done without a lot of excess expensive foundation work, because only the possiblity of change is built into the applications, platforms, vendor selections, requirements, databases, hiring, etc.

Allowing for change can be architected almost for free - except you have to pay the architect :) . And I did say "almost", so maybe it could have a 3 - 5% add-on cost.

Like when you name a file, device, version, or etc. like this:

myplan.txt

or better:

myPlan1.txt

or

myPlan01.txt

but of course myPlan00001.txt is a waste of keystrokes, but by how much?

Same thing but with the overall architecture of information technology for a company or product.