Home > A Practical Guide using UML > Why Architect?

Why Architect?

It has become standard practice in the software industry to engage in a process of software analysis and design along with coding. This design facilitates  understanding the structure of the developed software. Architecting simply  recognizes the need to focus on the bigger picture of the software design and  to provide guidance to the development team designers. At the software  architecture level, we’re more interested in the subsystems, components, and  interfaces than in the classes and methods.

According to Hofmeister, software architecture:
aspects for others, but to expose them so that the architect can reason provides a design plan – a blueprint of the system, and that it is an abstraction to help manage the complexity of the system. . . . The  purpose of the software architecture is not only to describe the important about the design.

As described earlier in this chapter, the software architecture is a place to capture early design decisions, provide constraints on the lower-level design  and implementation, and provide the organizational structure for the development  team. Getting the architecture defined well up front saves a great deal of  pain and trouble throughout the development process. The goal is that a welldefined  architecture will produce a system that will be easier to design,  develop, and maintain.
A good architectural representation (sometimes any meaningful architectural  representation) is often missing completely from projects that have been under  development for some time. Often the role of the software architect is to capture  the existing architecture, then make recommendations for improvements for
future releases. We have been in this position, and it can be quite frustrating.
Major design changes may be required to repair the damage from the lack of a  software architecture, but convincing management to make these changes may  be an impossible task. Our hope is that the emphasis on good software  architecture practices will allow the software architect to get the architecture  right up front. In this way, the architect will not be the victim of a bad  architecture and can avoid playing catch-up to try to fix a bad architecture.

Here is a list of some of the uses for the software architecture description:

Training is essential for new team members. Anyone who has been assigned to an existing software project can appreciate the need for a well-documented  software architecture to quickly bring developers up to speed. In addition, this  information can be used to train customers, managers, testers, and operations  personnel for the software system. New architects will likely need to be  trained since most teams do not stay the same over the full life of a system.
Making modifications to the system must be done carefully so existing  functionality is not broken. A common maintenance need is to describe the  impact or scope of a change and hence the regression testing required to  ensure correctness of the change. This process should start with a careful  analysis of the existing software architecture, which includes the static and  dynamic aspects of the system.
Testers need to understand the system and its interfaces, at both the subsystem  level and the component level, to perform white box testing. In addition, key  process interactions are captured in the architecture views. Finally, each interface should have associated performance information that can be verified
by the test organization.
Ensuring architectural attributes such as testability, reliability, availability,  maintainability, and performance is another important use of the architectural  description. To reason about these attributes of software, there is a need to  explore and document these attributes of the software structure.
Verification of requirements – Architectural modeling will often expose  missing, invalid, or inconsistent requirements.

Project management – When the architecture moves beyond the preliminary  state, project managers can use the information to structure the development  organizations and identify work to be performed by specific development  teams. Project managers can use the architecture to identify interface elements  to be negotiated among the development teams. This can be useful when  contract or project negotiations need to take place to reduce functionality or  move functionality to a later build.
Operating a system – Large systems such as telephone switches that support  24 × 7 operations often require human operators to run and interact with the  system. Some of these may be users, but others will perform system administration  functions. The operations staff often needs an understanding of the
software structure to perform their job.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: