|
Eddy Vluggen wrote: able to explain the SOLID principles
100% agree. At least that's a start at some kind of metric.
Great input. Thanks.
|
|
|
|
|
I don't think you need to be an architect to know that. Any developer worth his/her salt should be able to explain that.
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: Any developer worth his/her salt should be able to explain that.
Agreed. However, it is amazing how few Architects even truly understand them. And by Architect I mean the ones with the titles who aren't Architects.
|
|
|
|
|
Ravi Bhavnani wrote: Any developer worth his/her salt should be able to I gave up on that a long time ago.
Smile a lot, don't argue
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
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
|
|
|
|
|
What's the difference between said three titles, outside the difference in the title?
What does each have to contribute?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: What does each have to contribute?
Good question. I would like to hear more too.
Also, the proliferation of names/titles throughout the industry is also why it would be quite helpful if there was somewhere to go that defined these more clearly. But, alas, I understand the difficulty / impossibility of that and how companies would surely mess it all up.
|
|
|
|
|
Companies do not like to share such info.
It might benefit the competition, and it might hurt the reputation of the company if it proves to be "just a title".
So, they should just keep hiring architext and keep their fingers crossed
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Companies do not like to share such info.
So true.
|
|
|
|
|
newton.saber wrote: Also, the proliferation of names/titles throughout the industry is also why it would be quite helpful if there was somewhere to go that defined these more clearly
Salary.com and places like that do an ok job.
However, I do not think I have seen many very good definitions of a software architect, because everyone has a different opinion.
Also, I worked at a company, where every developer on the server team had the title "architect" over their domain. There was one developer per domain, UI, database, network etc.
Finally, I have noticed the trend lately that companies use the term "Architect" much less for software and are now using "Staff" or "Principle" Engineer.
Unfortunately, at some companies "Staff" means low-level, while it's a prestigious position at others.
|
|
|
|
|
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?
-- modified 27-Jan-15 18:58pm.
|
|
|
|
|
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
If you can't read my code, try converting it here[^]
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Excellent point.
Excellent communication and persuasion skills are required to be a successful architect as the scale and stakes of a project increase.
|
|
|
|
|
Yes, this does definitely happen. Where I am from this is generally considered -- though often ignored by -- work for the Development Manager.
|
|
|
|
|
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.
|
|
|
|
|
Big Question:
Yes. That depends on the scale of the project. The larger the project, the more time will be spent communicating and coordinating and less time developing.
The architect is the contact point for communication. They do not always have the answers, but they know who does. More details below.
Code Project:
It's a great place for developers all around. Yes there are architects here. I believe the longer you develop and constantly maintain a single project, the more you tend to develop architect-type skills. So there are plenty of architects.
Interesting Question:
Architects provide stability, predictable development schedules, and are critical toward developing and delivering the product the customer wants (not necessarily asked for, and your manager or company may be your customer).
Details:
--------
Recognize that this is a role in the SDLC. An organization or project may not be large enough to require a sole position for architect. However, it is still a function that must be provided to create software.
A Software Architect is a technical role, responsible for the functional, structural and design integrity of a software system, this includes ensuring that the software remains viable into the future. Essentially, they are the steward of the code. They do not own it, they are simply responsible for it.
The activities a Software Architect Performs:
- Primary technical interface with the customer.
- Primary technical interface with management.
- The architect understands and communicates the technical challenges required to implement features to management.
-- Management can then make informed decisions.
- Coordinates the technical aspects of development, but does not actually direct development.
-- Project managers manage the budget and schedule
-- Team leads direct the work of developers at the level where the work is created.)
- The architect does not decide the features and direction of the product. Marketing, business development and management decide that.
- An effective software architect will be an accomplished software engineer.
- They are a mentor
- They will also still "live" in the code.
-- While they might not be a core producer of code, they will still be able to jump in and contribute as necessary.
-- Your ability to manage the technical aspects continue to diminish the further you are separated from the technical aspects.
- Software is such an abstract product. It is an idea articulated into a format a computer can understand.
-- Therefore an architect has access behind the curtain, and possesses the ability to assess the function and quality of the software.
- The architect will have broad knowledge.
-- The experts and domain specialists have the deep knowledge of a topic.
-- The architect
The architect needs to know how to
- A software Architect becomes more important as the size and diversity of a project grows.
-- A single developer or small team can coordinate relatively well.
-- As the size of the project grows the architect acts as a coordinator of communication between teams.
-- This allows separate teams to be responsible for their own components and their proper integration is coordinated by the architect.
- The architect may directly influence the design all of the way down to each individual developer.
- The architect does not dictate the implementation.
-- However, since they are responsible for the code they should be watching for maintenance issues and should help guide the developer to a more maintainable solution.
Someday (maybe soon) this will appear as a more detailed essay on my blog, which feeds to CodeProject as well.
And that is an interesting last question about can it be articulated into an ad. I believe it can. When I write the essay I will include a sample advertisement.
You didn't ask this, but how do you determine that you are interviewing a competent architect? Proven results over time. If they have a short tenure at each position and product, you cannot learn that much.
It may take 6mos to 2yrs to complete initial development.
You will need at least an additional 12 months of constant additions before you start to feel the maintenance pain of code rot. So that is something to look at.
Coming into a legacy product may account for something, but it does not dismiss the possibility of the "This is broken, I'm just going to rewrite this" attitude.
Regards,
Paul
modified 26-Jan-15 12:25pm.
|
|
|
|
|
Thanks so much for the expanded answer. It was a great read.
I will try to keep my reply short, but reading your article stimulated my thinking that :
If you work in a small(er) company you may be forced to do all those things that you defined as being architect behavior. I have found that to be very true. Meanwhile others at large companies may have never had the chance to take a project from beginning to end and watch over it through every part of the SDLC.
|
|
|
|
|
These questions could lead to long answers, but I'm going to keep it succinct:
newton.saber wrote: So, if you are an Architect, what is it that you believe you do that a software developer doesn't do?
Yes I am, and I have always felt that a software architect ensures that the code remains flexible, maintainable, efficient, documented, and tested. To do that, he/she creates frameworks, guidelines, best practices, etc., to prevent the developer from doing stupid things.
newton.saber wrote: I notice a lot of codeslingers around here, but curious if CodeProject also attracts Software Architects. What do you think?
Architects are a rare breed, but they must actually also be code slingers -- as an architect, I can only test my architecture against actual implementation.
newton.saber wrote: What value do you think a Software Architect really brings?
Consistency, reliability, the ability to see the bigger picture, plan for unforeseen changes, and is always looking for how to improve "the process", whatever that process is. It amazes me how few programmers, regardless of their years of experience, actually do that.
newton.saber wrote: What skills do you expect from an Arthitect?
See the above. That's certainly what I expect of myself.
newton.saber wrote: Can the value a Software Architect adds be put into words / definitively measured?
Absolutely. You should be able to see it in the quality of the documentation, the tests, and the ease in which programmers do their work. You should be able to see it in reduced bug reports, faster response to change requests / new features, and above all, a resilience in the application to accommodate changes / new features. If you hear "the program wasn't designed to do that" then the architect (if there was one) failed his job (I'm not talking making a satellite into an automated corn picker.)
Oh, and as an architect, I still find companies that don't use source control. It's getting better now with Git, BitBucket, etc., -- an architect should be constantly vigilant regarding tools.
So, have you ever used a state machine???
http://www.shopify.com/technology/3383012-why-developers-should-be-force-fed-state-machines[^]
|
|
|
|
|
This was all great stuff and I agree with you 100% on...
Marc Clifton wrote: how to improve "the process", whatever that process is. It amazes me how few programmers, regardless of their years of experience, actually do that.
Also, I was just doing some reading on state machines. Thanks for the link.
|
|
|
|
|
They call me a software engineer.
I design systems/applications, and code them. We have people on our teams that are "just" developers, who have no say in the final design of something, rather they implement our designs (coding); if that makes any sense.
Usually, developers move on to become engineers.
Now, with that said, the way technology is moving and evolving, there is less and less of a "line of difference" between the two. Most places just hire engineers, at various skill levels.
|
|
|
|
|
Slacker007 wrote: people on our teams that are "just" developers, who have no say in the final design of something
This is interesting too, because if you extend this out you end up with what I call "assembly line programming". I'm not saying your shop does that. I'm saying it because I've worked at places where they decided to have some people who only write Stored Procs, others who just write very specific functions or whatever.
Again, not saying your shop does that but if extended to a strong degree a worker becomes just a cog in the machine and development which was very creative and edging toward artistic endeavour becomes just like pulling the handle on the big machine. However, this same idea does create a system of high reproducibility and manager types like that a lot.
It's all an interesting balance.
|
|
|
|
|
You make very good points.
I have found that if someone only works with services, for instance, you have a higher quality product then if it was designed, implemented by someone who does not do services all the time and has to constantly refer to the internet or other people for instruction.
I speak in general terms here. We all have to learn some time; which is why you would apprentice, so to speak, under the "Services" guru/team.
|
|
|
|
|
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 Einstein
|
|
|
|
|