Are there any Software Architects here?
-
In addition to all of the above, IMHO, there is an element of 'politics' that a software architect has to play - this gets termed differently in different countries; from what I know, this is called 'lobbying' in the US. Sometimes, he needs to get different parties/departments to agree on the proposed solution, and this is more often then not, a 'politics' game.
Amen to that. There was a time when software developers were not allowed to approach the clients to get answers to their questions. All queries had to be submitted in writing to the system architects of the developer who would liaise with the system architects of the client. Heaven help you if you forgot a question or didn't get an answer to one of your questions; you had a deadline to meet. When not chasing answers to questions, our time, as system architects, would be spent demonstrating what we perceived as the big picture to client representatives (including congressional committees).
The difficult may take time, the impossible a little longer.
-
...and I don't (necessarily) mean you have the title of Software Architect. I believe many people are Architects -- because of what they do -- but do not have the title. Also, (unfortunately) many people have the title, but aren't actually Architects. Big Question So, if you are an Architect, what is it that you believe you do that a software developer doesn't do? CodeProject : Developer Heavy, Architect Light? I'm asking that as a question, not trying to rile anyone up. I notice a lot of codeslingers around here, but curious if CodeProject also attracts Software Architects. What do you think? Interesting Question What value do you think a Software Architect really brings? What skills do you expect from an Arthitect? Can the value a Software Architect adds be put into words / definitively measured? Just curious about your thoughts.
The function of architects is to have stupid, unworkable ideas, which the carpenters will redesign on site to make them work. It's pretty much the same in the programming world.
I wanna be a eunuchs developer! Pass me a bread knife!
-
...and I don't (necessarily) mean you have the title of Software Architect. I believe many people are Architects -- because of what they do -- but do not have the title. Also, (unfortunately) many people have the title, but aren't actually Architects. Big Question So, if you are an Architect, what is it that you believe you do that a software developer doesn't do? CodeProject : Developer Heavy, Architect Light? I'm asking that as a question, not trying to rile anyone up. I notice a lot of codeslingers around here, but curious if CodeProject also attracts Software Architects. What do you think? Interesting Question What value do you think a Software Architect really brings? What skills do you expect from an Arthitect? Can the value a Software Architect adds be put into words / definitively measured? Just curious about your thoughts.
Hi, I have that title and role in my company, and it makes me cringe a little when I read some replies implying that architect work is "just producing diagrams and let developers do the real work". Best way for me to answer the questions asked is to explain the role of the architects in my company I guess. So, here are some of the things I'm expected to do (along with my fellow architects): - knowing everything about all the technologies we use and the ones we could use: languages, frameworks, protocols, front end, back-end, cloud platforms, tools, etc. (note that it is 'expected' from us, personally I feel far from having all the knowledge others think I have or should have... And my learning is done on my free time, obviously...) - having an equal knowledge about the business, for all the clients - knowing all the technicalities of every project we operate - dealing with the clients and partners for everything technical. Involves presentations, meetings, fake smiles, and often dying a little inside and refrain from facepalming - when starting a new project, designing for the big picture, taking into account performances, reliability, security and using knowledge of all the projects to decide what we can or not reuse - breaking down the design into chunks for developers. Each developer is given requirements to meet for her chunk, then must design her chunk herself, that we will then review, with maybe several iterations. - managing development processes (source control, build, etc) - managing developers' recruitment and growth. Architects are in charge of technical interviews, developers' initial training, performance assessment, task repartition, etc. - ensuring code quality - building teams you know you can trust enough to delegate as much as you can - being responsible. As an architect, you make the overall technical decisions, and you tacitely approve the decisions of every people to whom you delegated, meaning you're accountable for everything that can go bad - taking the heat when things break, even if not design-related. Identifying the causes. Converting the heat you've taken into proper advice for developers so that the errors will never be done again. That's a key point of the role: taking the stress, but avoid putting it back on the developers (there is already the project manager for that...) - being able to quickly fix anything on any project - coding some critical parts, some tools or some abstractions to facilitate developers' work - suffering from impostor syndrom and str
-
I really hate how terms from construction bleed into software development. No! you aren't an "Architect". You aren't a "Design engineer". I've been named an architect and I have to deal with it - In my views the "Architect" is responsible for the technical direction that the project is taking and must maintain a vision of the entire system and plan technical items accordingly so that you don't end up with a mess of unmaintainable spaghetti. He is also responsible for dealing with management and explaining design decisions to the bean counters and time planners. But most importantly, I think the architect must follow his or others design decisions in code, be extremely competent technically and up-to-date with all SW dev. trends(and bullshit) and have the domain knowledge needed for making competent technical decisions. If the architect doesn't code, doesn't keep current on SW dev. practices(or even lacks knowledge on well establised practices), and only sits inside a UML tool then he most likely is producing negative value for the team. Unfortunately, life isn't this simple or idealistic and there's loads of "architects" out there that should be taken out back and shot. But there's also loads of developers out there that do what a real architect would do for a project that simply aren't recognized. Oh and it doesn't matter what you think an architect should do, it's what management thinks that matters. :)
Great points. Thanks for replying. I especially agree with you on:
slack7219 wrote:
If the architect doesn't code, doesn't keep current on SW dev. practices(or even lacks knowledge on well establised practices), and only sits inside a UML tool then he most likely is producing negative value for the team.
And definitely:
slack7219 wrote:
Oh and it doesn't matter what you think an architect should do, it's what management thinks that matters.
-
The function of architects is to have stupid, unworkable ideas, which the carpenters will redesign on site to make them work. It's pretty much the same in the programming world.
I wanna be a eunuchs developer! Pass me a bread knife!
Mark_Wallace wrote:
function of architects is to have stupid, unworkable ideas,
I've worked under these people too and they definitely are not architects, no matter how many times it says it in their title.
-
Hi, I have that title and role in my company, and it makes me cringe a little when I read some replies implying that architect work is "just producing diagrams and let developers do the real work". Best way for me to answer the questions asked is to explain the role of the architects in my company I guess. So, here are some of the things I'm expected to do (along with my fellow architects): - knowing everything about all the technologies we use and the ones we could use: languages, frameworks, protocols, front end, back-end, cloud platforms, tools, etc. (note that it is 'expected' from us, personally I feel far from having all the knowledge others think I have or should have... And my learning is done on my free time, obviously...) - having an equal knowledge about the business, for all the clients - knowing all the technicalities of every project we operate - dealing with the clients and partners for everything technical. Involves presentations, meetings, fake smiles, and often dying a little inside and refrain from facepalming - when starting a new project, designing for the big picture, taking into account performances, reliability, security and using knowledge of all the projects to decide what we can or not reuse - breaking down the design into chunks for developers. Each developer is given requirements to meet for her chunk, then must design her chunk herself, that we will then review, with maybe several iterations. - managing development processes (source control, build, etc) - managing developers' recruitment and growth. Architects are in charge of technical interviews, developers' initial training, performance assessment, task repartition, etc. - ensuring code quality - building teams you know you can trust enough to delegate as much as you can - being responsible. As an architect, you make the overall technical decisions, and you tacitely approve the decisions of every people to whom you delegated, meaning you're accountable for everything that can go bad - taking the heat when things break, even if not design-related. Identifying the causes. Converting the heat you've taken into proper advice for developers so that the errors will never be done again. That's a key point of the role: taking the stress, but avoid putting it back on the developers (there is already the project manager for that...) - being able to quickly fix anything on any project - coding some critical parts, some tools or some abstractions to facilitate developers' work - suffering from impostor syndrom and str
I can see that you are under a lot of pressure and your role as Architect seems to have a firm description where you work. It sounds as if you are filling the role of the true Arhitect that many of us understand / expect the role to be. Small Epiphany As I was reading your long list of responsibilities I was hit by an epiphany of sorts. Many of us have suffered under "Architects" who have honestly been more in the role of Manager -- who played the role of King -- who sat back, shot out what s/he thought were Genius Designs and then became utterly unaproachable when the Genius Design could not be implemented in real code. That's the problem many here have with Architect role. However, your role, to me, looks like the real role of Architect. Thanks so much for chiming in with your thoughts.
-
...and I don't (necessarily) mean you have the title of Software Architect. I believe many people are Architects -- because of what they do -- but do not have the title. Also, (unfortunately) many people have the title, but aren't actually Architects. Big Question So, if you are an Architect, what is it that you believe you do that a software developer doesn't do? CodeProject : Developer Heavy, Architect Light? I'm asking that as a question, not trying to rile anyone up. I notice a lot of codeslingers around here, but curious if CodeProject also attracts Software Architects. What do you think? Interesting Question What value do you think a Software Architect really brings? What skills do you expect from an Arthitect? Can the value a Software Architect adds be put into words / definitively measured? Just curious about your thoughts.
Its an abstraction level. When I wear that hat, I am designing at the metaphor level... Trying to validate the actual (real) design concerns. Does this HAVE to support 1000 computers connecting, picking off work to do (as in queues), or is it really 1,000 humans selecting the next thing they are skilled enough to handle with specific resources at their ready. In some cases, is 256ms delay between requests Obscene or acceptable. Knowing how technologies tie together, work together, and blending it with the Business Requirements. Add in testability, provabilitiy and fault tolerance. Finally, what Public APIs will we support for others to continue to connect into us, etc. etc. etc. When I am done, like others have said, I should be able to present management with the salient points of the process, and confirm we have it right. And at the same time, I should be able to work with the developers to make sure they build what is expected, and it works as described...
-
Its an abstraction level. When I wear that hat, I am designing at the metaphor level... Trying to validate the actual (real) design concerns. Does this HAVE to support 1000 computers connecting, picking off work to do (as in queues), or is it really 1,000 humans selecting the next thing they are skilled enough to handle with specific resources at their ready. In some cases, is 256ms delay between requests Obscene or acceptable. Knowing how technologies tie together, work together, and blending it with the Business Requirements. Add in testability, provabilitiy and fault tolerance. Finally, what Public APIs will we support for others to continue to connect into us, etc. etc. etc. When I am done, like others have said, I should be able to present management with the salient points of the process, and confirm we have it right. And at the same time, I should be able to work with the developers to make sure they build what is expected, and it works as described...
Great input.
Kirk 10389821 wrote:
When I am done, like others have said, I should be able to present management with the salient points of the process, and confirm we have it right. And at the same time, I should be able to work with the developers to make sure they build what is expected, and it works as described...
Agree 100%. A very good summary of what the Architect should really be doing. Sounds like your company is doing things right.
-
...and I don't (necessarily) mean you have the title of Software Architect. I believe many people are Architects -- because of what they do -- but do not have the title. Also, (unfortunately) many people have the title, but aren't actually Architects. Big Question So, if you are an Architect, what is it that you believe you do that a software developer doesn't do? CodeProject : Developer Heavy, Architect Light? I'm asking that as a question, not trying to rile anyone up. I notice a lot of codeslingers around here, but curious if CodeProject also attracts Software Architects. What do you think? Interesting Question What value do you think a Software Architect really brings? What skills do you expect from an Arthitect? Can the value a Software Architect adds be put into words / definitively measured? Just curious about your thoughts.
I used to work with a guy who thought he was an architect, but he was really just a programmer who didn't do anything. He would actually bring up in meetings the fact that some people (architects) spent their time designing and didn't bother with the code; that's what he wanted to be but not what he was hired to be. So he sat around and read books and kept other programmers from working by talking to them all day about interesting ideas that he'd never actually implement. When management lit a fire under him he'd pound out some code, but it would all just be prototyping with function stubs. He actually felt that implementing functionality was beneath him, as was maintaining/fixing his code. So basically someone had to come along behind him and finish his work, for which he would take credit but no responsibility. He was one of the most knowledgeable programmers I've ever worked with, and also one of the most useless. Despite his knowledge his code was poorly thought out and sloppy. He saddled the company with half-baked, buggy, incomplete in-house systems that were architected out the wazoo with five levels of frameworks but couldn't actually do what they were supposed to do. True architects are great, but spare me the wannabes.
-
I used to work with a guy who thought he was an architect, but he was really just a programmer who didn't do anything. He would actually bring up in meetings the fact that some people (architects) spent their time designing and didn't bother with the code; that's what he wanted to be but not what he was hired to be. So he sat around and read books and kept other programmers from working by talking to them all day about interesting ideas that he'd never actually implement. When management lit a fire under him he'd pound out some code, but it would all just be prototyping with function stubs. He actually felt that implementing functionality was beneath him, as was maintaining/fixing his code. So basically someone had to come along behind him and finish his work, for which he would take credit but no responsibility. He was one of the most knowledgeable programmers I've ever worked with, and also one of the most useless. Despite his knowledge his code was poorly thought out and sloppy. He saddled the company with half-baked, buggy, incomplete in-house systems that were architected out the wazoo with five levels of frameworks but couldn't actually do what they were supposed to do. True architects are great, but spare me the wannabes.
Great input. I've experienced this same thing.
StatementTerminator wrote:
He was one of the most knowledgeable programmers I've ever worked with, and also one of the most useless.
Great quote, because these people do tend to show up on many development projects. Often found at large companies where they and their code can hide out. :)
-
...and I don't (necessarily) mean you have the title of Software Architect. I believe many people are Architects -- because of what they do -- but do not have the title. Also, (unfortunately) many people have the title, but aren't actually Architects. Big Question So, if you are an Architect, what is it that you believe you do that a software developer doesn't do? CodeProject : Developer Heavy, Architect Light? I'm asking that as a question, not trying to rile anyone up. I notice a lot of codeslingers around here, but curious if CodeProject also attracts Software Architects. What do you think? Interesting Question What value do you think a Software Architect really brings? What skills do you expect from an Arthitect? Can the value a Software Architect adds be put into words / definitively measured? Just curious about your thoughts.
I think the "Architect" portion of the title is often misapplied. I worked for several years as a systems engineer (computer based systems for HVAC automation) in the construction industry. "Architect" in that context is how I see "Architect", abstractly, in "software architect". It means looking at more than code, object design, UI and workflow, etc. It means looking at hardware, power requirements, air conditioning, real estate/building rental, contracts, business processes, financing, project management, cost projections and estimating, labor management, software estimating (the real voodoo economics), and all the other aspects associated with the total life of the project. Consider this example: You are the software architect tasked with taking existing code (mostly VB6, some C++, some Java) in a product suite that is currently in production with existing customers who depend on it. There is existing cash flow to consider. There are existing enhancements and bug fixes in the pipeline to consider that, if not done to meet deadlines, affect contracts and cash flow, as well as the company's reputation. The marketing research team has made a very persuasive case that the company must, within 2 years, have its product suite providing some or all of its services on mobile devices (as appropriate for the functionality). Further, VB6 is a 32 bit language, and it is obsolete, no longer supported by Microsoft. Its compatibility with current Windows OSs is "iffy" at best, and questionable going forward in a market where you would need to support Windows, Android, iOS, and perhaps Windows Phone. Part of your challenge is to migrate completely off VB6 without negatively affecting existing contracts, maintaining the existing product, and meeting marketing's need for an updated and enhanced version that meets the market's needs on desktop, laptop, and mobile devices, and does so securely, with good performance. To do all that requires a lot more than software engineering alone. An architect for a building has to broadly cover similar areas, and often draws on others' expertise to do so, but making his or her own decision because they understand how each disciplinary area works and interacts. A software architect should do no less.
-
I suspect that a Software Architect designes applications which bend in a high wind instead of breaking... ;)
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
Nailed it in one, Griff. I understand the sentiment regarding codeslingers, but the write-ups I like here are the ones where someone explains why you would or wouldn't use a capability. Sure, we'd all like to have a triple-redundant quantum cloud cluster to perform sorts before they are requested, but here on Earth, maybe a call to sort() is good enough... I would extend the argument that a "pure" coder (software developer) implements what the customer wants, but a "Software Architect" designs and implements what a customer needs. (And "customer" in this case is anyone who wants the software...even the coder his/her self.) In reality, neither group is "pure"--a beautiful set of code, even to precise customer specs, is a failure if it doesn't get the real job done. And a perfect design doesn't mean crap if no one will use it.
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing this way?"
-
Ravi Bhavnani wrote:
And of course, an architect should be an experienced developer.
I like the definition you provide and especially that you added that last part about the SA (Software Architect) being an experienced dev. It's so important but we've all experienced someone who has Architect in their title but who is definitely missing the development experience. IT can be quite terrible. I find the difficulty that many here are having explaining what an Architect does/is interesting bec. then how do you prove Architect abilities to a prospective employer. Thanks for your great input.
newton.saber wrote:
how do you prove Architect abilities to a prospective employer.
That's easy.. you show them that you already have the title someplace else. The implication is that, since you weren't born with the title, someone, somewhere thought you deserved it and christened you with it. Whoever that was, they trust them.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
I think the "Architect" portion of the title is often misapplied. I worked for several years as a systems engineer (computer based systems for HVAC automation) in the construction industry. "Architect" in that context is how I see "Architect", abstractly, in "software architect". It means looking at more than code, object design, UI and workflow, etc. It means looking at hardware, power requirements, air conditioning, real estate/building rental, contracts, business processes, financing, project management, cost projections and estimating, labor management, software estimating (the real voodoo economics), and all the other aspects associated with the total life of the project. Consider this example: You are the software architect tasked with taking existing code (mostly VB6, some C++, some Java) in a product suite that is currently in production with existing customers who depend on it. There is existing cash flow to consider. There are existing enhancements and bug fixes in the pipeline to consider that, if not done to meet deadlines, affect contracts and cash flow, as well as the company's reputation. The marketing research team has made a very persuasive case that the company must, within 2 years, have its product suite providing some or all of its services on mobile devices (as appropriate for the functionality). Further, VB6 is a 32 bit language, and it is obsolete, no longer supported by Microsoft. Its compatibility with current Windows OSs is "iffy" at best, and questionable going forward in a market where you would need to support Windows, Android, iOS, and perhaps Windows Phone. Part of your challenge is to migrate completely off VB6 without negatively affecting existing contracts, maintaining the existing product, and meeting marketing's need for an updated and enhanced version that meets the market's needs on desktop, laptop, and mobile devices, and does so securely, with good performance. To do all that requires a lot more than software engineering alone. An architect for a building has to broadly cover similar areas, and often draws on others' expertise to do so, but making his or her own decision because they understand how each disciplinary area works and interacts. A software architect should do no less.
Great reading and great points and you are the first I've noticed to mention $$$. Your points make the importance of all the outside elements pushing in on a project and the necessity of making sound trade-offs on the decisions made. At the end it isn't about the technology at all, it is about a business solution. However, as soon as I say that, people are going to think I'm saying you could just write everything in JavaScript, but I don't mean that either. I mean the most important thing is the business solution related to the bottom line. That's why the true architect has to know so much because: 1. it has to be economically feasible for the company 2. it has to keep the company secure, 3. it has to be easily maintainable so the company doesn't lose $$$ doing maintenance, etc.
-
newton.saber wrote:
how do you prove Architect abilities to a prospective employer.
That's easy.. you show them that you already have the title someplace else. The implication is that, since you weren't born with the title, someone, somewhere thought you deserved it and christened you with it. Whoever that was, they trust them.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
patbob wrote:
you show them that you already have the title someplace else
I'm hoping you just forgot the emoticon for laughter. Those are the "Architects" many of us have worked for in the past. I once asked a onsite Architect, "How long have you been doing this?" He answered, "A little over 1 year." "Oh, but how long have you been coding?" "Just a year. I became an Architect when I learned C#," he said. "What were you doing before that?" "I was a accountant and knew the business." He had the title though.
-
Great reading and great points and you are the first I've noticed to mention $$$. Your points make the importance of all the outside elements pushing in on a project and the necessity of making sound trade-offs on the decisions made. At the end it isn't about the technology at all, it is about a business solution. However, as soon as I say that, people are going to think I'm saying you could just write everything in JavaScript, but I don't mean that either. I mean the most important thing is the business solution related to the bottom line. That's why the true architect has to know so much because: 1. it has to be economically feasible for the company 2. it has to keep the company secure, 3. it has to be easily maintainable so the company doesn't lose $$$ doing maintenance, etc.
I agree, and thanks. Of course, the ones who would think you are saying you could write everything in JavaScript are missing the $$$ point. When it comes to the technology considerations, you have to pick technology, including the languages involved, that provide the performance, reliability, and scalability in the end-user environment that keep the user using your product (cash flow to your company) and not another product (loss of cash flow to your company). Loss of cash flow means folks don't get paid. IMHO, software architects, at least this one, should keep his or her hands in coding to some degree in order to know what the technology holds. If nothing else, coding and testing new language features and testing capabilities to gauge usefulness and benefit. At least enough time to know whether or not something is worth having others spend time with it.
-
...and I don't (necessarily) mean you have the title of Software Architect. I believe many people are Architects -- because of what they do -- but do not have the title. Also, (unfortunately) many people have the title, but aren't actually Architects. Big Question So, if you are an Architect, what is it that you believe you do that a software developer doesn't do? CodeProject : Developer Heavy, Architect Light? I'm asking that as a question, not trying to rile anyone up. I notice a lot of codeslingers around here, but curious if CodeProject also attracts Software Architects. What do you think? Interesting Question What value do you think a Software Architect really brings? What skills do you expect from an Arthitect? Can the value a Software Architect adds be put into words / definitively measured? Just curious about your thoughts.
Here is one fellows opinion: http://noperfectprogram.wordpress.com
-
I agree with you. Someone who is an Arhitect but doesn't really have the development chops to back it up isn't an Architect at all. Also, I've read that book, 97 Things Every Software Architect Should Know[^] Not a bad read because it's from so many viewpoints.
newton.saber wrote:
Someone who is an Arhitect but doesn't really have the development chops to back it up isn't an Architect at all.
I agree. Software architecture is highly technical, not just conceptual. Anyone with a CS background can work at the conceptual/design level, but it takes a high degree of technical knowledge to know how to do that in a way that will actually work as needed in the real world. Plus, programmers are not likely to listen to an "architect" who can't speak their language and understand what they are doing. I know I wouldn't. It's like someone being semiconductor architect without ever having been an electrical engineer, something's fishy about that. A software architect without a programming background is someone I'd consider a glorified project manager, or a misplaced academic. Part of the problem, I think, is that it's a prestigious title but rarely needed. Any experienced programmer can do basic architecture, it's part of the skill set, and it's all that's needed on most projects. It's really only the large, complex projects that require a specialist to come in and work on the architecture. And that's really how I think of it, architecture is a specialized programming job in the same way that being a DBA is a specialized IT job, someone you bring in when the needs are beyond what the programmers can/should do on their own. But everyone seems to want the title, whether a full-time architect is needed or not.
-
Mycroft Holmes wrote:
I do the design of the app from the database structure through to the UI.
So few devs know to do it this way -- which is a hybrid Domain Modeling start and works for most projects very well / far better process than 95% of the devs use. Thanks for mentioning it.
newton.saber wrote:
So few devs know to do it this way
Really? I've done development this way for a long time, just from experience, I assumed most people did it that way. Actually, working on DB structure is the part of my job where I'm actually doing a bit of architecture, that's when everything has to be thought through. It's just mindless tedium after that. Show me your (sane) DB structure and I have a pretty good idea of how the entire system works, it's the first thing I want to see when working on a new system.
-
Architects design systems that they think just takes bricklayers (programmers) to build, whereas, in fact the programmers need to be structural engineers to build safe and robust systems from the architect's plans, as architects have little knowledge of how things actually work in the real world.
========================================================= I'm an optoholic - my glass is always half full of vodka. =========================================================
Chris Quinn wrote:
as architects have little knowledge of how things actually work in the real world.
Some of them.
Chris Quinn wrote:
in fact the programmers need to be structural engineers to build safe and robust systems from the architect's plans
That of course is too generic. - It ignores that doing that in any complex system is a significant challenge and one that cannot be achieved by any one individual. - It ignores that to do that there are in fact implementation details that must be done which really have nothing to do with architecture unless the architect is going to a very low level. For example avoiding injection attacks. - It ignores that the knowledge required to do this in a significant enterprise is probably beyond the capability of any single individual. For example locking down a web server and locking down a database server (and apps) are very different.
Chris Quinn wrote:
Architects design systems
Architects can have other roles of course. For example insuring that customer requirements do not subvert long term corporate goals and that customer requests can be correctly munged to produce something that is cost effective to implement.
