Contribution 0 - Revision history

Rmonson at 04:04, 10 May 2008

Rmonson — Sat, 10 May 2008 04:04:05 GMT

←Older revision		Revision as of 04:04, 10 May 2008
Line 6:		Line 6:
	Yet we see software architects try to design systems that will be, for lack of a better term, "future proof" all the time. It’s simply not possible to future proof an architecture. No matter what architectural decision you make now, that choice will become obsolete eventually. The cool programming language you used will eventually become the COBOL of tomorrow. Today’s distributed framework will become tomorrows DCOM. In short, today’s solution will always be tomorrow’s problem.		Yet we see software architects try to design systems that will be, for lack of a better term, "future proof" all the time. It’s simply not possible to future proof an architecture. No matter what architectural decision you make now, that choice will become obsolete eventually. The cool programming language you used will eventually become the COBOL of tomorrow. Today’s distributed framework will become tomorrows DCOM. In short, today’s solution will always be tomorrow’s problem.

-	If you accept this fact that the choices you make today will most certainly be wrong in the future, than it relieves you of the burden of trying to future proof your architectures. If any choice you make today will be a bad choice in the future than don’t worry about what the future will hold, choose the best solution that meets your needs today.	+	If you accept this fact, that the choices you make today will most certainly be wrong in the future, than it relieves you of the burden of trying to future proof your architectures. If any choice you make today will be a bad choice in the future than don’t worry about what the future will hold, choose the best solution that meets your needs today.

	One of the problems architects have today is analysis paralysis and a big contribution to that problem is trying to guess the best technology for the future. Choosing a good technology for right now is hard enough, choosing one that will be relevant in the future is futile. Look at what your business needs now. Look at what the technology market offers now. Choose the best solution that meets your needs now because anything else will not only be wrong choice tomorrow, but the wrong choice today.		One of the problems architects have today is analysis paralysis and a big contribution to that problem is trying to guess the best technology for the future. Choosing a good technology for right now is hard enough, choosing one that will be relevant in the future is futile. Look at what your business needs now. Look at what the technology market offers now. Choose the best solution that meets your needs now because anything else will not only be wrong choice tomorrow, but the wrong choice today.

Rmonson at 04:03, 10 May 2008

Rmonson — Sat, 10 May 2008 04:03:26 GMT

←Older revision		Revision as of 04:03, 10 May 2008
Line 4:		Line 4:
	No one can predict the future. If you accept this as a universal truth, than the question becomes how far ahead is the future? One decade? Two years? Twenty minutes? If you can’t predict the future than you can’t predict anything beyond right now. This very moment and the ones that preceded it are all you are know until the next moment occurs. This is the reason we have car accidents – if you knew you were going to have an accident on Thursday you would probably stay home.		No one can predict the future. If you accept this as a universal truth, than the question becomes how far ahead is the future? One decade? Two years? Twenty minutes? If you can’t predict the future than you can’t predict anything beyond right now. This very moment and the ones that preceded it are all you are know until the next moment occurs. This is the reason we have car accidents – if you knew you were going to have an accident on Thursday you would probably stay home.

-	Yet we see software architects try to design systems that will be, for lack of a better term, future proof all the time. It’s simply not possible to future proof an architecture. No matter what architectural decision you make now, that choice will become obsolete eventually. The cool programming language you used will eventually become the COBOL of tomorrow. Today’s distributed framework will become tomorrows DCOM. In short, today’s solution will always be tomorrow’s problem.	+	Yet we see software architects try to design systems that will be, for lack of a better term, "future proof" all the time. It’s simply not possible to future proof an architecture. No matter what architectural decision you make now, that choice will become obsolete eventually. The cool programming language you used will eventually become the COBOL of tomorrow. Today’s distributed framework will become tomorrows DCOM. In short, today’s solution will always be tomorrow’s problem.

	If you accept this fact that the choices you make today will most certainly be wrong in the future, than it relieves you of the burden of trying to future proof your architectures. If any choice you make today will be a bad choice in the future than don’t worry about what the future will hold, choose the best solution that meets your needs today.		If you accept this fact that the choices you make today will most certainly be wrong in the future, than it relieves you of the burden of trying to future proof your architectures. If any choice you make today will be a bad choice in the future than don’t worry about what the future will hold, choose the best solution that meets your needs today.

Rmonson at 04:40, 8 May 2008

Rmonson — Thu, 08 May 2008 04:40:09 GMT

