How do aspiring architects get their first breakthrough, considering they have no previous Hands on experience in architecting? Is knowledge of architecture from books, certification, sufficient?
Academic knowledge (books, certifications, etc.) are definitely an asset. These introduce the general information on different architecture types, how they compare, etc. However knowing this does not make one an architect on its own.
Aspiring architects would have experience developing software, experiencing and understanding the complete software cycle. Initiative is important, that works where there is an open team environment, and it helps to know the inner workings of the technologies being leveraged.
How long an aspiring architect actually spends in the lower hierarchy depends on the dedication, inquisitiveness, learning ability, and most of all talent.
Software engineers are constantly experiencing “architecture” from day-one. Meaning, they get a problem, they design a solution, implement the design, and see how that works, get feedback from seniors/mentors and improve.
Aspiring Architect will obviously have knowledge and no experience. So how do they get their first break considering that no one will take a chance with aspiring architect?
An architect will always have experience. They start out as devs or infrastructure guys, which is where aspiring architects gain depth of experience. Breadth comes later, much as Salman explained above (it’s not going to happen without talent, initiative and a solid mix of experience, academic knowledge and a real desire to succeed). Most architects I know probably won’t be able to pick out any single breakthrough point in their careers. Aspiring architects just evolve into the role based on their abilities. That said, I think the formal structure in larger companies like systems integrators makes it difficult to formalize the role. Smaller companies like startups make the transition easier for aspiring architects because they’re more interested in results and less concerned with title.
So, for sample, let’s say, “Devs will most likely have solid experience in C++, J2EE/Java or other development environment. So after having 6-8 years of experience in C++ can an aspiring architect call himself/herself an architect?”
The answer to this question is subjective, so all I can offer is my personal opinion –
There are degrees of architecture. 6-8 years of say, C++ dev experience may make the dev a product architect. But so could 4 years with various versions of Exchange Server. Then again, C++ and Java alone won’t make a solutions architect, much less an enterprise architect. And we haven’t even started talking about being a good or bad architect 😉
Add performance, maintainability, security, networking, test, deployment, and soft skills like conflict resolution, problem solving, stakeholder management, expectation management, documentation and communication skills, reliability and integrity to name but a few to the C++ and Java experience, and you might have the makings of a “good” architect. I put “good” in quotes because as I said, it’s subjective.
I know devs with 18 years’ experience in some really arcane technologies like the Microsoft crypto API who are not architects. There’s this guy I know who after 2 years’ formal work experience is designing high performance distributed systems with really awesome bells and whistles like identity federation that delivers real business value.
Everything’s relative, and while certifications will help an architect find a job much like a degree does, it will not guarantee that the architect is good or even great.
So, another nice question is “So how & when do a dev realize that he/she is fit for an architect role? Is number of year of experience a good criteria? They still do not have an experience in Architecting. Why should someone take a chance & give them a break?”
If it’s a growth opportunity with the current employer, there are a number of ways to get the aspirations noted, like talking to the development manager, project manager, architect, etc. actively participating in architecture related activities, discussions on architecture, down to explicitly showing interest in the area.
While switching to another organization, the resume (first point of contact) needs to be engineered to highlight/showcase the related skills and experience.
In my opinion having development experience does not make one an architect. There are additional qualities for an architect that is not prominent in a developer. For example, curiosity, problem solving on a large scale, system interactions, complexity problems, etc. There has to be a “knack” or talent for it. Like I said before, it has a lot to do with the individual.
You are right that organizations will try not to risk picking up an aspiring architect, however, that is not necessarily a hard rule. Organizations may at times pick up an aspiring architect because of financial reasons also.
Bottom line is how well the aspiring architect actually prepares and then sells the architect within. Got to look at it from a sales (figurative) point of view, i.e. individual has “software architecture services”, creates “sales-pitch” for the “customer” and supports that sales-pitch with why his services are relevant to others.
Let see this: “It’s the sales pitch and luck which will make the difference, apart from knowledge. After getting an architect role, there is a high likelihood that the aspiring architect will fail for the first time or may not be able to handle it to the best of his/her abilities. But will learn a lot with actual hands on experience but will face a problem getting the second project. Will need another round of sales pitch and luck, perhaps…
I respectfully disagree. Luck, in my opinion, has nothing to do with it 😉 The architect should also never fail. The architect knows up front whether he/she knows how to deliver a project or doesn’t even start. If an aspiring architect is likely to fail then experience can be gained by shadowing an experienced architect. If an inexperienced architect is given responsibility for a project or program that fails, I’d question the CTO or whoever it was that assigned that responsibility.
Also, I think that is a golden rule, watch and learn, all that works adopt, all that doesn’t work, avoid. It’s not only about looking at others (co-workers, mentors, etc.) but also one self. It is a life style rather than a habit.
We being human have a tendency to fail, however, being human, we can observe and learn and improve ourselves to reduce this tendency.
Sanjay, luck may take you only so far, however, being prepared, anticipating, working hard, learning every day, is far more powerful and effective than luck. Luck is made, making the right decisions at the right time may seem random, and however, being prepared allows one to do exactly that.
Knowing your limits (knowledge, experience, skill, etc.) is important, however, it is more important to actively address these limits.
Taking on any responsibility is very serious business. One has to be prepared to fulfill it. It is a commitment that needs to be honored.
I’ll echo what Michael, a member of IASA, said, failure is not an option. However, hard work, due diligence definitely pays off.
Again, for someone who claims to be an aspiring architect, every stage in the hierarchy is a valuable learning experience, each experience should be leveraged. Even a developer when given an assignment is given a (relatively) high-level task, for which code needs to be written, how the code is written, what algorithm is used, why one algorithm is preferred over another, are all aspects through which a developer can hone and improve and expand his skill, experience and knowledge.
Leave nothing to chance.
I’m talking about luck, in the sense, that an organization is ready to hire an untested aspiring architect. (Analogy: A patient allows getting open heart surgery done by a newbie) To err is human. CTO/CEO keeps saying that one learns more from mistakes than success. If an architect never fails then perhaps the work is very routine and predictable, in my opinion. For a routine and predictable work an experienced architect is a best bet. For new and different kind of project which an experienced architect has never done before both aspiring and experienced seems to be at par. What do you think?
Architects are not a breed of esoteric people who fall from the sky. They learn from experience an evolve into one. In many organizations, the term architect itself is very vague. It may be very well possible that a large program will have a “Technical Architecture Group” which is made up of a panel of relevant technical experts. They may be headed by an Enterprise Architect or Solutions Architect.
The normal growth path of an architect is technical architect > solution architect > enterprise architect. Technical Architect roles are typically based on specific technical expertise in technologies such as Java, .NET, C++ etc. They can take up the role of defining architecture and guiding designers in coming out with the right solution. So if you have C++ expertise for 8 years, you may take the role of TA in a project which is primarily centered around the same technology. This will enable you to interact with other technology streams and TAs which you can master as well as the solution aspects from the SA/EA. This experience will enable a TA to move to higher roles subsequently.
To the matter of routine vs. new, please understand that every project and customer requirement is unique. It is in the interest of the architects to find newer and alternate approaches for addressing various problems. Aspiring architect can never be equated to an experienced one, irrespective of what project they work on. Experience can never be replaced.
Aspiring architects should find good architects as mentors and work in the shadows of good architects for as long as possible in addition to all the experience and knowledge gained from other sources. Good technical managers will always try to develop aspiring architects in this way.
I have mentored many aspiring architects over the years, with which I have actually developed a coaching and mentoring program specifically for aspiring architects. The biggest challenge for most aspiring architects is not the technical bits but the soft and leadership skills required to be a good architect.
I wonder how many aspiring architects will get the exposure which will let them know that they are competent. Take for example Service Company in which the dev are supposed to design, code and deliver and a major chunk of projects are maintenance & migration projects. In Products Company the core architecture is already done long back and architects have to maintain, enhance or refactor & add new functionalities. So although IASA has a great framework in place many people will find it difficult to show some complex project in which they have done substantial architecture work in an individual capacity. So most of architects can only sit for multiple choice type exams & get certification & use sales pitch to get architect level job. The same goes with EA. Very few companies actually do EA and hence aspiring EA architects cannot get experience or even exposure & can just pass TOGAF, Zachmann, etc certification and pray for good luck. Whether the architect is competent to do EA will only be revealed when he implements EA.