The Process of Software Architecting

The Process of Software Architecting

1. Chapter 1

   • It’s difficult to find an organization that isn’t in the software business in some way
     • Software needs
       • Provide the required capability
       • Available when promised
       • Sufficient quality
       • Get delivered at an acceptable price
       • Directly influenced by the architecture of the software
   • Applying the Process
     • A practice is an approach to solving one or several commonly occurring problems
       • These practices can be incorporated within any process you might use
         • Pick and choose those practices that will add the most value to your projects and architectures
   • The Process in Brief
     • Architecting activities sit between requirements and development
       • Iteration Starts
         • Define Requirements activity
           • Architect will participate in some of the detailed tasks
           • Create Logical Architecture activity
             • The resulting architecture is independent of any technology considerations
               • Tasks
             • Create Logical Detailed Design activity
               • The logical architecture is input to any detailed design that is performed
               • Create Physical Architecture activity
                 • Based on the requirements, logical architecture, and logical detailed design, the architect then refines the architecture
                   • Takes technology into account
                     • It has the same Tasks as the Logical Activity
                 • Create Physical Detailed Design activity
                   • Physical architecture is input to any detailed design that is performed. Which results in the basis of implementation
                   • Iteration Ends
       • Architect provide guidance to the team as needed

2. Chapter 2

   • Architecture
     • The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. (IEEE 1471 2000)
       • System is a collection of components organized to accomplish a specific function or set of functions
       • The environment, or context, determines the setting and circumstances of developmental, operational, political, and other influences upon that system.
       • System stakeholder is an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system
       • A component may be logical or physical, technology-independent or technology-specific, large-grained or small-grained
         • A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment
     • Defines Structure
       • The structural aspects of an architecture manifest themselves in many ways
         • A structural element could be a subsystem, a process, a library, a database, a computational node, a legacy system, an off-the-shelf product, and so on
       • Composition of structural elements, their relationships
         • Any connectors needed to support these relationships), their interfaces, and their partitioning
     • Defines Behavior
       • Architecture defines the interactions among these structural elements
         • Interactions provide the desired system behavior
     • Focuses on Significant Elements
       • In general, the architecture is not concerned with the fine-grained details of these elements
       • Significant elements are those that have a long and lasting effect, such as the major structural elements
     • Balances Stakeholder Needs
       • Often, meeting all the expressed needs is not possible
         • Making trade-offs in time frame or functionality
         • Non-functional requirements are quite often the most significant requirements as far as an architect is concerned
     • Embodies Decisions Based on Rationale
       • Important considerations are the documenting of the decisions that led to this architecture and the rationale for these decisions
         • Important for the Stakeholders and also the review of the architecture
     • May Conform to an Style
       • Most architectures are derived from systems that have a similar set of concerns. This similarity can be described as an architectural style
       • Reusable assets in general
     • Influenced by its Environment
       • In essence, the environment determines the boundaries within which the system must operate
       • Environment includes
         • Business mission
         • System stakeholders
         • Internal technical constraints
         • External technical constraints
     • Influences Development Team
       • It makes perfect sense to align the software development team structures with the architecture after it has been defined
         • Its beneficial but it could fall into a ideal case that isn't real
     • Has a Particular Scope
       • For each specific component type of architecture, a corresponding type of architect exists (software architect, hardware architect, and so on)
   • Architect
     • The architect is the technical lead on the project and, from a technical perspective, ultimately carries responsibility for the technical success or failure of the project
     • The architect must have skills that are typically broad rather than deep
     • Technical Leader
       • In addition to having technical skills, the architect exhibits leadership qualities
       • The architect (or lead architect, if the architect role is fulfilled by a team) is the technical lead on the project and should have the authority to make technical decisions
       • Because the success of the architect is closely linked to the quality of the team, participation in interviewing new team members is also highly appropriate
     • May Be Fulfilled by a Team
       • Given the requirement for a very broad set of skills in an architect, it is often the case that the architect role is fulfilled by more than one person
         • It is important to have one individual who is considered to be the lead architect
     • Understands the Software Development Process
       • It is important for them to understand the team members’ roles and responsibilities, as well as what they are producing and using
     • Has Knowledge of the Business Domain
     • Has Technology Knowledge
       • An architect does not need to be a technology expert as such, however, and needs to be concerned only with the significant elements of a technology, not the detail
     • Has Design Skills
       • The architecture embodies key design decisions, so the architect should possess strong design skills
     • Has Programming Skills
     • Good Communicator
     • Makes Decisions
       • It is still the architect’s responsibility to make the appropriate decisions, which do not always prove to be right
     • Aware of Organizational Politics
     • Negotiator
       • the architect interacts with many stakeholders, some of these interactions require negotiation skills. A particular focus for the architect is minimizing risk as early as possible in the project
   • Architecting
     • Characteristics, that underlie the process of architecting
       • Is a Science : With this recognition comes an emphasis on techniques, processes, and assets that focus on improving the maturity of the process of architecting
       • Is Art: always a need to provide some level of creativity, particularly true when dealing with novel and unprecedented systems
       • The architect is involved in many aspects of the development process
         • In result architecting spans many disciplines
       • Is an ongoing activity, what means that isn't done only once, but throughout the project
       • The process of architecting is not complete until the system is delivered
       • The process of architecting, therefore, must accommodate all these stakeholders to ensure that their concerns
       • Involves making Trade-Offs due to the amount of forces that should be balanced
       • They actively seek experience that may be codified in architectural patterns, design patterns, off-the-shelf components, and so on. In other words, the architect seeks out reusable assets
       • Is both Top-Down and Bottom-Up since most of the projects don't start from 0 and the environment
     • Benefits of Architecting
       • Key factor in reducing cost, improving quality, supporting timely delivery against schedule, supporting delivery against requirements, and reducing risk.
       • Qualities such as performance, security, and maintainability cannot be achieved in the absence of a unifying architectural vision
       • Drives consensus among the various stakeholders because it provides a vehicle for enabling debate about the system solution
         • Development teams with a good vision of what they are implementing have a better chance of implementing the product as desired
       • Arguably the major benefits are those related to the support provided to project planning and project management activities in general—specifically scheduling, work allocation, cost analysis, risk management, and skills development
       • Primary objectives of the process of architecting is making sure that the architecture provides a solid framework for the work undertaken by the designers and implementers
         • Must also define the appropriate practices, standards, and guidelines that will guide the designers and implementers in their work
       • Manage complexity as architecting focuses on certain level of abstraction and significant elements
       • Support both the production and consumption of reusable assets
         • Reduce the overall cost of a system and also improve its quality
       • The result should be an architecture that is appropriately documented to ease the maintainability of the system
       • Allows architects to reason about the impact of making a change before it is undertaken

3. Chapter 3

   • Method Content
     • A role defines the responsibilities of an individual or a set of individuals working together as a team within the context of a software development organization
       • Project Manager
       • Application Architect
       • Infrastructure Architect
       • Data Architect
       • Business Analyst
       • Lead Architect
     • Work Product
       • Executables, Project plans, source code
       • Products with value to stakeholders, most of the times ready to deploy
       • Documents and results of the Tasks related to activities
     • Tasks
       • Jobs in an unitary form are assigned to one rol
       • To show progress the task should create or modify something in the product
     • Iterations that is composed of activities are repeated based on a Process
   • Process
     • The process are based on Methodologies
       • Traditional
         • Waterfall
           • Each activity or task should be completed before passing to another
         • Iterative
           • A group of tasks or an activity pass through a process of iteration
             • This iteration is self-conclusive
       • Agile
         • Work in parallel with the client
         • React to the changes to prevent or react in the best way
         • Products are mainly code

Bilder und Dateien der Mindmap