J
Jim in Arizona
Can someone tell me what the difference is, if any, there is between a
Software Architect and a Software Developer?
TIA,
Jim
Software Architect and a Software Developer?
TIA,
Jim
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
M
Michael Nemtsev
Hello Jim,
http://en.wikipedia.org/wiki/Software_architect
http://www.bredemeyer.com/who.htm
JA> Can someone tell me what the difference is, if any, there is between
JA> a Software Architect and a Software Developer?
JA>
JA> TIA,
JA> Jim
---
WBR, Michael Nemtsev [C# MVP] blog: http://spaces.live.com/laflour
team blog: http://devkids.blogspot.com/
"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo
http://en.wikipedia.org/wiki/Software_architect
http://www.bredemeyer.com/who.htm
JA> Can someone tell me what the difference is, if any, there is between
JA> a Software Architect and a Software Developer?
JA>
JA> TIA,
JA> Jim
---
WBR, Michael Nemtsev [C# MVP] blog: http://spaces.live.com/laflour
team blog: http://devkids.blogspot.com/
"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo
J
JR
The salary is quite different.
JR
JR
K
Kevin Spencer
Your question is quite understandable. In a sense, a Software Architect does
the same thing that a Software Devloper does. Given a set of requirements,
each is tasked with the responsibility of satisfying those requirements via
software. However, that is where the similarity ends. If you compare a
building architect to a carpenter, you get much the same result. The
difference is one of scope.
A Software developer is a person that writes instructions to a computer, in
the form of code. These instructions comprise a structure that performs an
encapsulation of a set of tasks all related to the satisfaction of the
original set of requirements. The result may be a DLL or class library, an
executable, or something similar. It may or may not have a user interface,
or a programming interface. Generally speaking, there will be a variety of
tasks and sub-tasks encapsulated into a single package, or a small set of
packages that all work together.
Big things are made up of lots of little things. The larger the set of
requirements, the more components it will have. Just as the tools used to
dig the foundation for a house are not the same (except conceptually) as the
tools used to build the foundation for a skyscraper, so the tools of the
Software Architect are different than the tools used by the Software
Developer. A Software Architect's job is to create something large enough
that it requires the work of a large number of people working in cooperation
to perform it. So, the Software Architect is the designer of the big
picture, and rather than writing instructions to a computer in code, the
Software Architect's job is to give instructions to groups of people, in
various ways that people understand, such as written documents, speech,
drawings and diagrams, and so on.
Because of the nature of the job, the Software Architect also becomes the
point of contact between the client and the builders. The job involves
people skills, human communication skills, the ability to organize and
coordinate between smaller organizations of people, as well as a complete
technical understanding of the actual software to be developed. The Software
Architect should be able to write the software, but is not tasked with doing
so, only ensuring that it is done.
Often, in fact, the Software Architect does not interact directly with the
Software developers. If the job is large enough, the Architect will
coordinate with Software designers who are in charge of groups of
developers. In such a case, the actual design of the larger parts of the
software will not be done, but overseen, by the Software Architect.
At any rate, that's the big picture.
--
HTH,
Kevin Spencer
Microsoft MVP
Software Composer
http://unclechutney.blogspot.com
The shortest distance between 2 points is a curve.
the same thing that a Software Devloper does. Given a set of requirements,
each is tasked with the responsibility of satisfying those requirements via
software. However, that is where the similarity ends. If you compare a
building architect to a carpenter, you get much the same result. The
difference is one of scope.
A Software developer is a person that writes instructions to a computer, in
the form of code. These instructions comprise a structure that performs an
encapsulation of a set of tasks all related to the satisfaction of the
original set of requirements. The result may be a DLL or class library, an
executable, or something similar. It may or may not have a user interface,
or a programming interface. Generally speaking, there will be a variety of
tasks and sub-tasks encapsulated into a single package, or a small set of
packages that all work together.
Big things are made up of lots of little things. The larger the set of
requirements, the more components it will have. Just as the tools used to
dig the foundation for a house are not the same (except conceptually) as the
tools used to build the foundation for a skyscraper, so the tools of the
Software Architect are different than the tools used by the Software
Developer. A Software Architect's job is to create something large enough
that it requires the work of a large number of people working in cooperation
to perform it. So, the Software Architect is the designer of the big
picture, and rather than writing instructions to a computer in code, the
Software Architect's job is to give instructions to groups of people, in
various ways that people understand, such as written documents, speech,
drawings and diagrams, and so on.
Because of the nature of the job, the Software Architect also becomes the
point of contact between the client and the builders. The job involves
people skills, human communication skills, the ability to organize and
coordinate between smaller organizations of people, as well as a complete
technical understanding of the actual software to be developed. The Software
Architect should be able to write the software, but is not tasked with doing
so, only ensuring that it is done.
Often, in fact, the Software Architect does not interact directly with the
Software developers. If the job is large enough, the Architect will
coordinate with Software designers who are in charge of groups of
developers. In such a case, the actual design of the larger parts of the
software will not be done, but overseen, by the Software Architect.
At any rate, that's the big picture.
--
HTH,
Kevin Spencer
Microsoft MVP
Software Composer
http://unclechutney.blogspot.com
The shortest distance between 2 points is a curve.
N
Nick Malik [Microsoft]
I agree but differ in one point.
In one sense, this is true, but in another, it is not. The Architect is
involved with creating a system that can meet the users needs, and often
must communicate directly with the users, but on a large enough project, the
architect is rarely "the point of contact" in an exclusive sense. Quite
often, that is the "Prime Contractor" who is involved with the customer on a
day-to-day basis. If the project is large enough, you may have an initial
architect who delivers models to a team of architects who deliver designs to
many development teams who deliver the system components.
My current project uses dev teams in three continents and four timezones for
two disparate business groups located in global operations centers around
the planet. If I was THE point of contact, I'd be little else. It's a
two-to-three year project. I'd be dead long before it completed.
--
--- Nick Malik [Microsoft]
Enterprise Application Architect
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
Because of the nature of the job, the Software Architect also becomes the
point of contact between the client and the builders.
In one sense, this is true, but in another, it is not. The Architect is
involved with creating a system that can meet the users needs, and often
must communicate directly with the users, but on a large enough project, the
architect is rarely "the point of contact" in an exclusive sense. Quite
often, that is the "Prime Contractor" who is involved with the customer on a
day-to-day basis. If the project is large enough, you may have an initial
architect who delivers models to a team of architects who deliver designs to
many development teams who deliver the system components.
My current project uses dev teams in three continents and four timezones for
two disparate business groups located in global operations centers around
the planet. If I was THE point of contact, I'd be little else. It's a
two-to-three year project. I'd be dead long before it completed.
--
--- Nick Malik [Microsoft]
Enterprise Application Architect
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
K
Kevin Spencer
Understood, Nick. This is, of course, a matter of the recursive nature of
the process. As the projects increase in scope, the hierarchy repeats
itself, with slight variations of the pattern according to the level of
recursion, in a "fractal" manner.
--
Kevin Spencer
Microsoft MVP
Software Composer
http://unclechutney.blogspot.com
The shortest distance between 2 points is a curve.
the process. As the projects increase in scope, the hierarchy repeats
itself, with slight variations of the pattern according to the level of
recursion, in a "fractal" manner.
--
Kevin Spencer
Microsoft MVP
Software Composer
http://unclechutney.blogspot.com
The shortest distance between 2 points is a curve.