Architecture and Design

• Architecture and Design are also called as work product.
• Architectural and Design involves inputs, processes, and outputs
• Inputs
• Requirements
• What is to be solved
• Qualities
• How “good” is it?
• Assets
• What is available
• Outputs
• Architecture
• Viability
• Architecture and design both focus on the content and the context of the target system, ensuring that it does the right things and does things the right way.
• Architecture: Nodes and components = “black boxes”
• Design: Nodes and components = “white boxes”
• This simple framework can be extended, enabling us to see a repeating pattern across the scales which includes followings processes
• Requirements
• Architecture
• Design
• Architecture can be at any scale, and the scale is defined by the characteristic dimension of the architecture’s elements.
• It defines the structure and behavior of the elements of a system.
• The elements of an amplifier are its tuner,cables, and remote controls. It can also include the power supply, and the circuit board.
• The elements of a circuit board are its resistors, fuses, and integrated circuits.
• The elements of an integrated circuit are transistors and other components.
• Based on the scale we can determine
• Above that scale are the ‘requirements’ of the world in which the system sits.
• At that scale is the ‘architecture’ between the elements of the system.
• Below that scale is the ‘design’ of the insides of the elements of the system.
• IT system’s requirements are modelled as interactions with actors and other upstream and downstream systems.
• IT system’s architecture’s elements are components and nodes, and so on.
• IT system’s design model includes the insides of components, nodes, messages, and connections.
• Architecture helps us to validate the accuracy of our system
• Architecture is documented under architecture guidance that helps ensure our system is a good system.
• Architecture guidance includes:
• Reuse the work as much as possible. 
• Tried and tested parts
• Tried and tested structures of parts (reference architectures)
• Principles and patterns that help ensure the architecture is created in a good way
• Architecture can be defined as artefact where the architecture of a system describes its overall static structure and dynamic behavior. 
• It models the system’s elements, the externally manifested properties of those elements, and the static and dynamic relationships among them.
• The artifacts present models of the target IT system.
• They can be driven by models of the broader business system, of which this target IT system is a part.
• The target IT system must meet the specific business requirements placed on it.
• They can be guided by artifacts documenting architectural principles, patterns, and building blocks.
• The target IT system must meet the wider architectural requirements placed on it.
• It is also used by Enterprise Architects at the enterprise scale as they plan transition initiatives which may be elaborated by the IT Architect.
• Architecture when defined as a discipline
• Architecture is an engineering discipline that studies methods of designing IT systems that provide a solution of a business problem. The solution must satisfy functional and non-functional requirements in a way that best balances competing stakeholders concerns and must take constraints into account.

• Difference between architecture and design
• Architecture is creating a structure.
• Design is detailing the content.
• Methods of software delivery
• SPM for AI
• JavaAD for Java app development
• Methods define the approach we used to deliver a work product.
• Define how our deliverables meet with clients requirements and what work products we need to create.
• Role of architecture
• Acts as a solution blueprint that can be reviewed and validated.
• Communication tool for stakeholders and teams for future reference for maintenance and change, developing related systems and integration.
• Delivery Environments: Input into the delivery environments’ design and specification, tools and platforms of choice for solution.
• Delivery Planning: Starting point for developing the project plan (Waterfall delivery), solution and feature backlog (Agile delivery),resource requirements and team structure
• Estimates: Starting point for cost estimation.
• Enable parallel development by understanding how inter-component dependencies can and should be managed
• Foundation for commercial agreements.
• Foundation for Declaration of Understanding and segregation of responsibilities between various parties.
• Need of Architecture
• Both Functional capabilities and Non-functional requirements and Service Levels may be contractually binding.
• Failure to achieve targets may result in financial penalties for the IT provider, and/or a loss of business for the client
• If an architecture that meets the specified requirements cannot be established it is a red flag.
• The sooner this is known the better for all the stakeholders
• The effort expended should always be proportionate to the risk and return involved.
• Without a developed architecture, it is rare that all significant risks are known and well understood
• Lack of architecture means that there is no basis for solution cost and delivery time estimates.