Pages

Tuesday, March 9, 2010

Software Architect



One of the sessions I attended at Tech-Ed MEA 2010 was on ‘Agile Architect’. This interactive session was steered by Scott Hanselman and Aaron Skonnard who gave valuable insight into the role of a software architect within an organization. So let us jump right into the discussions in the following sections.


Organizational Role

A software architect usually reports to the Chief Technology Officer or CTO. The CTO sets the future technology tone for an organization. An architect, on the other hand, articulates the vision of the CTO. He understands the business domain to the heart and conceptualizes the overall business needs into proper software requirements.

It is important to understand that a software architect is both a technical and political figure in an organization. He understands the business strategies. He understands the business both inside and out including business rules, policies and decisions. In short he must see the big picture when making his decisions.



Technical Aspect

A good software architect must be technology savvy. He understands the technology (to be used) in and out. He is well versed with latest technical trends, programming languages, software methodologies and development tools. This may seem to be an overstatement, however; being thorough from a technical point-of-view has two advantages. First he gets the respect of his team and hence they listen to him. Second, the developers always have someone to talk to when faced with a technical issue.

An architect should be a programmer at heart. This doesn’t necessarily mean that he writes production code, however; coding is a norm for him. A personal project or small business application can keep him on his toes.

One trait of an architect is to experiment with different technology. An architect’s search for cutting edge technology leads to user friendly business applications which are a boost for the business.

One important trait of an architect is to remember the basics of his IT education. Over the years, software architects forget about basics including data structures, databases, software engineering etc. A good architect remembers the basics which help him better design and implement software systems.

Last but not the least is that an architect always comes with a working prototype of the system to be developed. This simple point cannot be emphasized enough. A working prototype is critical in convincing the top management, ensuring user satisfaction and communicating with team members. The prototype doesn’t need to be a complete application. But it must show the big picture to all the stakeholders involved.



Problem Solving Skills

One question often asked by under-training architects is that do they need to know design patterns and software methodologies. The answer is both yes and no. Every designer handles a problem differently but proven best practices have their weight. They reduce the overall complexity and are optimized for performance. An architect may have good problem solving skills, however; knowing best practices always goes in his favor.

There is a saying that any solution which can be expressed in numbers is better than others. An architect evaluates his design and solution from a complexity point of view. For example, he may use Line of Codes (LoC) to determine the complexity of the code. Breaking the system into subparts and applying different complexity matrices allows him to perform a systematic evaluation of the system.



Personality Traits

As an architect, every developer must adapt some personality traits at an early stage of his career. He has the urge to ask ‘WHY’. Talking to different people within an organization lets him understand the business strategy. A good architect is often spotted talking to users and taking notes. This trait makes him different from the ‘Average Joe’.

When designing a system, an architect follows values principles such as conforming to standards, applying best practices and adhering to architectural values. For example, even if he is tasked to design a small application in limited amount of time, the application has a proper architecture. He understands that every application grows over time and becomes a maintenance nightmare if not architected properly.

I hope that in this post, you have learnt along the lines. Do share your thoughts on this. Stay tuned for more…

No comments:

Post a Comment