none
Call yourself an Architect?

    General discussion

  • I was wondering what people expect when you meet someone calling themselves an architect (obviously in the context of software). So if they say architect you expect them to be able to...?

    Tuesday, April 22, 2008 5:57 AM

All replies



  • Another interesting thread!

    I would expect someone who is expert in problem solving, can see the most effective way forward for a solution, from a business and technology perspective.

    I would see an architect as having excellent communication skills, the ability to translate a business stretegy into a set of software solutions.  I would expect an architect to be able to see risk and mitigate it.  I would expect an architect to be able to communicate both to the business and the a technical audience.
    I would expect an architect to be able to have knowledge of the technical implementation details rather than just a theoretical or paper based view of the solution.  I would expect that architect to, given their knowledge be able to foresee any difficulties in maintainabilty, implementation, useability, extensibility and so on and be able to come up with the best compromise on these.
    I would expect an architect to also be inventive and able to imagine different ways to do things, including those that may not yet have been attempted by any other architects, to be able to step back and look at the problem, and come up with the greatest solution.

    There's more, but I'll let someone else have a go at this now!

    Martin Platt.
    Tuesday, April 22, 2008 6:43 AM
  • An extract from TOGAF: Who is an architect?

    the role of the architect can be summarized as to:

           Understand and interpret requirements: probe for information, listen to information, influence people, facilitate consensus building, synthesize and translate ideas into actionable requirements, articulate those ideas to others. Identify use or purpose, constraints, risks, etc. The architect participates in the discovery and documentation of the customer's business scenarios that are driving the solution. The architect is responsible for requirements understanding and embodies that requirements understanding in the architecture specification.

           Create a useful model: take the requirements and develop well-formulated models of the components of the solution, augmenting the models as necessary to fit all of the circumstances. Show multiple views through models to communicate the ideas effectively. The architect is responsible for the overall architecture integrity and maintaining the vision of the offering from an architectural perspective. The architect also ensures leverage opportunities are identified, using building blocks, and is a liaison between the functional groups (especially development and marketing) to ensure that the leverage opportunities are realized. The architect provides and maintains these models as a framework for understanding the domain(s) of development work, guiding what should be done within the organization, or outside the organization. The architect must represent the organization view of the architecture by understanding all the necessary business components.

           Validate, refine, and expand the model: verify assumptions, bring in subject matter experts, etc. in order to improve the model and to further define it, adding as necessary new ideas to make the result more flexible and more tightly linked to current and expected requirements. The architect additionally should assess the value of solution-enhancing developments emanating from field work and incorporate these into the architecture models as appropriate.

           Manage the architecture: continuously monitor the models and update them as necessary to show changes, additions, and alterations. Represent architecture and issues during development and decision points of the program. The architect is an "agent of change", representing that need for the implementation of the architecture. Through this development cycle, the architect continuously fosters the sharing of customer, architecture, and technical information between organizations.

    Tuesday, April 22, 2008 7:57 AM
  • I posted a response couple month ago to a similar article...  here is what I posted...

     

    In the past 14+ years I have worked with organizations of different size, shape, background and culture...  Artchitecture means different in each of them...  In one, architect is nothing but a toll gate, in other architect sends lots of teck emails from vendors to tek folks in the company, in other architect writes the most complex piece of algorithm that a common developer can not, and finally, the prefix of architect may change the ball game fully like Infrastructure architect, Data architect, Application architect, Solution architect, Information architect, Security architect...

     

    Somewhere, the essence of architect is lost in almost all of the companies now a days.

     

    I also have a great respect for this article with the role of architect...

     

    http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

     

    An expert...

    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. Improving the development team’s ability gives an architect much greater leverage than being the sole decision maker and thus running the risk of being an architectural bottleneck. This leads to the satisfying rule of thumb that an architect’s value is inversely proportional to the number of decisions he or she makes.

    Tuesday, April 22, 2008 2:16 PM
  • [Edit - this was posted before Gaja reply]

    Interesting thanks for the replies. So far the answers have assumed quite a high level, which I may add is what I too would assume. However I'm seeing a number of...developers calling themselves 'Uber Architect' or something just as natty. So I was interested what the first thought of people was. I like to use the more tranditional construction architect as an analogy...

     

    1. Someone who architects a city and worries about the sewer, electricity, number of schools, hospitals, etc.

    2. Someone who architects a complex building such as a hospital with lots of potential uses and change of use

    3. Someone who architects a less-complex building such as a house

    4. Someone who designs a kitchen

    5. Someone who fits a kitchen

     

    So when someone says, "I'm an architect" I'm immediatley thinking at least 3 moving towards my idea of an uber architect at 1. [Generalisation Warning] What I find is most architects are at 4. i.e. they can design a solution using patterns but they don't have skills to evaluate what is the best option they typically grab a few patterns and "architect" or rather design a solution. I'm aware of the subtly different titles you can have with the word architect in it, but as the post says, I'm interested in hearing peoples initial views when faced with an architect.

     

    Tuesday, April 22, 2008 2:37 PM
  • interesting pdf, I like 'chief scientist'. What is interesting about that is the blurring of what I consider as a senior developer and an architect. In my analogy Science Officer Fowler seems to allow an architect to be at all of the levels depending on your context.
    Tuesday, April 22, 2008 3:00 PM
  • lol...  You are right, Fowler doesnt want to be called as architect...  He is super architect or 'Chief Scientist'.

     

    Anyway, Fowlers analogy of architect is an "Application Architect" who is moving towards "Solution Architect". 

     

    Architect in one company is totally different in other company, sometimes even within different teams in same company.

     

    There is no one good definition of architect.  I agree, with your listing that 3,2,1 all are architects, but maturity level and responsibilities differ at each level. 5 is certainly a developer, not an architect. 4 is senior developer and aspiring architect.

     

    Sometimes when people ask me what is the ultimate career goal of architect as they grow up in career ladder, I say, Architect ultimately becomes CTO (Chief-Technology-Officer) and Project leaders ultimately becomes CIO (Chief-Information-Officer), with CTO reporting to CIO...  Although this is not true in many organizations, but thats how I would see this happening if we all live in reasonable world.

    Tuesday, April 22, 2008 3:16 PM
  •  

    The career path is interesting because I took a serious look at this and I felt that it was general accepted that wearing the architect badge means less to zero coding and rarely financially better off than a senior developer. To paraphrase the quote, "If you like hands-on developing of software then an architect role is not for you". I think that was from the Skyscraper site. So it's interesting that you see the path leading to Chief Big Dodah.

     

    Tuesday, April 22, 2008 3:30 PM
  • Since you put it that way, making money has less bearing on what work you do, especially as Technology Worker.  There are some COBOL programmers that probably make more money than two levels above them.  Purely because it is a legacy application that was built 30 years ago, and they are the only ones that know those applications.  The companies are probably running their mission critical apps on those, rewriting in a modern technology would cost more than thier department's budget year over year.  It is easier to keep these cobol programmers paid outrageously than rewriting those apps.  YES, BAD IDEA if you ask me, but sometimes BOTTOMLINE comes as a hard truth.

    Tuesday, April 22, 2008 6:06 PM
  • A few years from now and I'll be hoping they're paying top dollar for c# developers! But no, my point was that as a career move you've got to love the non-coding side 'cause they'd be no other reason, i.e. you won't get to Chief Fancy Title. Except that if you accept Prof Fowlers definition then my senior developer == Fowlers application architect.

    Tuesday, April 22, 2008 8:53 PM
  • End of the day, we all have to love what we do, either coding, architecting, testing, project management, etc., etc.,  As a whole there are less then 0.5% Cheif Fancy titles available.  So, if we dont like what we do, and dont get a career appreciation, then we should quit current job or look elsewhere (hoping we all have the luxury to move elsewhere)

     

    I agree to your point to some extent, because there is no one way to say who is an architect or what is the definition of architect in IT. 

    I have been working on insurance domain (around new business, underwriting, sales tools, CRM, self-service [web/IVR], et al) for 13+ years using enterprise content management, BPM, .NET, J2EE, etc.,  As soon as I look for a job in non-insurance domain as architect I would be considered less experience for example in supplychain, retail, etc., because I wont have domain experience in those sectors.  Architecture does require domain knowledge along with technical skills as you grow in the career ladder.

    Tuesday, April 22, 2008 9:41 PM


  • I read about this some time ago, and read that in some companies you could indeed be a knowledgeable coder, and be considered an architect, whereas in other companies the solution architect for instance, is an equal but sideways in position to the development manager.  The solution architect coming up with the solution structure, the development manager implementing it.  Personally I would tend to agree that both are, just of varying skill levels.

    I agree that architect is bandied about far too often, that people who have designed the odd piece of code are an architect, which I guess could be seen to be true for the context of the job.  If all that is required of someone in a company is for them to design non-scalable, small applications, then in that sense they are capable of being an architect for that system.  That doesn't make them able to be an architect for a huge distributed messaging system though, that would require a person more experienced in the areas around that sort of an implementation.

    From the point of view of the wider understand of what a solution architect is and does, it's about managing risks inherent in choices of architectures, or compromises between then, and putting together something that is the best solution for that company at that time, and possibly in the future also, whilst not over-engineering.

    I think though in the same way as you get people specialising in areas within development, such as languages, or web / windows, the same happens to an extent with architects.  In the same way, the top developers are enterprise able developers, quite probably also able to manage the basics of application architect positions (due to the large amount of knowledge at the enterprise level).  In the same way, there is the top architect, who is also able to communicate at an enterprise level (not necessarily an enterprise architect)  This is the problem with the variable nature of the role, architect-apprentice, to architect-extrodinaire...  Such a range, but I think they're all architects of varying abilities.

    In terms of the non-coding side, I think personally it's because you don't have time to code as well as we a good architect as well.  I still enjoy tinkering with code, and will on occasion stretch my coding hamstrings.  The point to me is that a good architect, one that comes up with good real, workable solutions is going to still be able to identify with what it is to be a coder.  Those that do not, are 'ivory tower architects', who come along, design some theoretically perfect solution, and walk away with a big fat bin full 'o cash, before anyone works out the difficulties in implementation.  A good architect has to work with developers, and thus must still enjoy being involved in coding, although probably from a distance more often than not.

    Being an architect is a journey, just and performing your role as an architect is a discovery process, the more you discover, the further along that  journey you get.  A lot of that situation is due to the fact that IT technologies are constantly changing, so you're unlikely to have "seen it all", but as your experience grows you're likely to have seen similar things, albeint with different names, or slightly different functionality.

    Martin Platt.
    Tuesday, April 22, 2008 9:47 PM
  • I agree with the points made, and many of the interviews with well known architects say they prefer to use a technology themselves in order to understand it, but that doesn't mean use it in a solution, is that as satisfying...for me yes given you'll be more capable of explaing how to use it in a future solution or why you stay well clear of it.

    I guess my frustration is the point of not been able to clarify what an architect is.  I see a number of people  label themselves 'Lead this architect', 'Chief that architect' and ask them what an ESB is and they'll look at you like you're from Mars. So as much as a I laughed at Martin Fowlers Chief Scientist title I beginning to think it's time we killed off the title Architect and replaced with something more akin to what the person does. I think I'll go for 'Senior Pathfinder & Developer', WDYT Wink


    Wednesday, April 23, 2008 6:01 AM
  • Boss code monkey

    Wednesday, April 23, 2008 12:06 PM
  • What is found in the Models for Evaluating and Improving Architecture Competence white paper

    http://realworldsa.dotnetdevelopersjournal.com/modelsforevaluatingimprovingarchitecturecompetence.htm
    Friday, April 25, 2008 2:11 AM
  • Coincidentially, the architecture journal has an issue about the role of architects.

     

    To me personally, there's a number of levels to walk through, each requiring a broader field of knowledge

     

    application architect

    • design an application
    • implement the design
    • provide coaching/guidance to developers
    • (mostly) proficient in one domain: eg asp.net/windows apps, doesn't have too much knowledge of system around it (like servers, databases)

    solution architect

    • design an entire solution (set of applications) plus the interactions between them
    • proficient in multiple domains

    architect

    • toughtleader

     

     

     

    Cheers

     

    F

    Saturday, April 26, 2008 5:35 AM
  • and if i had read Diego's post, I would have known there's a new forum as well..

     

    Saturday, April 26, 2008 5:38 AM
  • It's interesting the point you touch, pkr

     

    From an architect, my belief, you should expect what Martin, Marshaln and Gaja first replied. Even if it seems too general (to be true in real projects ) it's the right basis an architect must show all the time

     

    I remember an anechdote, in 2002 I delivered a headhunt for J2EE devs and archs for a project so I prepared two multiple choice exams to easily filter aspiring candidates (not yet to choose "who", what was done with later interviews). What we needed was decreasing the people to interview to certain quotas

     

    So the exam on Java development contained certain questions on APIs, main classes (collections, I/O, Swing, etc) while the arch exam was more focused on Java EE capabilities, but not on API internals. So I remember that one of the architect candidates after the exam (he had failed) complaint about the nature of it. He told me "a real architect doesn't need to be proficient on what Java is able to do or not but in technology selections in general". Like Java o .NET? DB/2, Oracle, SQL Server or open source databases?, and so on

     

    He was partly right!!! But in that project context, he was wrong: Java EE had been already chosen by the technology board and that decision wasn't subjected to further revisions for the rest of the project. So given that context, his thoughts on what a real architect must do was now inaccurate

     

    However, for sure, a real architect must be able to switch contexts easily. I mean, if you were an architect on COBOL platforms (mainframes, bah) and the company decides to migrate to a server farm, Intel-based platform, you shouldn't need to learn everything from scratch. My personal case? I was a Java developer who became a Java architect. I learned about MS technologies for a particular case with a customer. Of course my proficiency was deeper in the Java platform for some while but I was still able to "architect" (not to code) the solution based on .NET and other MS prods

     

    How could I do that? Just applying what Martin, Gaja and Marshaln said that a real architect must do

    Thursday, May 22, 2008 8:38 PM
    Owner
  •  pkr2000 wrote:

    [Edit - this was posted before Gaja reply]

    Interesting thanks for the replies. So far the answers have assumed quite a high level, which I may add is what I too would assume. However I'm seeing a number of...developers calling themselves 'Uber Architect' or something just as natty. So I was interested what the first thought of people was. I like to use the more tranditional construction architect as an analogy...

     

    1. Someone who architects a city and worries about the sewer, electricity, number of schools, hospitals, etc.

    2. Someone who architects a complex building such as a hospital with lots of potential uses and change of use

    3. Someone who architects a less-complex building such as a house

    4. Someone who designs a kitchen

    5. Someone who fits a kitchen

     

    So when someone says, "I'm an architect" I'm immediatley thinking at least 3 moving towards my idea of an uber architect at 1. [Generalisation Warning] What I find is most architects are at 4. i.e. they can design a solution using patterns but they don't have skills to evaluate what is the best option they typically grab a few patterns and "architect" or rather design a solution. I'm aware of the subtly different titles you can have with the word architect in it, but as the post says, I'm interested in hearing peoples initial views when faced with an architect.

     

     

    When I see an Achitect, I straight kneel to the ground.

     

    For the rest, as you may guess, I disagree on the whole line, and will never work in your team (good for you), not even to make coffee (not good for you).

     

    Wink

     

    -LV

    Friday, May 23, 2008 4:25 AM
  • Diego, yes it's not something the posts have dwelled on but the non-platform specific skills is interesting. A lot of the posts have talked about should an Arch' code or not but I wonder if the response to that question would have been the same if it was asked, "given an architect should be platform agnostic should they be able to code in any platform"?
    Friday, May 23, 2008 2:26 PM
  • Given the diversity and enormosity of today's technology landscape atleast I dont try to code in all the platform.  I have done pretty good coding upto webservices in JEE and gone to all the levels in .NET (Although I usually stay away from javascript and save it for other developers that like it).  I have spent atleast a month playing around with Ruby but did not do any enterprise level application on it other than my personal learning.

     

    My point is, we wont have time to learn every technology stack to do coding.  I am a deep down .NET developer, high-level JEE developer.  That is probably because I started my career in C/C++, so learning Java or C# was given.  But I can architect a solution in .NET or JEE or in one case we used both the technologies to meet business need.

    Friday, May 23, 2008 8:07 PM
  • Interesting points now guys.

     

    My thoughts on this is that it isn't completely necessary for an architect to be able to code in the language in which they are architecting a solution, although it would probably help.  It seems to be that it is important to be able to have coded proficiently in the past in a main stream language, and thus understand the gotchas, and difficulties using that language.  Moving to a different platform will involve its own set of challenges, it is likely to include a large amount of crossover, and so when working in conjuction with developers who are experts, a good solution can be reached.

     

    The argument is a little like saying that a building architect must first be a builder to be a successful building architect, not so, though being one would probably be helpful.  Or the argument that a building architect that builds using wood cannot build using bricks - whilst there are different skills at play, a lot of the skills are going to be the same.

     

    I have to admit that most of my recent work has been in the Microsoft arena, but I don't believe that makes me less able as an architect.  If I was to architect a solution that had no Microsoft products or technologies at all, then I would certainly carry a certain level of risk inherent in my knowledge gaps in those technologies.  I would counter that argument by kicking of a proof of concept project to validate my choices and assumptions.  The job largely remains the same though.

     

    Martin.

     

    Monday, June 09, 2008 11:13 PM
  •  Martin Platt wrote:
    The argument is a little like saying that a building architect must first be a builder to be a successful building architect, not so, though being one would probably be helpful.  Or the argument that a building architect that builds using wood cannot build using bricks - whilst there are different skills at play, a lot of the skills are going to be the same.

     

    I'd say the opposite, that is that an architect cannot but also be a programmer: maybe some day one specializes, but where a *software* architect can come from, I mean: really?

     

    Indeed, it is this very analogy with the "building architect" that to me is quite problematic...

     

    From the premise:

     

    -- Customer -> [Architect] -> Engineer -> Worker => A house.

    (An Architect of ... makes form from empty.(?))

     

    -- Customer -> Analyst -> [Architect] -> Developer => Some software.

    (An Architect of Software is a high level designer and integrator. (Just not an Analyst, I suppose.))

     

    -- Customer -> Analyst -> Designer -> Coder => A software.
    (Architecture is auxiliary, so transversal to the projects; a Software Architect deals with infrastructural issues to support development. (More or less, as I've got it.))

     

    Now, whatever (software) architecture is, we are back to waterfall. From that point on, we already know.

     

    Otherwise, which one of the above is the (software) architect we are talking about here? Second option is intriguing, although what is architecture there? High-level design? Low-level analysis? Both?

     

    We are back to the waterfall. Generally speaking, we are engineers, aren't we?

     

    -LV

     

    P.S. ...unless one has got the other way round in mind...

    Tuesday, June 10, 2008 11:24 PM
  •  

    An architect that was a programmer is likely to be a better architect, but again, this comes down to what level of involvement you have with a project.  An example could be an enterprise architect, that's still an architect role, but not one that should necessarily need knowledge of programming.

    An application architect would need that sort of knowledge to do the job well, that is definitely the case.

     

    Not really too sure what you're getting at with the different flows from Customer to some product, or how waterfall comes into the question at all?

     

    Waterfall does not imply architecture, or vice versa.  A project has a beginning and an end, and how many 'iterations' or deliveries are made during that project, and how much feedback is given has an impact on a waterfall style versus an agile one.

     

    I would agree that we are engineers, if we're an application architect, but if we're a solution architect or higher, there are so many more skills involved, such as negotiation, conflict resolution, project management, business strategy and so on, as well as the whole 'design software' bit.  In that instance, we're probably not engineers at all, and are more like "software facilitators", "solution evangelists", that sort of thing.  The software is the end of the chain of a whole lengthy process, and the development of that software, I would expect would be done by developers, not architects.

     

    As an architect you can have knowledge of coding, and technologies, but to have the people skills, business strategy and domain knowledge, project management and all these other things, it's almost impossible to have time to do those things well as still be a programmer.

     

    Being a programmer first doesn't seem to be a prerequisite either, due to these other set of skills, probably somebody from a business analyst background could also make a reasonable job as an architect too?

     

    By the way, I do know where you're coming from, I was a developer first, but I believe also having been been a DBA, project managed, and so on are what makes me good at my job, not that I know how to program using C, C++, C#, VB or whatever.

     

    Martin.

    Wednesday, June 11, 2008 12:35 AM
  • Martin Platt:

     

    > An architect that was a programmer is likely to be a better architect, but again, this comes down to what level of involvement you have with a project.  An example could be an enterprise architect, that's still an architect role, but not one that should necessarily need knowledge of programming.

     

    How that can be, I cannot understand.

     

    How can an enterprise architect have no knowledge of programming? And how, by the way, can a business analyst have no knowledge of programming? With no knowledge of programming, are they going to treat "it" like a black box? Sort of big lego system with bricks and all? Is that why, by the way, we struggle so much down there in production (analysis included)?

     

    > I would agree that we are engineers, if we're an application architect, but if we're a solution architect or higher, there are so many more skills involved, such as negotiation, conflict resolution, project management, business strategy and so on, as well as the whole 'design software' bit.

     

    To me you keep generalizing dangerously. For instance, would you think the average engineer does not deal with all that and exactly that?

     

    > In that instance, we're probably not engineers at all, and are more like "software facilitators", "solution evangelists", that sort of thing.  The software is the end of the chain of a whole lengthy process, and the development of that software, I would expect would be done by developers, not architects.

     

    That developers develop and architects mostly do something else I am not questioning. Neither I can see any significant difference between our good old waterfall with architecture auxiliary and in support, and your picture with architecture as a facilitator. Well, maybe I see it: "evangelist"... Pardon me: evangelist of what apart from herself?

     

    > As an architect you can have knowledge of coding, and technologies, but to have the people skills, business strategy and domain knowledge, project management and all these other things, it's almost impossible to have time to do those things well as still be a programmer.

     

    Although obviously you will be architecting more and mostly, you *must* come from programming at least as much as Fabio Capello has been a football player and of great caliber. Would you hire a coach who has never touched a ball in his life?

     

    > Being a programmer first doesn't seem to be a prerequisite either, due to these other set of skills, probably somebody from a business analyst background could also make a reasonable job as an architect too?

     

    I have been working (also) has a business analyst for quite some time now, and -- as said -- I cannot even imagine an analyst, at any level, who has no strong competence of building real software... first hand! [And no, this is not like putting bricks together...]

     

    Not only we are back to the waterfall: we are still struggling with it. The architects will wait.

     

    -LV

    Wednesday, June 11, 2008 2:00 AM

  • An enterprise architect would have to have some knowledge of software and what is involved in developing software, but they do not need to have been a programmer to be an architect.  That was the question initially.

    A business analyst should be analysing business requirements.  There are varying levels of business analysts out there, those that talk business and domain only, and those that have some technical knowledge and probably overlap with architects in their role.  A business analyst that analyses the business does not need to know how to solve the problem, to be able to explain that it exists - they report what is, what problems there are from a business perspective.  The fact that business analysts who have some technical knowledge try to solve the problem there and then often leads to issues.

    The argument that an architect should be a coder, can be a negative experience.  If as architect you have intimate knowledge of the code implementation that can often taint your views of how things should be implemented.  Instead of working out how something should be done best, instead working from what is backwards to how that can be manipulated to fit in with the requirements.

    Yes, I did generalise, what I mean there is that a software engineer doesn't do really participate in those skills, or at least, if they do, they're either working in a very small company, or they're an architect with a different role title.

    Evangelism of the solution, business buy-in, that sort of thing?  You're a lucky person if you work in a company that always agrees immediately with whatever architecture you propose, or business strategy.

    The footballer analogy is silly.  As an architect, you can design software with knowledge of how to design software, and know very little about a language.  It is this very skill that allows an architect to move from one platform to another with very little knowledge of that platform.  Going back to that analogy of the coach, no you wouldn't probably hire someone to actually coach football skills if they were not a former footballer, but the manager you might do. He could be good with strategy, motivational skills, money and so on, and would be useful, whilst relying upon those that know to implement the balls skills part.

    We will have to agree to disagree with the BA point, I think it can be useful to have a technical background, but it can also be dangerous, as previously stated.

    What does an architect being a former programmer have to do with waterfall?  How many iterations, and how much customer feedback you get in a project has NOTHING to do with the architect on the project having been a former programmer or not.

    I would finish saying that probably most of the best architects are former developers, but that that shouldn't necessarily need to be the case.  Often roles are blurred, multi-skilled people who can be an architect, BA, developer and so on isn't a good thing, many head are more often than not better than one, no matter how many skills they have!  An Infrastructure architect certainly doesn't need to be a former developer but that person is still an architect.  The application architect certainly does. 

    Martin.
    Wednesday, June 11, 2008 2:29 AM
  •  Martin Platt wrote:

    Going back to that analogy of the coach, no you wouldn't probably hire someone to actually coach football skills if they were not a former footballer, but the manager you might do. He could be good with strategy, motivational skills, money and so on, and would be useful, whilst relying upon those that know to implement the balls skills part.


    Yes, there is a large number of top managers that were pretty poor footballers...and more vice versa. So just because you're technically good at a specific area (e.g. goal-keeper) doesn't mean you're good at appreciating the whole, organising the strategies and choosing the constituent parts. Actually I think it's a very good analogy for those who support the, "you don't need to code everywhere" camp, i.e. if you've been involved in the game somewhere you gain some experience of what others do (and how they do it) even if you don't do it yourself.





    Wednesday, June 11, 2008 6:26 AM
  • Martin,

     

    You have addressed none of my points and just keep telling your story. And again: I couldn't agree less with the points you make, and for reasons that are so trivial and evident that I just give up.

     

    You guys (general "you" and no compliments from this point on) not only have no proper definition of Architecture and never will find it; you actually have no idea what software production is, what it means, where it comes from and how it actually happens. You literally don't know what you are talking about, starting from the very concept of requiremenrts gathering.

     

    You and "the Java community" have made this industry so miserable, and of course you have the inconditionate support from this new generation of self-claiming "architects", so happy that incompetence is considered a key factor of success by your own theory; of course.

     

    You literally don't know what you are talking about, and you are just very lucky that real software developers are much smarter than that, so that your *** is always safe and you don't even need to get how inadequate you are: but you'll mention developers only to blame in case anything goes wrong, otherwise long live the queen that you are.

     

    You literally don't know what you are talking about. Come down here to production some day and I'll show you a couple of things, including requirements engineering which you have no idea what it is, and how that and the rest bloody differ from anything you are used to provide, that you call it analysis or design.

     

    You literally don't know what you are talking about. Come down here some day you bloody idiots, cool cars and girls, and geeks and this ain't gonna happen under my reign.

     

    You just suck.

     

    -LV

    Wednesday, June 11, 2008 9:54 AM
  • pkr2000:

     

    > Yes, there is a large number of top managers that were pretty poor footballers...and more vice versa.

     

    You just don't know the difference between an analogy and pushing an analogy too far.

     

    Another Michelangelo.

     

    -LV

    Wednesday, June 11, 2008 9:57 AM
  • Boss monkeys.

     

    -LV

    Wednesday, June 11, 2008 10:10 AM
  • You keep talking about some mythical business project level, then maybe the Architect you talk about is rather some manager (not even a team lead).

     

    Indeed, IME, the number 1 problem in the software arena is not technical nor technological, it is the managers! It is the software managers, 99 out of 100, who just do not know what they are talking about. It is them who blow up any quality as well as any budget, as well as any growing. "OO and BLL uber alles, this is the spec and that's it, extra-time is a must for God, the Nation and yourself, and all the rest just ain't gonna happen." [That's what they can grasp, and that's what they implement. If anything can go wrong, it is the developers or the customers, depending on the style of management, or rather depending on the situation. Bye bye Murphy.]

     

    But software is not like cars and not like bricks, least to say it is a service vs. product thing. It's uncomparably much more complicated than that. You just don't know what you are talking about, literally. And you suck.

     

    -LV

    Wednesday, June 11, 2008 10:54 AM
  • As an aside, although quite OT for this forum, you might be interested in this thread from the MathForum (sci.math), with a quote from John Von Neumann.

     

    Re: Von Neumann quote

    http://mathforum.org/kb/message.jspa?messageID=6252554

     

    No discussion there has started at the moment, but the article by Von Neumann referred to is very interesting in itself. It supports an understanding of the science and practice of building information and software systems as to their position within the overall scientific and applied panorama.

     

    Then von Neumann continues:

    \\
    At the inception the style is usually classical; when it shows signs of
    becoming baroque, then the danger signal is up. It would be easy to give
    examples, to trace specific evolutions into the baroque and the very
    high baroque, but this, again, would be too technical.
    \\

    Now my question is:
    Is it known what examples von Neumann had in mind, here?

     

    I say Computer Science is one such example, where we risk to forget that building information systems is at best an applied science, at most a descriptive one, with a strongly empirical base in any case (trying to use some Von Neumann's terminology that is in the article). [That is, I think, Engineering.]

     

    -LV

    Thursday, June 12, 2008 7:36 PM
  •  Martin Platt wrote:

     

    I have to admit that most of my recent work has been in the Microsoft arena, but I don't believe that makes me less able as an architect.  If I was to architect a solution that had no Microsoft products or technologies at all, then I would certainly carry a certain level of risk inherent in my knowledge gaps in those technologies.  I would counter that argument by kicking of a proof of concept project to validate my choices and assumptions.  The job largely remains the same though.

     

    Martin.

     

    I think that is exactly the right attitude to take (without getting too Donald Rumsfeld) if you know your unknowns, because of your experience, then at least you can do something about it. I was wondering Martin, do you get the sense of becoming pigeon holed as a Microsoft Arch' or perhaps you even prefer that?

     

    Friday, June 13, 2008 9:19 PM
  • I second what Gaja said, "Love what you do". Either it be coding or it be designing, we should love it like a lustful lover. And moreover, I believe that the efforts for Domain Specific Languages and Model-Driven Architectures may not have evolved if architects had started to design applications based on certain technologies.

     

    An architect must be technology-neutral, and that doesn't necessarily mean that a coder cannot be an architect. Switch over the roles according to your situations.

     

    "Call yourself an Architect?" Absolutely not. Its like a school-going kid claiming herself as an engineer for that she is aspiring to be. Becoming an architect needs more experience in both technology and designing, to a greater extent (not years).

     

    One short-cut - for a newbie into the industry - to become an architect before the hair goes grey (mine is already 70% lolz. I have just turned 24.. poor guy!!) is to work 16 hours a day, spending some time on splendidly available free-lance projects and exploration of new designs tailoring mainly the non-functional requirements.

     

    Afterall, the question tags made the man Einstein and toying with new designs can make a good architect. Until then, its advisable not to claim yourselves as an ARCHITECT, as do I.

    Friday, October 10, 2008 1:39 PM
  • An architect is the person who can see the broad field of the application context and organize it to the details and make sure that all of the moving parts are actually moving the way that they should.
    Thursday, May 07, 2009 4:57 AM
  • interesting pdf, I like 'chief scientist'. What is interesting about that is the blurring of what I consider as a senior developer and an architect. In my analogy Science Officer Fowler seems to allow an architect to be at all of the levels depending on your context.
    Pkr2000,

    The definition of Architect depends on the organisation's size and the type of architect. Even within the context of software there's  aSolution Architect and an application architect and probably others.

    what sets the solution architect apart from the application architect is scope. The solution architect has the widest possible scope once the requirements have been extracted by the subject matter expert  by an analyst (functional or business).

    An application architect works on a smaller scope of system change, once the solution at a wider level has been devised.

    Of course in a small organisation these collapse into the same role.

    So perhaps knowing in what contect of software organisation the architect works would assist with your question.
    Wednesday, September 30, 2009 6:36 AM
  • I think, architect should be the solution provider but not be another problem/issue creator. The solution should be maintainable for long go.

    Now days, it has been observed that people who uses complex words (talks lot) – bookies words are considered more technical and expert. But I feel an architect should have knowledge of lot many things and the solution s/he provides should not be complex (easy to maintain).

     


    Ashish Khandelwal
    http://ashishkhandelwal.arkutil.com


    Ashish Khandelwal http://ashishkhandelwal.arkutil.com
    Monday, November 09, 2009 1:01 PM
  • I got an interesting insight into what a chief archtiect does when I did a product demo for Bill Gates not long before he retired.  He had an uncanny knack for putting his finger right on the hardest problem we were trying to solve, and propose alternate approaches on the spot, which made for a lively discussion on why we chose the route we did, then he could connect what we were doing with half a dozen other teams at Microsoft.  He hasn't written code for a while, but his technical ability was much deeper than any manager between me and him in the room, I was rather surprised at how much, actually.  So the most senior Architect is not a manager, but a technical leader who can connect the dots and see the industry trends and has enough expierience as a developer to know exactly when to push back on the development team and tell them they need to try harder, or push back on the business/marketing/sales team and tell them they don't know that what they are asking is nearly impossible or many years of research.  Then it's just a matter of scope.  Lower level architects keep the dev team honest, and the code in good shape for the future, they stop throw away work, and have enough experience to guide the team around the common pitfalls and mistakes that typically cause wasted effort like big redesigns.  If you have a dev calling themselves "Uber architect", then great, but hold them to it, if big redesigns still keep happening then they are not really doing the job of architect.  I like your earlier analogy to building architects.  Imaging you're half way through building a sky scraper and the architect says, "oh rats, we have to start over".  Never happens.  Same should be true for a good software architect and that's why the get paid the big bucks.
    Wednesday, July 07, 2010 7:52 AM