none
Should an architect code? If so, how much? RRS feed

  • Question

  • Hello guys ,

     

       be all you welcome to this just launched forum on The Architect Role

     

       I wanted to open the first discussion thread but Magnus was quicker than me and opened his

     

       Anyway, there's a recurrent question that has been around my head for years, and it's incredible how I was changing my mind about that over the time, though I'm not yet convinced on my current vision as I wasn't either before

     

       The question is, as the title states, should architects code? How proficient should they be in coding? Should they master the latest APIs? Should they know about those latest APIs but give the lead developers the chance of master them? Where is the right balance in the architect knowledge?

     

       I used to believe that an architect had to master APIs and platforms (directory server, DBMS, OS) better than anyone else if he/she wanted to hold the role. But experience showed me that such pretension is highly stressful and time consuming. You can't spend all the time you have in understanding every minor detail as you still need to architect your solution!!  (when were you thinking in doing it?)

     

       But the opposite extreme is also bad: an architect who doesn't care on latest programming and platform advantages could just model a too abstract architecture (when not outdated), creating a later problem to developers, who will have to map those abstract (irrelevant? ) thoughts into a concrete implementation

     

       There's a common consensus that establishes that the architect must know, but not necessarily do it him/herself. However, I still remember my experience with Enterprise JavaBeans (EJB), easy to assimilate, politically correct from any viewpoint, but a heavy stone for developers both in terms of coding (don't want to remember those XML manifests again ) and later execution (as a homework write, 100 times, "scalability matters", "scalability matters", "scalability matters", ...). So in this case where I failed was indeed so: I knew (about EJB) but I hadn't done on my own (yeah, the typical PoC was a complete success: the screen displayed "Hello, World!!", so what? )

     

       Surely this later consensus about the architect accompanying but not being part goes in the right direction but there are yet some considerations to take into account. What do you think?

    Friday, April 25, 2008 11:47 PM

Answers

  • Architect = risk reduction.

    In my opinion the architect is supposed to make an assessment of the situation she is facing and then decide on what she thinks will be the best solution to the problem at hand. This solution constitutes a route for others to follow and she will later be held accountable for how safe and effective that route was, and will be rewarded by how efficient it was.

    When you talk about:

    A network architect, security architect, application architect, process architect, web architect, data architect, information architect, infrastructure architect, business architect, solution architect, chief architect, enterprise architect

    You are just stating the scope of the risk, the scope of the decisions she has to make and will be accountable for. But at the same time you are determining a context because we naturally set scope through context. The risk can be a challenging technology, a politically charged situation or a complex business problem.

    Sometimes the key to the solution will be negotiation and bargaining, sometimes it will be sound knowledge of technology and on others it may simply be good communication. This means that each situation requires a different set of qualities and personal traits to solve them. So scope takes us away from a common definition for architect.

    But personally I think there are some common qualities and personal traits and those are risk reduction capabilities like assessing situations, comparing probable outcomes, etc… That is why I think you need to define the problem (risks) and then the architect that can handle them J

    The question shouldn’t be “Should an architect code?” the question should be “is coding a risk here?

     I participated as architect in government projects where I never saw a line of code and I never cared about it (there risk was not there) we were architecting processes beyond technology. But I also participated in the creation of frameworks at Microsoft where the code we were making was everything (the risk was there) and that made the difference as an architect.

    Your friend! Alex Jack

     

    Sunday, April 27, 2008 3:54 PM
  • This has been (and continues to be) a very interesting thread.  Let me say up front that, as an ex developer, I still like to code, but I am carefull to remind myself that is not my primary job.

     

    I agree with what has been said about the Solution Architect being able to code to develop Proofs of Concept and Architectural spikes, especialy when dealing with areas of technical risk in an architecture.  I am glad that someone pointed out that Infrastructure Architects exist and probably do not code or need to code. :-)  Business Architects, Security Architects, and other specialties are probably in the same boat. 

     

    There is another strong reason for a Solution Architect to be able to code and that is to maintain credibility with the developers that will have to implement his/her architecture.  One of the jobs of an Architect is to lead/guide developers in implementaing the architecture that they have set down.  The Architect needs to strive to be "snow proof" and that usualy requires a good deal of knowlege and experience with the development tools and language in use. 

     

    Bill

     

     

    Sunday, April 27, 2008 10:30 PM
  • Diego,

     

    I think that architects in an ideal world should code from time to time, so that they're still able to identify with the challenges of implementing their architectural designs.  That said, it is often difficult to do that, and still find time to rally thr troups, keep the architecture skills up to scratch, manage projects, and so on.

     

    What I try to do, is to involve myself in some aspect of the proof of concept type work so that I know that the reference architecture is going in the right direction and is a good point of reference.  That said, you really have to step away too, otherwise the team is not going to be able to learn from you, or understand your thoughts and wonderful ideas.

     

    I think that intimate knowledge of the implementation detail of a system is often counter productive to a good architectural design, as it is easy to be 'tainted' by the thought process of technology and implementation, instead of choosing unemotionally based on the best fit.  I don't code anywhere near as much as I used to do, for this reason, and will try to involve myself in productive situations such as peer reviews, presentations to teach technology, tools or techniques that might involve the writing of code, and so on.

     

    I think knowledge that there are API available to the architect to achieve a certain set of functionality is sufficient, that technically it is possible to achieve what the architect wants to achieve.  If the architect is unsure that such a situation occurs, then that is part of the analysis work, and proving it out with a PoC. 

     

    Parameter list details are required so that the correct data is available to the API, however having siad that, the concept on encapsulation and loosely coupled architectures should not mean that knowledge of an API list should drive the shape of the architecture visibly.

     

    The worst thing is an 'ivory tower architect', one that comes up with a perfectly designed, theoretically ideal solution, without considering the implementation detail.  That's almost as bad as hacking the solution together without a formalised design, as usually the solution end up with workaround upon workaround, and bruised egos.

     

    That's my 2 cents anyway.

     

    Martin Platt.

    Monday, April 28, 2008 10:43 PM

