Software architect Information & Software architect Links at HealthHaven.com

Software architect is a general term with many accepted definitions, which refers to a broad range of roles. Generally-accepted terminology and certifications began appearing in connection with this role near the beginning of the 21st Century.

[edit] History

With the increased popularity of multi-tier application development, the choices of how an application can be built have also increased. Given that expansion, the risk that a software development project may inadvertently create an end product that in essence already exists has grown markedly. A new 'Software architect' role became necessary during software development.

The software architect concept began to take hold when object oriented programming (OOP) was coming into more widespread use (in the late 1990s and early years of the 21st Century). OOP allowed ever-larger and more complex applications to be built, which in turn required increased high-level application and system oversight.

The main responsibilities of a software architect include:

Limiting the choices available during development by

choosing a standard way of pursuing application development
creating, defining, or choosing an application framework for the application

Recognizing potential reuse in the organization or in the application by

Observing and understanding the broader system environment
Creating the component design
Having knowledge of other applications in the organization

Software architects can also:

Subdivide a complex application, during the design phase, into smaller, more manageable pieces
Grasp the functions of each component within the application
Understand the interactions and dependencies among components
Communicate these concepts to developers

In order to perform these responsibilities effectively, software architects often use Unified Modeling Language and OOP. UML has become an important tool for software architects to use in communicating the overall system design to developers and other team members, comparable to the drawings made by building architects.

[edit] Duties

Despite the lack of an accepted overall definition, the role of software architect generally has certain common traits:

[edit] Design

The architect makes high-level design choices much more often than low-level choices. In addition, the architect may sometimes dictate technical standards, including coding standards, tools, or platforms, so as to advance business goals rather than to place arbitrary restrictions on the choices of developers. Note that software architects rarely deal with the physical architecture of the hardware environment, confining themselves to the design methodology of the code.

[edit] Communication

Architects also have to communicate effectively, not only to understand the business needs, but also to advance their own architectural vision. They can do so verbally, in writing, and through various software architectural models that specialize in communicating architecture.

[edit] Types of software architects

The enterprise architect handles business-related software decisions that frequently can involve multiple software systems within an organization, spanning several projects teams, and often at more than one site. The Enterprise Architect may seldom see or interact with source code.

An application architect works with a single software application. This may be a full- or a part-time role. The application architect is almost always an active software developer.

Other similar titles in use, but without consensus on their exact meaning, include:

Solutions Architect, which may refer to a person directly involved in advancing a particular business solution needing interactions between multiple applications. May also refer to an Application Architect.
System Architect (singular), which is often used as a synonym for Application Architect.
Systems Architect (plural), which is often used as a synonym for Enterprise Architect or Solutions Architect.

The table below indicates many of the differences between various kinds of software architects:

Architect Type	Strategic Thinking	System Interactions	Communication	Design
Enterprise Architect	Across Projects	Highly Abstracted	Across Organization	Minimal, High Level
Solutions Architect	Focused on solution	Very Detailed	Multiple Teams	Detailed
Application Architect	Component re-use, maintainability	Centered on single Application	Single Project	Very Detailed

In the software industry, as the table above suggests, the various versions of architect do not always have the same goals^[1].

[edit] Architect metaphor

The term "software architect" came into being because of the perceived similarities between the creation of software and the creation of buildings.^[2] The sudden popularity of the term in the world of information technology most likely stems from Bill Gates’ relinquishing of the title President and CEO of Microsoft to assume the role of “Chief Software Architect.” The phrase reflected his new role as an overseer of many software development projects at Microsoft.

Although a simplified construction metaphor may be flawed^[3], the term is still meaningful in the sense that it describes the "design" aspect of the job.

The use of any form of the word 'architect' is regulated by 'title acts' in many states in the US, and a person must be licensed as a building architect to use it. Enforcement of these laws may be lax, if it is immediately clear that the title refers to the computer industry and not the building industry.

[edit] Ivory towers

When architects become too disconnected from the actual developers, they are often dismissively termed "Ivory Tower Architects". This is partly due to the limited usefulness of the construction metaphor. Moreover, many "Waterfall model" development methodologies of the past encouraged this working method.

Application or solutions architects work at a level of detail that demands involvement in actual coding, and will function best with a substantial background in software development. A school of thought holds that enterprise architects should also have a development background, so as to avoid the issues that can arise from an ivory-tower approach.

[edit] See also

[edit] References

[edit] External links

[0] Anecdote about an interaction between Solution and Enterprise Architect

[1] WWISA Philosophy

[2] Google Search for "Construction Metaphor Software"

[1]

[2]

[3]

Contents