What is the difference between a software architect and a software developer?

In your own words, what is the difference between a software architect and a software developer?





I would be happy if you would answer it. Thanks.

What is the difference between a software architect and a software developer?
the software architect is the person who draws up the plans for the new program. The software developer is the person who actually implements the plans ("blueprints") that the architect drew up. They can be, but aren't always the same person.
Reply:Software Architects are characterised by their ability to define solutions on the web rather than just developing small to medium web applications. This includes but is not limited to designing and developing leading-edge enterprise solutions over the web. You should have comprehensive skills that are required to build interactive, data-driven Web applications.





Software developers simply write code and implement modules which go with the patterns defined by the software architect.
Reply:Software systems can be divided architecturally along two broad dimensions. The first is the marketecture, or the "marketing architecture." The second is the tarchitecture, or the "technical architecture." I refer to the traditional software architect or chief technologist as the tarchitect and the product marketing manager, business manager, or program manager responsible for the system as the marketect.





The tarchitecture is the dominant frame of reference when developers think of a system's architecture. For software systems it encompasses subsystems, interfaces, distribution of processing responsibilities among processing elements, threading models, and so forth. As discussed in Chapter 1, in recent years several authors have documented distinct styles or patterns of tarchitecture. These include client/server, pipeline, embedded systems, and blackboards, to name a few. Some descriptions offer examples of where these systems are most appropriately applied.





Marketecture is the business perspective of the system's architecture. It embodies the complete business model, including the licensing and selling models, value propositions, technical details relevant to the customer, data sheets, competitive differentiation, brand elements, the mental model marketing is attempting to create for the customer, and the system's specific business objectives. Marketecture includes—as a necessary component for shared collaboration between the marketects, tarchitects, and developers—descriptions of functionality that are commonly included in marketing requirements documents (MRDs), use cases, and so forth. Many times the term whole product is used to mean marketecture.





The $50,000 Boolean Flag





One "heavy client" client/server architecture I helped create had a marketing requirement for "modular" extension of system functionality. Its primary objective was that each module be separately priced and licensed to customers. The business model was that, for each desired option, customers purchase a module for the server that provided the necessary core functionality. Each client would then install a separately licensed plug-in to access this functionality. In this manner, "modules" resided at both the server and client level. One example was the "extended reporting module"—a set of reports, views, and related database extract code that a customer could license for an additional fee. In terms of our pricing schedule, modules were sold as separate line items.





Instead of creating a true "module" on the server, we simply built all of the code into the server and enabled/disabled various "modules" with simple Boolean flags. Product management was happy because the group could "install" and "uninstall" the module in a manner consistent with their goals and objectives for the overall business model. Engineering was happy because building one product with Boolean flags is considerably simpler than building two products and dealing with the issues that would inevitably arise regarding the installation, operation, maintenance, and upgrade of multiple components. Internally, this approach became known as the "$50,000 Boolean flag."





The inverse to this approach can also work quite nicely. In this same system, we sold a client-side COM API that was physically created as a separate DLL. This allowed us to create and distribute bug fixes, updates, and so forth, very easily; instead of upgrading a monolithic client (challenging in Microsoft-based architectures), we could simply distribute a new DLL. Marketing didn't sell the API as a separate component, but instead promoted it as an "integrated" part of the client.





Moral? Maintaining a difference between marketecture and tarchitecture gives both teams the flexibility to choose what they think is the best approach to solving a variety of technical and business problems.











by








http://www.dhaarvi.blogspot.com
Reply:There seems to be a blending of architecture and design in these answers. Let me try this:





A software *architect* is the person who comes up with *one or more* arrangements for the modules and/or components of the software and defines what parts talk to which and what the responsibilities of each part of the software is. Examples of architectures: client/server, message pipes, pipes and filters, plugins, etc.





A software *designer* chooses between architectures to select the one (or combination of two or more) architecture that will successfully fulfill the requirements of the project.





Architecture is synthesis. Design is analysis.





A software *developer* implements the *design* that has been selected, which itself is made up of one or more *architectures*. A developer translates the design into (in the case of object orientation) modules, classes, psuedocode, and finally code. Then comes debugging of the code once it is written.
Reply:The Software Architect is more like the Person who decides on overall patterns for the Developers.


The Software Developer is a bit like the Sub Contractors who make the various components of what the Team Architect wants; Thats based on what these guys tell me after I install their software.
Reply:based on the experience in years and No of projects a Software Engineer reaches a stage where he can analyze critical data like design of Software ..Requiermetns of Clients and make decisions to deliver. This stage of the Person takes him to a level called as the Software Architect. In Short this person decides on the Course of Action that needs to be taken for the Development of the Software and get it delivered.Though he individually may/may not be responsible for coding he is responsible for the succesful deliver of the project /software to its clients.





Developer on the other hand is devoid of this knowledge and may need more experience in handling such situations. hence is stil writing code.based on his experience and ability to grasp he can take the responsibility of minor things which will result in him being the architect at one time if he sticks to technology or a Project manager on the other if he sticks to Politics.