Software Architect Dimensions - A Comment
76 views
Skip to first unread message
Srinivas Ivaturi
Dec 29, 2007, 12:04:38 AM12/29/07
to arch...@googlegroups.com
All
I read the following comment in one of the blog post and thought of sharing.
"I hear programmers speak here about a number of relevant programing skills. From a business-centric perspective, architects should be corporate assets, not code designers. There are five dimensions to a software architect role: 1. technology 2. consulting 3. strategy 4. organizational politics 5. leadership Technology should consume perhaps less than 20% of an architect's day. Projects don't fail because of bad design or ugly code or improper/inefficient testing or even a wrong choice of technologies. There is no such thing as a perfect technology for a task at hand, only bad leaders and poor visionaries. The above mentioned are but consequences of poor organizational choices and a lack of focus. And patterns? They are but a convenient communication framework of the day. Should we know it as architects? Yes. At least we should know where the repositories are, and how to look through the repositories for a match with a task at hand. Frameworks change. For example, is MVC in Struts really M-V-C? Some people would say no. Unfortunatelly, those are few in between, for Struts rules. Oh no, or is it AJAX that rules? Or maybe SOA and REST and web services? No, no, it's OOP and generics, and AOP. One interesting thing happened with software engineering after WWW hit the mainstream. Some became gods in their own minds, and everyone became an architect. Vanity rules, and it will come to bite the software industry worse than the dot.com crash did. For Bankers are not a very patient bunch. Remember Occam's razor. "one should not increase, beyond what is necessary, the number of entities required to explain anything." That's wisdom. Now, you Mr./Mrs. Architect, who got bitten more than once by your own vanity and have learned some valuable life lessons, you go and explain this to a young hotshot who thinks he's got it all down after two books read and three projects completed and left for someone else to maintain. Someone should teach a class titled: "History of software art" and make it a mandatory read. Got to run..."
Lets role the thoughts.
--
Srinivas Ivaturi
Blog:http://www.javablogs.net
http://srinivas.wordpress.com
Member:http://groups.google.com/group/hiteccityjug
http://www.java-tips.org
I read the following comment in one of the blog post and thought of sharing.
"I hear programmers speak here about a number of relevant programing skills. From a business-centric perspective, architects should be corporate assets, not code designers. There are five dimensions to a software architect role: 1. technology 2. consulting 3. strategy 4. organizational politics 5. leadership Technology should consume perhaps less than 20% of an architect's day. Projects don't fail because of bad design or ugly code or improper/inefficient testing or even a wrong choice of technologies. There is no such thing as a perfect technology for a task at hand, only bad leaders and poor visionaries. The above mentioned are but consequences of poor organizational choices and a lack of focus. And patterns? They are but a convenient communication framework of the day. Should we know it as architects? Yes. At least we should know where the repositories are, and how to look through the repositories for a match with a task at hand. Frameworks change. For example, is MVC in Struts really M-V-C? Some people would say no. Unfortunatelly, those are few in between, for Struts rules. Oh no, or is it AJAX that rules? Or maybe SOA and REST and web services? No, no, it's OOP and generics, and AOP. One interesting thing happened with software engineering after WWW hit the mainstream. Some became gods in their own minds, and everyone became an architect. Vanity rules, and it will come to bite the software industry worse than the dot.com crash did. For Bankers are not a very patient bunch. Remember Occam's razor. "one should not increase, beyond what is necessary, the number of entities required to explain anything." That's wisdom. Now, you Mr./Mrs. Architect, who got bitten more than once by your own vanity and have learned some valuable life lessons, you go and explain this to a young hotshot who thinks he's got it all down after two books read and three projects completed and left for someone else to maintain. Someone should teach a class titled: "History of software art" and make it a mandatory read. Got to run..."
Lets role the thoughts.
--
Srinivas Ivaturi
Blog:http://www.javablogs.net
http://srinivas.wordpress.com
Member:http://groups.google.com/group/hiteccityjug
http://www.java-tips.org
Reply all
Reply to author
Forward
0 new messages