Logical and Physical Architecture

 When you have defined the user stories (requirements) for a new system, the next step is to design the system architecture. There are two main parts to this:

1. Logical Architecture:  This is a high-level view of the system, focusing on the different components or building blocks needed to meet the requirements. It's like a blueprint for the system, showing how the different pieces should work together.

⠀For example, if you're building a system to report bugs, the logical components could be:
* Ticket Creation
* Ticket Assignment
* Notifications (to the requester and resolver)
* Communication (adding notes to the ticket)
* Ticket Closure

⠀The logical architecture doesn't go into the technical details of how each component will be built. It just maps out what components are needed and how they should interact.




2. Physical Architecture: This is the more technical view of the system, specifying the actual technologies and infrastructure that will be used to build the components defined in the logical architecture.

⠀The physical architecture might include things like:
* Databases to store ticket data
* User interfaces (web or mobile apps) for creating and viewing tickets
* APIs for communication between components
* Servers or cloud services to run the application code
* Load balancers and other infrastructure components

Essentially, the logical architecture is the high-level design, while the physical architecture is the implementation plan for making that design a reality using specific technologies and infrastructure.
The two architectures are closely linked – the physical components need to support and enable the logical components and their interactions. But the logical architecture comes first, defining what the system needs to do, before the physical architecture specifies how it will be built.

Comments

Post a Comment

Popular posts from this blog

Data Models

  When you think of system design,   Data Models   is a common term that you will hear. So what are Data Models? Very simply it is the way how data for a product or tech system is represented. And this represented ideally depends on the customer or the use case. Take the example of a car. One way to define a car can be to use the attributes like model, color, price, year of manufacture. Another way to define a car can be using attributes - License plate, owner name, history of accidents. If you are making a tech product for the use of a car buyer - then the Data Model 1 is more relevant and if you are making a tech system for the police, then Data model 2 is more relevant.  (One more reason to think customer backwards!!) . Broadly, there are three types of data models: 1) Relational; 2) Document; 3) Graph. The most well-known is the  relational data model . You can see this data typically in a tabular format where each row represents a relation. (SQL is a popula...
Read more

Deep Learning

Image
A few weeks ago, we discussed   representation learning , which allows an algorithm to automatically discover and learn the most useful features from the data itself (unlike classic machine learning that relies on human-defined features). However, representation learning has a limitation when it comes to intricate problems like voice or image recognition, where it becomes challenging to create a representation due to complexities. For instance, in speech recognition, accents pose a difficulty in representing them as a mere set of features. This is where deep learning steps in to solve this problem. Deep learning expresses the representation in terms of other simpler representations. For example, if we need to identify whether an image depicts a car or an animal, the first input to the model can be just the colors. These colors then serve as input to another representation of edges, which further feeds into contours, and so on, until after multiple layers, we can understand the type...
Read more