Software design and Architecture

 The Role of the Software Architect  If you gathered a group of software architects in a room and asked them to describe the jobs they do, you would probably end up with at least a dozen different definitions. More tellingly, if you asked the people with whom the architects work how their colleagues fill their working hours, you would probably get still more definitions. Our own practical experience supports this. On some projects, the person with the title of architect has a very hands-on, directional involvement in the nuts and bolts of designing, coding, and testing. Alternatively, architecture may be viewed as an ivory tower from which pronouncements are handed down at intervals to the build and implementation teams. Architect is also often used as a generic title to denote a senior technical member of staff (such as the Java architect that a number of organizations have). Architects may specialize in one area, such as networking, middleware, or database design, to the exc...

 Architectural Perspectives we explained how we use viewpoints (such as the Context, Functional, Information, and Deployment viewpoints) to guide the process of capturing and representing the architecture as a set of views, with the development of each view being guided by the use of a specific viewpoint. When creating a view, your focus is on the issues, concerns, and solutions pertinent to that view. So, for an Information view, for example, you focus on things such as information structure, ownership, transactional integrity, data quality, and timeliness. Many of the important concerns that are pertinent to one view are much less important when considering the others. Data ownership, for example, is not key to formulating the Concurrency view, nor is the development environment a major concern when considering the Functional view. (Of course, the decisions taken in one view can have a considerable impact on the others, and it is a big part of the architect’s job to make sure tha...

 Architectural Descriptions  An architecture for a software system can be an incredibly complex thing. Part of the architect’s role is to describe this complexity to the people who need to understand it. The architect does this by means of an architectural description. Products” in this context consist of a range of things—particularly architectural models, but also scope definition, constraints, and principles. We discuss each of these in more detail in Parts II and III. A description of an architecture has to present its essence and its detail at the same time—in other words, it must provide an overall picture that summarizes the whole system, but it also must decompose into enough detail that it can be validated and the described system can be built. Although it is true that every system has an architecture, it is unfortunately not true that every system has an AD. Even if an architecture is documented, it may be documented only in part, or the documentation may be out-of-d...

  Stakeholders  Traditional software development has been driven by the need of the delivered software to meet the requirements of users. Although the definition of the term user varies, all software development methods are based around this principle in one way or another. However, the people affected by a software system are not limited to those who use it. Software systems are not just used: They have to be built and tested, they have to be operated, they may have to be repaired, they are usually enhanced, and of course they have to be paid for. Each of these activities involves a number—possibly a significant number—of people in addition to the users. Each of these groups of people has its own requirements, interests, and needs to be met by the software system. We refer collectively to these people as stakeholders. Understanding the role of the stakeholder is fundamental to understanding the role of the architect in the development of a software product or system. We defin...

 Architectural Elements  As explained previously, we standardize the term architectural element to refer to the pieces from which systems are built. The nature of an architectural element depends very much on the type of system you are considering and the context within which you are considering its elements. Programming libraries, subsystems, deployable software units (e.g., Enterprise Java Beans or .NET assemblies), reusable software products (e.g., database management systems), or entire applications may form architectural elements in an information system, depending on the system being built.  An architectural element should possess the following key attributes • A clearly defined set of responsibilities  • A clearly defined boundary ' • A set of clearly defined interfaces, which define the services that the element provides to the other architectural elements Architectural elements are often known informally as components or modules, but these terms are already ...

  Introduction Reviews are an opportunity for others to eyeball your documents/design/code/software architecture and for you to inspect others' work. They facilitate knowledge interchange. But their primary goal is to increase software quality. They help you to spot faults before they become real disasters. This text tries to bring together elements a reviewer can use in his/her software architecture review. Background If you want some formal definitions what a software architecture is, I recommend reading the information  here . The general tone in these definitions is that you need to make high-level decisions about the system you're going to build: Ø   What style are you going to use? What is the structure? Ø   How is it going to function? How do structural components of the architecture work together? Ø   How does it meet the needs of all the stakeholders? For an existing system, you can detect these key factors that will give you an idea of ...