←Older revision		Revision as of 04:40, 8 May 2008
Line 15:		Line 15:
	This work is licensed under a		This work is licensed under a
	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]		[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
		+
		+

	Back to [[97 Things Every Software Architect Should Know]] home page		Back to [[97 Things Every Software Architect Should Know]] home page

Rmonson at 04:39, 8 May 2008

Rmonson — Thu, 08 May 2008 04:39:52 GMT

←Older revision		Revision as of 04:39, 8 May 2008
Line 12:		Line 12:

	By [[Richard Monson-Haefel]]		By [[Richard Monson-Haefel]]
		+
	This work is licensed under a		This work is licensed under a
	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]		[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]

	Back to [[97 Things Every Software Architect Should Know]] home page		Back to [[97 Things Every Software Architect Should Know]] home page

Rmonson: /* Today's solution is tomorrows problem */

Rmonson — Thu, 08 May 2008 04:39:35 GMT

Today's solution is tomorrows problem

←Older revision		Revision as of 04:39, 8 May 2008
Line 12:		Line 12:

	By [[Richard Monson-Haefel]]		By [[Richard Monson-Haefel]]
-		+	This work is licensed under a
-	~~Creative Commons Attribution 3~~	+	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
-	~~[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3] <img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by/3.0/us/88x31.png"/>~~	+
-		+
-	This work is licensed under a [~~href="~~http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3~~.0 United States License~~].	+

	Back to [[97 Things Every Software Architect Should Know]] home page		Back to [[97 Things Every Software Architect Should Know]] home page

Rmonson: /* Today's solution is tomorrows problem */

Rmonson — Thu, 08 May 2008 04:38:22 GMT

Today's solution is tomorrows problem

←Older revision		Revision as of 04:38, 8 May 2008
Line 14:		Line 14:

	Creative Commons Attribution 3		Creative Commons Attribution 3
-	~~<a rel="license" href="~~http://creativecommons.org/licenses/by/3.0/us/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by/3.0/us/88x31.png"/>~~</a><br/>~~This work is licensed under a ~~<a rel="license"~~ href="http://creativecommons.org/licenses/by/3.0/us/">Creative Commons Attribution 3.0 United States License~~</a>~~.	+	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3] <img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by/3.0/us/88x31.png"/>
		+
		+	This work is licensed under a [href="http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3.0 United States License].

	Back to [[97 Things Every Software Architect Should Know]] home page		Back to [[97 Things Every Software Architect Should Know]] home page

Rmonson at 04:32, 8 May 2008

Rmonson — Thu, 08 May 2008 04:32:06 GMT

←Older revision		Revision as of 04:32, 8 May 2008
Line 14:		Line 14:

	Creative Commons Attribution 3		Creative Commons Attribution 3
		+	<a rel="license" href="http://creativecommons.org/licenses/by/3.0/us/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by/3.0/us/88x31.png"/></a><br/>This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by/3.0/us/">Creative Commons Attribution 3.0 United States License</a>.

	Back to [[97 Things Every Software Architect Should Know]] home page		Back to [[97 Things Every Software Architect Should Know]] home page

Rmonson at 04:31, 8 May 2008

Rmonson — Thu, 08 May 2008 04:31:17 GMT

←Older revision		Revision as of 04:31, 8 May 2008
Line 12:		Line 12:

	By [[Richard Monson-Haefel]]		By [[Richard Monson-Haefel]]
		+
	Creative Commons Attribution 3		Creative Commons Attribution 3

	Back to [[97 Things Every Software Architect Should Know]] home page		Back to [[97 Things Every Software Architect Should Know]] home page

Rmonson at 04:31, 8 May 2008

Rmonson — Thu, 08 May 2008 04:31:00 GMT

←Older revision		Revision as of 04:31, 8 May 2008
Line 12:		Line 12:

	By [[Richard Monson-Haefel]]		By [[Richard Monson-Haefel]]
		+	Creative Commons Attribution 3

	Back to [[97 Things Every Software Architect Should Know]] home page		Back to [[97 Things Every Software Architect Should Know]] home page

Rmonson at 04:28, 8 May 2008

Rmonson — Thu, 08 May 2008 04:28:17 GMT

←Older revision		Revision as of 04:28, 8 May 2008
Line 13:		Line 13:
	By [[Richard Monson-Haefel]]		By [[Richard Monson-Haefel]]

-	Back to [[97 Things Every Software Architect Should Know]]	+	Back to [[97 Things Every Software Architect Should Know]] home page