The Lounge - CodeProject

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[^]

Imperative to Functional Programming Succinctly

Contributors Wanted for Higher Order Programming Project!

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. Smile | :)

Yes, and those people also believe that if you have a funny face, then you must be a clown. Big Grin | :-D

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. Smile | :)

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.

Welcome to the Lounge