All replies

  • An architect is ultimately responsible for making tough decisions early in the design process. In certain cases an architect cannot make a decision until a certain hypothesis is proven right or wrong. This means that an architect needs to have the ability to create a quick proof of concept (working code) to demonstrate that a key piece of technology or an approach will work in the proposed architecture. For example, an architect may know that a solution needs to have a certain level of authorization granularity at specific performance goals. A choice needs to be made between a custom solution or buying a COTS software package from two vendors. An architect can make a decision based on recommendations or based on the marketing material from the vendor, but he or she won’t know for sure until a quick prototype is created to test the promised results against desired goals (quality attributes).


    The short answer is that a software (application) architect must be able to write code, but it is not his or her main responsibility.


    Constantin K.
    Firebrand Architect™
    http://www.SoftwareArchitectures.com

    P.S. Since the question didn’t specify the flavor of an architect I choose to disclose that I live in the business & software architecture worlds.

    Saturday, April 26, 2008 4:55 AM
  • Imho,


    an architect should most certainly be a coder.  However, that doesn't mean he/she should code in the day to day job, rather he/she should at least code with the technologies he/she's trying to use.

    For myself, I'm unable to create an architecture if I don't know how the technology works..

    Reading an article in a magazine doesn't give me a feel for the technology, just a theoretical overview
    I need to have some code grinding time to really get it.

    Proof of concepts are one way to get some experience with new technology, at least if they are executed right.  A hello world screen just doesn't cut it Wink  Personally I favor a complexity driven approach, tackling the most complicated piece of problem.  While my POC takes significantly longer to develop, it's saved my *ss and the  project a couple of times Smile

     

    Cheers

    Saturday, April 26, 2008 6:06 AM
  • On a practical note, you must be able to confidently field questions, even it is to say, "I don't know but I'll find out". Also, you won't be responsible for hiring the development team so you must be able to know when someone is selling you a line, and the only to be sure is to try it yourself. That doesn't mean you have to spend a week doing it, but just enough (as mentioned) to prove the concept.

    Saturday, April 26, 2008 10:07 AM
  • Happy to make the first post in this forum which relates to my article on the subject of the Role of the Software Architect: Caring and Communicating - shameless plug ;~)

    We are all in agreement so far in this thread - the Architect should code...

    Reason I so shamelessly bring up my artricle is that I mention the pattern which indicates the Architect should be a coder (in the section 'Architecture is Technology').

    The pattern is 'Architect also Implements' Organizational Patterns of Agile Software Development [Coplien & Harrison, 2005].

    The book is really great and the patterns are also invaluable! I have the great privelige of knowing Cope on a personal level and he is a very profound and vise man!

    Cheers,

    /Magnus
    Sunday, April 27, 2008 7:11 AM
  • Architect = risk reduction.

    In my opinion the architect is supposed to make an assessment of the situation she is facing and then decide on what she thinks will be the best solution to the problem at hand. This solution constitutes a route for others to follow and she will later be held accountable for how safe and effective that route was, and will be rewarded by how efficient it was.

    When you talk about:

    A network architect, security architect, application architect, process architect, web architect, data architect, information architect, infrastructure architect, business architect, solution architect, chief architect, enterprise architect

    You are just stating the scope of the risk, the scope of the decisions she has to make and will be accountable for. But at the same time you are determining a context because we naturally set scope through context. The risk can be a challenging technology, a politically charged situation or a complex business problem.

    Sometimes the key to the solution will be negotiation and bargaining, sometimes it will be sound knowledge of technology and on others it may simply be good communication. This means that each situation requires a different set of qualities and personal traits to solve them. So scope takes us away from a common definition for architect.

    But personally I think there are some common qualities and personal traits and those are risk reduction capabilities like assessing situations, comparing probable outcomes, etc… That is why I think you need to define the problem (risks) and then the architect that can handle them J

    The question shouldn’t be “Should an architect code?” the question should be “is coding a risk here?

     I participated as architect in government projects where I never saw a line of code and I never cared about it (there risk was not there) we were architecting processes beyond technology. But I also participated in the creation of frameworks at Microsoft where the code we were making was everything (the risk was there) and that made the difference as an architect.

    Your friend! Alex Jack

     

    Sunday, April 27, 2008 3:54 PM
  •  

    I think that the answer to this question varies based on the specific role that an Architect fills in the "Architect taxonomy". The common Architect roles in the “Architect Taxonomy” are Enterprise Architects, Infrastructure Architects, and Solution Architects. In some organizations the role of a Technology Architect (Example: SharePoint Architect, Java Architect etc.) is also prevalent. Of these categorizations, I would say that the "Should an architect code?" question is most pertinent to the "Solution Architect" and to the development centric "Technology Architect" communities, and will therefore narrow down my thoughts to these segments.

     

    Note: The “Architect Taxonomy” referred to above is not a formally published taxonomy. I use the term to refer to a general classification of formal Architect roles that I have seen in typical enterprises.

     

    Solution Architects:

     

    The general expectation is that folks filling this role have the ability to architect and design holistic solutions that integrate a spectrum of technologies. It is expected that the individual has had significant hands-on exposure to a broad set of technologies that span the spectrum of areas of pertinence to IT solutions of relevance to the business domain. Put another way, this could also be described as the “has been in the trenches” requirement. Developing this level of experience takes a significant amount of time and inevitably implies hands on exposure to writing code to address a variety of requirements that would have required depth exposure to different areas over time.

     

    The broad exposure results in the Solution Architect developing an understanding of a broad spectrum of technologies and their optimal interplay in materializing good solutions. The hands-on depth exposure across various technologies (even if developed at different stages and projects), arms the Solution Architect with the skills required to comfortably drill down deep into specific areas (including new domains and technologies) on demand based on the relevance to the business need and the solution that must be architected.

     

    A Solution Architect position is a role of much relevance and pertinence in organizations that are responsible for developing solutions which require the adoption and integration of a broad range of technologies. Individuals filling this role should possess the technical skills required to efficiently create optimal solution architectures and recommend optimal technology choices, when dealing with projects that traverse the “tried and tested” path. They are expected to be the “go to” technical leads who possess the ability to roll up their sleeves and get hands-on (including coding to create representative POCs – not the toy “hello world” type prototypes that Diego alludes to in his post) when there are requirements to train/mentor junior staff and/or address business needs that require exploring new solution/technology investments.

     

    The focus for a Solution Architect IMO should be to constantly develop and maintain technical breadth, and to retain the interest & ability to get hands on and drill down deep into any technology of pertinence to meeting their business needs. In this context of coding skills, a solution architect is not a developer. A Solution Architect should possess the experience and ability to uptake coding assignments of pertinence to creating representative POCs to guide junior staff and explore new investments. Solution Architects should be able to fluently map out, select, and validate/justify technology investments for the solution architectures that they create. It is not practical to expect a Solution Architect to be able to demonstrate deep and “off the top of the head” knowledge of every technology and programming API. Striving to sustain such proficiency will counter the solution architect’s core responsibility to develop the technical breadth required to be able to tackle a variety of solution requirements, more efficiently and optimally than developers who are deeply skilled in specific technologies. Setting and being practical & real about the role’s responsibilities and expectations, is vital to facilitating a successful partnership between Solution Architects and developers/technology architects, and in helping developers/technology architects better understand the demands of the Solution Architect role and in seeing the role as a career growth path, should they choose to develop further in the technical discipline.


     

    Technology Architects:

     

    Technology specific Architect roles are rapidly becoming prevalent. Job ads for roles like SharePoint Architects, .NET Architects, Database Architects, Java Architects etc. are fairly common in the industry today.

     

    Individuals filling these roles are in general expected to possess high levels of hands on skills of relevance to their areas of technical focus. The focus of these architects is to develop breadth and depth of pertinence to their specific technology, and to actively contribute to production coding (assuming that their area of specialization includes programming aspects). They differ from developers in the context of the “breadth” that they develop (ideally through real world experience) in relation to their specific area of technology focus (Note: the breadth here is within the realms of a specific area/technology, and does not encompass the broader breadth expected of a Solution Architect). Technology architects should be able to efficiently navigate the maze of options of pertinence to their technology and make the tradeoffs required to optimally apply the technology to address the related solution requirements. They are also expected to contribute actively to production coding, while mentoring the junior staff on their technology teams.

     

    The Technology Architect role is a good “next step” career path for developers with an interest in developing and applying a broad range of hands-on skills of relevance to a fairly broad but specific area/technology (Examples: Database Architect (area), SQL Server Architect (technology)).

     

    Solution Architects and Technology Architects complement each other and can work together effectively to materialize sound solutions.

    -Karthik
    Sunday, April 27, 2008 4:34 PM
  •  

    I agree with Alejandro and I will extend him, on the other hand I’m not so agree with applying taxonomy to architecture. Let me go deeper on this.

    When you apply taxonomy to group you aren’t doing anything but restricting what should be done hence people stop caring about other things. Architect should care about the two big concerns (citing Erich Brechner on I.M. Wright’s “hard code”), those are the whole end-to-end component interaction and the UX.

    Based on what said, we can conclude that an Architect should (must) do whatever it takes to get the product to a usable state, where she can assure the design principles and premises defined for the specific project relaying on the development team.

    Putting this as an example, when you’re developing a big component that it will connect distributed systems with an unknown protocol for sure the architect will nail down to see how the implementation goes, so he writes code. On the other hand if you were writing an enterprise application with well defined technology boundaries but a complex security federation sub-system he must be involved on AD or ADFS rather to write the code.

    Architect role (talking a little bit about the name of the forum) is to nail down problems, understand and simplify complexity. For sure an architect wouldn’t be the best coder in the building, so as Diego says she might need a simple proof of content to mitigate the risk and reduce the complexity.

    It seems that based on what I’m saying an architect should know every technology involved, well that’s not what I intend to say. As a good Architect you should get SME’s (subject matter experts around you) they will know how to make the implementation efficient in terms of code, an Architect seeks design efficiency. A lesson learnt with experience is that an efficient design is the only thing that lasts, code might change, migrate and be re-factored but an efficient design won’t go.

    In conclusion, the architect should write code whenever he considers code is the problem, there is no recipe for this, and you just have to apply your criteria. On the other hand, will be good if the architect at some point can take commitments with code (but only those that are easy-to-cut and non-shippable) just to keep it real (Again I.M Wright’s “Hard Code”), to stay in sync with the developers team.

    Coding is fun, Architecture is complex, so you will see Architects coding J

     

    thanks,
    ~johnny

    johnny g. halife | southworks | http://staff.southworks.net/johnny
    Sunday, April 27, 2008 5:12 PM
  • Hi Diego,

     

    I'd say the key is for the person designing the software to have sufficient knowledge of technical constriants and be sympathetic to them. 

     

    Having first-hand knowledge will give such a person the best possible knowledge and sympathy, so yes, having coding experience and keeping that experience fresh will make a big difference.  That said, as long as the person is sufficiently knowledgeable, really listens to those who will have to make the design a reality, and is truly sympathetic, I wouldn't say it is an absolute necessity.

     

    Notice I don't say "architect." Smile  This is partly due to my current (probably passing) antipathy towards the term, and also because those who call themselves architects are not the only ones who design software--I'm thinking of product managers, interaction designers, visual designers, and yes, even developers themselves.

     

    --Ambrose

    Sunday, April 27, 2008 6:28 PM
  • This has been (and continues to be) a very interesting thread.  Let me say up front that, as an ex developer, I still like to code, but I am carefull to remind myself that is not my primary job.

     

    I agree with what has been said about the Solution Architect being able to code to develop Proofs of Concept and Architectural spikes, especialy when dealing with areas of technical risk in an architecture.  I am glad that someone pointed out that Infrastructure Architects exist and probably do not code or need to code. :-)  Business Architects, Security Architects, and other specialties are probably in the same boat. 

     

    There is another strong reason for a Solution Architect to be able to code and that is to maintain credibility with the developers that will have to implement his/her architecture.  One of the jobs of an Architect is to lead/guide developers in implementaing the architecture that they have set down.  The Architect needs to strive to be "snow proof" and that usualy requires a good deal of knowlege and experience with the development tools and language in use. 

     

    Bill

     

     

    Sunday, April 27, 2008 10:30 PM
  • This is the post on behalf of fellow MCA architect Aric Bernard:

     

    Should an Architect code? It depends….

     

    First it depends on the scope of the architect.  i.e.  Enterprise, Solution, Infrastructure, Operations, Business Process, etc.  Architects can be classified in many different ways – of course some debate which of these are “true” architects, but personally I find that argument to be nonsense.  Any of the various architect scopes (assuming technology focused) should have a good understanding of how the various technology components fit together, but not necessarily the fine detail. 

     

    Should an enterprise architect have hands on experience writing an application that takes advantage of the latest capabilities in .NET Framework 3.5, WCF, and SQL 2008?  Probably not.  Should an enterprise architect be aware of the new features in SQL 2008?  Probably not – not unless those new features provide a critical technology that can fulfill a technology gap that the business can take advantage of in a way that improves existing systems or allows to systems to be implemented in a more agile, reliable, available, and efficient manner.

     

    A solution architect on the other hand should understand most if not all of the new features of SQL 2008 (assuming the business has not standardized on i.e. Oracle).  Should the solution architect have hands on experience, at least in an experimental fashion, with writing an application that takes advantage of relevant capabilities in .NET Framework 3.5, WCF, and SQL 2008?  As some point yes. While the products are in beta?  Maybe, but that depends on the business and relevance of the technology.  Should the solution architect be an expert in implementing these technologies?  Probably not – this is better left to the SME that is responsible for designing or writing modules with those technologies.  Of course this depends on the solution architects job duties – maybe they are responsible for providing some of the technology modules, and in that case yes they should be an expert.

     

    Should the infrastructure architect be intimately familiar with .NET Framework 3.5, WCF, and SQL 2008? Possibly, but from a different aspect.  The infrastructure architect should understand the benefits of each as it applies to the infrastructure.  For example, what benefits will SQL 2008 provide in terms of fault tolerance such as improvements to log shipping, clustering, etc. and what impact if any will these technologies have on the network? Similarly, the Operations architect will want to understand how these new technologies can impact or enhance the operational aspects of the current architecture.  Do they provide new capabilities to enhance the ability to manage, monitor, and report on existing or new systems?

     

    Now of course not all architects fill one roll or another, and in some companies they may fill more than one role.  As such, my answer to the question “Should an Architect code?” is:

    An architect should do whatever is required to ensure that key decisions are [properly] made by the appropriate business and technology stake holders, and that those decisions result in effective and efficient system for current technology implementations and into the foreseeable future.  If coding is what is required, then yes.  If discussions with a SME are sufficient, so be it.  It is more important for the architect to have technology breadth and have the ability to acquire technology depth when necessary than it is for the architect to attempt to keep up with the latest languages and product releases.  More important than the technology itself is the ability for the architect to communicate amongst his superiors, peers, and subordinates in an effective manner.

     

    I am an infrastructure architect.  Do I code?  YES – but only when required to fulfill an outstanding need in the infrastructure, and most of the time I am scripting not coding.  Do I understand the idiosyncrasies regarding the development of an enterprise application?  ABSOLUTELY NOT – but my peers working as solution architects do.  My limited coding efforts do enhance my ability to communicate with the solution architects and the enterprise architect to ensure that the infrastructure will meet the needs of any overarching architectures and specific solutions, and that those solutions will adhere to any rules, regulations, and restrictions implemented in the infrastructure or that the appropriate negotiations and adjustments will take place.  As such, I personally find it beneficial, but not required.

    Aric Bernard | Microsoft Certified Architect, Infrastructure

    Technology Services Group | Consulting and Integration

    Monday, April 28, 2008 3:50 AM
  • Miha, although I understand the point I'd have to disagree with Aric's stance. Whilst I agree that an Enterprise Arch' *shouldn't* need to have a working knowledge of those technologies I would not feel happy making decisions about the technologies to use unless I had tried them out for myself. This maybe just the bad experiences I've had relying on the input from others but unless I've "kicked the tyres" of a technology I find it difficult to select it.

    Monday, April 28, 2008 5:44 AM
  •  

    An Architect SHOULD NOT CODE, an Architect doesn't work alone, he got a team, if there is RISK involved because of new technology, He is the one to call a POC, and get a Senior Developer to create that code.

     

    In that sense I'm pointing more to an Architect as a Manager, or a Business Architect role and Enterprise Architect indeed.

     

    Now if you are an Architect INSIDE a development team, you are going to code, each and everyday, or be heavily involved on code reviews. It really depends on the type of Architect role.

    Monday, April 28, 2008 5:36 PM
  • As part of MCA [Microsoft Certified Architect] certification we have a competency "technology depth" where candidates have to demonstrate significant and thorough proficiency in at least two technologies.

     

    For Solution Architects it is the most common (and the easiest) approach to demostrate it through their coding experience (for example Java and .NET development). If you can't code, you can bring some alternate technical depth to the table - but usually this is much harder to defend.

     

    In other words, the MCA Architect strawman has to have depth in order to gain credibility with technical stuff - otherwise they are managerial drones. This depth is manifested as coding ability with more than 80% of Solution Architect candidates.

     

    Miha

    Monday, April 28, 2008 6:58 PM
  • But is that an accurate account of an architect or a flaw of the MCA Wink? IMO I'd agree with the MCA definition in principal anyway.


    Monday, April 28, 2008 8:02 PM
  • Diego,

     

    I think that architects in an ideal world should code from time to time, so that they're still able to identify with the challenges of implementing their architectural designs.  That said, it is often difficult to do that, and still find time to rally thr troups, keep the architecture skills up to scratch, manage projects, and so on.

     

    What I try to do, is to involve myself in some aspect of the proof of concept type work so that I know that the reference architecture is going in the right direction and is a good point of reference.  That said, you really have to step away too, otherwise the team is not going to be able to learn from you, or understand your thoughts and wonderful ideas.

     

    I think that intimate knowledge of the implementation detail of a system is often counter productive to a good architectural design, as it is easy to be 'tainted' by the thought process of technology and implementation, instead of choosing unemotionally based on the best fit.  I don't code anywhere near as much as I used to do, for this reason, and will try to involve myself in productive situations such as peer reviews, presentations to teach technology, tools or techniques that might involve the writing of code, and so on.

     

    I think knowledge that there are API available to the architect to achieve a certain set of functionality is sufficient, that technically it is possible to achieve what the architect wants to achieve.  If the architect is unsure that such a situation occurs, then that is part of the analysis work, and proving it out with a PoC. 

     

    Parameter list details are required so that the correct data is available to the API, however having siad that, the concept on encapsulation and loosely coupled architectures should not mean that knowledge of an API list should drive the shape of the architecture visibly.

     

    The worst thing is an 'ivory tower architect', one that comes up with a perfectly designed, theoretically ideal solution, without considering the implementation detail.  That's almost as bad as hacking the solution together without a formalised design, as usually the solution end up with workaround upon workaround, and bruised egos.

     

    That's my 2 cents anyway.

     

    Martin Platt.

    Monday, April 28, 2008 10:43 PM
  • Should an architect code?

    Short answer: Yes, a bit.

    Long answer: http://blogs.msdn.com/tomholl/archive/2008/04/29/thoughts-on-being-a-solution-architect.aspx :-)

     

    Tom

    Wednesday, April 30, 2008 10:32 AM
  •  Tom Hollander wrote:

    Should an architect code?

    Short answer: Yes, a bit.

    Long answer: http://blogs.msdn.com/tomholl/archive/2008/04/29/thoughts-on-being-a-solution-architect.aspx :-)

     

    Tom

    Sounds about right to me, I expect you're pleased I've validated your job Wink

     

     

    Wednesday, April 30, 2008 10:40 AM
  • The answer depends on what do you mean by “architect” (noun) and also by “code” (verb).

    What seasoned designers talk about when discussing architecture is so all-encompassing and important for the final outcome that makes me wonder why a project team member wouldn’t need to fully master the actual concretization of such concepts at all levels? I suspect the answer is related to the sad state of practice in many organizations due to the faulty belief that the main task in writing software is a mechanical and repetitive task that can be industrialized with expendable and interchangeable human ‘resources’.

    See: Discussing uncomfortable questions

    Pursuing a clear definition of a concept like architecture is good because the related thinking-researching cycles give opportunity to reach sound conclusions (by ‘sound’ I mean -inferences with scientific properties like provisional and falsifiable). I have not yet found a satisfactory definition for what architecture in computing really means, far less a definition of what the role of an architect could possibly be. By now, the proposal by Frederick Brooks, Jr. for the concept of architecture is arguably the most sensible definition I have found:

    “Computer architecture, like other architecture, is the art of determining the needs of the user and then designing to meet those needs as effectively as possible” –Oxford English Dictionary

    Why? Because it explicitly includes three key concepts: art, user needs, and design.

    A discussion about the design concept would be in order to answer the question: “Should an architect code?”

    So, if by code, do you mean executing a mechanical and repetitive task that can be industrialized? Then the answer is ‘no’ (and also ‘no’ for any self-respecting software professional by the way).

    On the other hand, if by code, do you mean the act of expressing design intentions and the execution of models to corroborate hypothesized ideas with contextual data? Then the answer is ‘yes’ (and also ‘yes’ for any self-respecting software professional by the way).

    Next, I quote a thinker whose name I don’t know (if the author is listening, see: What type of person should design software? ).

    "There are certainly people who think more about high level structure than they do about low level details. This is a valuable talent, and not one that should be scoffed at or discounted. Unfortunately, in some circles, it has become popular for people with these talents to divorce themselves from code. The term "architect" takes on an aura of authority and power, whereas a coder is deemed a lowly laborer, a dime-a-dozen worker bee.

    In reality, while the difference in talent is real, the polarization into different roles with different authorities is harmful. Those folks who are good at modeling and architecture must still remain grounded in code. For their skills to remain relevant and useful, they have to keep in touch with the medium they are trying to create structures for. Likewise, the programmer who divorces himself from concerns of architecture harms himself and his team by abdicating responsibility for something he is in an intimate position to control. There is a way for these two talents to work well and closely together, but they have to put forth the effort to understand each other."


    More notes about the practice of architecture:

    Software architecture is much more than structure

    Architecture is not about scalability, not even about user, it is all about usage

    Feedback would be much appreciated.

    Thursday, May 1, 2008 9:07 PM
  • As a PMI Project Manager I do learn that you need to balance betweeen Technical and Business matters, I favor more TOGAF since it is a creation of Architecture based on business requirement. When I hear that an architect should code or that an Architect should deeply know (400 level developer) it sound to me, that is a Senior Developer NOT an Architect. It doesn't matter what type of Architect you are; you should favor one technology over the other based on a complex decision criterias as: support, resource technical level, licensing, market maturity, adquisition cost, maintenace cost. 

     

    Is not what I can code, is what the business can support once coded. So given the same technical requirements my Architecture should vary depending on my customer ability to deal with that Architecture - not that I can code on it.

    Friday, May 2, 2008 7:58 PM
  • hi jon_arce:

    After reading your post and re-reading sections about architecture in The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks, Jr. I am wondering if what the role of a nowadays architect really wants to be is that of the old notion of data processing analyst. What do you think?

    The key deliverable from data processing analysts was written functional specifications; the best of those analysts described an abstract, coherent and conceptually integrated system —yet to be implemented— and all their description was from the standpoint of the business and end-user. Later (and sometimes), the senior developers took the functional specification and delivered a technical specification of how the system’s internals would be “constructed” and then —in all waterfallish fashion and most often than not— the “dime-a-dozen coders” took the technical specification and “built” the system. It all made sense. It was all wrong (see Writing 2 here).

    Data processing analysts did not “code”; very, very far from doing that. Isn’t that what you are saying about architects?

    Many years, colossal amounts of human effort and vast amounts of money have been wasted for our industry to learn that waterfall and sequential thinking —like the one described a paragraph ago— for the realization of complex computing systems just don’t work for most of the situations. Why would we want to bring back the notion of data processing analysts? Which could possibly be the advantages of doing that?

    Now, if we think —on one side— of an architect as a role, not as an individual, whose key aim is to describe an abstract, coherent and conceptually integrated system clearly to all the team and, if we think —on the other side— of a developer as a role, not as an individual, whose key aim is to provide feedback about the technical feasibility for each architectural decision, then both roles could be fulfilled by the same professional or group of professionals (like a team in charge of accurately delivering the right system into the hands of customers and end-users).

    What is the role of an architect? Sorry, I don’t get it, architect *is* already a role, not an individual. Should an architect design? Yes, the mere essence of architecting if that of describing —from the standpoint of the business and end-user— an abstract, coherent and conceptually integrated system that solves the business problem.

    Saturday, May 3, 2008 1:26 AM
  • First off, strictly speaking I would say that a modern software arch' is not a data analyst. The flow of data through a business is part of what an arch' must know but an arch' must "plan" a more technical aspect. E.g. Data Analyst: A warehouse receives replenishment order. Architect: Replenishment orders are sent to the warehouse queue service. The order are dequeued by the...

    I realise that you weren't suggesting they were the same and a I do agree that an arch' can be one of many hats that can be worn by single team member, I think that is especially true of smaller companies. However, back to the question in hand, I still believe that an arch' should have hands-on-experience of the technologies they are going to sanction. That doesn't mean they're necessarily going to don the hat of developer but they should have a good understanding of it. OK, maybe you're the book reading sort that can glean every crumb of information required but personally there is nothing like getting your hands a bit dirty to understand the technology. Resurrecting my cooking analogy, you'd expect a master chef to know what the core ingredients taste like and how they should be cooked. That doesn't mean they can't ask the chefs that work for them to do the cooking.
     

    Saturday, May 3, 2008 8:27 AM
  • I agree with the following points:

     

    1. The architect should be able to code POC's BUT not necessarily to a very complex level, usually that's when devs come in.

     

    2. The architect should be able to use the new APIs BUT not to the level of knowing every single switch and flag, usually it is enough to know that there is a switch or flag, or there is a way to tweak this method.

     

    3. The architect does need to show some coding ability to get some "street cred" with the developers or else no one will listen to him/her.

     

    4. Any architect who loves technology will definitely code when they get the chance and when there is a need to do so.

     

    5. Usually it is more debugging and problem solving than coding Smile

     

     

     

    Sunday, May 4, 2008 1:42 PM
  •  

    I agree with Bill and others on the following points:

     

    1. An architect needs to code to gain "street cred" with developers

     

    2. An architect loves technology anyway, so they always like to play around with code.

     

    3. Solution architects usually need to put POCs together and this is a lot easier when they are used to writing code.

     

    Here are some points I disagree on:

     

    1. Everyone called "architect" shoul have at least basic level coding, I am sure infrastructure and security architects can benefit greatly from scripts and scripting languages. They at leas need to have the knowledge.

     

    2. The architect does not have to be able to code better than any dev, but they are usually more able to debug and problem solve which is really important to help a dev in trouble Smile

     

    Thats my 2 cents on it.

    Sunday, May 4, 2008 1:47 PM
  •  LivetoCodeCodetoLive! wrote:

     

    Here are some points I disagree on:

     

    1. Everyone called "architect" shoul have at least basic level coding, I am sure infrastructure and security architects can benefit greatly from scripts and scripting languages. They at leas need to have the knowledge.

     

    2. The architect does not have to be able to code better than any dev, but they are usually more able to debug and problem solve which is really important to help a dev in trouble

     

    Thats my 2 cents on it.

     

    Well, I too disagree on that, and I believe you hit the spot there, about where this distinction Developer/Architect lies.

     

    IMHO, there is no distinction at all, if not in the "degree" of the various components that make an Architect's competence.

     

    On a side, I'd claim that the level of _development_ competence, in an Architect, _must_ be very high compared to that of the average Developer, whichever the domain of problems the Architect might be _actually_ operating in. Of course, s/he will not be a competent developer/architect in _any_ possible problem domain, but we are not talking in theory here, so we must suppose that s/he is competente where she is supposed to be.

     

    You might now say that s/he cannot be competent in architecture and at the same time be -say- a guru in algorithms. And that is true. Yet, I am not talking about low level tricks in C++ and the like: each his/her own preference and specialization, I am just talking about a broad and solid programming knowledge, which cannot but come from years and years of experience developing _real code_.

     

    Then, some might say that the role of an Architect goes beyond programming, and that is true as well. Still, first you run the risk of reducing development to sell and buy, unless you remember that your Architect must be a potentially decent coder for the given problem domain, otherwise having a look at the best deals is going to be his only resource. Second, again, where those supposed Architects are supposed to be coming from? Fresh from school, straight into architecture, then regularly from the boss's office to the shop and back?

     

    Ok, that's enough for the desagreement, and I hope you get my point there, since the criticism is only rhetorical.

     

    What's much more serious is the *benefit* that we risk to miss. If you think of an Architect as a very competent developer, who has choosen to specialize in technological and integration needs, then any distinction Dev/Arch simply fades into the usual "many people many hats" approach.

     

    Bottom line: Architecture is just a role in the project. Even better: Architecture is a specific project _activity_, and specializing in Architecture (as well as, on the other side, hiring "Architects") risks to be a very bad move to /your/ "agility" plans.

     

    -LV

     

    P.S. Given the context, a side note: I am not here advocating against traning and certifications. I too am -say- MCP, and I can see the good of it. But, that certification surely cannot exhaust the domain of my competences, it rather certifies my competence in a specific activity/role.

    Sunday, May 4, 2008 7:28 PM
  •  Marco Dorantes wrote:
    What is the role of an architect? Sorry, I don’t get it, architect *is* already a role, not an individual. Should an architect design? Yes, the mere essence of architecting if that of describing —from the standpoint of the business and end-user— an abstract, coherent and conceptually integrated system that solves the business problem.

     

    Marco, pardon me, but there is where I see most of the problems.

     

    That is, I agree on Architect being a role, and in the context of Agility I'd better say Architecture is an activity. Where I do not agree is:

     

    1. "describing -- from the standpoint of the business and the end-user": this forgets Analysis and the fact that *that* is your starting point as developer/designer/architect, although the architect might very well have to take into account *internal* technological and business constraints;

     

    2. "describing ... an abstract ...": indeed, it is *not* abstract anymore! It was abstract in analysis, it becomes concrete in design (and it is *not* abstract with respect to coding either, it is rather "high-level");

     

    3. "describing ... system that solves business problems.": finally, no! WHO solves the business problem? The Account? The Analyst? The Manager?  The Developer? Or, rather... the TEAM?! Or maybe the COMPANY as a whole? Or is it the joint partnership and effort of CUSTOMER/SUPPLIER/USERS/DEVELOPERS??? So, and in any case, a million times no!!!

     

    -LV

     

    P.S. Corollary: the following statement is so imprecise to be completely wrong:

     

    > "Computer architecture, like other architecture, is the art of determining the needs of the user and then designing to meet those needs as effectively as possible" –Oxford English Dictionary

    Monday, May 5, 2008 5:04 AM

  •  Marco Dorantes wrote:

    So, if by code, do you mean executing a mechanical and repetitive task that can be industrialized? Then the answer is ‘no’ (and also ‘no’ for any self-respecting software professional by the way).

    On the other hand, if by code, do you mean the act of expressing design intentions and the execution of models to corroborate hypothesized ideas with contextual data? Then the answer is ‘yes’ (and also ‘yes’ for any self-respecting software professional by the way).



    I really agree with this. The architect should have a good and intimate knowledge of "coding" activity, this does not means that he/she should write production code, but surely he has to know how to write good code. An architect should be able to code the infrastructure of a product, and he should be able to review the code of the developers, to see if developers code fit into the standards of the project and should be able to help developers to solve difficult problem that can arise in the developing process.

    Moreover if the architect does not write code, his role will be too distant from that of the developers, I mean that in a team a developer tend to have more respect for people with good coding skills. If an architect does not write code, and worse, if he/she is not able to write good code, it is difficult that he/she can instruct others to build the architecture he/she had designed.

    So, my personal answer is

    1) Should an architect code? Yes, he should have a good coding skill, to make prototypes of the architecture, and also to code against new technology to verify that they fits the needs of the project.

    2) If so, how much? It is impossible to give a significative number or percentage, it depends on the project but usually coding should not be his/her primary activity.

    Alk.
    Monday, May 5, 2008 6:48 AM
  •  LudovicoVan wrote:


     

    2. "describing ... an abstract ...": indeed, it is *not* abstract anymore! It was abstract in analysis, it becomes concrete in design (and it is *not* abstract with respect to coding either, it is rather "high-level");

     

    3. "describing ... system that solves business problems.": finally, no! WHO solves the business problem? The Account? The Analyst? The Manager?  The Developer? Or, rather... the TEAM?! Or maybe the COMPANY as a whole? Or is it the joint partnership and effort of CUSTOMER/SUPPLIER/USERS/DEVELOPERS??? So, and in any case, a million times no!!!

     


    re: 2. I think you're being harsh here. A design is abstract, you can't physically use it. Well, maybe you can if you have some 4GL tool, but essentially IMO it is abstract.

    3. An arch' does *help* to solve business problems, if not there is no point in the role. Every employee of a company should be solving a business problem, no?






    Monday, May 5, 2008 7:46 AM
  •  pkr2000 wrote:
     LudovicoVan wrote:

    2. "describing ... an abstract ...": indeed, it is *not* abstract anymore! It was abstract in analysis, it becomes concrete in design (and it is *not* abstract with respect to coding either, it is rather "high-level");

     

    3. "describing ... system that solves business problems.": finally, no! WHO solves the business problem? The Account? The Analyst? The Manager?  The Developer? Or, rather... the TEAM?! Or maybe the COMPANY as a whole? Or is it the joint partnership and effort of CUSTOMER/SUPPLIER/USERS/DEVELOPERS??? So, and in any case, a million times no!!!

    re: 2. I think you're being harsh here. A design is abstract, you can't physically use it. Well, maybe you can if you have some 4GL tool, but essentially IMO it is abstract.

    3. An arch' does *help* to solve business problems, if not there is no point in the role. Every employee of a company should be solving a business problem, no?

     

     

    I apologise for my tone, it's just not one of my best built-in features (also, please keep in mind I am not an English native speaker).

     

    > 2. I think you're being harsh here. A design is abstract, you can't physically use it. Well, maybe you can if you have some 4GL tool, but essentially IMO it is abstract.

     

    This is _not correct_, and I'll give the two reasons: on a side, design is no more "abstract" than code itself (this is "software" after all), it is rather "high-level"; on the other side, we all know that pseudo-code is just low-level design.

    > 3. An arch' does *help* to solve business problems, if not there is no point in the role. Every employee of a company should be solving a business problem, no?

     

    That indeed was my whole point with those million no's...

     

    -LV

    Monday, May 5, 2008 8:00 AM
  • Just wanted to draw something out from all this.

     

    Software architects need to code in order to lead.  There seems to be a lot of agreement on this point, though voiced in various ways (sympathize, understand the medium, street creds, etc.).  But it all seems geared towards leading.

     

    I tend to agree that the core competency of what we often recognize as a "software architect" is essentially a leader. 

     

    Design leads implementation.

     

    Really, isn't that all there is to it?

     

    Everything else we do can be derived from that principle.  For example, directly (through management or explicit team leadership roles) or indirectly (through design specifications and mentoring), designers lead implementers. 

     

    I'd submit (again) that "architect," as a name, is really part of a broken analogy that has led us down a slippery slope of endless debates and confusion. 

     

    We may be stuck with the name, sadly, but if we can at least refocus it on leadership and less on particular technical responsibilities and activities, we might actually be able to come to some meaningful consensus on the role that is useful for helping both the business and the technical sides of things to better understand and utilize what we do. 

     

    Business folks understand leadership, so I think we'd have a much easier job of communicating our value if we focus on that.

    Monday, May 5, 2008 3:06 PM
  •  J. Ambrose Little wrote:

    Just wanted to draw something out from all this.

     

    Software architects need to code in order to lead.  There seems to be a lot of agreement on this point, though voiced in various ways (sympathize, understand the medium, street creds, etc.).  But it all seems geared towards leading.

     

    I tend to agree that the core competency of what we often recognize as a "software architect" is essentially a leader. 

     

    Design leads implementation.

     

    Really, isn't that all there is to it?

     

    Everything else we do can be derived from that principle.  For example, directly (through management or explicit team leadership roles) or indirectly (through design specifications and mentoring), designers lead implementers. 

     

    I'd submit (again) that "architect," as a name, is really part of a broken analogy that has led us down a slippery slope of endless debates and confusion. 

     

    We may be stuck with the name, sadly, but if we can at least refocus it on leadership and less on particular technical responsibilities and activities, we might actually be able to come to some meaningful consensus on the role that is useful for helping both the business and the technical sides of things to better understand and utilize what we do. 

     

    Business folks understand leadership, so I think we'd have a much easier job of communicating our value if we focus on that.

     

    With all respect, I do not agree on this either, unless for the endless debates and confusion coming from the name "architecture". Indeed, now it seems to me you are making it equivalent to the team leading role, which is not.

     

    > Design leads implementation. Really, isn't that all there is to it?

     

    How do we then explain TDD?? Please note that I am very critical to TDD, but not because I agree with you, rather because I believe every activity in the project iterates in parallel and nested with each other (the "fractal-concurrent" process).

     

    To me there _is_ indeed an "architect" or rather an "architecture", and it is a collection of practices including the aforementioned integration issues and (internal!) business contraints.

     

    What's ambiguous with such definition?

     

    -LV

    Monday, May 5, 2008 3:20 PM
  • P.S.

     

    Let's maybe keep in mind, on a side, that there is a specific and well-defined distinction in Software Engineering (a sub-branch of Information Engineering) between Primary Activities (Analysis, Design, Code, Test) and Auxiliary activities (Architecture being one of them, along with Configuration Management, Plans and Estimation, Risks Management, PM, QA, etc. etc., to just name a few); on the other side, as to the "business value", let's maybe keep in mind the ISO definition of Quality which stands for the degree of satisfaction of the product to customer's requirements, with a distinction between Explicit vs Implicit (business vs technological) Requirements.

     

    Again, I cannot see any chance of (intrinsic) confusion in the definitions above, although they could surely be specified in some (arbitrarily) greater detail.

     

    -LV

    Monday, May 5, 2008 3:32 PM
  • Hi LV,

     

    Just the fact we're having this long and disputational discussion after so many others have had this discussion is clear evidence that there is a problem with the architecture-based terminology.

     

    As for TDD, it does involve design.  And at the very least, you are leading your implementation through the design of tests.  Those tests are supposed to reflect the intentions of the thing that you are designing, i.e., in a sense, they are a design specification.  And many also advocate design outside of the tests themselves, i.e., design that leads the tests.

     

    I don't necessarily distinguish between conceptual leadership and interpersonal leadership here as I think they're intimately related--the interpersonal leadership is an extension of the conceptual.  So even on a one-person team, there is this leadership by design.  As teams scale, the leadership scales with it, often to particular individuals, either explicitly or implicitly. 

     

    By the way, I think this is true in other, even non-technical disciplines--leadership presupposes on vision.  (Design is vision applied to the creation of things.)  And this further shows how a focus on leadership would be more relatable for business folks--they understand the need for clear vision and leadership.

     

    HTH.

    Monday, May 5, 2008 3:33 PM
  •  J. Ambrose Little wrote:

    Hi LV,

     

    Just the fact we're having this long and disputational discussion after so many others have had this discussion is clear evidence that there is a problem with the architecture-based terminology.

     

    As for TDD, it does involve design.  And at the very least, you are leading your implementation through the design of tests.  Those tests are supposed to reflect the intentions of the thing that you are designing, i.e., in a sense, they are a design specification.  And many also advocate design outside of the tests themselves, i.e., design that leads the tests.

     

    I don't necessarily distinguish between conceptual leadership and interpersonal leadership here as I think they're intimately related--the interpersonal leadership is an extension of the conceptual.  So even on a one-person team, there is this leadership by design.  As teams scale, the leadership scales with it, often to particular individuals, either explicitly or implicitly. 

     

    By the way, I think this is true in other, even non-technical disciplines--leadership presupposes on vision.  (Design is vision applied to the creation of things.)  And this further shows how a focus on leadership would be more relatable for business folks--they understand the need for clear vision and leadership.

     

    HTH.

     

    > I think this is true in other, even non-technical disciplines--leadership presupposes on vision.

     

    On that I completely I agree. Does that make leadership == architecture?

     

    Please note that I have already answered your questions, but you didn't answer mine.

     

    > And this further shows how a focus on leadership would be more relatable for business folks--they understand the need for clear vision and leadership.

     

    Yep! Still that doesn't make architecture == leadership, although it might make architecture more shippable.

     

    -LV

    Monday, May 5, 2008 3:38 PM
  • Hi again, LV,

     

    With respect, I did address your concerns.

     

    As for leadership being equal to architecture, I'd say two things: first, yes in the sense of describing in a very essential way what it is we do (as I think I've elaborated), and second, again, I think there is some confusion (even in this microcosm of the grand 'architect' discussion) and thus objection due to the term 'architecture' itself.

     

    It's very clear that 'architecture' does not equate to 'leadership' on a terminological level, and that is precisely what I'm driving at.  "Architecture" has multifarious and divergent meanings within just our little slice of reality.  It puts the emphasis on technical details and activities that are bound to differ, often enormously, from one organization, one project, and even one person to the next, and that is one reason why it is such a bad term to describe the commonality of what we do across all those things.

     

    Again, what I'm suggesting is that the commonality exists at the fundamental level of conceptual leadership and extended to interpersonal leadership. 

    Monday, May 5, 2008 4:00 PM
  • J. Ambrose Little wrote:

     

    > With respect, I did address your concerns.

     

    With all respect, I'm afraid not.

     

    > As for leadership being equal to architecture, I'd say two things:

    >  first, yes in the sense of describing in a very essential way what it is we do (as I think I've elaborated),

     

    With all respect, you have maybe described what /you/ do.

     

    > and second, again, I think there is some confusion (even in this microcosm of the grand 'architect' discussion) and thus objection due to the term 'architecture' itself.

     

    With all respect, there is no such *intrinsic* confusion at all, or at least I cannot see any confusion of any kind if not for what comes from said "shippability".

     

    > It's very clear that 'architecture' does not equate to 'leadership' on a terminological level, and that is precisely what I'm driving at.  "Architecture" has multifarious and divergent meanings within just our little slice of reality.  It puts the emphasis on technical details and activities that are bound to differ, often enormously, from one organization, one project, and even one person to the next, and that is one reason why it is such a bad term to describe the commonality of what we do across all those things.

     

    With all respect, I am wandering which little slice of reality is /yours/.

     

    > Again, what I'm suggesting is that the commonality exists at the fundamental level of conceptual leadership and extended to interpersonal leadership.

     

    Leadership != architecture, and you have no way demonstrated the opposite.

     

    So, where is the confusion? (I have even answered this, but you didn't! Oh, yes, maybe it's a matter of which planet one comes from... Then what about devising an inter-planetary tongue, so that we could finally understand each other, even on Earth? That sounds great... to me, I mean.)

     

    -LV

    Monday, May 5, 2008 4:12 PM
  • This is getting a little out hand! First off let's revisit the title of this thread, we're at a risk of hijacking it to become, yet again, "what is the definition of arch'". Obviously they are related but then they would be on this forum wouldn't they? The underlying problem we've ended up discussing is that due to most of us being human (can you guess who is the Turing machine Wink ) that we use words differently. The term arch' means different things to different people regardless of how many dictionary def's or ISO documents you care to submit. If we can at least return to the question, the general consensus of the modern software arch' is that it is useful for them to understand the technologies used to implement an arch'. To understand a technology it useful to "have-a-go" at the technology, i.e. to do some coding. Therefore it would appear that it would be useful for a software arch' to do some coding.


    Monday, May 5, 2008 4:50 PM
  • Guys,

     

       I want to really thank you for all the answers. It seems there are certain agreement on the right involvement of an architect with coding. Certainly how much or how little will depend on project contexts, previous experience and general background

     

       Clearly the debate, beyond this thread, will continue  as long as the boundaries of certain roles (architect and project leader/manager, architect and developer, etc) keep being so fuzzy (I'm sure that everybody of us has a right definition of where the front-lines should go through, but what it's difficult is avoiding later collision of those definitions )

     

     

     

       I wanna thank all you again

    Wednesday, May 7, 2008 12:42 AM
  • I think that an Architect should be able to code so that they can add more realism to the projects that they design.  I have been designing systems for 20+ years and have coded all along the way except for my time at IBM.
    Thursday, May 7, 2009 4:53 AM