Two types of architects are their
1. The software architect (solution architect)
2. The enterprise architect (binding business needs into the overall system/software architecture.
A good architect in my opinion should have the following characteristics regardless of technology:
1. The ability to take a complex problem and break it down into simple well defined manageable subcomponents that are loosely coupled. This reduces tight dependences, whereby, the architect can farm out subcomponents. Thus, allowing for true parallel development across a large team.
2. Architect and design a solid base application framework that allows for extensibility and ease of maintainability. In essence, design a system that can withstand the test of time, as well as meet other tenets of industrial-strength software.
3. Ensure that the application scales, and meet or exceed SLA commitments (i.e. security, performance, durability, robustness, etc)
4. Use best practices and architectural design patterns within reasons: DON’T over-engineering the system to death.
5. Do more with less: Use proven technologies and reusable library frameworks
6. Ensure that the system is highly automated, requiring little to no operator intervention, thus, reducing the Total Cost of Ownership (TCO)
7. Has a lot of real experience in truly distributed architectures. Someone who can talk-the-talk and walk-the-walk.
8. Enterprise architects should be very much able to defend, promote and sell the business case for the architecture to be of true value for the customer/company implementing their architecture. Unfortunately this comes with political skills as well, and these are normally obtained through years of experience in the field.
9. Enterprise Architect is much different than a Solutions Architect. Enterprise Architect is an individual that can walk into a business and model the business processes, lead the development of a strategic plan, etc. i.e. if you are familiar with the zachman framework (as an example, I know others exist) and have experience in that arena, you'll understand what an EA is. A solutions Architect can take a describe box or boxes and put together a solution. They can also provide guidance on standards, technology choices, etc. Finally, they help lead the development efforts with the technical team and provide a liason between the business and technical side. The sometimes work at a level similiar to a PM on a project, but not always.
10. A Solutions Architect is not just someone who understands technology. An SA understand people, understands the business, understands the technology, and has the experience necessary to meet the requirements on time, on budget, with customer satisfaction.
11. He should be familiar with all the latest fashion in software production with a rock solid discernment to shift out the gold from the fluff. In other words, able to choose the right path into the future.
12. Strive for KISS in all situation. He always keep "well-meaning impractical theorists" out of the project.
13. He is a good programmer (takes one to know one) but do not compete with his staff in the project.
14. He has experience before of the businessdomain of the project.
15. An architect mitigates the technical risks associated with a system. A technical risk is something that is unknown, unproven, or untested. Risks are usually associated with the service-level requirements and can occasionally be associated with a business requirement. Regardless of the type of risk, it is easier to address the risks early in the project while creating an architecture, then to wait until construction when you have a large developer base that could potentially be waiting while risks are solved.
16. An architect must lead the development team to ensure the designers and developers build the system according to the architecture. As the leader, difficult decisions must be made about trade-offs in the system and the architect is the person who must make those decisions. To lead, the architect must be a good written and oral communicator. It is up to the architect to communicate the system to the designers and developers who will build it. This is typically done with visual models and group discussions. If the architect cannot communicate effectively, then the designers and developers will probably not build the system correctly.
17. An architect should be able to produce and effect a business solution using whatever tools are reasonably and readily made available.
18. A true architect is resourceful enough to look at the problem, find and gain a knowledge of the basic resources (technologies and people) necessary to construct a solution that meets the immediate business need.
Microsoft Certified Architect ProgramsThe Microsoft Certified Architect (MCA) programs identify and certify top industry experts in IT architecture. Microsoft Certified Architects have proven experience designing and delivering the right IT solutions for enterprise customers. These MCA professionals typically have five or more years of advanced IT architecture experience, possess expert technical and leadership skills, and become part of an exclusive, world-class community of experts who continually collaborate on best practices within the IT industry. MCA candidates must definitively showcase seven competencies of business acumen and technological proficiency to a panel of industry experts in a Review Board interview in order to achieve the MCA credential. MCA certification was built by and for industry architects.
