Marcus Ahnve: Why the Term 'Architect' Doesn't Cut It Anymore

Discussions

News: Marcus Ahnve: Why the Term 'Architect' Doesn't Cut It Anymore

  1. Marcus Ahnve, in "Why the Term 'Architect' Doesn't Cut It Anymore," quotes Neal Ford on changing his title away from 'Architect.' Neal says:
    The title of "Architect" for software developers has gotten so diluted that its meaningless anymore. In fact, its almost pejorative because so many "paper" architects give it a bad name. I've gotten "Oh, dude, I'm so sorry" looks from people when I tell them I'm an architect, assuming that I've had a head injury or something and can't do real development work anymore. After long formulating and advice from others, I've now changed my title to the probably more apt "ThoughtWorker/Meme Wrangler"... The interesting side effect of this happens because I put my title on my presentation slides. In the US, but particularly overseas, people ask me "What does mee-mee wrangler mean?" So, I get to explain it. But that's way better than the now deprecated "Architect" title. It's a shame that, because we have no real industry-wide certifications, the nominally most advanced title has been co-opted by so many people divorced from reality. I've had to defend decisions made for SOA initiatives in front of "Architectural Review Boards" by people who last wrote code in COBOL. Can they really make good decisions about modern technology if they never touch it?

    Threaded Messages (33)

  2. Dilution[ Go to top ]

    I concur, the problem of the word “Architect” is the same as any other in a job title (What is the *real* difference between an “Analyst Programmer” and a “Software Engineer”?) I try to associate an “Architect” in the IT business to an “Architect” in the construction business – the person with the overall view and high-level knowledge of the coarse entanglements of business, technology and people. An “Enterprise Architect” (one that, as in construction “builds” an enterprise made out of different components). Any other person involved is NOT an architect (OK there might be multiple “enterprise architects” if the level of complexity of the project is the same as, let’s say building a city), a plumber is NOT a piping architect, an electrician is NOT an electrical architect – the same way someone that understands JavaEE is NOT a Java Architect (and neither in .NET or C++) – they are solution designers for a specific component of a much bigger domain (the REAL solution). A good piece of software that has the most efficient algorithms programmed is hardly a solution to a business (the mapping of the RIGHT algorithms – ‘business logic’ – and the right programming – one that causes minimal impact on operations and deployment – makes the business efficient, and even though it might not use the best algorithms (for some specific business reasons) it is a solution (the same way that using bricks and titanium to build council houses might not be efficient for the business). If you are defending designs in front of people that programmed in COBOL, there is at least one of 2 problems – you might be stereotyping people because they are not in the ‘bleeding edge’ of technology (COBOL still serves a purpose for certain businesses), or the people put in front of you don’t understand what you are explaining or don’t understand how the technology pieces you are using solve a problem in a better way than their traditional solutions(so you can replace “COBOL” with any other language, and still face the same problems, it will be difficult to replace the people, so more time will be needed making the people think in your same wavelength). Remember that analogous to a construction’s “architect”, half of the time you know the materials (“software” and “hardware”), a quarter of the time you are a project manager (managing budget and timescales), and finally the most important quarter of the time is spent managing expectations (the “psychology” of capturing requirements and negotiations between users and delivery/operations).
  3. How come?[ Go to top ]

    So how come building architects can design complex buildings and structures without having to lay the bricks or mix the concrete? Of course, having a good understanding of concrete and bricks is important, but there are also many other concerns (e.g. design patterns). Sure the term software architect is misused by every Tom, Dick and Harriette, but then so is the term software engineer. Anyone can be a programmer or software developer (by definition all you have to do is program or develop software). People just need to distinguish good software architects / engineers from lesser quality ones. Cheers, Ashley. -- Ashley Aitken Perth, Western Australia mrhatken at mac dot com
  4. Sheila as well[ Go to top ]

    My construction architecture friends (or civil engineering or construction engineering, i guess it will depend on each university/country) had to take courses on materials (tensions, aesthetics, etc) ... but there is a catch, "building" has been around for thousands of years ... "software" just for decades ... so laying brick is in perspective easier (ask Tom and Dick), but you still see enormous failures in construction (due to aesthetics or wrong tensions) happen every now and then. And before someone points it ... yeah they also run into over-budgets (so it is not only software!). Tune in to Discovery channel ... and have a look!
  5. Re: Sheila as well[ Go to top ]

    so laying brick is in perspective easier (ask Tom and Dick), but you still see enormous failures in construction (due to aesthetics or wrong tensions) happen every now and then.
    ..and there are only so many patterns and combinations thereof that you can lay bricks. Software on the other hand..
  6. Re: Sheila as well[ Go to top ]

    My construction architecture friends (or civil engineering or construction engineering, i guess it will depend on each university/country) had to take courses on materials (tensions, aesthetics, etc) ... but there is a catch, "building" has been around for thousands of years ... "software" just for decades ... so laying brick is in perspective easier (ask Tom and Dick), but you still see enormous failures in construction (due to aesthetics or wrong tensions) happen every now and then.

    And before someone points it ... yeah they also run into over-budgets (so it is not only software!).

    Tune in to Discovery channel ... and have a look!
    Can we stop with the "building architect" / "software architect" comparisons. If there was any relationship beyond a thin facade of wording similarity our industry would have a much better success rate. The problem with the title "software architect" is that people treat it as a job you train for instead of a role that through time, talent, and effort you slowly become qualified to fulfill.
  7. So how come building architects can design complex buildings and structures without having to lay the bricks or mix the concrete?
    Well actually they don't. Their designs must be presented to and reviewed by and ultimately signed off by structural engineers. Probably the best analogy in software to a brick and mortar Architect is a business analyst. They are customer facing, find out about what the customer's needs and goals are etc. They use drafters to draw up blue prints and engineers to certify the structures. It's actually very funny that Architect was adopted as a term to describe a role along the engineering career path. I actually think the term Engineer should be reclaimed as a proud title and in no way indicative of a junior role. Just my $0.02. btw, my business card says Architect :D
  8. Right, all title arguments aside, my resume says "architect" if the job is looking for an architect. My resume would say "coding cowboy" if the position was looking for one. In the end it is just a HR-computer matching algorithm. Amongst my peers I'd rather just be known as a developer.
  9. Oh how very sadly and unfortunately true. I was sat in a meeting only last Friday, discussing my proposal for a new Enterprise Somethingorother team, and had to admit that the term 'architecture' would probably have to be dropped in order for this new team to have a hope of being taken seriously. The critics on the other side of the table were all business people. I wish it weren't the case, but alas, the perceived glory attached to the role has attracted many that, as the article points out, either couldn't code for toffee, or see the world as simplistic boxes and arrows and magical reuse, or perhaps are just really poor communicators. What would be interesting though, are views on a better term for architect2.0? (given that I can't see Meme Wrangler catching on..)
  10. Too much for single title[ Go to top ]

    In order to better present my opinion, I will briefly describe traditional roles. (System) Architect - one who has a vision of what is to be achieved with information system, and has ability to explain that to other people. It is not necessary for architect to be of ICT origin. Sometimes architect is the customer who ordered the system. Project (Product) manager - there is conceptual difference between project and product, but, project manager is usually a man who makes deal with customer, and manages communication with customer, manages time, human and money resources, resolves conflicts, steers project in certain direction, in order to complete the project. Depending on organization, he is more business/marketing oriented, or has competence to evaluate and make technical and design decisions System Analyst - using his skills and knowledge of Information Engineering, gathering inputs from customers, system technologists and other specialist and sources, makes model of as-is and to-be System Technologist - person that has know-how from particular field or knowledge, that can explain or help with making models, or algorithms of how is something to be done System Engineer - today's DBA and/or Software Engineer (Programmer). Software engineer is person that can be both Designer and Coder. System Operator - today's end user (not derogatory - they can be more skilled than above, especially if they know mathematic methods and can do Quantitative analysis and data mining) Then, with advances in IT, one man could do all by himself for small and medium sized projects - Developer (from architect, manager to analyst and software engineering, or combination). Term "Developer" means more capable than "Programmer", but all "coders" (usually new wave, some time about 1992-3, with rise of Visual Basic) suddenly started to call themselves "Developers", although they don't deserve/d to be called "Programmers". Demand for IT workers has driven such development. Clearly, it is time consuming and expensive to produce fully skilled IT worker, so various method such as ACME programming seminars, various artifact generators, etc are used to enable people to do specialized, less demanding niches, at lower cost, which is ok. IT is about money. (open source is about money, too) That leads to occasional conflicts, when such people acquire terminology and start to compete. That is natural, and if you are really good at Information and Software engineering, you will have no problem to calmly respond with rational arguments, and presentation of case study with graphs that business can understand. In fact, communication skill is often key to success, and competitive advantage. Now, back to subject :) Title of "Architect" is not diluted, it was just wrongly used. Not every developer is architect, and vice versa. Architects from customers side are often people that owner trusts, and who are about to make some decisions on macroscopic levels. You are obviously one that can do all of the above, and are trying to find a just one word title to describe all? :) How about writing everything on business card? Although, we have Information science - more theoretic, and Computer science also called Informatics - more about applying System analyst is not bad - if you can do that, you can do project management and architecture. Speaking of the System, we have Design and Development of Information Systems, which is separated into Information engineering and Software engineering. How about "Information and Software engineer"?
  11. Re: Too much for single title[ Go to top ]

    These days I just tell people that "I work with computers", and move the subject on to something more interesting. I've had many different roles in development, and as a freelancer I pride myself on being able to do whatever development/design role is required for the job in hand, so I'm not too bothered about job titles. However, in many companies the latest job title is a fashion accessory that the company rewards its employees with to keep them sweet. So I don't think you will have much luck trying to get the world to apply a consistent set of titles. Besides, this time next year we will all be meme wranglers.
  12. I work with computers, too![ Go to top ]

    These days I just tell people that "I work with computers" ..
    Yup, that's been my standard answer for a couple of years now. It gives me a chance to hear things from the other person before they pigeon-hole me based on a title, etc. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  13. Re: Too much for single title[ Go to top ]

    Architects from customers side are often people that owner trusts, and who are about to make some decisions on macroscopic levels.
    I agree. And is this not also where the problem begins? The two key words being "trusts" and "decisions". To make good decisions, you must have enough data/knowledge/experience/etc to have a reasonable chance of success, and the communication skills to explain these decisions to those whose skills lie in less technical areas. And if you can make good decisions, and explain them well, you earn trust. I would not be surprised to find that the world is full of building sites where carpenters, electricians, and brick layers criticise the 'architects' whose plans they are forced to work to, so perhaps software is no different than the real world. The bash-the-architect theme is certainly an old one on TSS. And even though my experience of software development is that it is much more akin to engineering poetry than engineering bridges, I have yet to hear a better term for the people you describe who owners trust to make good decisions about their software products at the macro level. Which is why, even though it's understandable, it's such a pity that so many people outside the field have lost faith in it. All great technical architects I have worked with, as far as I can remember, coded frequently (even if only outside office hours) - what that meant was in the unlikely event that they over-engineered an idea, they could have a productive conversation with developers and rectify it (and also give the developers enough respect not to architect all the way to pseudocode).
    You are obviously one that can do all of the above, and are trying to find a just one word title to describe all? :)
    Ah.. if only :) but one simple, respected, term for a cross-project, strategic thinking, technical lead is surely not too much to ask. Or is it?
  14. Too many titles[ Go to top ]

    You don't actually believe that all these titles make a dime's worth of difference do you? I've always thought the old Bell Labs approach made the most sense, everyone was MTS (Member of Technical Staff) with a few MTS PIs (Principal Investigator, think Ken Ritchie or Rob Pike) thrown in for good measure.
  15. Yes and no[ Go to top ]

    If you are talking about roles I described, yes, because they are roles and not titles. This roles are reference points. Although some titles are named after roles, sometimes. If you are talking about the rest, then, 90% no. I can do all of that, and prove it, so I don't care much. But, I also believe in details, and it is matter of fact that product that is wrapped nicer than other will tend to sell better. Business outfit (uniform) and title will make things a bit more easier when we speak about non-technical (from business) architects. 70% of opinion is made by first impression. Depending on environment, I later change in more casual clothes, when I start working.
  16. Re: Too many titles[ Go to top ]

    Anyone know of a link for the definitions of the Bell Labs titles (or is that all there is)? I like MTS and had heard they used 'Distinguished Engineer' as a title you could only attain by being voted thus by your peers, and kinda liked the notion. If the consensus is that there aren't so much duff titles, as duff experiences with individuals performing under those titles, then some kind of certification/peer review would sound like a good idea.
  17. anything else joe?[ Go to top ]

    Joe, can't you come up with anything else besides the regurgitated "Architects suck" article? I think i'll go hang out on infoq.com for awhile...
  18. Re: anything else joe?[ Go to top ]

    Joe, can't you come up with anything else besides the regurgitated "Architects suck" article? I think i'll go hang out on infoq.com for awhile...
    Feel free, Bill. But "architects suck?" Where do you see that in the post? Did you notice, by any chance, that there were four other articles posted so far this morning, with different subjects? This is your site, man. If you feel there's content out there that should be here, feel free to point it out.
  19. Re: anything else joe?[ Go to top ]

    Joe, can't you come up with anything else besides the regurgitated "Architects suck" article? I think i'll go hang out on infoq.com for awhile...
    +1
  20. Though I agree with the thought. I do not agree with the action. One of the problems with our industry is that the only way that people feel they can make their mark these days is to coin a new catch phrase, rather than educate the masses. I think we should stop this insane practice and rather than give up on a term that is appropriate in favor of some new phrase or catch word or catch title, why not educate those who have no clue and stand our ground.
  21. When the title is diluted, management can always make up new ones, just like they made up the 'Architect' title. How about 'Composer', 'Tzar', 'Supreme Leader' or 'Prince'? Imagine having a title like 'Enterprise Solution Prince', now that'll impress the heck out of your audience.
  22. ... formerly known as ...[ Go to top ]

    When everyone tires of that, you inevitably become 'The Architect Formerly Known as Prince'. The only firm conclusion I can draw from this whole discussion is that Neal Ford is a pretentious git, and that ThoughtWorks seems to attract more than its fair share of those. The interesting question is whether TW deliberately hires pretentious gits, or is that just what people turn into after a while working for a company with such a pretentious name. Mik
  23. Oh the irony....[ Go to top ]

    Interesting to see someone complain about titles being handed out like candy and becoming degraded because of it. That happened a long time ago and partly because because the IT industry chose to start using the titles for its own purposes. The IT industry shouldn't have picked up titles like "Engineer" and "Architect" in the first place. These titles have no relevance to the IT industry, but the usage of these titles are tenuously justified on the basis that Engineers, Architects and IT people all "seem to build stuff" for a job. I'm an Engineer (Mech) by training and become an "IT Guy". Engineers and Architects are members of professions that are governed by entry requirements, overseen by professional bodies, and bound by their professional membership to uphold certain ethical and professional standards. IT workers don't have this, and even if they did they should use different titles because they operate in a different field. I've seen this debate a thousand times on message boards about what an Engineer and an Architect role each represent in the IT world. Everybody comes up with a different definitions which disagree wildly with everybody else's, because there are no definitions of such roles for the IT world. The titles indicate membership of professions that have little or no overlap with the IT world and continued use in the IT industry is just nonsensical.
  24. Re: Oh the irony....[ Go to top ]

    Yeah, but without the titles how would we know who to pay more?
  25. There is some confusion around the term enterprise architect. I empathize with the frustration surrounding the "paper" architects - dinosaurs with little to no experience in actual coding, or the technologies that they are expected to assemble into a solution. But then, I'm usually frustrated by the use of the terms "architect", "architecture" and "solution"; I find someone claiming to be an architect, and they turn out to be a developer, a business analyst, or worse yet, the aforementioned "paper" architect. So I agree with the article's general disillusionment with the term. But I'm also not comfortable with what I read as an implied narrow definition of "architect" to include just the technical aspects of a solution. That would be a "technical" architect. Maybe that's the real problem. No one really agrees on what an architecture is, and we are left in the interim with a number of people supplying what seems to me to be some arbitrary definitions of what the different terms mean. What follows is just my opinion - I've found it useful in dealing with people and understanding where the different pieces fit together. As always, caveat emptor. Perhaps someone else will find it useful as well... In our deployments we use the following definitions: (append "architecture" to each if you want...) 1. Functional - Analysis of the business requirements. This is usually the job of the business analysts. Usually this expressed as a functional specification - use cases, collaboration diagrams, etc. 2. Application - the translation of the functional requirements into a framework. Sometimes this is Java / J2EE , sometimes a DSL - highly deployment specific. 3. Project - how the whole thing is managed. Roles, responsibilities, delivery schedules, release management. This is the "glue" for how the solution is delivered. This is usually a combination of several smaller dimensions, like QA and Project Management. It's usually expressed in terms of a project plan, testing plans, deployment architecture, etc. This is usually realized using tools like maven, ant, and so on. 4. System - the realization of the "non-functional" aspects of the system. High Availability, Scalability, Performance, Reliability and so on. This is expressed in a system specification. This is realized in the deployment specific configurations. Each of the axes requires a certain level of expertise, and in most projects, no one person owns the whole picture. Architects can fall into each of these categories - some people are better at the Application Architecture than the Functional or Business Architecture, and so on. What I've seen is that all 4 of these pieces contributes to what we call the "Solution". So then, I apply the term "Solutions Architect" to the person who is able to understand, elaborate on, and execute each of the axes, and to keep the entire picture in mind. So then, there are "technical" architects, "business" or "functional" architects, and so on. Interestingly, the project architecture is usually a role fulfilled by a combination of QA, Project / Program management and Consulting. BTW, these definitions have been around for awhile in one form or another. The OMG for instance, has a reference model similar to the one above.
  26. More than the S/W[ Go to top ]

    For small systems, tackling the complexity of the information and software is the primary concern. This can be managed largely by the software designer/developer. As the systems get larger, the complexity and management of the platform and environment increases and needs someone with a higher-level view than just the software. So many other issues have tyo b etaken into account: sizing, maintenance, monitoring, backups, release management, budget. This is the function for which a sufficiently qualified architect is worth their weight in gold. IMO "Software Architect" is a pointless title. Software Analyst or Designer is better. Kit
  27. If the west coast marketroids didn't spend 99% of its time thinking up complete bullshit marketspeak while desperately clinging and to any title that have a semblance of respect and competence, we wouldn't have this problem. You can go ahead and disparage an old "COBOL" programmer, but the fact is that no real progress or new technology has emerged in the last ten years. It's ironic that you complain about COBOL programmers not liking your "SOA initiatives" (initiative? what's wrong with project? That doesn't cut it anymore?), since SOA is basically procedural programming rediscovered. What? You mean you provide a service (aka procedure) with a message (aka parameters) and you get a response (aka return value)? Some guy whines about a title not meaning anything, while he actively participates in the entire process of repackaging/recycling a concept and simultaneously disparaging of people that used that concept originally. Thanks for the good laugh.
  28. My friend, you don't have a clue about what SOA is. It is an architectural style that evolved from and extended component based and 3 tier architectures. It is not at all about procedural programming or any other kind of programming. Also, the fact that messages are arguments being “evidence” of something is a silly comment. Object methods take arguments too. So what? What programming language of any type or paradigm doesn’t have some form of argument passing? In all programming languages the methods, functions, subroutines also have some way of returning results, directly or indirectly. The message style (esp. self-describing messages) of passing data and the data as contract concepts have much greater importance and effect than merely being arguments. In simple terms, with distributed components your collaboration logic (use case realization) was either executed on the client or passed to the server as a command object to be executed there. In a service-style, that logic is implemented in the service – a façade for the collaboration. The collaboration is a use case realization because otherwise it would likely be specific to a client design. That would make it less reusable and hardwire it to another tier’s design defeating the purpose of having tiers. As far as COBOL is concerned, you can implement SOA and CBA using COBOL. COBOL’s main disadvantages here would be that it is not dynamic in its use of memory and structures and that it is not object-oriented both of which you can work around if you must. If you were an architect you would know these things.
  29. Sooo Sensitive about SOA... HTTP Request, HTTP Response == procedural programming Sure there's lots of architectures that plop stateful concerns all over the map. Sure there are distributed object architectures that use WS as a messaging protocol. Because, you know, SOA, is soooo much more revolutionary than CORBA from 15 years ago...or not. To use one of my least favority technical adjectives, I'll grant that WS is "lightweight" compared to CORBA. Sorry to rain on your SOA parade, why do you think using a nonoptimized protocol like HTTP became such a ubiquitous idea? Is it the amazing technical advantages of HTTP like GET and POST? The pure joy of UTF-8 or whatever HTTP uses to encode itself? Or maybe it's because the security nazis at every company closed all ports except 80 and 443, so that the only practical way to do messaging was over those few remaining web ports, using them effectively as a security bypass? Well, I'll grant webservers provide nice Transport-Layer Security relatively transparently too. But seriously, SOA is not the greatest thing since sliced bread, it isn't the grand evolution of messaging since ever. It's an organically evolved entity complete with warts and whistles that grew out of the practical ubiquity of web servers. SOA's grand acceptance in the marketplace is it's ability to piggyback on the infrastructures and knowledge and collective learning of HTTP from mid and late-90s web programming. However, XML and SOA really provide no amazing revolution over older less adopted/propietary schemes from a decade ago. The theme of the post was motivated by some young guy getting challenged by "old guys that don't know anything". My point: they're probably like me, tired of hearing people shill the same old shiny turd as THE SOLUTION TO ALL YOUR WISHES AND DESIRES and OMG WE HAVE TO DUMP EVERYTHING AND RECODE IT THIS WAY. My point of ripping on SOA is that it isn't anything new, but a collection of old stuff. Using SOA in a non-SOA environment many not make sense from organization purposes, even if there aren't technical barriers to its use. Or maybe the old guard is lazy. Hard to tell when the article reeks of overconfidence and self-importance.
  30. Carl, You are confusing SOA with web services, with HTTP, with programming and with implementation technologies like CORBA. Your rant is against the hype mostly emanating from self serving vendors and “implementation free” consultancies. I don’t disagree with you there, but that is not SOA. SOA is an architectural STYLE. You can do SOA, as I have, using CORBA, J2EE, RPC, messaging middleware, Tuxedo, SMTP, or any number of other middleware and communications options. You can program your components and services using OOP, procedural languages, assembler, scripts or whatever else floats your boat. The key issues for SOA are components (their characteristics, interfaces and governance) and the use of components in collaborations/orchestrations to realize use cases as service operations. Components are generally associated with OOA, but in the early days (1980’s and early 90’s) where often programmed in a procedural language such as ‘C’. For non-OO believers, data-centric structured analysis (as opposed to functional decomposition) can yield pretty composable components too provided you remember to keep a separation of concerns and roles and to strongly encapsulate your implementation. The service interface style has evolved over time, but the key aspect that has remained pretty constant has been to send each operation a single message and get one in response. More recently is has become popular with web services (WSDL in particular) to only expose the service end point and not each operation and allow the end point to interpret the message and then select and execute the appropriate operation. Nevertheless, both the client and the service understand the operation being requested and the contract that it adheres to. I’ve been practicing SOA since around 1990 and I know I didn’t invent it so I’m not sure how old it really is. I think it’s a great style. Its flexible, scalable, combines ample reuse opportunities, etc. It nicely supports event-driven architecture’s as well which is where things should be headed. BTW, I’m an old guy – 27 years in IT and I like it better than sliced bread.
  31. Re: Really[ Go to top ]

    Everyone knows these 'Architect/Engineer' titles are bogus. Lets quit kiddin ourselves and move on! to real content!!
    That's a pretty general statement. Are you sure there isn't anyone who thinks these titles aren't bogus? I'd be concerned if someone was a developer on my projects and they made statement like that. Cheers, Ashley.
  32. If the west coast marketroids didn't spend 99% of its time thinking up complete bullshit marketspeak while desperately clinging and to any title that have a semblance of respect and competence, we wouldn't have this problem.

    You can go ahead and disparage an old "COBOL" programmer, but the fact is that no real progress or new technology has emerged in the last ten years.
    Carl, can't you come up with anything else besides the regurgitated "West coast marketroids suck - nothing new has been invented since the 1806" article? I think i'll go hang out on infoq.com for awhile... -- kidding.
  33. Really?[ Go to top ]

    Everyone knows these 'Architect/Engineer' titles are bogus. Lets quit kiddin ourselves and move on! to real content!! That said how about titles of slave-coder, coder, senior-coder and finally chief-coder?
  34. it depends[ Go to top ]

    If titles are given only to provide folks with job-satisfaction then its useless. If correctly given titles signify - what the person will do in a job - what the person is capable of doing - signifies his/her experience level - maturity level in a domain area and so on I hate it when people use titles as boasting point. The important thing is what was the reason why someone got a title. If the reasons are good and the person was deserving then i will respect the person and his title.