Software architect

From Wikipedia, the free encyclopedia

 This article needs additional citations for verification.
Please help improve this article by adding reliable references. Unsourced material may be challenged and removed. (October 2007)
This article may require cleanup to meet Wikipedia's quality standards.
Please improve this article if you can. (October 2007)

Software Architect is a general term that may refer to a broad range of roles. There are many accepted definitions. Vendor neutral and consensual terminology is evolving around this role in the last decade.

Contents

[edit] History

With the increased popularity of multi-tier application development, the choices of how an application can be built have also increased. Developers find themselves "reinventing the wheel" many times in the same organization.

A new 'Software Architect' role became a need during software Development.

The main responsibilities of this new role are:

  • Limit the choices during development by
  • Spot potential reuse in the organization or in the application by

This happened at the time when the object oriented programming (OOP) was getting widespread use (late 1990s and early 2000). With the help of OOP, increasingly larger and more complex applications were being built. There became a need to oversee from a high level these complex applications. Software Architects were given a this new responsibility that includes:

  • During design, break down the complex application to smaller manageable pieces
  • Understand the functions of each component
  • Understand the interactions and dependencies between component
  • Communicate the aboves to developers

Therefore, it is assumed that a Software Architect has knowledge about OOP and Unified Modeling Language (UML). UML is a modeling language that became important for Software Architects to communicate their design to developers and other team members, it is like drawings for building architects.

[edit] What the Software Architect does

Even given the lack of simple definition, there are some aspects to the role that are shared by all architects:

[edit] Strategic Thinking

Architects are focused on solving business needs in a strategic manner. For example, decisions are evaluated against how they will allow the enterprise, or a single software system to grow and perform in the long term. Great care is taken to create and spot opportunities for re-use.

Because of the strategic bias, decisions that an architect will make will often differ from those that a developer or a project manager will make. In many ways, the architect acts as the business owner would if they were technically savvy.[1] While a developer is working and focused on to develop a software component, not necessarily seeing how the components would work together. The Software Architect sees the big picture and defines the interaction between components.

[edit] System Interactions

Architects deal with boundaries, interfaces, and interactions. These may be between two systems written in different languages at different locations, or between two components of the same software system, written in the same coding language.

Service-oriented architecture is a recent evolution that has the potential to simplify architects' jobs. This is primarily because it provides a way of thinking about architecture that is closely aligned with the architect's need to define the APIs of systems.

[edit] Design

The architect makes many high level (and sometimes low level) design choices.

In addition, the architect may dictate various standards, including coding standards, tools, or platforms. The reason for doing so is to facilitate strategic goals, rather than to arbitrarily restrict the choices of developers.

[edit] Communication

The final aspect is that they have to communicate, firstly in order to understand the business needs, and then in order to communicate their own architectural vision.

In addition to verbal communication, there are various Software Architectural Models that specialize in communicating architecture.

[edit] Types of Software Architects

The Enterprise Architect deals with strategic software decisions (aligning IT with the business), typically involving many software systems within an organization, across several projects teams, typically at more than one site. The Enterprise Architect may seldom see or interact with source code.

Within the context of a single software project another distinction can be made between the physical architecture which relates to the hardware environment, and the software architecture, which involves the design methodology of the code.

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

Other architect titles that are in use, but without consensus on the exact meaning include:

  • Solution Architect - may refer to the focus on driving a particular business solution, which needs interactions between multiple applications. May also refer to an Application Architect.
  • System Architect (singular) - used as a synonym to Application Architect.
  • Systems Architect (plural) - used as a synonym to Enterprise Architect or Solution Architect.

The simple table below can further assist in understanding the differences between 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
Solution Architect Focused on solution Very Detailed Multiple Teams Detailed

In the software industry, there is a fair amount of conflict[2] between Application and Solution Architects, and Enterprise Architects. Looking at the table above, it is not hard to see why. For example, Application and Enterprise Architects are almost completely opposite in terms of focus!

[edit] Architect Metaphor

The term "Architect" came into being because the creation of software was likened to the construction of buildings[3]. It is clear that the role is necessary, and the closest equivalent in the building industry is the Architect.

The overwhelming popularity of the term Architect in the context of software development can be traced to the day Bill Gates announced that he was relinquishing the title of President and CEO of Microsoft and assuming the role of Chief Software Architect. Suddenly lots of people decided that their job title also needed to include the word "Architect". Gates has since moved on.

It is generally agreed that a simplified construction metaphor is flawed[4] with regard to software development. Nevertheless, the term is still meaningful in the sense that it describes the "design" aspect of the job.

[edit] Ivory Towers

When Architects become too divorced from the teams that are actually doing development, they are often termed as "Ivory Tower Architects". The picture in people's minds is that of the Architect creating the architecture definition, and then handing it off to the development team(s).

Partly, this is the fault of the flawed construction metaphor (architect handing blueprints off to builder). Also, many "Waterfall model" development methodologies of the past encouraged this style of working.

[edit] Controversy

At the level of detail that an Application or Solutions Architect works, it is necessary to get involved in the actual coding. A software-development background is a requirement for the job. Some people extend this requirement to Enterprise Architects too. The fear is that an Enterprise Architect without the necessary development background will tend towards the "Ivory Tower" way of doing things.

[edit] References

  1. ^ Business Improvement Through Better Software Architecture
  2. ^ Anecdote about an interaction between Solution and Enterprise Architect
  3. ^ WWISA Philosophy
  4. ^ Google Search for "Construction Metaphor Software"

[edit] See also