Discussions

News: How do you become an Architect?

  1. How do you become an Architect? (63 messages)

    Teflon Ted - not to be confused with Ted Neward - has written up "How do you become an Architect?," a blog that suggests three primary things to do to become, more or less, The Architect. The foremost one: always be the guy in every meeting with the best design idea. (No word from Ted on whether this means actually having good ideas, or whether the key is to have stupid peers. Your Humble Editor bets on the former.) The expansion on the first idea is to "Be able to recognize and vocalize the pros and cons of every idea." This helps you classify which ideas are the best, and why - and being able to explain the ideas also helps you associate yourself with the good ones, even if they aren't yours in origin. So how do you recognize good ideas and learn to explain them? Here's Ted's advice:
    Read, read, read! I am a bookworm. I read books on design patterns, frameworks, methodologies, programming languages, antipatterns, usability, etc. If you can grok it and regurgitate it at the appropriate times, you'll be The Idea Guy.

    Threaded Messages (63)

  2. Architect by default[ Go to top ]

    The other way you can be the architect is to be the only developer in your department that has actually written code before ;) I don't consider myself an architect, but this has happened to me before.
  3. Idea guy?[ Go to top ]

    Since I do use the term of system-, software-, eai- and information architect to try to convey what I do I'll describe some of my thoughts on the subject. Wether you use the term 'architect' or use another term I believe there is a need for a role where the end responsibility lies for the structure and *-ilities of the things you're delivering. When your scope is a small software system (few developers etc.) it really is lead programmer. You're the primus inter paris. One of the guys and the process largely just flows out of programming experience. When your scope is a bigger software system in my experience you make a transition; you can't and shouldn't track all details but should have ways to make sure that what everybody is doing falls into place. Personally I think the term software architect or system architect is as good as any for this role. In my mind this does not mean that you should know everything better than everybody else at all times. Although a certain development authority is crucial ideally you should use the combined intelligence and experience of your team; together you're capable, if everything goes well, of managing the complexity. You alone can not. When your scope is making sure that everything falls into place across projects and across information systems you move into a wholly different process; you're still involved in design to a certain extent but the whole feedback process and decision process changes. So why does the term generate such anger, especially among programmers? Largely it is because programmers feel that the 'architect' gets all the credit (higher pay, perks of visiting faraway conferences etc.) for non-sensical poewerpoint slides and that they do all the hard difficult 'real' work. Sometimes that's true ( the pompous architect, the architect who intimidates with abstractness) , sometimes programmers fail to see which things matter at a more macro level. Of course it is true that a programming problem can be just as complex and hard to solve as problems at the architectural level. There's generally a difference in the impact of making a mistake. Personally I think that there is a place for large-scale design, across information systems of for large systems/projects; a CIO can't just say "we're busy working, we'll see where we end up". But a largescale- or topdown-design can be wrong because of unknown details that only manifest themselves at the level of having programmed and tested something. A good architect plans for this and 'humbly' incorporates these results. There's a lot more to this of course. Groeten uit Nederland
  4. Re: How do you become an Architect?[ Go to top ]

    How do you become an architect? Print yourself up some business cards. Hell...you could even call yourself Chief Architect too. That's what I did.
  5. Re: How do you become an Architect?[ Go to top ]

    I still laugh when I see this topic raised again and again. It is more evidence that the theservside is getting worse and worse. Whatever happened to this place?
  6. I still laugh when I see this topic raised again and again.

    It is more evidence that the theservside is getting worse and worse. Whatever happened to this place?
    +1 It used to be much more decent. *sigh*
  7. Re: How do you become an Architect?[ Go to top ]

    don't worry you didn't fool me ;)
  8. Experience + study[ Go to top ]

    An architect should be a hands-on reader.
  9. Well...[ Go to top ]

    1) start by getting a computer science degree including data structures, computer architecture, algorithms, programming languages, operating systems. 2) write code by implementing specifications made by experienced developers. Watch how experienced developers break down medium-complexity tasks assigned by architects into more detailed, implementable designs. Learn version control, code reviews, logging, testing and debugging, SQL, databases. 3) Become experienced developer that attends architecture meetings, and produce detailed designs for architecture steps assigned. Start looking at frameworks in use, and why people use them. Learn about database history (hierarchical databases, etc), mainframe -> client/server -> n-Tier -> internet evolution, learn about fortran -> cobol -> C -> C++ -> Java/dotNET, learn about CGI -> servlets -> JSP -> whatever you use now, learn about propietary API -> ODBC/JDBC -> ORM/EJB, learn about CORBA/COM -> RMI -> Web Services, learn as much as you need to know about XML without making everything about XML. 4) Become architect of a smaller project of maybe you and one or two other devs. 5) Become bigger architect of more important stuff. 6) Become such a big architect that you don't even write code any more.
  10. Re: Well...[ Go to top ]

    I forgot to comment on the actual article: Never assume you have the best design. Most smart people assume they know it all, but refuse to admit they're wrong when they are. And given that they are human, they will be wrong about 20% of the time no matter how good they are. The best, smartest people I know come up with solutions that are 60-90% right always, and can hone in on the 40-10% that they're wrong about very quickly with no ego investment.
  11. Re: Well...[ Go to top ]

    " 6) Become such a big architect that you don't even write code any more. " At this point realise you have no pratical skills left and spend all day doing UML and Powerpoint.
  12. it is a good suggestion[ Go to top ]

    the way one has to proceed for designing is good one.especially for new comers into the design phase
  13. Re: Well...[ Go to top ]

    Dammit, you can tell when my ADD kicked in my original message. The last three steps are pretty empty, probably because I don't do those roles right now. At the higher level, architects need to learn about how to manage projects economically, not just make the best technical solution: - reuse code, standardize where feasible/useful/possible, such as languages, frameworks, vendors, and the like. You'll need a bullshit sensor for when the salesman come in - implementing a usable software development process. this is one of the hardest tasks in known history, I'd guess less than 10% of places can do this successfully - budgeting and realize what you can accomplish with how much money is available. A pie-in-the-sky design is nothing without the money to pay for the people to build it - simplifying as much as possible - developing your people and adding people you need, reforming and/or getting rid of poor performers - managing your systems in a limited hardware setting. Computing power may be dirt cheap these days, but the people to run servers aren't. and most of all: - requirements requirements requirements: managing expectations, getting enough detail, getting CYA-addicted a-holes to commit to scope, preventing scope creep, fitting requirements into schedule and budget (pick two: features, cost, schedule)
  14. Re: Well...[ Go to top ]

    6) Become such a big architect that you don't even write code any more.
    What's that supposed to mean? An architect should always write code or else he will end up creating "smoking" designs that has nothing to do with the reality - I have seen that before dozens of times. At minimum, the architect should write spikes and poc's of new designs and frameworks. In fact, I think that a development team must not have an Architect at all. At most, a Lead Developer, helping the less senior developers to come up with a reasonable design.
  15. Re: Well...[ Go to top ]

    6) Become such a big architect that you don't even write code any more.


    What's that supposed to mean? An architect should always write code or else he will end up creating "smoking" designs that has nothing to do with the reality - I have seen that before dozens of times. At minimum, the architect should write spikes and poc's of new designs and frameworks.

    In fact, I think that a development team must not have an Architect at all. At most, a Lead Developer, helping the less senior developers to come up with a reasonable design.
    You dont need an architect if you only have one team anyway - an architect role only emerges in large multi-team projects. Paul.
  16. Becoming an architect requires you to raise from the pack. It is essentially a matter of applying the "Dogbert consults" (TM) pattern, which of course requires some chutzpah. Here is how to become an architect, when faced with another guy like you ("Bob"), who also wants the job: 1. Come up with some idiosyncratic design and framework that somehow smells of a current trend. 2. Defend your design with teeth and nails in every meeting. Preparation helps, make a list of 10 reasons why Bob's design sucks. If your bladder is bigger than that of other people, and there is lots of coffee around, then that helps too. 3. Introduce your framework in some central place of your company's business. 4. Use time after work to expand your design such that it adds new features. Note that this may mean that you no longer will have a social life, but a true architect does not need such a thing. 5. Introduce subtle changes that mean that others, especially Bob, will need to continuously adapt. Explain to others why your new features are the best thing since sliced bread. 6. Humiliate Bob, ideally in presence of a customer or superior, by explaining why their code and design is a bad idea. 7. Coerce Bob into doing things your way. Watch as Bob's morale goes down. Eventually he will quit or do something he will regret. You have gotten rid of Bob, your design is inside of the code base, congratulations, you have become The Architect. (Dogbert Consults is a trademark of Scott Adams)
  17. A better question would be why would you want to become an "architect"? My personal experience, in two different organizations (one large, the other very large), is that the architect role sucks. You attend an endless series of meetings, you generate stacks of PowerPoint, you make recommendations and proposals based on years of experience and months of research, and in the end the development teams do what their first line managers (who generally consider you a nuisance) tell them to do regardless of the "direction" you've provided. I would much rather continue to build, marketable, technical skills as a senior developer than do a job that sucks just to have a title that sounds cool to the uninitiated. As one of the other posters suggested if you want a cool title just print yourself some business cards with the title of your choice, e.g., King of the World, Fount of Knowledge, or my personal favorite: Dean of Women.
  18. Re: How do you become an Architect?[ Go to top ]

    A better question would be why would you want to become an "architect"? My personal experience, in two different organizations (one large, the other very large), is that the architect role sucks. You attend an endless series of meetings, you generate stacks of PowerPoint, you make recommendations and proposals based on years of experience and months of research, and in the end the development teams do what their first line managers (who generally consider you a nuisance) tell them to do regardless of the "direction" you've provided.
    Or better yet some non-technical person generates stacks and stacks of PowerPoints containing analysis with which you adamantly disagree, then proceeds tell all comers that if they want the rationale and justification they can talk to you because you are the expert behind the analysis.
  19. The best title for a business card: intergalactic emperor.
  20. http://www.bredemeyer.com/who.htm
  21. I would much rather continue to build, marketable, technical skills as a senior developer than do a job that sucks just to have a title that sounds cool to the uninitiated. As one of the other posters suggested if you want a cool title just print yourself some business cards with the title of your choice, e.g., King of the World, Fount of Knowledge, or my personal favorite: Dean of Women.
    I agree with your comment.
  22. Re: How do you become an Architect?[ Go to top ]

    A better question would be why would you want to become an "architect"?
    Essentially for many people, the answer is: Because your company instructs you to. A lot of very large organizations work along the lines of "architect or bust". If you are not becoming an "architect", your job is due to be offshored. Which is one of the reasons why there are so many bad architects around - panic and fear hardly spawn bright and brilliant ideas ;-).
  23. My name is Art Vandelay! I am an architect! I am unemployed and stay with my parents! yada..yada..yada...
  24. Everyone is an architect...[ Go to top ]

    I've had to interview a number of people ranging from 5-15 years experience and my question is...who isn't already an architect? To me, a developer == architect because the majority of people I've interviewed have had the title but not the experience. Or at least that's the title they give on their resume.
  25. The term 'architect' tends to mean different things to different people, and is used to refer to a variety of roles. It seems to have become particularly watered-down of late, in the Java world at least, to mean anyone who has ever served as lead developer on a project, no matter how small. That being said, to me the title 'architect' applies to people who have attained a firm enough grasp on the tactical issues involved in software development that they are able to think and act strategically. In other words, an architect is in the habit of (and has sufficient experience to) weigh the risks and rewards of a given technical decision against values such as flexibility, extensibility, maintainability, testability, reusability, etc. as well as against potential impacts on other teams such as operations, test, CM, build/deploy, production support, and so forth. So to become an architect, a developer would need to do the following: 1. Spend time learning about the issues that affect the other teams, and learning more about what they do and how they do it. (You can do this in part through reading, but IMO there's no substitute for talking with people who are on the front lines to get a true understanding of the problems they face.) 2. Spend time learning about the 'ilities', through reading, discussion, and experimentation, and become familiar with some of the current tools, frameworks, design techniques, etc., that developers have used to address them. 3. In addition, work towards making yourself an expert in at least one programming language, as well as at least two other technologies (e.g., XML, ORMs, web application frameworks, etc.). One of the best ways to do this is by reading code, a much-neglected skill. Use JAD liberally (where needed) to explore any language or framework features that you don't fully understand, and wrestle with the code until it yields its secrets to you. You won't regret it! "...and then you'll be a Man^H^H^HArchitect, my son (or daughter, as the case may be)." ;-)
  26. The question is wrong[ Go to top ]

    I think the term architect is misused in a similar way of professor. A professor is a position in an academic institution, usually head of a department. Professor is not a title. Likewise an architect is simply a person that has a position where he or she looks at the bigger picture as opposed to a developer that has a narrower scope. An architect is not a developer that has read so many design patters that he has ascended into a "higher being". :-)
  27. The Accidental Architect[ Go to top ]

    I recently attended a SOA seminar and when asked for a show of hands on who was an architect, I raised my hand. When asked if any developers were in the crowd, a chuckle ensued and -- I raised my hand again. Funny thing was, nobody noticed (or cared). I think that's sad, and the developer bashing I've seen in "architect courses" is even sadder. My tips for becoming an architect: -Gain the respect from the developers actually implementing solutions. You should be able to jump in and get your hands dirty. I've also found that you need to have a good working relationship with system or business analysts. -Prove yourself on successful projects. Word travels fast when your design is good. -Develop diplomacy skills. Lots of managers feel that architecural decisions from somebody else make them look technically weak. You need to find a way to sell the best idea, and cut through red-tape. -Think big picture, think strategically, think abstactly. The challenge of a good architect is to be tactically and strategically proficient. Developers and managers often fall to either side. -Read, read, read.
  28. I tried to resist this thread for a while but as it's stayed on the top and people are actually chiming in with similar sentiments I just can't take it anymore. .. No self respecting genuine developer I've known personally (to hopefully discount / save me from innocents ) would actively seek out such an ignorant name for a job description. It's no wonder all of the large organizations that employ this ancient method of three old wise men doling out "Architectures" to the stupid masses of developers always seem to fail or spend too much money or end up with pieces of crap software products. A ~real~ architect is someone who writes code using the designs he creates on a daily basis. He also doesn't shoot himself in the foot by deciding that only his blessed being can possibly handle design decisions and allows the rest of his "team" to also "architect" their own software. It's the only way your team will grow and get better. grrrrrr.....
  29. I tried to resist this thread for a while but as it's stayed on the top and people are actually chiming in with similar sentiments I just can't take it anymore. ..

    No self respecting genuine developer I've known personally (to hopefully discount / save me from innocents ) would actively seek out such an ignorant name for a job description. It's no wonder all of the large organizations that employ this ancient method of three old wise men doling out "Architectures" to the stupid masses of developers always seem to fail or spend too much money or end up with pieces of crap software products.

    A ~real~ architect is someone who writes code using the designs he creates on a daily basis. He also doesn't shoot himself in the foot by deciding that only his blessed being can possibly handle design decisions and allows the rest of his "team" to also "architect" their own software. It's the only way your team will grow and get better.

    grrrrrr.....
    Excellent post! Exactly. I truly believe that any good, strong Software Engineer is indeed a Programmer/Applications Architect. Period. It can't be any other way. To be a genuinely good developer one must enjoy what they do, i.e. designing and writing applications code, and putting modules together, building a system... Programming is a craft, and the only way to do it well is to do it with passion! And if you indeed have passion for programming, for designing solutions on all levels on a daily basis, would you really want to give it up and move to another "more senior role?" If someone becomes an "Architect" because 1) They have never liked writing code; 2) They love going to the meetings; 3) They are political and enjoy seeing themselves "above" the programming masses; 4) The position pays more than the developer's position, etc. - then chances are they are just useless bureaucrats and nothing else... Unfortunately, the title hierarchy in todays IT organizations is completely messed up. Developers are considered just "code monkeys" who are supposed to take orders from tech leads and do what they are told. Tech leads go to the meetings with architects/bureaucrats and dev managers where they make "high-level" decisions and pass them to developers. Most developers in such organizations fond themselves completely out of the decision making loop, which leaves many talented developers frustrated and forces them to change jobs. Such organizations end up with a handful of useless but very political architects and tech leads, and scores of unmotivated incompetend developers. We know what the results are... I believe that there should be no such thing as a "junior" developer. A programmer is either good or bad. Period. An unexperienced programmer can still be very good. Such people are always willing to learn and absorb knowledge from the people they work with. And every decent developer should be involved in the decision making process because they, sure as hell, have some good ideas to offer. If you have developers that you feel cannot contribute any useful ideas to the application architecture, then, perhaps, you have chosen wrong people for theh job.
  30. I tried to resist this thread for a while but as it's stayed on the top and people are actually chiming in with similar sentiments I just can't take it anymore. ..

    No self respecting genuine developer I've known personally (to hopefully discount / save me from innocents ) would actively seek out such an ignorant name for a job description. It's no wonder all of the large organizations that employ this ancient method of three old wise men doling out "Architectures" to the stupid masses of developers always seem to fail or spend too much money or end up with pieces of crap software products.

    A ~real~ architect is someone who writes code using the designs he creates on a daily basis. He also doesn't shoot himself in the foot by deciding that only his blessed being can possibly handle design decisions and allows the rest of his "team" to also "architect" their own software. It's the only way your team will grow and get better.

    grrrrrr.....
    +1
  31. poo[ Go to top ]

    Joseph Ottinger, Please stop posting f'ing poo like this. Thanks a lot.
  32. Socialize !!![ Go to top ]

    If you are working for a big company where you have to report to managers who don't have any clue about the technology, then I would say the best practice is to learn how to socialize with them!!
  33. That's it: socialize[ Go to top ]

    All this knowledge may be good and well, but the times for lone heroes are over. Nowdays, I find it much more important to be able to "sell" your ideas to a team, be them managers or software engineers. If you become the guy, who always knows better, I would not foretell a long-term career, not in a corporate environment, at least. Of course, it helps if your ideas are backed by knowledge and experience, which is also hopefully seen on your results. (However, in such corporate environment a quick and cheap hack is favoured most of time, rather than a longer, nicer architected solution. Remeber? They are managers, with no idea of technology, but they do know numbers.) It is more and more important to be able to build a team and sell ideas, rather than pure knowledge alone. As it was said: socialize! IMHO. Cheers Tibor
  34. What is an architect?[ Go to top ]

    Wikipedia says
    An Architect is a person who is involved in the planning, designing and oversight of a building's construction. The word "architect" is derived from the Latin architectus or from the Greek arkhitekton. In the broadest sense an architect is a person who translates the user's needs into the builder's requirements. An architect must throughly understand the building and operational codes under which his or her design must conform.
    so thats you lot ruled out
  35. I think, "Software Architect" title is very lucrative. i found most of the developers and IT guys are interested on this title, whether they are experienced or not.. :) personally, i belief the following qualities are important for an architect: 1. gentle man, who try to understand every one's idea 2. prompt in new idea generation. 3. aware about most of the pitfalls and security issue. 4. who can properly explain their idea through documentation or open discussion 5. good idea about cost and risk analysis ... 6. who can forecast 7. analysis an idea with abstract tools. (it is better when a development team is mixed of various technologies) 8. In touch with most of the technological group. 9. Who can lead a great brainstorming session 10. who can convince marketing and business dude with proper explanation thats all..
  36. Architect = lead programmer. Am I the only one who expect the project team to make their own decision? No need for a wise man... just a lead programmer who can make the final decision based on his team members opinions and know what is happening in the other projects (to try to go in the same direction).
  37. Architect = lead programmer. Am I the only one who expect the project team to make their own decision?
    No you are not but I wish you where. Where I work we are currently trying to clean up after years of "projects teams that make their own decision". The decisions they make are good from the view of solving the problem assigned to the project. The result is sub optimal solutions. Data and logic copied and scattered throughout several systems. There has to be someone that has another scope whatever name you have for that person(s).
    No need for a wise man... just a lead programmer who can make the final decision based on his team members opinions and know what is happening in the other projects (to try to go in the same direction).
    Just looking at other projects isn't enough. Projects is just living for a short period and you can't expect to be so lucky that the project that works on the system you should consider is currently running. Systems/applications live a lot longer and it is them you have to consider. That is why you need someone that coordinate things between projects.
  38. Re: How do you become an Architect?[ Go to top ]

    I would strongly agree with what Bjorn has said. It is naive to say that a project team should be free to make their own decisions, unless there is one and only one project in the company. The architect is the person that is asked to look across many various systems to see the patterns that emerge across them. If you are a developer, even a lead developer, you often do not have that visibility, and you will then tend to reinvent the solution yourself, especially if you are under certain deadlines. I think much of the confusion is based on the fact that there are different types of architects. An enterprise architect is different that a domain architect, who is different from an application architect. For example, as an SOA architect, one of my primary concerns would be the services that compose the system, and the interfaces that make up the service. I could care less what algorithms and programming language the developer uses to code the service. I leave that concern to the lead developer of each service. Having said that, my approach would be much different if I am acting as the applicaion architect. Now I do care about the programming language, algorithms, and frameworks used. My only point is that it's just a matter of role and context. The work "architect" has no meaning without the proper context. Joe Pardi dotJ Software http://www.dotjonline.com
  39. Read, read, read! I am a bookworm.
    I guess u r a "Reader" then. Does it rhyme with architect?
  40. obfuscate, obfuscate, obfuscate
  41. who cares[ Go to top ]

    I have no desire or need to be an architect. I love to code and solve problems. Being an architect means you don't have time to code and gain deep experience. instead, they are stuck in meetings all day. Books are nice, but frankly they don't teach you anything in terms of getting the app coded, tested and deployed. that knowledge comes from doing the job, not talking about it. also, an architect has to show he knows technology before he gets my respect. if he doesn't understand technology, that person isn't an architect no matter what his title says. so all this talk about being an architect is just a lot of hot air. how many people have been on projects, where the tech lead was the one really driving the project, while the "architect" did very little. those who can do, those who can't fake it. peter
  42. I have spent long hard hours thinking about this question :-) My business card states exactly what I do Hang on a sec, I can't remember it, I think I have one in my pocket...... Ahhh, there it is "I make stuff happen" Call yourself what you like, but if you can make it happen, people want you, businesses need you. If you can make it happen and not hurt peoples self esteem, wow you really are a GURU. Whatever happened to that, GURU. I remember when the popular phrase was he's a GURU. I think Mr. Gates started the Architect thing with him becoming MS Chief Architect. I would have to say if any one deserves the title he does. That's about a nickels worth :-) Have a fantastic day.
  43. Re: How do you become an Architect?[ Go to top ]

    Instead of arguing what an architect's required characteristics are, I suggest starting from the other end: 1. define what the architecture is (this is the most difficult task - RUP can help as it clearly defines roles for development teams) 2. define the architect(architecture team) as a person(team) responsible for the architecture 3. decide what characteristics are necessary for accomplishing the goal - architecture Consultancy bill: Writing a post: 1$ Know what to write: 999$ ---- 1000$ http://www.enterpriseware.co.uk
  44. Reading is nice, but......[ Go to top ]

    It's a combination of lots of reading, mega-tons of real world experience, leadership skills, and last-but-not-least a decent personality. One last thing, make sure your ego is not so huge that you can't fit through the door to your office :-) I have seen some great architects in my time and also my share of just all-around horrible people that got an architect gig through the good old boy system (who you know vs. what you know). Just my 2 cents from the Java EE trenches, Tom Pridham
  45. I've written on this subject recently, in the introduction to my upcoming book, "Release It!". Two divergent sets of activities both fall under the term "architecture." One type of architecture strives toward higher levels of abstraction, more portable across platforms, less connected to the messy details of hardware, networks, electrons, and photons. The extreme form of this approach results in the "ivory tower"---a Kubrickesque clean room, inhabited by aloof gurus, decorated with boxes and arrows on every wall. Decrees emerge from the ivory tower and descend upon the toiling coders. "Use EJB container-managed persistence!" "All UIs shall be constructed with JSF!" "All that is, all that was, and all that shall ever be lives in Oracle!" If you've ever gritted your teeth while coding something according to the "company standards" that would be ten times easier with some other technology, then you've been the victim of an ivory tower architect. I guarantee that an architect that doesn't bother to listen to the coders on the team doesn't bother listening to the users, either. You've seen the result: users that cheer when the system crashes, because at least then they can stop using it for a while. In contrast, another breed of architect rubs shoulders with the coders, and probably is one. This kind of architect does not hesitate to peel back the lid on an abstraction, or to jettison one if it does not fit. This pragmatic architect is more likely to discuss issues like memory usage, CPU requirements, bandwidth needs, and the benefits and drawbacks of hyperthreading and CPU bonding. The ivory tower architect most enjoys an end-state vision of ringing crystal perfection, but the pragmatic architect constantly thinks about the dynamics of change. "How can we do a deployment without rebooting the world?" "What metrics do we need to collect, and how will we analyze them?" "What part of the system needs improvement the most?" "By the time this launches, what version of the interfaces will our counterparties be using?" When the ivory tower architect is done, the system will not admit any improvements; each part will be perfectly adapted to its role. Contrast that to the pragmatic architect's creation, in which each component is good enough for the current stresses---and the architect knows which ones need to be replaced depending on how the stress factors change over time. For this discussion, I would also add that the architect must be a leader. Architects rarely have enough authority to truly enforce conformance to their architecture. I've never seen a single system blocked from going into production just because it didn't fit enterprise standards. That means the architect, if they aren't on the individual project teams, work through influence, not control. Hence, the need for leadership and earned (not demanded) respect. Leadership does not imply infallibility. "Always having the best design idea" is a really dumb goal. Being able to rapidly converge on a great design, together with consensus from the development team, is a much better goal. Understanding forces (like the -ilities, production operations, and good interface design) and bringing them to the discussion is key. Knowing the most patterns doesn't prove anything, and it definitely doesn't imply better designs. Cheers, -Mike Nygard mtnygard at charter dot net http://www.michaelnygard.com/ Author of "Release It!" http://pragmaticprogrammer.com/titles/mnee/index.html
  46. Re: How do you become an Architect?[ Go to top ]

    Be able to recognize and vocalize the pros and cons of every idea
    Thts wat an architect must know... just introducing gud designs is not enough... one must Convince ppl..must be able to explain plus and down side of his design.. Sudhir Nimavat
  47. More than ...[ Go to top ]

    Zachman ? TOGAF ? E2AF ? EUP ? Being a good "software designer" is not the same as being a good architect - you can design "good" software, that has the taregeted the wrong business solution. A good architect has to be not only an ubber designer but also an ubber psychologist and an ubber clairvoyant for the business (which at the end of the day is what matters). Think strategically, develop tactical.
  48. .. by listening.[ Go to top ]

    The best way to become an Architect is by listening. - Listen to your business customer. At the end the day your designs are only good if it meets his or her needs. - Listen to developers. You may have the best blueprints, but they are worth nothing if you don't have developers on board to build them. Paul's Blog / Architect
  49. It is incredible to realize how much space you can discover under (what was previously considered to be) the bottom. There are weeks and weeks of posts around nothing on TSS (or sensationally ridicules, is there anybody who remeber that regarding TCP/IP unreliability ?), but this.....
  50. I Here is one of the simpler ways. - start understanding some buzzwords and talk about them. - Discuss your architecture in various forums to get the pros and cons. - concentrate more on what really architecture is and get your hands dirty by writing some code often (otherwise there is a danger that you may forget about programming completely) - Be a best listener and proactively approach team to get the inputs of their experience on working on a system designed by you. kalyan
  51. I used to work in a company where there was the Chief Architect, and 5 guys beneath him who were Specialised Architects. Before you did ANYTHING you were expected to go and tell these guys what you were about to do. Every so often these guys would look through the code to see if they could find any bad code, even though we were all agile and we did regular code reviews on top of pair programming. No trust. I hated such a restrictive environment, especially since one of the Specialised Architects was 7 years younger than me and had just left college 6 months previously. How he could ever have had enough experience for that role is beyond me - just because he could bulls*** the boss. It was not a case of sour grapes, (I don't want to be an architect) but rather I would like to be left to get on with my job, and be given enough trust that I can code without a 21 year old boy giving me a hard time cos he doesn't agree with my ideas. Anyway I left for another post and I am loving actually having the freedom do my job on a day to day basis, with input from architect when need be.
  52. Re: How do you become an Architect?[ Go to top ]

    I hated such a restrictive environment, especially since one of the Specialised Architects was 7 years younger than me and had just left college 6 months previously. How he could ever have had enough experience for that role is beyond me - just because he could bulls*** the boss.
    I think your frustration comes down to this from the original post:
    If you can grok it and regurgitate it at the appropriate times, you'll be The Idea Guy.
    I'm sorry, "the idea guy"? Sounds more like the "no idea" slug. I don't think describes the kind of person who will be a successful architect. It sounds like the kind of person who could be "chief regurgitator." A true architect should be someone with good conceptual understanding and who can design on a high-level. Regurgitating esoteric terms and acronyms at the appropriate times might get you promoted but if that's your idea of skill, then I don't think you should even be in software development at all. So, for people wondering why there is so much antipathy towards this post, it's because it's often the worthless bullshitters that get put into these roles and are either detrimental to development or systematically ignored.
  53. Re: How do you become an Architect?[ Go to top ]

    So, for people wondering why there is so much antipathy towards this post, it's because it's often the worthless bullshitters that get put into these roles and are either detrimental to development or systematically ignored.
    I very much agree. I think this applies to any "senior"-level position in the software industry. The less competent (or the more insecure, for whatever reason) the person in the role of a Development Manager, Architect, or Tech Lead, the more obstructive they are in the overall process. People like that vigorously protect their ground by trying to exclude as many people as possible from the decision-making process. They can rarely be found at their desks, they spend most of their time in meetings behind closed doors - endless meetings that result either in zero action items, or in generic directions that often only offend the thinking programmers who feel being treated as, basically, typists. That said, I have been lucky to have worked with a few very strong SEs in the Architect role who were capable to provide a very keen, helpful insight into the task on vertually any level. But these guys are just good software engineers, period. I very much agree with those who point out a necessity for a good architect to be able to convey his/her thoughts and ideas in a very clear way. Again, I believe that any good SE should possess this quality to a certain extend and be able to express ideas on paper and in person so that other people can understand, get engaged in the discussion, and follow. Unfortunately, this quality often gets replaced by the talent of smooth-talking and BS-ing, which often does nothing but impress the management and irritate the engineers, but leads the project nowhere. Again, true story... :)
  54. First of all Architects whose main skill is being able to smooth talk, discuss jargons with aplomb annoy developers, hurt morale and basically enjoy a symbiotic relationship with myopic managers who can only think about their next promotions. In my opinion an architect needs to be great developer first. Otherwise fellow developers just dont have enough respect for that person. Next experience and insight that the architect brings has to be such as that can seperate forest from the trees. There are number of architectural decisions that have to be made from time to time and this ability to balance tradeoff's combined with excellent development skills is what is required to accomplish that. Being an architect is not about kissing ass with your managers. A lot of times it is about putting your neck on the line for your developers and explaining to your managers that certain decisions are detrimental to the project, that a schedule is unreasonable and will result in failure and so on. Lastly an architect should be very approachable. Developers do not like architects with an attitude. Such architect tend to create distrust for their own skills. Be there when your developers need you and please can that attitude. This helps team building and promotes a spirit of cooperativeness. Even the most hardened "protect my territory" developer will come around if the architect is a approachable sharing member of the team. The cluture of a team is defined by the attitude of the architect. Sameer
  55. Re: How do you become an Architect?[ Go to top ]

    First of all Architects whose main skill is being able to smooth talk, discuss jargons with aplomb annoy developers, hurt morale and basically enjoy a symbiotic relationship with myopic managers who can only think about their next promotions.

    In my opinion an architect needs to be great developer first. Otherwise fellow developers just dont have enough respect for that person. Next experience and insight that the architect brings has to be such as that can seperate forest from the trees. There are number of architectural decisions that have to be made from time to time and this ability to balance tradeoff's combined with excellent development skills is what is required to accomplish that.

    Being an architect is not about kissing ass with your managers. A lot of times it is about putting your neck on the line for your developers and explaining to your managers that certain decisions are detrimental to the project, that a schedule is unreasonable and will result in failure and so on.

    Lastly an architect should be very approachable. Developers do not like architects with an attitude. Such architect tend to create distrust for their own skills. Be there when your developers need you and please can that attitude. This helps team building and promotes a spirit of cooperativeness. Even the most hardened "protect my territory" developer will come around if the architect is a approachable sharing member of the team. The cluture of a team is defined by the attitude of the architect.

    Sameer
    Ha ha ha ha ha........ im not agree with u... its possible to develope a software without an architect... but cant be developed the way it should be... lol Sudhir Nimavat
  56. Re: How do you become an Architect?[ Go to top ]

    Easy how people can list out the functional specs of an architect. The system shall... First turn it around from what you think is "required" to what the market is asking for. As I see it company's usually have and people usually are architects with a specific skill, experience or gimmick: Types: Domain Architect - you add value by knowing the business well and less so the technologies Technical Archiect - you know a specific technology but are light on domain knowledge. .Net, J2EE, Oracle, SAP, etc... Process Architect - some domain or technology is important but the employer has no process or is culturally stuck. You bring methodology gimmicks (agile). Tier Architect - Presentation, Business or Domain Tier architect. Even batch vs Real-time architect. Business Architect - a PowerPoint smoothie. Help companies build a glossary of their dysfunction. Functional Architect - the security guy, the ORM guy, the logging system guy. Integration Architect - API wonk, the file pusher. the SLA jockey. Keeps a relationship with the integrating company. Acedemic Architect - don't code anymore, may not even design, quizes others on GoF patterns PM Architect - more technical or development manager, juggles many balls, sacrifices quality and cuts corners to deliver it IT ignorant business. The Stalinist Architect - all knowledge is kept and decisions made by this one person. The bottleneck. A control freak. They usaully have done something important in the past but are no longer adding value and riding on vapors. The Messianic Architect - all of the above, the second coming. The answer to all your problems. Charismatic. The silver bullet. It all sound so easy with this guy.
  57. Architect is like a CEO[ Go to top ]

    An architect to a development team is like a CEO to a company. What does a CEO do? Well... depends on which company you talk about. Some play golf all the times. (When I was in China, they correctly translate the title as the "Chief Eating Officer.") But in most places (read "small",) they also stayed up late and write documents and designs, like the one in my current shop in the Silicon Valley. Some others also do cleaning and making coffee in the office. If you become an architect, unless you are extremely lucky (or unlucky, depending on your point of view,) you would be like the former type: doing no real stuff and making empty talk. For some, like what I've been through, you have to work on everything from making marketing PowerPoint to fixes unit tests and build scripts. Maybe you can be spared of writing marketing PPT but probably nothing else. When I was a developer, I didn't need to worry about much of what happens above the product module. Do you still want to be an architect?
  58. If you do your job with passion, be it developer, architect, musician, whatever, you'll probably do the right things. In all cases, you should never lose sight of the main target: make your project succeed! And in order to succeed, you should: - Know about some of the existing techniques, their abilities, their limitations; - Accept not to know everything but never stop learning; - Know about the development process, having developed yourself is definitely a must (an architect must have been a developer); - Leave your ego aside and listen to what other people say : they often come up with good ideas, stuff you did not think of. Your job is to gather info from many sources; - Have good communication skills to transfer business constraints to the development teams and technical info and issues to your management; - Be pragmatic and adopt the "good enough" attitude; - Be pragmatic and write yourself a proof-of-concept of what you recommend; - Be pragmatic and know about the risks associated with your recommendations; - Be pragmatic and make sure the architecture answers the real customer needs and specifications. YAGNI is nice; - Involve other people, especially the developers who will be directly affected by the architecture, in your decisions or recommendations; - Define an architecture that you would happily use yourself. Conversely, never recommend anything you would not use yourself as a developer; - Be humble. Never forget you are merely a cog in the team machinery. Be accessible and ready to answers questions and justify choices; - Be humble. Be ready to change your design if someone else comes up with a better idea; - Be humble: you're at the service of the development team, not the other way around. I believe architects have a role to play, to keep development consistent, to see the big picture and avoid repeating the same mistakes. People who want to do architecture to climb some kind of social hierarchy will most likely lack the humility to communicate with the rest of the team, an attitude which can jeopardize a project. Yann
  59. Ted is a bery bery funny fella. Infect he is hilarious on this one.
  60. This topic is indeed really interesting in some aspects. Here is my story: I like software development and software engineering all my life. Until now, I have 10 years of experience (details can be seen at www.hanoian.com), but still don't have the title of "Software Architect". Many people who know me have told that I have quite an awesome capability in software design and implementation. However, becoming an architect requires some other skills that I don't have. For example, in a meetings where people don't know a thing about Design Patterns, there is no way for me to teach them. Or guys fancy them selves as software architects, but they are only good at vibrating bullsh*t seem always be able to get high positions such as CIO or Technology Manager in corporations, and they wouldn't here anything about real technologies in the meetings. So, I guess in order to become a Software Architect (I don't mean a real one, but a title), it is not about your technical ability, but the ability of bullsh*ting and you must have a right amount of Stupidity. (Not too stupid to get ignored, but not too smart so that nobody can understand what you say).
  61. Big Picture is the Easy Part[ Go to top ]

    If an architect is supposed to deal with the big picture only, then who is supposed to deal with specific challenges? When you look at an architectural diagram of a software system, it's pretty much the same as any other one. Three-tier system with frontend, business tier, and database or legacy backend. But try to solve a tough problem like how to sent a message from server to the client browser without a refresh. Or try debugging a server when you have no stacktrace and the errors seem to happen randomly. You can easily read up on the current frameworks, technologies and buzz words to come up with a decent high level design. The software world needs very few "architects", but many many talented, innovative problem solvers (AKA engineers).
  62. The best way to become an architect is to be a civil cervant for live in some kind of it-ish department. You will become an architect automatically around age of 50. You dont need knowledge of anything, just sit and wait. Then you can finally burn public money.
  63. Architecture is more than just coding / technology skills, or having the best 'design idea' in a meeting. It is not enough to know what the 'right' thing to do is, you need to convince others of it :-). That is the difference between an 'architect' and an 'experienced lead dev'. One is not better than the other, but the skillsets are different. The architect needs communication skills and 'technology breadth' - with at least enough depth in order to make the right decisions. On the other hand, a lead dev has to have more 'technology depth' - with at least enough breadth in order to be aware of touchpoints to other areas. Some experienced devs do become good architects, while others choose not to make this transition. For those devs who do want to become architects, it is important to interact with other architects, and keep up-to-date with the latest thinking. One good site for this is http://www.skyscrapr.net - a community site for architects that is run by the architecture team at Microsoft. (I work at MS now, although I spent years in the java world before - which is why I still read TSS). Thanks, Atanu
  64. http://myjavaserver.com/~sudhirnimavat/