• Secure and Scalable Lottery System for Affordable Housing on AWS: Developed a transparent and secure lottery system for affordable housing using AWS. Features include user authentication via Cognito, API Gateway integration, DynamoDB storage, and blockchain for auditability.
• Scalable Django-Based Movie Recommendation System on AWS: Built a movie recommendation system using Django, AWS RDS, and OpenSearch. The architecture supports scalability, load balancing, and secure data management.
• High-Availability Web Application with AWS CloudFront S3 and RDS MySQL: Implemented a high-availability web app with CloudFront, S3, and RDS MySQL. The setup includes load balancing, CDN integration, and secure data storage.
• Scalable Chatbot Infrastructure on AWS with Auto Scaling and OpenSearch: Provisioned a scalable chatbot infrastructure using AWS Auto Scaling, OpenSearch, and RDS. Ensures high availability and performance for large-scale user interactions.
• CI/CD Pipeline for Unity Game Deployment with AWS Cognito Authentication: Developed a CI/CD pipeline for deploying a Unity game on AWS S3. Integrated AWS Cognito for user authentication and managed automated deployments.
• Serverless Web App-AWS Lambda-API Gateway: Created a serverless web application using AWS Lambda and API Gateway. The architecture is fully scalable, cost-efficient, and eliminates server management overhead.
• CI/CD Pipeline for IaC: Built a CI/CD pipeline for Infrastructure as Code (IaC) using AWS CodePipeline, CloudFormation, and EC2 instances. Automated the deployment and management of AWS resources.
• Three-Tier Secure Web Application Architecture: Designed a secure three-tier web application architecture on AWS. Features include load balancing, RDS MySQL, and multi-layer security configurations.
• AWS Two-Tier Infrastructure with Secure Web and Database Setup: Implemented a two-tier web and database infrastructure on AWS using EC2 and RDS. Focused on security, scalability, and ease of management.
• AWS Scalable Web Infrustructure With Cloud Formation: Developed a scalable web infrastructure using AWS CloudFormation. Automated the deployment of a VPC, load balancers, EC2 instances, and RDS, ensuring high availability and cost-efficiency.

Projects are crucial for gaining practical, hands-on experience. From the outset of my cloud technology journey, I recognized that it wasn’t enough to simply understand how a service functions in isolation—I needed to see how it integrates within a broader, real-world context. With a business background, I fundamentally understand that technology should serve the business, not the other way around. This perspective naturally leads to designing systems with simplicity, efficiency, and purpose in mind. In an enterprise environment, every configuration change introduces numerous considerations—often exceeding a thousand—that must be meticulously evaluated.

The approach I’ve applied to my public projects mirrors how I would tackle real-world scenarios, always beginning with the business requirements. These include gaining a deep understanding of the business's operations, identifying its technological needs, ensuring compliance when handling customer data, safeguarding security, planning for scalability to accommodate millions of users, and developing a robust disaster recovery strategy. As expected, the list of considerations is comprehensive.

At a senior level, most architects' detailed system designs remain proprietary, with much of the work governed by internal agreements. Why is this worth noting? Because building systems from scratch is a specialized and complex endeavor. While many systems share common components, no two are exactly alike, as each business has unique requirements. This is why new hires often spend their initial months familiarizing themselves with the company’s architectural and technical documentation.

I am continually developing private repositories, which I will release when they become applicable for real-world application. My focus has always been to design each project within a business context, prioritizing the organization's needs. A notable challenge, however, is documenting these systems within a universally accepted framework—something that doesn’t yet exist. Each company typically documents its systems in slightly different ways. For consistency, I have adopted the TOGAF framework, which I find offers both the structure and flexibility to accommodate various inputs.

For every project I publish, I strive to go beyond the technical deliverables by providing an extensive list of critical considerations. These are categorized and evaluated against a range of key factors. My goal is for anyone engaging with my projects—whether for learning or professional purposes—to understand that these considerations are ever-present, even if not explicitly detailed in every instance.

If you're interested, feel free to visit my blog, where I share my projects, thought experiments, and the common challenges I encounter, along with my approaches to addressing them.

The repository is organized into the following directories, each corresponding to a phase of the TOGAF ADM process:

• Preliminary
• Architecture_Vision
• Business_Architecture
• Information_Systems_Architecture
• Technology_Architecture
• Opportunities_and_Solutions
• Migration_Planning
• Implementation_Governance
• Architecture_Change_Management
• Requirements_Management

Purpose: Preparation and initiation activities to meet the business directive for a new enterprise architecture.

• Artifacts:
  • Architecture Principles Document
  • Architecture Vision
• Produced: At the beginning of the ADM cycle.
• Stored: In the Preliminary directory.

Purpose: Develop a high-level aspirational vision of the capabilities and business value to be delivered.

• Artifacts:
  • Request for Architecture Work
  • Statement of Architecture Work
  • Business Scenarios
  • Architecture Vision Document
  • Stakeholder Map Matrix
• Produced: Early in the ADM cycle.
• Stored: In the Architecture_Vision directory.

Purpose: Develop the business architecture to support the agreed architecture vision.

• Artifacts:
  • Business Architecture Baseline
  • Business Architecture Target
  • Business Architecture Gap Analysis
  • Business Interaction Matrix
  • Business Function Matrix
• Produced: After the Architecture Vision.
• Stored: In the Business_Architecture directory.

Purpose: Develop the information systems architecture including data and application architectures.

• Artifacts:
  • Data Architecture Baseline
  • Data Architecture Target
  • Data Architecture Gap Analysis
  • Application Architecture Baseline
  • Application Architecture Target
  • Application Architecture Gap Analysis
• Produced: After Business Architecture.
• Stored: In the Information_Systems_Architecture directory.

Purpose: Develop the technology architecture.

• Artifacts:
  • Technology Architecture Baseline
  • Technology Architecture Target
  • Technology Architecture Gap Analysis
  • Technology Standards
• Produced: After Information Systems Architecture.
• Stored: In the Technology_Architecture directory.

Purpose: Identify the major implementation projects and group them into work packages.

• Artifacts:
  • Project Context Diagrams
  • Benefits Diagrams
  • Implementation and Migration Plan
• Produced: After Technology Architecture.
• Stored: In the Opportunities_and_Solutions directory.

Purpose: Develop a detailed roadmap for implementing the target architecture.

• Artifacts:
  • Implementation and Migration Plan
  • Transition Architectures
  • Implementation and Migration Strategy
• Produced: After Opportunities and Solutions.
• Stored: In the Migration_Planning directory.

Purpose: Provide architectural oversight for the implementation.

• Artifacts:
  • Architecture Contract
  • Compliance Assessment
• Produced: During implementation.
• Stored: In the Implementation_Governance directory.

Purpose: Ensure that the architecture adapts to changes in the technology and business environment.

• Artifacts:
  • Architecture Compliance Review
  • Architecture Change Request
• Produced: As needed during the architecture lifecycle.
• Stored: In the Architecture_Change_Management directory.

Purpose: Manage architecture requirements identified during any phase of the ADM cycle.

• Artifacts:
  • Requirements Repository
  • Requirements Specification
• Produced: Throughout the ADM cycle.
• Stored: In the Requirements_Management directory.