Software architect

From Wikipedia, the free encyclopedia

Jump to: navigation, search

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.

Contents

[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
  • 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] Strategic thinking

Architects address the technological aspects of business needs by considering what a given technology can contribute to the overall functions of the system, as distinct from how that technology will perform its own functions. This encourages opportunities for re-use of the technology and ultimately contributes to the organization's efficiency.

As a result, an architect's decisions will often differ from those that a developer or a project manager might make. In many ways, the architect acts as a technically savvy business owner would.[1] Where a developer will construct a software component based purely on technical specifications designed for creating software, the software architect will integrate many such components into a coherent and viable whole.

[edit] System interactions

Architects deal with the interactions of systems, whether between components written in different languages at different times and at different locations, or between components of the same software system that use the same coding language. One recent approach to this facet, known as service-oriented architecture, offers new ways to define the APIs of systems.

[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:

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
Application Architect Component re-use, maintainability Centered on single Application Single Project Very Detailed
Solutions Architect Focused on solution Very Detailed Multiple Teams Detailed

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

[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.[3] 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[4], the term is still meaningful in the sense that it describes the "design" aspect of the job.

[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

Personal tools