|
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
|
|
|
|
|
TheGreatAndPowerfulOz wrote: Real architects
Agree.
Unfortunately, many people (not necessarily here at CP) think that if your title has Architect in it then you are real. 
|
|
|
|
|
Yes, and those people also believe that if you have a funny face, then you must be a clown. 
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
Well I have the title but consider myself a senior dev, I do the design of the app from the database structure through to the UI. I then code it to UAT and hand it over to the support team.
IMHO any seasoned LOB developer must be able to do this. An architect on the other hand probably does the design and then gets a code monkey to do the development while he moves on to the next project.
I also think an architect should be able to design across multiple, disparate systems and platforms, something I am incapable of doing.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
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.
|
|
|
|
|
I believe the role of the Architect is to ensure the technical design of the product is 'correct'.
In order to do this they need to be technical (so they know the techniques that could be used, and can select the best ones for the circumstances)
they also need to understand the whole project - as such they need to be able to talk to the product owner(s) at a non-technical level in order to make decisions on the technologies to be used.
So it is the architect that should be making the decision on different technical aspects of the project - and ensuring they are adhered to and are consistent.
Like a building architect doesn't just look at how pretty the house is, but ensures that the tensile strength of the materials is sufficient for the location - that the glass in the windows is the right glass for the situation, the Software Architect will make sure that the MVVM framework used is the right one for the job - and is used correctly; that the third party controls selected are used consistently etc.
they are the one that stops the developers from using some new technique they just read about because it looks cool, and forces them to use tried and tested techniques.
They cramp our style, but ensure a technically consistent and stable product. - That's the value.
The skills are many; They need to be a competent developer, and constantly learning about new things (and prepared to listen to input from developers with suggestions about using different tools for the job). They need to be able to listen to product owners and translate their requirements into sensible solutions (so you don't end up with a 7 tier solution to a desktop app that displays the time in China, or a monolithic application that runs the entire international business.)
Can the value be measured?
That's tough - without an Architect solutions can be a mix of techniques, inconsistent and difficult to maintain - unless all the developers just agree and work the same way) but measuring what may have been compared to what is is always hard!
PooperPig - Coming Soon
|
|
|
|
|
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 stress, because that's a lot to take on, and you're never ready to deal with it, and damn your too young for that.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
