Friday, July 21, 2006
What can corporate America learn from playing games?
Awhile back, we had a discussion with a software developer that worked at a gaming company and learned a lot about good server architectures...
Imagine if enterprisey folks pulled their heads out their bleeps and started studying the architectures of others. For example, wouldn't it be interesting if Alan Pelz-Sharpe blogged on the content management architecture of say playboy.com than some corporate entity who is less mature? Imagine if the folks at Gartner instead of sending desist notes to James Governor instead focused on sharing with us enterprisey folks the architecture of gambling sites that are not only highly available and load balanced not just between data centers but sometimes between countries which never seem to lose a transaction nor suffer from mysterious slowdowns.
At some level, the Ruby Community is accurate in their description of most IT folks in corporate America as being too enterprisey. We over-engineer things which results in more costs than need be. It is amazing that many of the web 2.0 sites are built on the LAMP stack and run on only two or three single CPU pentium servers while us enterprisey folk need millions of dollars worth of infrastructure for applications that will receive less traffic because we are worried about scale.
The funny thing is that while we can learn a lot from many of the successful web 2.0 companies on how to be lightweight, I am of the belief that we could learn more from gaming engines and their architecture.
I wonder what it would take for industry analysts to start producing analysis for corporate consumption on the architectures such as Battle.net which supports 75,000 concurrent in a highly secure manner. Most gaming companies have security nailed not only in terms of firewalls but actually have embedded secure software development practices into their applications as well. I suspect that folks who study secure coding such as Gary McGraw could learn a thing or two.
From what I know of battle.net the most intriguing thing about it is that it supports so many users let is still a single threaded application. Us enterprisey folk have been convinced over the years that multiple threads of execution are required in order to build an enterprise application. We couldn't live without our J2EE containers that make it easier to build them. I wonder what would happen if an enterprise architect challenged their own culture in this regard?
Another thing that is interesting is that gaming engine architects are conscious of what their application looks like on the wire. They can tell you for each and every function within their application and exactly how many packets are generated. I suspect that absolutely zero folks in the blogosphere that are employed in corporate environments have even thought about this before the fact (we are great at doing it in a crisis though).
Anyway, I hope to figure out a way for folks in enterprises to learn better architecture and have pinged several software developers in the gaming software development profession and have asked them if they would be interested in doing a podcast to talk about some things that we could learn from them. Stay tuned...
| | View blog reactionsImagine if enterprisey folks pulled their heads out their bleeps and started studying the architectures of others. For example, wouldn't it be interesting if Alan Pelz-Sharpe blogged on the content management architecture of say playboy.com than some corporate entity who is less mature? Imagine if the folks at Gartner instead of sending desist notes to James Governor instead focused on sharing with us enterprisey folks the architecture of gambling sites that are not only highly available and load balanced not just between data centers but sometimes between countries which never seem to lose a transaction nor suffer from mysterious slowdowns.
At some level, the Ruby Community is accurate in their description of most IT folks in corporate America as being too enterprisey. We over-engineer things which results in more costs than need be. It is amazing that many of the web 2.0 sites are built on the LAMP stack and run on only two or three single CPU pentium servers while us enterprisey folk need millions of dollars worth of infrastructure for applications that will receive less traffic because we are worried about scale.
The funny thing is that while we can learn a lot from many of the successful web 2.0 companies on how to be lightweight, I am of the belief that we could learn more from gaming engines and their architecture.
I wonder what it would take for industry analysts to start producing analysis for corporate consumption on the architectures such as Battle.net which supports 75,000 concurrent in a highly secure manner. Most gaming companies have security nailed not only in terms of firewalls but actually have embedded secure software development practices into their applications as well. I suspect that folks who study secure coding such as Gary McGraw could learn a thing or two.
From what I know of battle.net the most intriguing thing about it is that it supports so many users let is still a single threaded application. Us enterprisey folk have been convinced over the years that multiple threads of execution are required in order to build an enterprise application. We couldn't live without our J2EE containers that make it easier to build them. I wonder what would happen if an enterprise architect challenged their own culture in this regard?
Another thing that is interesting is that gaming engine architects are conscious of what their application looks like on the wire. They can tell you for each and every function within their application and exactly how many packets are generated. I suspect that absolutely zero folks in the blogosphere that are employed in corporate environments have even thought about this before the fact (we are great at doing it in a crisis though).
Anyway, I hope to figure out a way for folks in enterprises to learn better architecture and have pinged several software developers in the gaming software development profession and have asked them if they would be interested in doing a podcast to talk about some things that we could learn from them. Stay tuned...
