What does it take to become an architect? — Ramarao Kanneganti Home page: "Personality traits
To be successful architect, you must have the following traits:
'The ideal architect should be a person of letters, a mathematician, familiar with historical studies, a diligent student of philosophy, acquainted with music, not ignorant of medicine, learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations.' – Vitruvius, circa 25 BC.
1. You should be passionate: Go back to the quote by Christopher Alexander in the beginning of this note. As it said, as long you are doing a job, you should try to do it as best as anybody else in the world can do it. Your pride and passion in your work makes you the strongest critic of your own work.
2. You should be inquisitive: In these days, there are far too many new developments in the technological front. Unless you are naturally curious, you may miss the right tools for the job. If you do not try these tools by yourself, you will end up taking recommendations from others, worse -- from the vendors.
3. You should be skeptical: In the era of hype and buzzwords, it takes a special talent to remain inquisitive, passionate and yet the same time skeptical about the technical advances. Understanding the history of software provides a good dose of reality, enough to make anybody a skeptic.
4. You should be honest: It takes intellectual honesty to acknowledge one's shortcomings and learn. It also helps in serving the customers and your colleagues better.
5. You should be courageous: Without courage to speak out and confidence to make recommendations, you will never be able to make a difference in the state of the world, especially, in the world of software.
6. You should be compassionate: Unless you understand the impact of your actions you will not make the correct technical choices. It is easy to lose sight of the impact on people when working with machines. As an architect, the choices you make will effect not only you, but also your colleagues and customers, not only now but also even in future.
7. You should be quality conscious: Quality of a work reflects in the details. Paying attention to even the smallest details and balancing them with the realities of the project is the hallmark of a true architect.
8. You should be ready to convince others: As an architect, you should be able to convince your team members, managers, and clients of your vision. It means having the patience to explain to the outsiders, the interest to mentor the junior team members, and the humility to listen and learn from others.
9. Above all else, you should have good taste: Good taste, while being subjective, is easy to recognize. An architect should develop good taste that leads to consistency of vision, simplicity of design, and cleanliness of implementation.
- Sent using Google Toolbar"
Sunday, July 11, 2010
What does it take to become an architect? — Ramarao Kanneganti Home page
What does it take to become an architect? — Ramarao Kanneganti Home page: "What is an IT/Software architect?
I often get resumes with architect in title. Judging by these resumes, an architect is supposed to have the following qualities:
1. Knowledge of UML
2. Being able to draw architecture diagrams
3. Experience as a developer
Architect: Someone who knows the difference between that which could be done and that which should be done. -- Larry McVoy
The predominant thought seems to be progrmmers with long years of experience in coding either become managers or architects. Typically, all the people with an interest in technology become architects. But, what is the role of an architect in software development?
1. Defining the problem in technical terms: Normally, the problem is stated in the terms of the domain -- it could be scientific, business, or any other area where the solution is needed. To solve that problem using the computer, you must be able to state the problem in 'computerese', which means, in the terms of established technical frameworks. Typically, it takes:
1. Understanding the problem as explained by the customers
2. Translating into the computer solution domain
3. Guiding the customer to well understood problem-solution patterns, and
4. Understanding where true innovation is required
2. Specifying the technologies needed: A given problem can be solved with diverse combinations of technologies. It is the architect's job to specify what technologies to be used.
3. Defining the major modules of the system: The architect also must break down the system into modules and define interactions between modules. In fact, she should also specify the guidelines of interactions so that the module dependencies are well understood.
4. Recommending patterns and frameworks: Since there is nothing new under the sun, each problem, in some fashion must have been solved earlier. It is the architect that should identify the relevant previous patterns to apply in the current project. In addition, she may need to define new patterns to be used in the application.
5. Establishing code quality measures: For example, code reviews and design reviews fall under the code quality measures. The architect should establish the guidelines and practices in the team.
6. Establishing Best Practices: Any given task can be done in many ways, some of which are equally good. However, an architect must establish best practices for doing even these mundane tasks so that consistency is maintained, and unnecessary effort is spared in looking for solutions.
7. Maintaining conceptual integrity of the application: As the project grows, requirements change; new technologies get added; new people come into the project. With all these changes, it becomes imperative to maintain a coherent and consistent vision of the project. An architect should be able to do that.
With these duties in mind, I am going to list the characteristics of a successful architect.
Personality traits
To be successful architect, you must have the following traits:
'The ideal architect should be a person of letters, a mathematician, familiar with historical studies, a diligent student of philosophy, acquainted with music, not ignorant of medicine, learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations.' – Vitruvius, circa 25 BC.
1. You should be passionate: Go back to the quote by Christopher Alexander in the beginning of this note. As it said, as long you are doing a job, you should try to do it as best as anybody else in the world can do it. Your pride and passion in your work makes you the strongest critic of your own work.
2. You should be inquisitive: In these days, there are far too many new developments in the technological front. Unless you are naturally curious, you may miss the right tools for the job. If you do not try these tools by yourself, you will end up taking recommendations from others, worse -- from the vendors.
3. You should be skeptical: In the era of hype and buzzwords, it takes a special talent to remain inquisitive, passionate and yet the same time skeptical about the technical advances. Understanding the history of software provides a good dose of reality, enough to make anybody a skeptic.
4. You should be honest: It takes intellectual honesty to acknowledge one's shortcomings and learn. It also helps in serving the customers and your colleagues better.
5. You should be courageous: Without courage to speak out and confidence to make recommendations, you will never be able to make a difference in the state of the world, especially, in the world of software.
6. You should be compassionate: Unless you understand the impact of your actions you will not make the correct technical choices. It is easy to lose sight of the impact on people when working with machines. As an architect, the choices you make will effect not only you, but also your colleagues and customers, not only now but also even in future.
7. You should be quality conscious: Quality of a work reflects in the details. Paying attention to even the smallest details and balancing them with the realities of the project is the hallmark of a true architect.
8. You should be ready to convince others: As an architect, you should be able to convince your team members, managers, and clients of your vision. It means having the patience to explain to the outsiders, the interest to mentor the junior team members, and the humility to listen and learn from others.
9. Above all else, you should have good taste: Good taste, while being subjective, is easy to recognize. An architect should develop good taste that leads to consistency of vision, simplicity of design, and cleanliness of implementation.
Technical Experience
It takes experience to become an architect. This sort of experience cannot be counted in the number of years, but in the amount of wisdom gained from it. If you want to become an architect, you should try to acquire and master these skills.
1. You must know the basics of computers: There are several aspects to the basics of working with a computer. These basics will help you understand the nature of solutions that people are used to. It lets you anchor your ideas with familiar simple patterns.
1. You should master at least one OS: I prefer people to master one version of Unix (or Linux) for it encourages people to explore 'under the hood'. However, any OS will do for this purpose. To truly master an OS, you should be able to install, maintain, manage, and make it do whatever you want to do.
2. You should master at least one scripting language: Turns out that most of the time, we manipulate text, whether we are writing code, generating code, generating data, analyzing test results, or preparing reports. A scripting language that lets you do these tasks efficiently will make you effective.
3. You should master at least one High Level Language: It goes without saying that at least one main stream HLL (C++, Java, C#, C) is absolutely essential. Of course, it is even better if you know languages like LISP, to understand the possibilities of language design.
2. You should master the tools of trade: Since you work with these tools no matter what you do, mastering them makes you efficient. Be sure to choose the tools that are ubiquitous or that you can carry with you.
1. You should master at least one editor: Since editor is the most used program, mastering it is essential for an architect. I use Emacs, but any editor with extensibility and macros will do.
2. You should master at least one document producing system: Producing well-written, informative, and aesthetically pleasing documents is a needed skill for an architect. The most popular tools to develop such documentation is MS Office. Several Open Source proponents use SGML/HTML/XML. LaTeX, TeX is the most used system in Academia. The market you are pursuing may best dictate your choice.
3. You should understand the basics of computer science: Many people learn programming on street corners. While the practice of programming is just that -- practice, it can benefit from good understanding of basics of computer science. For example, I find myself using the data driven abstractions in all my designs.
1. You should understand data models: Most computer programs are concerned with collecting, classifying, managing, and presenting data. As such, understanding data models, schemas, and databases is an important part of an architect's portfolio.
2. You should understand transactions: There are far too many myths associated with transactions. An architect understands where transactions are needed, where they are superfluous, and where they can be simulated in programs and in databases.
3. You should understand three fundamental Programming Constructs: All programs are built up using the same techniques: combination of the basic blocks, abstraction to create new building blocks, and application of these abstractions. Understanding and practicing these fundamental techniques in proofs, code, or documents is an experience that an architect should have.
4. You should understand higher-order functions, and data-driven abstractions:
'Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp.' - Phil Greenspun
One of the original models of programming languages, lambda calculus has no data; instead it is represented as functions. These days, it is common to abstract programs as declarative data, particularly in programs where flexibility is desired. A proper understanding of these abstractions is necessary for an architect to create good architectural patterns.
4. You should learn the craft of programming and managing software through practice: Any architect should write code. Without writing code, they cannot meaningfully design the system. In fact, through this practice they should learn a few things:
1. You should have, through practice, a set of preferred solutions that you thoroughly understand: A friend of mine has several standard templates for solving the problems with the tools that he knows well. For example, he could put together any workflow automation with email and procmail. Philip Greenspun used AOL Server, TCL, and Oracle to solve his problems. Joel Splosky uses Excel to solve his problems. Basically, you need to develop trusted frameworks that can help you solve your problems. Since you practiced these technologies already, you would not waste time in interoperability issues; more over, you would have evolved best practices in these frameworks.
One aspect of these technologies is that they enable you to develop quick prototypes. Often as an architect, you need to prototype to validate some ideas. Having a least expensive way of prototyping a realistic application can help you make the right choices.
2. You should understand abstractions for standard problems: Using patterns is an effective way to capture trusted solutions for most common problems. However, patterns are too concrete to capture several problems. There are standard abstractions that any architect must be familiar with. A partial list includes:
1. Use of caching: Caching occurs in all ORM solutions, and in any solution where you keep data in multiple places. There are standard solutions with different characteristics -- real time coherence, delayed coherence, and on-demand coherence.
2. Use of views: Most problems are concerned with maintaining different views of data. Even the MVC paradigm is about presenting a different view of the data. Most of the data analysis packages present different views of data.
3. Use of declarative extensions: To extend a static program, there are different strategies ranging from command line options to dynamically loading extensions to XML based configuration files. Some systems provide scripting extensions.
3. You should understand the standard software development practices: A partial list includes
1. programming life cycles -- XP practices, Waterfall methods, RUP,
2. requirements writing,
3. version control,
4. development environment configuration,
5. logging,
6. debugging,
7. documentation,
8. building process,
9. testing process,
10. release process, and
11. bug tracking process.
5. You should learn to work with a team: Since your decisions as an architect impact the whole team, you should learn to work with the team. I am not going to list out the rudiments of team play, but I would like to point out the technical skills required:
1. You should be able to write well:
'Programs must be written for people to read, and only incidentally for machines to execute.' -- Abelson & Sussman, SICP.
Most programmers communicate more with people than machines during the course of a project. In fact, even writing programs is predominantly to communicate with people. It is no wonder that for an architect, being able to write well is one of the most fundamental necessities.
2. You should practice good communication mechanisms: Since most of the knowledge about building a system is captured in conversations, it is imperative that architects should have good understanding of the mechanisms for fostering and developing those communications. For example, understanding on how to set up project portals, how to publish code reviews, code metrics results, how to encourage mails to mailing lists -- all these activities help reduce the learning curve for a new member.
3. You should make work interesting: As it is, working with computers can get boring, unless you can make the work interesting. You should encourage junior members to learn and experiment so that they can gain from experience. For example, you could motivate them by offering a chance to do the following:
1. learn new technologies,
2. apply best practices,
3. learn and documenting patterns and frameworks, and
4. learn good development principles.
4. You should be available for the whole project life cycle: Unless you are ready to accept the consequences of your choices, you should not make architectural decisions. You make sane choices only if you are forced to think about how a technology is used by the developers and how it is supported by the vendors or community, and how it can be upgraded to support new advances in the other technologies and protocols.
- Sent using Google Toolbar"
I often get resumes with architect in title. Judging by these resumes, an architect is supposed to have the following qualities:
1. Knowledge of UML
2. Being able to draw architecture diagrams
3. Experience as a developer
Architect: Someone who knows the difference between that which could be done and that which should be done. -- Larry McVoy
The predominant thought seems to be progrmmers with long years of experience in coding either become managers or architects. Typically, all the people with an interest in technology become architects. But, what is the role of an architect in software development?
1. Defining the problem in technical terms: Normally, the problem is stated in the terms of the domain -- it could be scientific, business, or any other area where the solution is needed. To solve that problem using the computer, you must be able to state the problem in 'computerese', which means, in the terms of established technical frameworks. Typically, it takes:
1. Understanding the problem as explained by the customers
2. Translating into the computer solution domain
3. Guiding the customer to well understood problem-solution patterns, and
4. Understanding where true innovation is required
2. Specifying the technologies needed: A given problem can be solved with diverse combinations of technologies. It is the architect's job to specify what technologies to be used.
3. Defining the major modules of the system: The architect also must break down the system into modules and define interactions between modules. In fact, she should also specify the guidelines of interactions so that the module dependencies are well understood.
4. Recommending patterns and frameworks: Since there is nothing new under the sun, each problem, in some fashion must have been solved earlier. It is the architect that should identify the relevant previous patterns to apply in the current project. In addition, she may need to define new patterns to be used in the application.
5. Establishing code quality measures: For example, code reviews and design reviews fall under the code quality measures. The architect should establish the guidelines and practices in the team.
6. Establishing Best Practices: Any given task can be done in many ways, some of which are equally good. However, an architect must establish best practices for doing even these mundane tasks so that consistency is maintained, and unnecessary effort is spared in looking for solutions.
7. Maintaining conceptual integrity of the application: As the project grows, requirements change; new technologies get added; new people come into the project. With all these changes, it becomes imperative to maintain a coherent and consistent vision of the project. An architect should be able to do that.
With these duties in mind, I am going to list the characteristics of a successful architect.
Personality traits
To be successful architect, you must have the following traits:
'The ideal architect should be a person of letters, a mathematician, familiar with historical studies, a diligent student of philosophy, acquainted with music, not ignorant of medicine, learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations.' – Vitruvius, circa 25 BC.
1. You should be passionate: Go back to the quote by Christopher Alexander in the beginning of this note. As it said, as long you are doing a job, you should try to do it as best as anybody else in the world can do it. Your pride and passion in your work makes you the strongest critic of your own work.
2. You should be inquisitive: In these days, there are far too many new developments in the technological front. Unless you are naturally curious, you may miss the right tools for the job. If you do not try these tools by yourself, you will end up taking recommendations from others, worse -- from the vendors.
3. You should be skeptical: In the era of hype and buzzwords, it takes a special talent to remain inquisitive, passionate and yet the same time skeptical about the technical advances. Understanding the history of software provides a good dose of reality, enough to make anybody a skeptic.
4. You should be honest: It takes intellectual honesty to acknowledge one's shortcomings and learn. It also helps in serving the customers and your colleagues better.
5. You should be courageous: Without courage to speak out and confidence to make recommendations, you will never be able to make a difference in the state of the world, especially, in the world of software.
6. You should be compassionate: Unless you understand the impact of your actions you will not make the correct technical choices. It is easy to lose sight of the impact on people when working with machines. As an architect, the choices you make will effect not only you, but also your colleagues and customers, not only now but also even in future.
7. You should be quality conscious: Quality of a work reflects in the details. Paying attention to even the smallest details and balancing them with the realities of the project is the hallmark of a true architect.
8. You should be ready to convince others: As an architect, you should be able to convince your team members, managers, and clients of your vision. It means having the patience to explain to the outsiders, the interest to mentor the junior team members, and the humility to listen and learn from others.
9. Above all else, you should have good taste: Good taste, while being subjective, is easy to recognize. An architect should develop good taste that leads to consistency of vision, simplicity of design, and cleanliness of implementation.
Technical Experience
It takes experience to become an architect. This sort of experience cannot be counted in the number of years, but in the amount of wisdom gained from it. If you want to become an architect, you should try to acquire and master these skills.
1. You must know the basics of computers: There are several aspects to the basics of working with a computer. These basics will help you understand the nature of solutions that people are used to. It lets you anchor your ideas with familiar simple patterns.
1. You should master at least one OS: I prefer people to master one version of Unix (or Linux) for it encourages people to explore 'under the hood'. However, any OS will do for this purpose. To truly master an OS, you should be able to install, maintain, manage, and make it do whatever you want to do.
2. You should master at least one scripting language: Turns out that most of the time, we manipulate text, whether we are writing code, generating code, generating data, analyzing test results, or preparing reports. A scripting language that lets you do these tasks efficiently will make you effective.
3. You should master at least one High Level Language: It goes without saying that at least one main stream HLL (C++, Java, C#, C) is absolutely essential. Of course, it is even better if you know languages like LISP, to understand the possibilities of language design.
2. You should master the tools of trade: Since you work with these tools no matter what you do, mastering them makes you efficient. Be sure to choose the tools that are ubiquitous or that you can carry with you.
1. You should master at least one editor: Since editor is the most used program, mastering it is essential for an architect. I use Emacs, but any editor with extensibility and macros will do.
2. You should master at least one document producing system: Producing well-written, informative, and aesthetically pleasing documents is a needed skill for an architect. The most popular tools to develop such documentation is MS Office. Several Open Source proponents use SGML/HTML/XML. LaTeX, TeX is the most used system in Academia. The market you are pursuing may best dictate your choice.
3. You should understand the basics of computer science: Many people learn programming on street corners. While the practice of programming is just that -- practice, it can benefit from good understanding of basics of computer science. For example, I find myself using the data driven abstractions in all my designs.
1. You should understand data models: Most computer programs are concerned with collecting, classifying, managing, and presenting data. As such, understanding data models, schemas, and databases is an important part of an architect's portfolio.
2. You should understand transactions: There are far too many myths associated with transactions. An architect understands where transactions are needed, where they are superfluous, and where they can be simulated in programs and in databases.
3. You should understand three fundamental Programming Constructs: All programs are built up using the same techniques: combination of the basic blocks, abstraction to create new building blocks, and application of these abstractions. Understanding and practicing these fundamental techniques in proofs, code, or documents is an experience that an architect should have.
4. You should understand higher-order functions, and data-driven abstractions:
'Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp.' - Phil Greenspun
One of the original models of programming languages, lambda calculus has no data; instead it is represented as functions. These days, it is common to abstract programs as declarative data, particularly in programs where flexibility is desired. A proper understanding of these abstractions is necessary for an architect to create good architectural patterns.
4. You should learn the craft of programming and managing software through practice: Any architect should write code. Without writing code, they cannot meaningfully design the system. In fact, through this practice they should learn a few things:
1. You should have, through practice, a set of preferred solutions that you thoroughly understand: A friend of mine has several standard templates for solving the problems with the tools that he knows well. For example, he could put together any workflow automation with email and procmail. Philip Greenspun used AOL Server, TCL, and Oracle to solve his problems. Joel Splosky uses Excel to solve his problems. Basically, you need to develop trusted frameworks that can help you solve your problems. Since you practiced these technologies already, you would not waste time in interoperability issues; more over, you would have evolved best practices in these frameworks.
One aspect of these technologies is that they enable you to develop quick prototypes. Often as an architect, you need to prototype to validate some ideas. Having a least expensive way of prototyping a realistic application can help you make the right choices.
2. You should understand abstractions for standard problems: Using patterns is an effective way to capture trusted solutions for most common problems. However, patterns are too concrete to capture several problems. There are standard abstractions that any architect must be familiar with. A partial list includes:
1. Use of caching: Caching occurs in all ORM solutions, and in any solution where you keep data in multiple places. There are standard solutions with different characteristics -- real time coherence, delayed coherence, and on-demand coherence.
2. Use of views: Most problems are concerned with maintaining different views of data. Even the MVC paradigm is about presenting a different view of the data. Most of the data analysis packages present different views of data.
3. Use of declarative extensions: To extend a static program, there are different strategies ranging from command line options to dynamically loading extensions to XML based configuration files. Some systems provide scripting extensions.
3. You should understand the standard software development practices: A partial list includes
1. programming life cycles -- XP practices, Waterfall methods, RUP,
2. requirements writing,
3. version control,
4. development environment configuration,
5. logging,
6. debugging,
7. documentation,
8. building process,
9. testing process,
10. release process, and
11. bug tracking process.
5. You should learn to work with a team: Since your decisions as an architect impact the whole team, you should learn to work with the team. I am not going to list out the rudiments of team play, but I would like to point out the technical skills required:
1. You should be able to write well:
'Programs must be written for people to read, and only incidentally for machines to execute.' -- Abelson & Sussman, SICP.
Most programmers communicate more with people than machines during the course of a project. In fact, even writing programs is predominantly to communicate with people. It is no wonder that for an architect, being able to write well is one of the most fundamental necessities.
2. You should practice good communication mechanisms: Since most of the knowledge about building a system is captured in conversations, it is imperative that architects should have good understanding of the mechanisms for fostering and developing those communications. For example, understanding on how to set up project portals, how to publish code reviews, code metrics results, how to encourage mails to mailing lists -- all these activities help reduce the learning curve for a new member.
3. You should make work interesting: As it is, working with computers can get boring, unless you can make the work interesting. You should encourage junior members to learn and experiment so that they can gain from experience. For example, you could motivate them by offering a chance to do the following:
1. learn new technologies,
2. apply best practices,
3. learn and documenting patterns and frameworks, and
4. learn good development principles.
4. You should be available for the whole project life cycle: Unless you are ready to accept the consequences of your choices, you should not make architectural decisions. You make sane choices only if you are forced to think about how a technology is used by the developers and how it is supported by the vendors or community, and how it can be upgraded to support new advances in the other technologies and protocols.
- Sent using Google Toolbar"
Subscribe to:
Posts (Atom)