Software Technology Architect

The below are only the points. Read the original article in [www.littletutorials.com]. Really awesome. In fact, the author of this article inspired me to restart my knowledge sharing activity and started writing few thing in the web. Sec-1:Set yourself up for success Define early on what success means for you, the team and the business Believe in the project: idea, architecture, time, team Understand the domain, the business requirements and the technical challenges Know your team: strengths, weaknesses, ambitions and personalities Have a plan as a result of a planning activity Be part in the design of everything Get your hands dirty and code8. Act as a communication proxy for your team Make sure everybody understands the big picture: their work has implications Fight for architecture and design consistency Know the status of everybody’s work and detect slippage Record technical debt if you need shortcuts but try to maintain architectural integrity; report the debt Use the process that...

One of my friend use to advice me to attend interviews every 6 - 9 months. I gave a try. I could see myself as a [Technology Lead] where I am lagging in the technical and other skills. To help my readers I am listing out few the areas where I came to know a TL has to update/upgrade. Protocols like SOAP, HTTP, TCP UML - Views (Process, Sequential, ...) UML - Diagrams (Collaboration, Communication, ...) Ajax - Internals, Architecture, Scenario, ... .NET tools - FxCop, NUnit, ... Profilers - CLR Profiler, ANTS, ... Estimation techniques Build Tools - MSBuild ASP.NET Performance Counters SOA concepts SDLC Process Unit Testing, Integration Testing, etc... EAI - BizTalk exposure Collaboration - MOSS concepts All the best!

I got a chance to search for the things that a software architect should be capable of and I came across the following link from O'Reilly. http://architect.97things.oreilly.com/wiki/index.php/97_Things_Every_Software_Architect_Should_Know_-_The_Book. It has many topics and I first looked into "Architects must be hands on". It really impressed me. Thanks a lot to the author of that topic. I liked few points that I enlisted below. - Architects should be bought into the team at the earliest part of the project. - Architects should not sit in an ivory tower dictating the way forward. - An architect is like an airline pilot, he might not look busy all of the time. - Architect should have responsibility for the delivery and quality of the projects. They gave clear picture on the roles of a software architect. There are two ultimate statements we can never miss. I copied them below. (1)The project manager (co-pilot) performs the day-to-day management tasks leaving the architect ...