What is an Architect?

Discussions

Blogs: What is an Architect?

  1. What is an Architect? (30 messages)

    In his blog, Okke van’t Verlaat ponders the question: What does it take to really be an architect? In this navel gazing exercise, Okke considers different variant definitions for Architect as defined by the SCEA and other organizations. The motivation for Okke's blog comes from an old but still relevant article written by Martin Fowler. In that article Martin classifies architects by how they work.
    In many ways, the most important activity of Architectus Oryzus is to mentor the development team to raise their level so that they can take on more complex issues.
    With so many different definitions for Architect, how is one suppose to identify who is and who is not one? Assuming that we get past that issue, the question still remains: what does it take to be a good architect?

    Threaded Messages (30)

  2. The problem with the term 'Architect' is, there is no wide spread acceptance of its definition and to some extent all the other titles suffer from the same problem (I have seen 'Senior Programmer' leading an IT project).

    Different definitions referred to in the blog come from the fact that architecture has different disciplines such as application architecture, information architecture, enterprise architecture and more. For example, SCEA's definition appears to be more applicable to an application architect. OpenGroup's definition sounds generic but probably not widely accepted.

    But why focus on the correct definition of the term architect? The question, "what does it take to be a good architect?" is what the IT community needs to answer. To me, regardless of which architecture area the person fits in or which certification he/she has, an architect
    1. Must be able to understand the business problem and identify the technologies to solve it
    2. Must know the options available to solve the problem and be able to evaluate them in light of the constraints and requirements
    3. Must be able to make technological decisions and be able to defend them in front of the stakeholders in reference to the bottom line (money or whatever it is)
  3. What does it take to be an architect? A big ego...
  4. I will add a point of clarification...

    It used to be adequate to be a programmer...

    Then everyone was one of these, and there was no way to distinguish the better ones from the common herd. So we invented the term Software Developer. Then everyone became a Software Developer-- everyone wanted this title.

    True enough, software was becoming more of a craft than a simple hacking session. But once everyone used the monicker of Software Developer, soon the better ones needed a way to distinguish themselves from the common rabble. So we came up with the term "Software Engineer".

    In the late 1990's everyone wanted to become a Software Engineer (my mechanical engineer friends cringe when we call ourselves 'software engineers'). Now, everyone uses the term Software Engineer, and once again, there was no way to distinguish the better ones from everyone else. To be fair, there was indeed, a measure of engineering-type acumen to be applied to software as systems grew more complex and difficult to manage.

    So now we use the term Software Architect, or just Architect. My question is, how will the better ones distinguish themselves from everyone else who now uses this term? Or, what will be the next term du jour...?

    Food for thought, that is all...
  5. Then everyone was one of these, and there was no way to distinguish the better ones from the common herd.

    I think to better distinguish them, who are "effectively" leading them and who are just following.

    And to add to the discussion, I would rather say that Architects are the one who sees the big picture while developers are the one who sees the smaller pictures that composed the big picture.
  6. An architect is what a recruitment agency tells a client they need when the client asks them to find someone who knows how to build and make shit work.

    The agent then procures a candidate senior developer who is looking for a "promotion" to fill the client's need for an architect.

    At the interview the "architect" is asked to draw on the whiteboard the architecture utilized on their last project. Unsure of whether the interviewer is asking for a system architecture, software architecture, component architecture, or some other architecture they draw none of the above and instead draw a class diagram.

    The interviewer, not knowing what an architect or architecture is in the software world, is suitably impressed and hires the candidate.

    On their first day the employee is told by the employer, at a very abstract level, what they need to deliver.

    The senior developer after the "promotion" discovers that they are doing the same shit on a different day.

    I have interviewed many developers wanting "promotions". Some into architecture, others into software engineering roles, some into web development or web services. Basically whatever the buzz word is at the time.

    Most "architects" cut code. Even if they (apparently) only "prototype". And I suggest being suspicious of those that don't roll their sleeves up and get their hands dirty.
  7. Kangaroo Island[ Go to top ]

    Remember Kangaroo Island?
  8. What Does It Take To Be An Architect?[ Go to top ]

    It used to be adequate to be a programmer... Then everyone was one of these, and there was no way to distinguish the better ones from the common herd. So we invented the term Software Developer. Then everyone became a Software Developer-- everyone wanted this title.

    Maybe terms like Software Engineer and Architect are b.s., but Software Developer is in no way pretentious or artificial. It simply reflects the fact that creating software requires more than writing code in a programming language; typically, a Visual Basic developer is going to spend quite a bit of their time dragging & dropping & aligning widgets onto forms, messing with property editors, etc.

    Furthermore, it's probably a good idea to sell yourself as a Software Developer since this doesn't sound restrictive - you wouldn't people to think that as a pure Computer Programmer, you're unwilling to do documentation work, run installations, attend requirements and pre-sales meetings, or do any of the the other stuff that is not as much fun as programming, but is always part of the job.

    In short, it's just a slightly more appropriate job description, not an exclusive club of some sort.
  9. You know... it's comments like this that get my dander up. Mr. Michaels, it does not take a big ego to be an architect. In fact, all good architects [in my experience] were and are very humble men and women.

    What they did share in common was a concern for the big picture as opposed to those narrow minded peon developers who cried "All architects are are developers with big egos."

    So think before your oral diahrreah gets out of hand.
  10. Am i a architect?[ Go to top ]

    A good architect should be able to take the pretty diagrams and drive out a detailed design.
    A good architect should be able to write solid code prefereably in several languages (when asked to do so).
    A good architect accepts responsibility.
    A good architect understands the underlying technology and the caliber of the team members who will be asked to deliver the final product.
    A good architect should know how to use a debugger.
    A good architect is willing to leave the office at the end of the day (or night) with "dirty" hands and sleeves rolled up to the elbow.
    A good architect understands the environment in which he/she works, politically and technically.
    A good architect must be able to justify the design and willing to accept corrections or alterations that represent "real world" conditions.
    A good architect reads and keeps up with new technology so that he/she can advise management and mentor developers.

    The quoted are the exact work tht i do in my organisation.. but often i get confused of wot my role is??? the reason for the real confusion is Im just 3 yr old kid in this field. But i hold the responsibility of a team lead, always co-ordinating with Projet Manager and Senior PM. Take part in project decision makings. I have never made any hard coding, but have always helped my members in getting things done. I have made some applicaitons to meet the clients spl requirements and integrated thm with our product. And many more critical solutions were given by me on the course of project developemnt as well as during the testing phases.
    Can anyone clearly tell me wot is my role??
  11. I would consider myself an Architect, but am now reconsidering after somebody I knew came out with the following quote:

    " I'm an architect , I don't code"

    Paul
  12. I would consider myself an Architect, but am now reconsidering after somebody I knew came out with the following quote:" I'm an architect , I don't code" Paul

    Surely this can't be true! - it should read
    "I'm an architect and I love to code (except I have a team of developers working for me who are lucky enough to do this and I contribute when I can)"
  13. Almost all the "GOOD" architects I have seen have been excellent coders in their previous roles. I have also known a few who refused to get promoted to Project Leads/Project managers and instead stuck to being architects.
  14. This is really very simple[ Go to top ]

    1. You make the decisions.
    2. You enforce the decisions.
    3. You take responsibility for your decisions.
  15. Standards[ Go to top ]

    This, among many other reasons, is why I think there should be some sort of accredidation process involved with software development and engineering. All other highly skilled fields require such a step to be allowed to practice the craft, and while our field is quite young when compared to the others, the need is still there.

    What I am suggesting is something similiar to the engineering exam most engineers must pass right after college, or how a doctor is board certified or the bar exam for lawyers.

    Quite a few people, especially those that are "self taught" may not like this concept, but it sorely needed.

    In doing this, we could then supply industry standard definitions of positions and fields, thus elleviating quite a bit of confusion. One small step towards a bright future instead of what we have now, which is anarchy.
  16. What is an Architect?[ Go to top ]

    To KNOW and UNDERSTAND what need to be done.
  17. What is an Architect?[ Go to top ]

    You're new here aren't you....

    All kidding aside. In my experience, Architects are people that don't code, they draft up technical documents about theoretical solutions..

    Sometimes they know how to code, sometimes they don't... and sometimes they just fumble around the business domain and the software buzzwords/languages/projects...

    that may be harsh...

    to correct your statement (They Should Know and Understand what needs to be done.)


    www.binaryfrost.com
    To KNOW and UNDERSTAND what need to be done.
  18. What is an Architect?[ Go to top ]

    Talk about taking the last few licks on this here decomposing horse. The reality is, anyone can call themselves an architect. Surely, there are more interesting things to discuss.

    (and yes, I am calling you Shirley)
  19. I think there is some validity to what a previous response described as programmer/developer desires to move "through the ranks" of various exotic sounding job titles. But just because your job title says you are an "Architect" it doesn't necessarily make you a good one. Some architects (I know a few) sit around and create presentable diagrams which are created to enlighten everyone on how the corporate "architecture" should be delivered and view the actual implementation as just a detail.

    Now there is absolutely nothing wrong with creating nice fancy diagrams. Afterall a picture is worth a thousand words but the picture by itself will never generate a thousand lines of code nor a detailed design. So....

    A good architect should be able to take the pretty diagrams and drive out a detailed design.
    A good architect should be able to write solid code prefereably in several languages (when asked to do so).
    A good architect accepts responsibility.
    A good architect understands the underlying technology and the caliber of the team members who will be asked to deliver the final product.
    A good architect should know how to use a debugger.
    A good architect is willing to leave the office at the end of the day (or night) with "dirty" hands and sleeves rolled up to the elbow.
    A good architect understands the environment in which he/she works, politically and technically.
    A good architect must be able to justify the design and willing to accept corrections or alterations that represent "real world" conditions.
    A good architect reads and keeps up with new technology so that he/she can advise management and mentor developers.

    There are many more statements that you could add to the list. We all will have a view of the "ideal" architect. What it boils down to for me whether I'm developing or architecting a system is this:

    I want someone who'll listen, admit mistakes (but not make many), and who can hit the keyboard running when a problem/issue comes up.
  20. What does it take to be an Architect?[ Go to top ]

    Agree. In addition to, I would like to add a few more statements imho.

    A good architect must participate in the project timeline preparation, and in most cases take primary responsibility on it - setup atleast two or more meetings with the Developers to carve it to a real timeline. MS Project :)

    A good architect may also be asked to/have to be good in recruiting/right picking the Developer candidates, after all the architect will be working with whom they recruit.

    A good architect may also have to deploy applications in and out.

    As somebody said here, yes, all kinds of documents & diagrams(technical, business, security, etc..) will also be done/completed by a good architect.
  21. Many of the points here relate to tasks that an "Architect" does. But in my experience of 30 years truly good archiects are rare. It's about some aspect of their mentality, they tend to be able to think more abstractly than the majority of developers. We all know the difference between programmers who create nothing but concrete classes and those that come up with abstract patterns that give their code much more flexibility and elegance. So with good Architects. Their designs are elegant and reflects an understanding of the business domain that often transcends a mere description of the problem in UML or whatever. They also seem to be able to see the broader effects on areas well beyond the immediate scope of the problem; they are often generalists and not technical specialists. So while devising a test for Architects is probably good news for people who devise such tests, it still will not guarentee a good Architect or Architecture, just one who can follow a cookbook - I've got a web app, let's have three layers, MVC - does that make me an Achitect? It's still about the individual.
  22. Architecture Role[ Go to top ]

    Now architecture role is more definitive than ever. because the software system are more complex, and there's so many underlying technologies. In fact, it's too difficult to decide which technology should be used for a project. Then an architecture tell us: This technology (maybe jsp/servlet, maybe ejb, maybe .net, etc.) is most suitable.

    There's also other roles in a project, e.g. project manager, who control project schedule mostly, and interview with clients; system analyst, who define customer's requirements; and software developers, programmers. They are roles, not persons. In a small project, project manager, system analyst, architecture roles may concentrate on one person. But the roles should be defined precisely.

    I think architecture should be free person in a team. He does everything and nothing. He may do not coding at all, but he should be very familiar with coding; He may do not interview with customers everyday, but he must share some time with customers; he may do not control the schedule, but he should know the schedule very well. So, that's a architecture, I think.

    -abel
  23. Specialisation[ Go to top ]

    In every discipline, complexities have over the years grown to such a level that we need to be able to handle them in a hierarchical fashion breaking them up into components so that the final task of rendering a workable solution is easier. Just as the field of medicine has specialists, who specialise in say Gynaecology, or perhaps say an ENT specialist, we need specialization in the field of IT as well.

    An architect is a specialist required to embrace technical problems at a particular level of abstraction. It is his job to understand the complexities associated with trying to provide a sometimes abstract solution and sometimes a more concrete solution using certain tools (software, hardware ..) for a given problem.

    No architect can provide a solution to everyone's liking primarily because such solutions dont exist. We have tried our best to tackle real-life problems using a binary realm, and unforunately the real life issues tend to be overwhelmingly complex and do not really have an exact binary mapping all the time.

    For good or for bad, whatever the case may be, the human society has the need for automation, and it is the job of the computer literates to try and do their best for a "better" tomorrow.

    Surely extremely mature people are required for this task, and whether people like it or not, maturity comes with age and experience. It is with maturity, and I am sure we have a lot of very mature people who come to this forum, that we are able to appreciate each other's views, and are able to come to a solution even though 5 different people may have 5 different views on a particular solution.

    So, to all the architects out there, I would like to urge you to think outside the box, beyond the realms that are normally expected of you, and hopefully, we can really have a better tomorrow.
  24. building a software system[ Go to top ]

    From Wikipedia -

    "An architect, also known as a building designer, is a person involved in the planning, designing and oversight of a building's construction, whose role is to guide decisions affecting those building aspects that are of aesthetic, cultural or social concern. More generally, an architect is the designer of a scheme or plan."

    Substitute 'software system' for 'building' and keep in mind that in order to fulfill the 'oversight' role and to 'guide decisions' the architect should probably be more experienced and skilled than those he or she is guiding or overseeing.
  25. building a software system[ Go to top ]

    whose role is to guide decisions affecting those [software system] aspects that are of aesthetic, cultural or social concern.

    Um, what?
  26. The Architect word is a new label to the software industry for the self identity. Offcourse all the software terminology is a cloning from the Building and Construction industry.

    To me... as Architect should be a
    o Good Listener and Good Analyst first.
    o Person who quest on gathering updates on the business wrt to a domain and wrt to the technology.
    o Should be more visionary.
    o Should work with Decision Anaysis and Resolution pattern.
    o Should be a good Navigator.
    o Should also think himself as a investor and decide on the road map / solution for the problem
  27. John Zachman (ZIFA) has a view of development where the roles of 1) standards-maker, 2) owner, 3) architect, 4) integrator and 5) piece-parts-maker are characterized across "who-what-where-when-how-why" specialized to IT.

    In a talk I heard some years back, he underscored a strong difference in world-view between
    3) the architect (who is working to plan the solution to the owner's problem in the standards context),
    4) the integrator (who fits pieces of hardware and code together to make the system), and
    5) the piece-parts-maker (who is working to make pieces of code or hardware, context free).

    George Morrow, late chair of Morrow Designs, San Leandro, CA is quoted as saying "Anyone who trusts a programmer deserves what happens to him." (See Morrow). I read that the first time in a Jerry Pournelle Byte mag column as "Anyone who hires a programmer to design a system for him deserves what he gets."

    An architect suboptimizes subsystems to optimize the system. Integrators and piece-parts-makers often are irritated with the forced suboptimization.

    Thanks for getting this far.
  28. Architect : Going back in History[ Go to top ]

    Architects is a very old term from quite a few decades now. Architects need to architect solutions. For Software Architects they are software solutions.

    Ideally the role of an architect is of a visionary who has a bird eye view of a complex system before it is developed. He should be able to anticipate non-functional aspects of the system and should be able to understand and provide solution for the same.
  29. What is an Architect?[ Go to top ]

    From Architect's Duties:

    Crafting the right architecture to solve the problem at hand is only part of the duties of a project's chief software architect. He or she must also:
    * get it defined and documented and communicated;
    * make sure everyone is using it, and using it correctly;
    * make sure that it comes out in stages in a timely way so that the overall organization can make progress before it's complete;
    * make sure management understands it (to the detail necessary);
    * make sure the right modeling is being done, to know that qualities like performance are going to be met;
    * give input as needed to issues like tool and environment selection;
    * identify and interact with stakeholders to make sure their needs are being met;
    * make sure that the architecture is not only the right one for operations, but also for deployment and sustainment;
    * resolve disputes and make tradeoffs;
    * resolve technical problems;
    * maintain morale, both within the architecture group, and externally as well. The latter is done by providing a sound design, when needed, and providing good presentations and materials to let everyone know the organization is on the right track.
    * understand and plan for evolutionary paths. Plan for new technology insertion.
    * manage risk identification and risk mitigation strategies associated with the architecture.
  30. What is an Architect?[ Go to top ]

    There has been a ton of exceptional posts to "What is an Architect?", most of which I agree with. I only have 10 years experience in the software engineering/maintenance domain (with a bachelors & masters in computer science as a shove in the right direction). In all that time I only found 1 person that was a real Architect. One of the earlier posts really nailed it when they said these people are hard to find, because they are in fact, far and few between. I learned many solid principles from this Architect, and the one I would like to share in this blog is that a real Architect doesn't make people feel/look stupid, they foster a learning relationship and inspire you so that you can grow as an individual yourself.

    What you have to beware of is the "self proclaimed architect", in other words, they have been in the "business" so long that they have appointed themselves as an architect due to their 20+ years in. These ones are easy to pick out because they are arrogant and exhibit similar qualities only present within a Dark Sith Lord...remember fear leads to anger, anger leads to hate, hate leads to suffering!
  31. Architect[ Go to top ]

    A lot of in-the-business titles fall into category
    like:

    coders/
    programmers/
    developers/
    software-engineers/
    software-architects/

    but none of this can match a title

    "THE PROGRAMMER" in hackers definition.
    so this is the real architect...

    IMHO.