Are there any Software Architects here?
-
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.
I work for a biotech company and we have the same thing going on here. We have chemists who have some C++ and C# experience who are "architects" because they know/understand the chemistry algorithms. They can't design code very well. It takes professional SW engineers to fix the bad code.
-
A related question: what is the difference between a software architect and a software designer? I have seen titles such as "Software Design Engineer" and other like it. Then, what is the difference between architecture and design? (It may be just a question of philosophy.) Also, how does a software architect differ from (compare to) a construction (building) architect? Is there a list of what a construction architect does?
-
I work for a biotech company and we have the same thing going on here. We have chemists who have some C++ and C# experience who are "architects" because they know/understand the chemistry algorithms. They can't design code very well. It takes professional SW engineers to fix the bad code.
And so it goes... Good luck to you.
-
...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.
A software architect is a good programmer and thinks ahead how the parts interoperate, whether or not the system is extensible and has good judgement to predict performance. A "software architect" which is not a good programmer is a disaster. One cannot have guts feeling about interoperability, extensability and performance without the skill to actually build the pieces. The grounding would be missing. While a manager can compensate not being a top-notch expert by using people skills, listening skills and listing to the best engineers, an architect cannot. Without the skills one makes a fool out of oneself when trying to tell professionals how to do their work. Well, the syntax details of a language might be the one thing which does not matter. A good software developer can do or is in the process of learning to do software architecture. But mediocre software developers can still code an algorithm without understanding the bigger picture.
-
No. Real architects don't only design, they also code.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert EinsteinSome of my inputs include: Software architects should -Design -for ease of understanding -for maintainability -for quality -for performance -write code -for the same reasons above -expect the highest quality code and design from his development team -know about testing, at least have a plan and have a good test team -keeping a common secure code base -be in communication with the customer, management, and all team members -look over the shoulders of his development team -have numerous code and design reviews with the developers -understand the data his system consumes, produces, and has internally This is not a full list.
-
...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.
Mmmmmmm! Are there any Software Architects here? Software Architect? Well, architects design things. We in the software industry are often compared to those in the building industry, but I think that the software industry is closer to the movie making industry, and the software architect more like the director (who might some times take a role and act!) But what makes a Software Architect? Firstly, a Software Architect must understand the full Software Development Life Cycle(SDLC) AND where in that cycle they operate. Like a movie, each software application has a life cycle. Like a movie, a software application can be used over and over by the end user. Unlike a movie, a software application can be changed in it life cycle and continued to be used by an end user. (although there can be a Director's Cut) To make that happen, players in the SLDC must understand their role as well as the SDLC. So who are these players? There are 5 major players and under each of them are teams of other players. These are: Project Manager: Team of Sub-Project Managers Scrum Master or some other project methodology champion. Business Process Manager: Team of Business Process technicians Team of Business Analysts Software Architects: Software Team Leads Teams of Senior Developers and Developers Quality Assurance Manager: Team of Testers Team of Technical Writers Enterprise Architect: Change Control Team Team of DBAs Team of System Engineers Support Manager Team of software Support staff So now the 5 major players are going have a virtual conversation for the life of the software application. The initial build of the software application will be done in a project, then later it will be Supported and enhanced in patches. The idea for the project will come from a customer, either internal to the organisation or external to the organisation. The Business Process Manager( or members of she/his team) will determine if the idea is feasible for the organisation. If it is, the Project Manager will form a project team. The Project Manager will be interested in three things: How long will it take? How many resources(both human and non-human) will it take? How much will it cost? The Software Architect will need the other players to help answer these questions. Although, the Software Architect won't
-
A software architect is a good programmer and thinks ahead how the parts interoperate, whether or not the system is extensible and has good judgement to predict performance. A "software architect" which is not a good programmer is a disaster. One cannot have guts feeling about interoperability, extensability and performance without the skill to actually build the pieces. The grounding would be missing. While a manager can compensate not being a top-notch expert by using people skills, listening skills and listing to the best engineers, an architect cannot. Without the skills one makes a fool out of oneself when trying to tell professionals how to do their work. Well, the syntax details of a language might be the one thing which does not matter. A good software developer can do or is in the process of learning to do software architecture. But mediocre software developers can still code an algorithm without understanding the bigger picture.
Thanks for your input. I totally agree with you on:
Chris Jacobi wrote:
A "software architect" which is not a good programmer is a disaster.
Many of us have suffered under "Architects" who could not code their way out of a wet paper bag. They create grand visions of Rainbow Unicorns which cannot be created in code and then we devs have to build code that creates the program anyway.
-
Mmmmmmm! Are there any Software Architects here? Software Architect? Well, architects design things. We in the software industry are often compared to those in the building industry, but I think that the software industry is closer to the movie making industry, and the software architect more like the director (who might some times take a role and act!) But what makes a Software Architect? Firstly, a Software Architect must understand the full Software Development Life Cycle(SDLC) AND where in that cycle they operate. Like a movie, each software application has a life cycle. Like a movie, a software application can be used over and over by the end user. Unlike a movie, a software application can be changed in it life cycle and continued to be used by an end user. (although there can be a Director's Cut) To make that happen, players in the SLDC must understand their role as well as the SDLC. So who are these players? There are 5 major players and under each of them are teams of other players. These are: Project Manager: Team of Sub-Project Managers Scrum Master or some other project methodology champion. Business Process Manager: Team of Business Process technicians Team of Business Analysts Software Architects: Software Team Leads Teams of Senior Developers and Developers Quality Assurance Manager: Team of Testers Team of Technical Writers Enterprise Architect: Change Control Team Team of DBAs Team of System Engineers Support Manager Team of software Support staff So now the 5 major players are going have a virtual conversation for the life of the software application. The initial build of the software application will be done in a project, then later it will be Supported and enhanced in patches. The idea for the project will come from a customer, either internal to the organisation or external to the organisation. The Business Process Manager( or members of she/his team) will determine if the idea is feasible for the organisation. If it is, the Project Manager will form a project team. The Project Manager will be interested in three things: How long will it take? How many resources(both human and non-human) will it take? How much will it cost? The Software Architect will need the other players to help answer these questions. Although, the Software Architect won't
Thanks for your great input. You are right about the Architect needing to know a little (and a lot) about everything. That's why -- as you indicated -- the Architect must really enjoy tearing the business apart and re-assembling it from every angle. Because all of the pieces are connected and the software solutions we create are really just automating the business, every piece is entwined with every other piece. It creates a lot of complexity. That's probably a big part of why companies get so overwhelmed by the whole thing, often lose their focus and then fail on projects.
-
Some of my inputs include: Software architects should -Design -for ease of understanding -for maintainability -for quality -for performance -write code -for the same reasons above -expect the highest quality code and design from his development team -know about testing, at least have a plan and have a good test team -keeping a common secure code base -be in communication with the customer, management, and all team members -look over the shoulders of his development team -have numerous code and design reviews with the developers -understand the data his system consumes, produces, and has internally This is not a full list.
:thumbsup: Every coder, programmer, developer, architect, code-monkey, etc should all strive for the same
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein -
Mmmmmmm! Are there any Software Architects here? Software Architect? Well, architects design things. We in the software industry are often compared to those in the building industry, but I think that the software industry is closer to the movie making industry, and the software architect more like the director (who might some times take a role and act!) But what makes a Software Architect? Firstly, a Software Architect must understand the full Software Development Life Cycle(SDLC) AND where in that cycle they operate. Like a movie, each software application has a life cycle. Like a movie, a software application can be used over and over by the end user. Unlike a movie, a software application can be changed in it life cycle and continued to be used by an end user. (although there can be a Director's Cut) To make that happen, players in the SLDC must understand their role as well as the SDLC. So who are these players? There are 5 major players and under each of them are teams of other players. These are: Project Manager: Team of Sub-Project Managers Scrum Master or some other project methodology champion. Business Process Manager: Team of Business Process technicians Team of Business Analysts Software Architects: Software Team Leads Teams of Senior Developers and Developers Quality Assurance Manager: Team of Testers Team of Technical Writers Enterprise Architect: Change Control Team Team of DBAs Team of System Engineers Support Manager Team of software Support staff So now the 5 major players are going have a virtual conversation for the life of the software application. The initial build of the software application will be done in a project, then later it will be Supported and enhanced in patches. The idea for the project will come from a customer, either internal to the organisation or external to the organisation. The Business Process Manager( or members of she/his team) will determine if the idea is feasible for the organisation. If it is, the Project Manager will form a project team. The Project Manager will be interested in three things: How long will it take? How many resources(both human and non-human) will it take? How much will it cost? The Software Architect will need the other players to help answer these questions. Although, the Software Architect won't
Good analyse with consistent arguments.:thumbsup: I agree with you... up to "Good Software Architects will WANT have NOT to code, because they love it must find the best coders and must recognize their best solutions for the project which he defines with its best experiment!" So I agree for its huge culture! But it doesn't have to be a good Mason but just know what a Mason can do best and how to do it."
entia non sunt multiplicanda praeter necessitatem
-
Hey, these are 2 different positions and you need Architect only for huge system in enterprise domain.Usually you have Solution Architect, Domain Architect and Enterprise Architect, according to the complexity of the solution and the enviroment. In small team or organitation sometime the Solution Architect is also a developer but you are in limit situation where may be you don't need a architect becuase you application is not too huge. Cheers, Antonio
I'd also add Application Architect to that list. Many senior engineers who contribute heavily to the design of your application and interfacing systems are partially filling that role. If you are regularly interfacing between the business and your team, designing ahead of time to meet foreseen requirements, and finding ways to reduce your app's technical debt then you may be an Application Architect depending on a company's definition. It is very dependent on the scope, complexity, and size of the solution and organization to justify these roles. A Solution Architect is overseeing the architecture of the set of applications which form said solution. I would normally think this is a dozen or more apps to qualify for this next distinction. Our solution contains 80+ applications. Someone at this level would definitely not be coding feature content. I would then jump to Enterprise Architect but I can see a Domain Architect having a place in larger organizations which have teams of architects. Then there's Systems Architect which is an ICT position. For those wondering generally an architect isn't delivering feature content because their responsibilities would cause them to be a block on the critical path. They are generally too busy interfacing between the business and engineering and while they may still write code generally it's big picture prototypes and system infrastructure. If they were to pitch in to help a team I'd think it would be limited to unit tests or basic items from the backlog... something that wouldn't interfere with the developers.
-
A related question: what is the difference between a software architect and a software designer? I have seen titles such as "Software Design Engineer" and other like it. Then, what is the difference between architecture and design? (It may be just a question of philosophy.) Also, how does a software architect differ from (compare to) a construction (building) architect? Is there a list of what a construction architect does?
James Lonero wrote:
Then, what is the difference between architecture and design? (It may be just a question of philosophy.)
There is none; the difference is purely etymological. Multiple people needing a word to describe something new, borrowing from the existing, and inventing a new title. Both are used to describe the same, a position where one is responsible for the overall structure, robustness, validity and consistency of the system, as well as for the interaction of various components. One would call that "design", the other "architecture". Both words describe the work of a developer that is tasked with getting the stuff of the other devs to work together nicely.
James Lonero wrote:
Also, how does a software architect differ from (compare to) a construction (building) architect?
A building-architect is an architect by definition, where the software-architect is usually just a title.
James Lonero wrote:
Is there a list of what a construction architect does?
No, but each country will have a degree, and one may assume some basic knowledge of local building regulations. In software, we cannot even agree on whether top-down or bottom-up is better, where the builder will simply exclaim that there will no work done on the roof before there's a foundation for the building. Building a house is often rather predictable :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
Thanks for your great input. You are right about the Architect needing to know a little (and a lot) about everything. That's why -- as you indicated -- the Architect must really enjoy tearing the business apart and re-assembling it from every angle. Because all of the pieces are connected and the software solutions we create are really just automating the business, every piece is entwined with every other piece. It creates a lot of complexity. That's probably a big part of why companies get so overwhelmed by the whole thing, often lose their focus and then fail on projects.
Companies get overwhelmed by the complexity, rather than lose focus. They seem to lose focus when what is really happening is that they are searching for the next "guru" that will give them the "silver bullet" solution. Managers need to be more educated as to what the SDLC is and what the impact is on building software in-house. Normally when companies build software in-house they have moved away from their core business activity into a realm that they really do not understand. (I am not advocating outsourcing, but I am advocating educating senior managers)
-
Good analyse with consistent arguments.:thumbsup: I agree with you... up to "Good Software Architects will WANT have NOT to code, because they love it must find the best coders and must recognize their best solutions for the project which he defines with its best experiment!" So I agree for its huge culture! But it doesn't have to be a good Mason but just know what a Mason can do best and how to do it."
entia non sunt multiplicanda praeter necessitatem
I still believe that "Good Software Architects will WANT to code", whether they actually get the time to do that is another story. You seem to be arguing that an Software Architect does not need to know how to "code up an enterprise level solution". That I would total disagree with! Enterprise level software applications are too complex to only theorise about their design, without practical long term hands on experience in actually building solution experience. Therein lies the issue and the problem senior non-technical managers face today: having to listen to "software architects" that have never "coded up an enterprise level solution". The lack of University level master degrees (unlike Building Architects) AND an industry that is still more craft than science ( at enterprise business solutions) (not even a software apprenticeship like Masons have) AND the technical complexity that are in enterprise software solutions can only really be counted by the Software Architect having decades of hands on, wide ranging (different business, different industries), in-depth experience. Without that experience, the Software Architect will be relying upon Senior Developers to perform tasks he/she should do or to know answers to issues that he/she should know or lead non-software stakeholders to the correct solution when he/she should convince and lead. I think that a great deal of thought needs to go into this. Also, don't confuse the "Solution Architect" with the Software Architect as they are completely different. The "Solution Architect" deals with the Business Solution, not the Software, Hardware, Networking Solutions. Regards frazGJF
-
Companies get overwhelmed by the complexity, rather than lose focus. They seem to lose focus when what is really happening is that they are searching for the next "guru" that will give them the "silver bullet" solution. Managers need to be more educated as to what the SDLC is and what the impact is on building software in-house. Normally when companies build software in-house they have moved away from their core business activity into a realm that they really do not understand. (I am not advocating outsourcing, but I am advocating educating senior managers)
frazGJF wrote:
Managers need to be more educated as to what the SDLC is and what the impact is on building software in-house.
frazGJF wrote:
Normally when companies build software in-house they have moved away from their core business activity
Those are both very good and valid points.