Improve software architect roadmap content (#7821)
* Phase A * Phase B * Phase C * Phase D * Phase E * Phase F * Phase - G * Phase H * Phase - I * Phase - J * Phase - <K>pull/7824/head
Vedansh
2 months ago
committed by
GitHub
parent
a317d90f14
commit
6158d4def8
83 changed files with 350 additions and 259 deletions
@ -1 +1,9 @@ |
||||
# Apis and integrations |
||||
# APIs and Integrations |
||||
|
||||
APIs (Application Programming Interfaces) are essential for enabling communication between different software applications, allowing them to share data and functionality seamlessly. They serve as the bridge that connects disparate systems, making it possible for applications to interact without needing to know the internal workings of one another. Integration, on the other hand, refers to the process of connecting these systems to work together effectively, often utilizing APIs to facilitate data exchange and process automation. By leveraging APIs in integrations, organizations can enhance operational efficiency, reduce data silos, and improve user experiences through seamless data flow between applications. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@What is API Integration](https://www.ibm.com/topics/api-integration) |
||||
- [@article@API Integration - Postman](https://www.postman.com/api-platform/api-integration/) |
||||
- [@article@API First Integration](https://www.infoq.com/articles/api-first-integration/) |
||||
@ -1,3 +1,7 @@ |
||||
# Application Level Architecture |
||||
|
||||
The lowest level of architecture. Focus on one single application. Very detailed, low level design. Communication is usually within one development team. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Application Architecture](https://www.codesee.io/learning-center/application-architecture) |
||||
@ -1 +1,3 @@ |
||||
# Architectures |
||||
|
||||
Architecture refers to the approach of designing and implementing software architecture with a focus on the tools and technologies that will be used during the development process. This perspective emphasizes that the selection of tools can significantly influence architectural decisions and the overall design of the system. |
||||
@ -1,7 +1,7 @@ |
||||
# Balance |
||||
|
||||
- **Quality comes at a price**: Earlier I talked about quality and non-functional requirements. If you overdo architecture it will increase costs and probably lower speed of development. You need to balance architectural and functional requirements. Over engineering should be avoided. |
||||
- **Solve contradicting goals**: A classic example of contradicting goals are short- and long-term goals. Projects often tend to build the simplest solution whereas an architect has the long-term vision in mind. Often, the simple solution does not fit into the long-term solution and is at risk to be thrown away later (sunk costs). To avoid implementation into the wrong direction, two things need to be considered: |
||||
1. Developers and business need to understand the long term vision and their benefits in order to adapt their solution and |
||||
2. managers who are responsible for budget need to be involved to understand the financial impact. It is not necessary to have 100% of the long term vision in place directly, but the developed piece should fit into it. |
||||
- **Conflict management**: Architects are often the glue between multiple groups with different backgrounds. This may lead to conflicts on different levels of communication. To find a balanced solution which also reflect long-term, strategic goals, it is often the role of architects to help overcome the conflict. My starting point regarding communication theory was the “Four-Ears Model” of Schulze von Thun. Based on this model a lot can be shown and deducted. But this theory needs some practice, which should be experienced during communication seminars. |
||||
Achieving balance in architecture requires managing trade-offs between quality, cost, and development speed, avoiding over-engineering while aligning functional and non-functional requirements. Architects must navigate conflicting goals, like balancing short-term simplicity with long-term vision, ensuring solutions fit future needs while involving developers, businesses, and managers in understanding the financial and strategic impact. Additionally, architects often mediate between diverse groups, resolving conflicts and aligning strategies through effective communication, such as the “Four-Ears Model” by Schulze von Thun, which aids in fostering collaboration and achieving balanced, strategic outcomes. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Wikipedia](https://en.wikipedia.org/wiki/Balance_(architecture)) |
||||
@ -1 +1,9 @@ |
||||
# Cloud providers |
||||
# Cloud Providers |
||||
|
||||
Cloud providers provide a layer of APIs to abstract infrastructure and provision it based on security and billing boundaries. The cloud runs on servers in data centers, but the abstractions cleverly give the appearance of interacting with a single “platform” or large application. The ability to quickly provision, configure, and secure resources with cloud providers has been key to both the tremendous success and complexity of modern DevOps. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Cloud Service Provider](https://www.techtarget.com/searchitchannel/definition/cloud-service-provider-cloud-provider) |
||||
- [@article@What are Cloud Providers?](https://www.redhat.com/en/topics/cloud-computing/what-are-cloud-providers) |
||||
- [@feed@Explore top posts about Cloud](https://app.daily.dev/tags/cloud?ref=roadmapsh) |
||||
@ -1,7 +1,7 @@ |
||||
# Consult and Coach |
||||
|
||||
Being pro-active is probably the best you can do when it comes to consulting and coaching. If you are asked, it is often too late. And cleaning up on the architecture site is something which you want to avoid. You need to somehow foresee the next weeks, months or even years and prepare yourself and the organization for the next steps. |
||||
Proactive consulting and coaching are essential to prevent architectural issues from escalating. Architects must anticipate future needs and prepare the organization by setting a clear vision of mid- and long-term goals, often using maturity models to provide structure and measure progress against SMART criteria. Building a **Community of Practice (CoP)** fosters collaboration, standardization, and knowledge sharing among professionals with shared interests, such as developers and architects, enhancing individual and organizational growth. Open-door sessions, held regularly without a strict agenda, encourage open communication, resolve minor issues promptly, and address complex topics through follow-ups, reducing misconceptions and ambiguity. |
||||
|
||||
- **Have a vision**: If you are deployed in a project, whether it is a traditional waterfall like approach or agile, you always need to have a vision of your mid- and long-term goals you want to achieve. This is not a detailed concept, but more a road-map towards everyone can work. As you cannot achieve everything at once (it is a journey) I prefer to use maturity models. They give a clear structure which can be easily consumed and give the current status of progress at every time. For different aspects I use different models, e.g. development practices or continuous delivery. Every level in the maturity model has clear requirements which follow the SMART criteria in order to ease measuring if you have achieved it or not. One nice example I found is for continues delivery. |
||||
- **Build a community of practice (CoP)**: Exchanging experience and knowledge among a common interest group helps distributing ideas and standardizing approaches. For example you could gather all JavaScript developer and architects in one room, every three months or so, and discuss past and current challenges and how they were tackled or new methodologies and approaches. Architects can share, discuss and align their visions, developers can share experience and learn from their peers. Such a round can be highly beneficial for the enterprise but also for the individual itself, as it helps building a stronger network and distributes ideas. Also check out the article Communities of Practice from the SAFe Framework which explains the CoP concept in an agile setting. |
||||
- **Conduct open door sessions**: One source of misconceptions or ambiguity is lack of communication. Block a fixed time slot, e.g. 30 min every week, for exchanging hot topics with your peers. This session has no agenda everything can be discussed. Try to solve minor things on the spot. Schedule follow-ups on the more complex topics. |
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Wikipedia](https://en.wikipedia.org/wiki/Consulting) |
||||
@ -1,10 +1,9 @@ |
||||
# Decision Making |
||||
|
||||
An architect needs to be able to take decisions and guide projects or the entire organization into the right direction. |
||||
|
||||
- **Know what is important**: Do not waste time with unimportant decisions or activities. Learn what is important. To my knowledge there is not a book which has these information. My personal favorites are these 2 characteristics which I usually consider when evaluating if something is important or not: |
||||
1. Conceptional Integrity: If you decide to do it in one way, stick to it, even if it is sometimes better to do it differently. Usually, this leads to a more straightforward overall concept, eases comprehensibility and eases maintenance. |
||||
2. Uniformity: If you for example define and apply naming conventions it is not about upper- or lowercase, but to have it applied everywhere in the same way. |
||||
- **Prioritize**: Some decisions are highly critical. If they are not taken early enough workarounds are build up which are often unlikely to be removed later and are a nightmare for maintenance, or worse, developers simply stop working until a decision is taken. In such situations it is sometimes even better to go with a “bad” decision instead of having no decision. But before it comes to this situation, consider prioritizing upcoming decisions. There are different ways to do so. I suggest having a look at the Weighted Shortest Job First (WSJF) model which is widely used within agile software development. Especially the measures time criticality and risk reduction are critical to estimate the priority of architecture decisions. |
||||
- **Know your competence**: Do not decide things which are not in your competence. This is critical as it may ruin your position as architect significantly if not considered. To avoid this, clarify with your peers which responsibilities you have and what is part of your role. If there are more than one architect, then you should respect the level of architecture in which you are currently deployed. As an lower level architect you better come up with suggestions for higher level architecture instead of decisions. Further, I recommend checking critical decisions always with a peer. |
||||
- **Evaluate multiple options**: Always lay out more than one option if it comes to decisions. In the majority of the cases I was involved in, there was more than one possible (good) option. Going with only one option is bad in two respects: First, it seems that you did not do your job properly and secondly it impedes making proper decisions. By defining measures, options can be compared based on facts instead of gut feelings, e.g. license costs or maturity. This usually leads to better and more sustainable decisions. Further, it eases to sell the decision to different stakeholders. Besides, if you do not have evaluated options properly you may miss arguments when it comes to discussions. |
||||
Effective decision-making is crucial for architects to guide projects and organizations in the right direction. Focus on what’s important by emphasizing **conceptual integrity** (sticking to consistent decisions for simplicity and maintainability) and **uniformity** (ensuring standards like naming conventions are applied consistently). Prioritize critical decisions early to avoid costly workarounds or project delays, using tools like the Weighted Shortest Job First (WSJF) model for prioritization. Stay within your scope of competence to maintain credibility, collaborate with peers, and clarify responsibilities within the architectural hierarchy. |
||||
|
||||
When making decisions, evaluate multiple options to ensure thorough analysis and foster stakeholder confidence. Comparing options based on measurable criteria, such as cost or feasibility, leads to better, fact-driven decisions. This process not only supports sustainable outcomes but also prepares you with strong arguments during discussions, ensuring alignment across teams and stakeholders. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Decision Making - Wikipedia](https://en.wikipedia.org/wiki/Decision-making) |
||||
|
||||
@ -1,11 +1,10 @@ |
||||
# Design and Architecture |
||||
|
||||
What makes a good design? This is probably the most important and challenging question. I will make a distinction between theory and practice. To my experience, having a mix of both is most valuable. Let’s start with theory: |
||||
|
||||
- **Know the basic design patterns**: Patterns are one of the most important tools an architect needs to have to develop maintainable systems. With patterns you can reuse designs to solve common problems with proven solutions. The book “Design Patterns: Elements of Reusable Object-Oriented Software” written by John Vlissides, Ralph Johnson, Richard Helm, Erich Gamma is a must-read to everyone who is in software development. Although the patterns were published more than 20 years ago they are still the basis of modern software architecture. For example, the Model-View-Controller (MVC) pattern was described in this book, which is applied in many areas or is the basis for newer pattern, e.g. Model-View-ViewModel (MVVM). |
||||
- **Dig deeper into patterns and anti-patterns**: If you already know all basic Gang-of-Four patterns, then extend your knowledge with more software design patterns or dig deeper into your area of interest. One of my favorite books about application integration is “Enterprise Integration Patterns” written by Gregor Hohpe. This book is applicable in various areas whenever two applications need to exchange data, whether it is an old-school file exchange from some legacy systems or a modern microservice architecture. |
||||
- **Know quality measures**: Defining architecture is not the end. There are reasons why guidelines and coding standards are defined, applied and controlled. You do this because of quality and non-functional requirements. You want to have a system which is maintainable, reliable, adaptable, secure, testable, scalable, usable, etc. And one piece to achieving all of these quality attributes is applying good architecture work. You can start to learn more about quality measures on Wikipedia. |
||||
Theory is important. Practice is equally—or even more—important if you do not want to become an Ivory Tower Architect. |
||||
- **Try out and understand different technology stacks**: I think this is the most important activity if you want to become a better architect. Try out (new) technology stacks and learn their ups and downs. Different or new technology comes with different design aspects and patterns. You most likely do not learn anything from just flipping through abstract slides but by trying it out by yourself and feeling the pain or the relief. An architect should not only have broad, but—also in some areas—deep knowledge. It is not important to master all technology stacks but to have a solid understanding of the most important in your area. Also, try out technology which is not in your area, e.g., if you are deep into SAP R/3 you should also try JavaScript and vice versa. Still, both parties will be surprised about the latest advances in SAP S/4 Hana. For example, you can try it by yourself and take a course at openSAP for free. Be curious and try out new things. Also try out stuff which you did not like some years ago. |
||||
- **Analyze and understand applied patterns**: Have a look at any current framework, e.g., Angular. You can study a lot of patterns in practice, e.g., Observables. Try to understand how it is applied in the framework, why it was done. And if you are really dedicated, have a deeper look into the code and understand how it was implemented. |
||||
- **Be curious and attend User Groups**. [Meetup](https://www.meetup.com/) |
||||
Good design in software architecture blends theoretical knowledge with practical experience. Theoretically, architects should master fundamental design patterns, such as those detailed in *"Design Patterns: Elements of Reusable Object-Oriented Software"*, which remain foundational for modern architecture. Advanced knowledge of patterns and anti-patterns, like those in *"Enterprise Integration Patterns"*, extends this understanding. Architects must also focus on quality measures, ensuring designs meet non-functional requirements like scalability, security, and adaptability. |
||||
|
||||
Practically, architects improve by experimenting with various technology stacks, gaining insights into their strengths and limitations. Exploring frameworks like Angular reveals real-world pattern applications, such as Observables, and fosters deeper understanding through hands-on coding. Attending user groups and engaging in communities, like those on Meetup, broadens perspectives and encourages curiosity, enabling architects to stay updated and continuously refine their craft. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@roadmap@Visit Dedicated Software Design Roadmap](https://roadmap.sh/software-design-architecture) |
||||
- [@opensource@Design Patterns for Humans](https://github.com/kamranahmedse/design-patterns-for-humans) |
||||
|
||||
@ -1,6 +1,9 @@ |
||||
# Distributed systems |
||||
# Distributed Systems |
||||
|
||||
Distributed systems are a type of computing architecture where components located on networked computers communicate and coordinate their actions by passing messages. These systems are designed to work together to achieve a common goal, often providing services or processing data in a collaborative manner. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Free Distributed Systems book from Maarten van Steen](https://www.distributed-systems.net/index.php/books/ds3/) |
||||
- [@article@Distributed Architectures](https://estuary.dev/distributed-architecture/) |
||||
- [@feed@Explore top posts about Architecture](https://app.daily.dev/tags/architecture?ref=roadmapsh) |
||||
|
||||
@ -1 +1,12 @@ |
||||
# Emc dms |
||||
# EMC and DMS |
||||
|
||||
EMC (Enterprise Metadata Catalog) and DMS (Document Management System) are two distinct concepts in the realm of data management and information systems. Below is an overview of each: |
||||
|
||||
An Enterprise Metadata Catalog (EMC) is a centralized repository that stores metadata about data assets within an organization. This metadata provides context, meaning, and structure to the data, enabling better data management and utilization. |
||||
|
||||
A Document Management System (DMS) is a software solution that helps organizations capture, store, manage, and track electronic documents and images of paper-based information. DMS solutions are essential for organizing and securing documents in a digital format. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@DMS](https://www.opentext.com/products/documentum-content-management) |
||||
- [@article@EMC Softwares](https://www.spiceworks.com/collaboration/content-collaboration/articles/top-10-enterprise-content-management-software-systems/) |
||||
@ -1 +1,7 @@ |
||||
# Enterprise software |
||||
# Enterprise Software |
||||
|
||||
Enterprise software refers to software applications that are designed to meet the needs of large organizations or enterprises. These applications are typically complex, scalable, and capable of integrating with other systems to support a wide range of business functions. Enterprise software is used to improve efficiency, streamline processes, and enhance productivity across various departments within an organization. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Enterprise Softwares](https://en.wikipedia.org/wiki/Enterprise_software) |
||||
@ -1 +1,9 @@ |
||||
# Esb soap |
||||
# ESB and SOAP |
||||
|
||||
ESB (Enterprise Service Bus) and SOAP (Simple Object Access Protocol) are two technologies that enable communication between different systems. ESB is a software architecture that allows for the integration of various systems, such as databases, web services, and mobile applications. SOAP is a messaging protocol that enables the exchange of structured data between systems over the internet. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Understanding SOAP: The Old Guard of Web Services](https://mariomthree.medium.com/understanding-soap-the-old-guard-of-web-services-6ca89d8ec312) |
||||
- [@article@Enterprise Service Bus](https://en.wikipedia.org/wiki/Enterprise_service_bus) |
||||
- [@article@ESB - IBM](https://www.ibm.com/topics/esb) |
||||
@ -1,8 +1,10 @@ |
||||
# Estimate and Evaluate |
||||
|
||||
- **Know basic project management principles**: As architect or lead developer you are often asked for estimates to realize your ideas: How long, how much, how many people, which skills, etc.? Of course, if you plan to introduce new tools or frameworks you need to have an answer for these kind of “management” questions. Initially, you should be able to give a rough estimate, like days, months or years. And do not forget that it is not only about implementing, there are more activities to consider, like requirements engineering, testing and fixing bugs. Therefore, you should know the activities the used software development process. One thing you can apply to get better estimates, is to use past data and derive your prediction from that. If you do not have past data, you can also try approaches such as COCOMO by Barry W. Boehm. If you are deployed in an agile project, learn how to estimate and to plan properly: The book “Agile Estimating and Planning” by Mike Cohn provides a solid overview in this area. |
||||
- **Evaluate “unknown” architecture**: As architect you should also be able to evaluate the suitability of architectures for the current or future context(s). This is not an easy task but you can prepare for it by having a set of questions at hand which are common for every architecture. And it’s not only about architecture but also about how the system is managed, as this also gives you insights about the quality. I suggest to always have some questions prepared and ready to use. Some ideas for general questions: |
||||
- Design practices: Which patterns does the architecture follow? Are they consequently and correctly used? Does the design follow a red line or is there an uncontrolled growth? Is there a clear structure and separation of concerns? |
||||
- Development practices: Code guidelines in place and followed? How is the code versioned? Deployment practices? |
||||
- Quality assurance: Test automation coverage? Static code analysis in place and good results? Peer reviews in place? |
||||
- Security: Which security concepts are in place? Built-in security? Penetration tests or automated security analysis tools in place and regularly used? |
||||
Estimation and evaluation are critical skills for architects and lead developers. Architects must understand basic project management principles to provide estimates for timelines, resources, and costs, considering all project phases like requirements, testing, and debugging. Using past data or models like COCOMO helps refine estimates. For agile projects, resources like *"Agile Estimating and Planning"* by Mike Cohn can offer valuable guidance. |
||||
|
||||
Evaluating "unknown" architectures involves assessing their suitability for current and future contexts through prepared questions. These should cover design practices (e.g., patterns and structure), development practices (e.g., code guidelines and deployment), quality assurance (e.g., test automation and peer reviews), and security measures (e.g., built-in security and penetration tests). This structured approach ensures informed decisions and promotes robust, maintainable solutions. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Evaluating Software Architectures](https://medium.com/oolooroo/evaluating-digital-architectures-a-deep-dive-into-modern-software-systems-analysis-dff3b0d2da8f) |
||||
- [@article@How to Evaluate Software Architecture: Methods and Tools](https://www.linkedin.com/advice/0/what-most-common-software-architecture-evaluation) |
||||
@ -1,15 +1,9 @@ |
||||
# ETL Datawarehouses |
||||
|
||||
In the world of data warehousing, if you need to bring data from multiple different data sources into one, centralized database, you must first: |
||||
|
||||
- **EXTRACT** data from its original source |
||||
- **TRANSFORM** data by deduplicating it, combining it, and ensuring quality, to then |
||||
- **LOAD** data into the target database |
||||
|
||||
ETL tools enable data integration strategies by allowing companies to gather data from multiple data sources and consolidate it into a single, centralized location. ETL tools also make it possible for different types of data to work together. |
||||
ETL (Extract, Transform, Load) is a key process in data warehousing, enabling the integration of data from multiple sources into a centralized database. The process begins by **extracting** data from original sources, followed by **transforming** it to ensure quality, deduplication, and combination, and finally **loading** it into the target database. ETL tools streamline this process, allowing companies to consolidate diverse data types and ensure seamless integration for effective data analysis and decision-making. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@What is ETL?](https://www.snowflake.com/guides/what-etl) |
||||
- [@video@ETL explained](https://www.youtube.com/watch?v=OW5OgsLpDCQ) |
||||
- [@video@ETL Explained](https://www.youtube.com/watch?v=OW5OgsLpDCQ) |
||||
- [@feed@Explore top posts about ETL](https://app.daily.dev/tags/etl?ref=roadmapsh) |
||||
|
||||
@ -1,3 +1,8 @@ |
||||
# Firewalls |
||||
|
||||
A Firewall is a network security device that monitors and filters incoming and outgoing network traffic based on an organization's previously established security policies. |
||||
A Firewall is a network security device that monitors and filters incoming and outgoing network traffic based on an organization's previously established security policies. Firewalls usually sit between a trusted network and an untrusted network; oftentimes the untrusted network is the Internet. For example, office networks often use a firewall to protect their network from online threats. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@What is a Firewall? - Cloudflare](https://www.cloudflare.com/learning/security/what-is-a-firewall/) |
||||
- [@article@Firewall - Cisco](https://www.cisco.com/site/us/en/learn/topics/security/what-is-a-firewall.html) |
||||
|
||||
@ -1 +1,8 @@ |
||||
# Architect frameworks |
||||
# Architect Frameworks |
||||
|
||||
Architect frameworks are tools that provide a structured approach to software architecture. They help architects organize their work, manage dependencies, and ensure consistency across projects. Some popular frameworks include: |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Architect Frameworks](https://www.techtarget.com/searchapparchitecture/definition/enterprise-architecture-framework) |
||||
- [@article@Common Software Architecture Frameworks](https://medium.com/@publicapplicationcenter/tutorial-notes-common-software-architecture-frameworks-1a9915e1d806) |
||||
|
||||
@ -1,10 +1,11 @@ |
||||
# Git |
||||
|
||||
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. |
||||
Git is a distributed version control system designed to handle projects of any size with speed and efficiency. Created by Linus Torvalds in 2005, Git tracks changes in source code during software development, allowing multiple developers to work together on non-linear development. It provides strong support for branching, merging, and distributed development workflows. Git maintains a complete history of all changes, enabling easy rollbacks and comparisons between versions. Its distributed nature means each developer has a full copy of the repository, allowing for offline work and backup. Git's speed, flexibility, and robust branching and merging capabilities have made it the most widely used version control system in software development, particularly for open-source projects. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@roadmap@Visit Dedicated Git & Github Roadmap](https://roadmap.sh/git-github) |
||||
- [@video@Git & GitHub Crash Course For Beginners](https://www.youtube.com/watch?v=SWYqp7iY_Tc) |
||||
- [@article@Learn Git with Tutorials, News and Tips - Atlassian](https://www.atlassian.com/git) |
||||
- [@article@Git Cheat Sheet](https://cs.fyi/guide/git-cheatsheet) |
||||
- [@article@Tutorial: Git for Absolutely Everyone](https://thenewstack.io/tutorial-git-for-absolutely-everyone/) |
||||
- [@feed@Explore top posts about Git](https://app.daily.dev/tags/git?ref=roadmapsh) |
||||
|
||||
@ -1,14 +1,14 @@ |
||||
# GitHub |
||||
|
||||
GitHub is a provider of Internet hosting for software development and version control using Git. It offers the distributed version control and source code management functionality of Git, plus its own features. |
||||
GitHub has become a central hub for open-source projects and is widely used by developers, companies, and organizations for both private and public repositories. It was acquired by Microsoft in 2018 but continues to operate as a relatively independent entity. GitHub's popularity has made it an essential tool in modern software development workflows and a key platform for showcasing coding projects and contributing to open-source software. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@opensource@GitHub Website](https://github.com) |
||||
- [@article@GitHub Documentation](https://docs.github.com/en/get-started/quickstart) |
||||
- [@roadmap@Visit Dedicated Git & Github Roadmap](https://roadmap.sh/git-github) |
||||
- [@official@GitHub](https://github.com) |
||||
- [@official@GitHub: Quickstart](https://docs.github.com/en/get-started/quickstart/hello-world) |
||||
- [@official@GitHub Documentation](https://docs.github.com/en/get-started/quickstart) |
||||
- [@official@Learn GitHub by doing](https://skills.github.com/) |
||||
- [@video@What is GitHub?](https://www.youtube.com/watch?v=w3jLJU7DT5E) |
||||
- [@video@Git vs. GitHub: Whats the difference?](https://www.youtube.com/watch?v=wpISo9TNjfU) |
||||
- [@video@Git and GitHub for Beginners](https://www.youtube.com/watch?v=RGOj5yH7evk) |
||||
- [@video@Git and GitHub - CS50 Beyond 2019](https://www.youtube.com/watch?v=eulnSXkhE7I) |
||||
- [@article@How to Use Git in a Professional Dev Team](https://ooloo.io/project/github-flow) |
||||
- [@feed@Explore top posts about GitHub](https://app.daily.dev/tags/github?ref=roadmapsh) |
||||
|
||||
|
||||
@ -1,8 +1,12 @@ |
||||
# GraphQL |
||||
# Graphql |
||||
|
||||
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. |
||||
GraphQL is a query language and runtime for APIs, developed by Facebook. GraphQL's flexibility and efficiency make it popular for building complex applications, especially those with diverse client requirements. It's particularly useful for mobile applications where bandwidth efficiency is crucial. While it requires a paradigm shift from REST, many developers and organizations find GraphQL's benefits outweigh the learning curve, especially for large-scale or rapidly evolving APIs. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Apollo GraphQL Tutorials](https://www.apollographql.com/tutorials/) |
||||
- [@feed@Explore top posts about GraphQL](https://app.daily.dev/tags/graphql?ref=roadmapsh) |
||||
- [@roadmap@visit Dedicated GraphQL Roadmap](https://roadmap.sh/graphql) |
||||
- [@official@Introduction to GraphQL](https://graphql.org/learn/) |
||||
- [@video@GraphQL Course for Beginners](https://www.youtube.com/watch?v=ed8SzALpx1Q) |
||||
- [@article@Introduction to GraphQL](https://thenewstack.io/introduction-to-graphql/) |
||||
- [@article@How to Execute a Simple GraphQL Query](https://thenewstack.io/how-to-execute-a-simple-graphql-query/) |
||||
- [@feed@Explore top posts about GraphQL](https://app.daily.dev/tags/graphql?ref=roadmapsh) |
||||
@ -1,11 +1,12 @@ |
||||
# Spark, Hadoop MapReduce |
||||
|
||||
[Apache Spark](https://spark.apache.org/) is a data processing framework that can quickly perform processing tasks on very large data sets, and can also distribute data processing tasks across multiple computers, either on its own or in tandem with other distributed computing tools. |
||||
Spark is a data processing framework that can quickly perform processing tasks on very large data sets, and can also distribute data processing tasks across multiple computers, either on its own or in tandem with other distributed computing tools. |
||||
|
||||
Hadoop MapReduce is a software framework for easily writing applications which process vast amounts of data (multi-terabyte data-sets) in-parallel on large clusters (thousands of nodes) of commodity hardware in a reliable, fault-tolerant manner. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Apache Spark](https://spark.apache.org/) |
||||
- [@article@Spark vs Hadoop MapReduce](https://www.integrate.io/blog/apache-spark-vs-hadoop-mapreduce) |
||||
- [@video@Hadoop explained in 5 minutes](https://www.youtube.com/watch?v=aReuLtY0YMI) |
||||
- [@feed@Explore top posts about Apache Spark](https://app.daily.dev/tags/spark?ref=roadmapsh) |
||||
|
||||
@ -1,14 +1,10 @@ |
||||
# How to Code |
||||
|
||||
Even as an Enterprise Architect, the most abstract level of architecture, you should still know what developers are doing on their daily basis. And if you do not understand how this is done, you may face two major problems: |
||||
|
||||
- Developers won’t accept your sayings. |
||||
- You do not understand challenges and needs of developers. |
||||
- **Have a side project**: The purpose of this is to try out new technologies and tools to find out how development is done today and in the future. Experience is the combination of observations, emotions and hypothesis (“Experience and Knowledge Management in Software Engineering” by Kurt Schneider). Reading a tutorial or some pros and cons is good. But this is just “book knowledge”. Only if you try out things by yourself you can experience emotions and can built up hypothesis about why something is good or bad. And the longer you work with a technology the better your hypothesis will get. This will help you to take better decisions in your day to day work. As I started programming I had no code completion and only some utility libraries to speed up development. Obviously, with this background I would make wrong decisions today. Today, we have tons of programming languages, frameworks, tools, processes and practices. Only if you have some experience and a rough overview in the major trends you are able to take part of the conversation and to steer development into the right direction. |
||||
- **Find the right things to try out**: You cannot try out everything. This is simply impossible. You need a more structured approach. One source I recently discovered is the [Technology Radar](https://www.thoughtworks.com/radar) from ThoughtWorks. They categorize technologies, tools, platforms, languages and frameworks into four categories: |
||||
- Adopt: “strong feeling to be ready for enterprise usage”. |
||||
- Trial: “enterprise should try it in one project that can handle the risk”. |
||||
- Assess: “explore how it affects your enterprise” |
||||
- Hold: “process with caution”. |
||||
|
||||
With this categorization it is easier to get an overview of new things and their readiness to better evaluate which trend to explore next. |
||||
Even as an Enterprise Architect, staying connected to coding practices is essential to understand developers’ challenges and earn their trust. Maintaining a **side project** allows you to explore new technologies, tools, and methodologies hands-on, building practical experience beyond theoretical knowledge. This helps in forming informed decisions and keeping pace with evolving trends in development. |
||||
|
||||
To prioritize what to explore, structured resources like ThoughtWorks’ Technology Radar can guide you. It categorizes technologies into **Adopt**, **Trial**, **Assess**, and **Hold**, helping architects focus on impactful and enterprise-ready innovations. Staying informed and involved ensures better collaboration and alignment with developers. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@How to Code](https://www.thoughtworks.com/insights/blog/how-to-code) |
||||
- [@article@Technology Radar](https://www.thoughtworks.com/radar) |
||||
@ -1,10 +1,17 @@ |
||||
# Java/Kotlin/Scala |
||||
|
||||
- **Java**: Java is a widely-used, object-oriented programming language known for its platform independence, reliability, and scalability. It’s commonly used for building large-scale enterprise applications, Android development, and web services. Java’s extensive libraries, frameworks, and strong community support make it a popular choice for developers. |
||||
|
||||
- **Scala**: Scala is a statically-typed programming language that combines object-oriented and functional programming paradigms. It runs on the Java Virtual Machine (JVM) and is known for its concise syntax, expressive power, and compatibility with Java. Scala is often used in data engineering, backend services, and applications requiring high concurrency. |
||||
|
||||
- **Kotlin**: Kotlin is a modern, statically-typed programming language designed to be fully interoperable with Java while offering more concise and expressive syntax. It is particularly popular for Android development due to its simplicity and safety features, such as null safety, and is gaining traction in backend development as well. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@roadmap@Visit Dedicated Java Roadmap](https://roadmap.sh/java) |
||||
- [@article@Java Basics](https://www.w3schools.com/java/) |
||||
- [@article@Learn the basics of Kotlin](https://blog.teamtreehouse.com/absolute-beginners-guide-kotlin) |
||||
- [@article@Kotlin Docs](https://kotlinlang.org/docs/reference/basic-syntax.html) |
||||
- [@article@Scala Tutorial](https://docs.scala-lang.org/tour/basics.html) |
||||
- [@official@Scala](https://www.scala-lang.org/) |
||||
- [@official@Scala Documentation](https://docs.scala-lang.org/) |
||||
- [@official@Kotlin](https://kotlinlang.org/) |
||||
- [@official@Kotlin Documentation](https://kotlinlang.org/docs/home.html) |
||||
- [@official@Java](https://www.java.com/) |
||||
- [@feed@Explore top posts about Java](https://app.daily.dev/tags/java?ref=roadmapsh) |
||||
|
||||
@ -1,18 +1,16 @@ |
||||
# JavaScript |
||||
|
||||
JavaScript allows you to add interactivity to your pages. Common examples that you may have seen on the websites are sliders, click interactions, popups and so on. Apart from being used on the frontend in browsers, there is Node.js which is an open-source, cross-platform, back-end JavaScript runtime environment that runs on the V8 engine and executes JavaScript code outside a web browser. |
||||
JavaScript allows you to add interactivity to your pages. Common examples that you may have seen on the websites are sliders, click interactions, popups and so on. Apart from being used on the frontend in browsers, there is Node.js which is an open-source, cross-platform, back-end JavaScript runtime environment that runs on the V8 engine and executes JavaScript code outside a web browser. TypeScript adds optional types to JavaScript that support tools for large-scale JavaScript applications for any browser, for any host, on any OS. TypeScript compiles to readable, standards-based JavaScript. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@roadmap@Visit Dedicated JavaScript Roadmap](https://roadmap.sh/javascript) |
||||
- [@article@W3Schools – JavaScript Tutorial](https://www.w3schools.com/js/) |
||||
- [@roadmap@Visit Dedicated TypedScript Roadmap](https://roadmap.sh/typescript) |
||||
- [@official@TypeScript](https://www.typescriptlang.org/) |
||||
- [@official@TypeScript Docs for Deep Dives](https://www.typescriptlang.org/docs/) |
||||
- [@article@The Modern JavaScript Tutorial](https://javascript.info/) |
||||
- [@video@JavaScript Crash Course for Beginners](https://youtu.be/hdI2bqOjy3c) |
||||
- [@video@Node.js Crash Course](https://www.youtube.com/watch?v=fBNz5xF-Kx4) |
||||
- [@video@Node.js Tutorial for Beginners](https://www.youtube.com/watch?v=TlB_eWDSMt4) |
||||
- [@article@Official Website](https://www.typescriptlang.org/) |
||||
- [@article@Official Docs for Deep Dives](https://www.typescriptlang.org/docs/) |
||||
- [@article@The TypeScript Handbook](https://www.typescriptlang.org/docs/handbook/intro.html) |
||||
- [@article@TypeScript Tutorial](https://www.tutorialspoint.com/typescript/index.htm) |
||||
- [@video@TypeScript for Beginners](https://www.youtube.com/watch?v=BwuLxPH8IDs) |
||||
- [@feed@Explore top posts about JavaScript](https://app.daily.dev/tags/javascript?ref=roadmapsh) |
||||
|
||||
@ -1,19 +1,7 @@ |
||||
# Layered Architecture |
||||
|
||||
Layered architecture is a software design pattern in which an application is composed of several layers or tiers. Each layer has a specific responsibility and communicates with the other layers through well-defined interfaces. This modular approach to software design allows for easier maintenance and testing, and also makes it possible to reuse components in different applications. |
||||
Layered architecture is a software design pattern where an application is divided into distinct layers, each with a specific responsibility, such as presentation, business logic, and data access. This approach promotes modularity, easier maintenance, testing, and component reusability. The most common implementation is the three-tier architecture, which separates concerns between the user interface, business rules, and data handling. However, it can introduce complexity, performance issues, tight coupling, and overhead if not carefully implemented. Despite these challenges, layered architecture is widely used in scalable and maintainable systems, particularly in enterprise applications. |
||||
|
||||
The most common type of layered architecture is the three-tier architecture, which is typically composed of a presentation layer, a business logic layer, and a data access layer. The presentation layer is responsible for displaying data to the user and receiving user input. The business logic layer contains the core business logic and rules of the application, and the data access layer is responsible for accessing and manipulating data in the database. |
||||
Visit the following resources to learn more: |
||||
|
||||
Layered architecture is a common approach to designing scalable and maintainable software systems, and it is often used in enterprise-level applications. |
||||
|
||||
While layered architecture has many benefits, it also has some drawbacks that should be considered. These include the following: |
||||
|
||||
- Complexity: Layered architecture can add complexity to an application, especially if it is not implemented carefully. This can make the application more difficult to understand and maintain. |
||||
|
||||
- Performance: Layered architecture can potentially impact the performance of an application, because data has to be passed between the different layers. This can be especially problematic if the application has a large number of layers or if the layers are not optimized for performance. |
||||
|
||||
- Tight coupling: If the layers in a layered architecture are not well-defined and loosely coupled, changes to one layer can potentially affect other layers, which can lead to maintainability issues. |
||||
|
||||
- Overhead: Layered architecture can add overhead to an application, because data has to be passed between the different layers. This can potentially impact the performance and scalability of the application. |
||||
|
||||
Overall, while layered architecture has many benefits, it is important to carefully consider the potential drawbacks and make sure that the benefits outweigh the costs in your specific application. |
||||
- [@article@Wikipedia](https://en.wikipedia.org/wiki/Layered_architecture) |
||||
|
||||
@ -1 +1,7 @@ |
||||
# Management |
||||
|
||||
Management in software architects encompasses various responsibilities and practices that ensure the successful design, development, and implementation of software systems. Software architects play a critical role in bridging the gap between business requirements and technical implementation. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Wikipedia](https://en.wikipedia.org/wiki/Management) |
||||
@ -1,10 +1,7 @@ |
||||
# Marketing Skills |
||||
|
||||
Your ideas are great and you have communicated them well but still nobody wants to follow? Then you probably lack marketing skills. |
||||
Marketing skills are essential for promoting your ideas effectively, especially when others may not immediately embrace them. To convince others, it's crucial to motivate them by demonstrating the value and benefits of your ideas in an easily digestible format, such as through prototypes or videos. Persistence is key; if you're convinced of your idea’s worth, you need to fight for it, even if it's met with resistance. Establishing allies who support your ideas can also make it easier to gain traction, so start building a network. Repeating your message regularly can help, but be cautious not to overdo it, as credibility is essential for long-term success. |
||||
|
||||
- **Motivate and convince**: How do companies convince you of buying a product? They demonstrate its value and benefits. But not just with 5 bullet points. They wrap it nicely and make it as easy as possible to digest. |
||||
- Prototypes: Show a prototype of your idea. There are plenty of tools for creating prototypes. In the context of enterprises who love SAP check out build.me in which you can create nice looking and clickable UI5 apps fast and easy. |
||||
- Show a video: Instead of “boring slides” you can also show a video which demonstrates your idea or at least the direction. But please, don’t overdo marketing: In the long term, content is king. If your words do not come true, this will damage your reputation in the long term. |
||||
- **Fight for your ideas and be persistent**: People sometime do not like your ideas or they are just too lazy to follow them. If you are really convinced by your ideas, you should continuously go after them and “fight”. This is sometimes necessary. Architecture decisions with long term goals are often not the easiest one’s: Developers do not like them, as they are more complex to develop. Managers do not like them, as they are more expensive in the short term. This is your job to be persistent and to negotiate. |
||||
- **Find allies**: Establishing or enforcing your ideas on your own can be hard or even impossible. Try to find allies who can support and help convincing others. Use your network. If you do not have one yet, start building it now. You could start by talking to your (open-minded) peers about your ideas. If they like it, or at least parts of it, it is likely that they support your idea if asked by others (“The idea by X was interesting.”). If they don’t like it, ask for the why: Maybe you have missed something? Or your story is not convincing enough? Next step is to find allies with decision power. Ask for an open-minded discussion. If you fear the discussion, remember that sometimes you need to leave your comfort zone. |
||||
- **Repeat It, Believe It**: “[…] studies show that repeated exposure to an opinion makes people believe the opinion is more prevalent, even if the source of that opinion is only a single person.” (Source: The Financial Brand) If you publish few messages often enough, it can help to convince people more easily. But be aware: From my perspective such a strategy should be used wisely as it could backfire as a lousy marketing trick. |
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Marketing Skills for Architects](https://openasset.com/blog/marketing-for-architects/) |
||||
|
||||
@ -1 +1,9 @@ |
||||
# Networks |
||||
|
||||
A computer network is a set of computers sharing resources located on or provided by network nodes. Computers use common communication protocols over digital interconnections to communicate with each other. These interconnections are made up of telecommunication network technologies based on physically wired, optical, and wireless radio-frequency methods that may be arranged in a variety of network topologies. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Networking - IBM](https://www.ibm.com/topics/networking) |
||||
- [@article@Networking - Wikipedia](https://en.wikipedia.org/wiki/Networking) |
||||
- [@article@Networking Basics](https://www.cisco.com/c/en/us/solutions/small-business/resource-center/networking/networking-basics.html) |
||||
|
||||
@ -1 +1,3 @@ |
||||
# Operations knowledge |
||||
# Operations Knowledge |
||||
|
||||
Operational knowledge refers to the understanding and insights that software architects need to effectively design, implement, and manage software systems throughout their lifecycle. This knowledge encompasses various aspects of software development, deployment, and maintenance, and it is crucial for ensuring that systems operate efficiently, reliably, and securely. |
||||
|
||||
@ -0,0 +1,8 @@ |
||||
# Prince2 |
||||
|
||||
Prince2 is a structured project management method and practitioner certification programme. Prince2 emphasizes dividing projects into manageable and controllable stages. It is adopted in many countries worldwide, including the UK, Western European countries, and Australia. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Prince2 Certification](https://www.axelos.com/certifications/propath/prince2-project-management) |
||||
- [@course@Prince2 Project Management Course](https://www.simplilearn.com/project-management/prince2-foundation-and-practitioner-certification-training) |
||||
@ -1 +1,7 @@ |
||||
# Programming languages |
||||
# Programming Languages |
||||
|
||||
A programming language is a system of notation for writing computer programs. Programming languages are described in terms of their syntax and semantics, usually defined by a formal language. Languages usually provide features such as a type system, variables, and mechanisms for error handling. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Programming Language](https://en.wikipedia.org/wiki/Programming_language) |
||||
@ -1,3 +1,7 @@ |
||||
# Proxies |
||||
|
||||
In computer networking, a proxy server is a server application that acts as an intermediary between a client requesting a resource and the server providing that resource. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Proxy Server](https://en.wikipedia.org/wiki/Proxy_server) |
||||
@ -1 +1,7 @@ |
||||
# SAP ERP, HANA, Business Objects |
||||
|
||||
SAP (Systems, Applications, and Products in Data Processing) is a leading enterprise resource planning (ERP) software provider that helps organizations manage their business operations and customer relations effectively. SAP ERP integrates various business processes, such as finance, sales, procurement, and human resources, into a unified system, enabling real-time data access and improved decision-making. SAP HANA (High-Performance Analytic Appliance) is an in-memory database and application development platform that allows businesses to process large volumes of data quickly and efficiently, supporting advanced analytics and real-time reporting. BusinessObjects, part of the SAP Business Intelligence suite, provides powerful tools for data visualization, reporting, and analysis, enabling users to transform raw data into actionable insights. Together, these solutions empower organizations to streamline operations, enhance productivity, and drive strategic decision-making through data-driven insights. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@SAP](https://www.sap.com/) |
||||
|
||||
@ -1 +1,8 @@ |
||||
# Security |
||||
|
||||
Security is a broad field that encompasses various measures and practices designed to protect information, systems, and networks from unauthorized access, damage, or theft. It is essential in safeguarding sensitive data and maintaining the integrity and availability of resources. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Security - Wikipedia](https://en.wikipedia.org/wiki/Security) |
||||
- [@article@Architect Security](https://aws.amazon.com/blogs/architecture/lets-architect-security-in-software-architectures/) |
||||
|
||||
@ -1,12 +1,10 @@ |
||||
# Serverless Concepts |
||||
|
||||
Serverless is a cloud-native development model that allows developers to build and run applications without having to manage servers. |
||||
|
||||
There are still servers in serverless, but they are abstracted away from app development. A cloud provider handles the routine work of provisioning, maintaining, and scaling the server infrastructure. Developers can simply package their code in containers for deployment. |
||||
Serverless is a cloud-native development model that allows developers to build and run applications without having to manage servers. There are still servers in serverless, but they are abstracted away from app development. A cloud provider handles the routine work of provisioning, maintaining, and scaling the server infrastructure. Developers can simply package their code in containers for deployment. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@What is serverless?](https://www.redhat.com/en/topics/cloud-native-apps/what-is-serverless) |
||||
- [@article@What is serverless computing?](https://www.cloudflare.com/learning/serverless/what-is-serverless/) |
||||
- [@article@What is Serverless?](https://www.redhat.com/en/topics/cloud-native-apps/what-is-serverless) |
||||
- [@article@What is Serverless Computing?](https://www.cloudflare.com/learning/serverless/what-is-serverless/) |
||||
- [@article@Serverless on AWS](https://aws.amazon.com/serverless/) |
||||
- [@feed@Explore top posts about Serverless](https://app.daily.dev/tags/serverless?ref=roadmapsh) |
||||
|
||||
@ -1,8 +1,7 @@ |
||||
# Simplifying Things |
||||
|
||||
Keep in mind the problem-solving principle Occam’s Razor which states to prefer simplicity. I interpret the principle as following: If you have too many assumptions about the problem to solve your solution will probably be wrong or lead to an unnecessary complex solution. Assumptions should be reduced (simplified) to come to a good solution. |
||||
Simplifying solutions is critical for effective problem-solving, aligning with Occam’s Razor, which favors simplicity by reducing unnecessary assumptions. To achieve this, “shake” your solution by analyzing it from different perspectives and questioning its assumptions. After complex discussions, take a step back to review the big picture and refactor if needed, giving your brain time to process ideas. Apply the *divide and conquer* method to break problems into smaller parts and validate their integration afterward. Finally, remember that refactoring is a valuable process to improve overly complex solutions, provided there’s adequate test coverage and stakeholder support. |
||||
|
||||
- **Shake the solution**: To get solutions simplified, it often helps to “shake” the solution and look at them from different positions. Try to shape the solution by thinking top-down and again bottom-up. If you have a data flow or process, then first think left to right and again right to left. Ask questions such as: “What happens to your solution in a perfect world?” Or: “What would company / person X do?” (Where X is probably not your competitor, but one of the GAFA (Google, Apple, Facebook, & Amazon) companies.) Both questions force you to reduce assumptions as suggested by Occam’s Razor. |
||||
- **Take a step back**: After intense and long discussions, highly complex scribbles are often the results. You should never ever see these as the final results. Take a step back: Have a look at the big picture again (abstract level). Does it still make sense? Then go through it on the abstract level again and refactor. Sometimes it helps to stop a discussion and continue the next day. At least my brain needs some time to process and to come up with better, more elegant and simpler solutions. |
||||
- **Divide and Conquer**: Simplify the problem by dividing it into smaller pieces. Then solve them independently. Afterwards validate if the small pieces match together. Take the step back to have a look at the overall picture for this. |
||||
- **Refactoring is not evil**: It is totally ok to start with a more complex solution if no better idea can be found. If the solution is making troubles you can later rethink the solution and apply your learning. Refactoring is not evil. But before you start refactoring, keep in mind to have (1) enough automated tests in place which can ensure the proper functionality of the system and (2) the buy-in from your stakeholders. To learn more about refactoring I suggest reading “Refactoring. Improving the Design of Existing Code” by Martin Fowler. |
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Simplifying Things](https://www.infoq.com/articles/driving-architectural-simplicity/) |
||||
|
||||
@ -1,3 +1,7 @@ |
||||
# Solution Level Architecture |
||||
|
||||
The mid-level of architecture. Focus on one or more applications which fulfill a business need (business solution). Some high, but mainly low-level design. Communication is between multiple development teams. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Solution Architecture](https://www.leanix.net/en/wiki/it-architecture/solution-architecture) |
||||
|
||||
@ -1,13 +1,10 @@ |
||||
# Sql databases |
||||
|
||||
SQL stands for Structured Query Language. It's used for relational databases. A SQL database is a collection of tables that stores a specific set of structured data. |
||||
|
||||
Examples of SQL Databases |
||||
|
||||
- MariaDB and MySQL |
||||
- PostgreSQL |
||||
SQL stands for Structured Query Language. It's used for relational databases. A SQL database is a collection of tables that stores a specific set of structured data. Examples of SQL Databases includes MariaDB, MySQL and PostgreSQL. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@roadmap@Visit Dedicated SQL Roadmap](https://roadmap.sh/sql) |
||||
- [@article@What is SQL? - AWS](https://aws.amazon.com/what-is/sql/) |
||||
- [@article@SQL Databases](https://www.openlogic.com/blog/what-sql-database) |
||||
- [@feed@Explore top posts about SQL](https://app.daily.dev/tags/sql?ref=roadmapsh) |
||||
|
||||
@ -1 +1,7 @@ |
||||
# Architect tools |
||||
# Architect Tools |
||||
|
||||
Architect tools are software tools that help architects to design, document, and manage software architectures. These tools can be used to create architecture diagrams, generate code, and automate the software development process. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Top 10 Software Architecture Tools in 2024](https://www.geeksforgeeks.org/software-architecture-tools/) |
||||
@ -1 +1,7 @@ |
||||
# Web and mobile |
||||
# Web and Mobile |
||||
|
||||
Web apps and mobile apps are two distinct types of software applications designed to run on different platforms. Web apps are accessed through web browsers and run on various devices using internet connectivity. They are platform-independent, making them easy to update and maintain, but often require an active internet connection. Mobile apps, on the other hand, are specifically developed for mobile operating systems like Android and iOS, providing enhanced performance, offline functionality, and seamless access to device features such as GPS, cameras, and sensors. While web apps prioritize accessibility and cost-effectiveness, mobile apps focus on delivering a tailored and optimized user experience. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Web vs Mobile](https://buildfire.com/difference-between-web-app-and-mobile-app/) |
||||
|
||||
@ -1 +1,7 @@ |
||||
# Working with data |
||||
# Working with Databases |
||||
|
||||
Working with databases involves storing, managing, and retrieving data efficiently to support applications and business processes. Databases can be relational, like MySQL and PostgreSQL, which use structured tables and SQL for querying, or non-relational (NoSQL), like MongoDB and Cassandra, which handle unstructured or semi-structured data. Effective database management requires designing normalized schemas for relational databases, ensuring data integrity, and optimizing queries for performance. For NoSQL databases, it's important to choose the right type (e.g., document, key-value, columnar) based on application needs. Additionally, managing transactions, indexing, backups, and security are crucial for maintaining reliable and scalable database systems. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Introduction to Databases](https://www.digitalocean.com/community/conceptual-articles/an-introduction-to-databases) |
||||
Loading…
Reference in new issue