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.
From a career path perspective, the role of an architect progresses from developer, senior developer, solution architect and architect. Sometimes a senior developer can jump few steps and become an architect based on varied skills and experience. So, asking questions in core java tests if the candidate has followed a career progression path. Next, there are several types of architects in IT, not just J2EE architects. One can be a data architect, application architect, solution architect, operational architect and so on. These roles may or may not exist in all companies and some roles are combinedly assumed. When selecting an architect, it is important to test several areas right from business and functional requirements to troubleshooting a deadlock issue in a distributed transaction and things in between. Architects should have all skills. Most important thing is the ability to research and development, which is true particulalry in this age of "pattern a week, language a fortnight" (Patent Pending :-)) type of discoveries. This proves, the would be architect has 360 degrees experience gained the hard way in IT shops.
The scope of assessing an architect varies based on the role he/she is likely to play(Application/Domain Architect, Solutions architect and Enterprise architect). So mere asking some technical questions like final, finally and finalize will not help to select a good architect. Questions like the below one might be more practical:
For an Application Architect : 1. Give a project requirement and ask him to depict the Application and System Architecture models then start ur question based on it... that will give a good idea.
2. All NFR questions.
3. Design methodologies used, issues, solutions.
4. Give a scenario ask them to design... - classdiagram, seq or deployment or component etc...
5. Questions on design patterns
6. Question on Team lead and peer interaction, presentations.
For a Solutions Architect: Questions about the project dependent items - like Infrasture team, security, development team - should be asked.
For an Enterprise Architect: 1. governance capabilities
2. Future roadmap
3. procurement
4. compare products
5. Business Interaction for new proposals and vicecersa
Wish you good luck in your recruitment now in future.
No comments:
Post a Comment