Application of TOGAF in actual software development/ SDLC

As a TOGAF certified professional, I often encounter misconceptions about the framework's applicability in standard software development lifecycles (SDLCs). While TOGAF is a comprehensive Architecture Development Method (ADM) for designing and maintaining enterprise architectures, it can also significantly contribute to the efficiency and effectiveness of regular SDLCs. This blog aims to clarify these connections and highlight the practical benefits of integrating TOGAF principles into everyday development practices.

Organizations possessing an Architecture group and following TOGAF principles are expected to adhere to the Architecture Development Method (ADM) cycle, shown below

The provided image illustrates the core concept of TOGAF: the creation and evolution of an Enterprise Architecture (EA). This architectural framework guides organizations in adapting to changing business landscapes and seizing emerging opportunities.

The Architecture Development Method (ADM) is a structured process within TOGAF, designed to apply architectural principles and practices to drive strategic change across business, information, process, and technology domains.

Application Architecture is a crucial component of the EA, typically addressed during Phase C (Architecture Development) of the ADM cycle. It provides a blueprint for individual application systems, detailing their interactions and alignment with the organization's core business processes.

While Enterprise Architecture offers a holistic view of the entire organizational architecture landscape, Application Architecture focuses on specific solutions targeting one or a few business requirements.

To ensure consistency and compliance, any new solution must adhere to the established EA. The EA team plays a pivotal role in validating the architecture from a governance perspective, safeguarding the organization's strategic direction. 

While TOGAF is a comprehensive framework, two key aspects are particularly relevant to developers:

1. Aligning development efforts with Business Strategy:

• Enterprise Architecture (EA): Provides a strategic roadmap for the organization, ensuring that development efforts align with long-term business goals.
• Application Architecture: Focuses on the specific requirements of individual applications, ensuring they contribute to the overall business strategy.

2. Enhancing data management and governance:

• Enterprise Architecture: Defines data standards, governance policies, and migration strategies, ensuring data consistency and quality across the organization.
• Application Architecture: Designs the data models and structures specific to each application, ensuring data integrity and security.

By understanding these distinctions, developers can work more effectively with enterprise architects to deliver high-quality solutions that support the organization's strategic objectives.

Journey of an on-premise web application to cloud

This post is helpful to guide any person/ organization who have their web application hosted on-premise or on some vendor servers and have futuristic view that they see their user base to grow in coming future. It's understood that initially it would sound difficult to move an application to cloud because we do not know if our application is fit to run on cloud. 

The phases below show approach that a Cloud Architect would adopt to migrate a web application hosted on non-cloud environment to cloud.

Phase I  [Initial adoption phase to understand if our application can run on cloud]	Phase II  [Now that application runs and we are happy, adopt the best practices of Cloud computing]	Phase III  [Try adopting to Cloud services]	Phase IV  [Cost cutting]
* Lift and shift the application as is into Docker and push to cloud.  * Backend database into separate EC2 instance.  * Deployment pipeline.	*Break big application into smaller chunks, Microservices to be introduced for most of the transaction to enhance performance.   * Microservices wrapped in containers.  * Introduce communication channel between components like RabbitMQ or SNS/SQS   * ELK for storage of logs, analysis and visualization for application and infrastructure monitoring, faster  troubleshooting, security analytics, etc.	* Check for Cloud services for Middleware, replacing your backend DB with RDS.  * Make use of Adapters that connects to Cloud services, shielding our application from a Cloud specific API.	* Define the minimum required instances [Dedicated/ Reserved capacity], based on this information connect with Cloud provider and have a contract defined.

Log shipping vs Mirroring vs Replication for Data Architects/ DBAs

Log Shipping: 

It automatically sends transaction log backups from one database (Known as the primary database) to a database (Known as the Secondary database) on another server. An optional third server, known as the monitor server, records the history and status of backup and restore operations. The monitor server can raise alerts if these operations fail to occur as scheduled.  

Mirroring: 

Database mirroring is a primarily software solution for increasing database availability. 

It maintains two copies of a single database that must reside on different server instances of SQL Server Database Engine. 

Replication: 

It is a set of technologies for copying and distributing data and database objects from one database to another and then synchronizing between databases to maintain consistency. Using replication, you can distribute data to different locations and to remote or mobile users over local and wide area networks, dial-up connections, wireless connections, and the Internet. 

Basic requirements for each of them

 
Log Shipping

• The servers involved in log shipping should have the same logical design and collation setting. 
• The databases in a log shipping configuration must use the full recovery model or bulk-logged recovery model. 
• The SQL server agent should be configured to start up automatically. 
• You must have sysadmin privileges on each computer running SQL server to configure log shipping. 

Mirroring

• Verify that there are no differences in system collation settings between the principal and mirror servers. 
• Verify that the local windows groups and SQL Server logins definitions are the same on both servers. 
• Verify that external software components are installed on both the principal and the mirror servers. 
• Verify that the SQL Server software version is the same on both servers. 
• Verify that global assemblies are deployed on both the principal and mirror server. 
• Verify that for the certificates and keys used to access external resources, authentication and encryption match on the principal and mirror server. 

Replication

• Verify that there are no differences in system collation settings between the servers. 
• Verify that the local windows groups and SQL Server Login definitions are the same on both servers. 
• Verify that external software components are installed on both servers. 
• Verify that CLR assemblies deployed on the publisher are also deployed on the subscriber. 
• Verify that SQL agent jobs and alerts are present on the subscriber server, if these are required. 
• Verify that for the certificates and keys used to access external resources, authentication and encryption match on the publisher and subscriber server. 

DB terms ABC - ACID, BASE and CAP

 

ACID is an acronym which is commonly used to define the properties of a relational database system, it stand for following terms 

• Atomicity - This property guarantees that if one part of the transaction fails, the entire transaction will fail, and the database state will be left unchanged. 

• Consistency - This property ensures that any transaction will bring the database from one valid state to another. 

• Isolation - This property ensures that the concurrent execution of transactions results in a system state that would be obtained if transactions were executed serially. 

• Durable - means that once a transaction has been committed, it will remain so, even in the event of power loss. 

• 
  

BASE properties are the common properties of recently evolved NOSQL databases. According to CAP theorem, a BASE system does not guarantee consistency. This is a contrived acronym that is mapped to following property of a system in terms of the CAP theorem 

• Basically available indicates that the system is guaranteed to be available 

• Soft state indicates that the state of the system may change over time, even without input. This is mainly due to the eventually consistent model. 

• Eventual consistency indicates that the system will become consistent over time, given that the system doesn't receive input during that time

•  

CAP theorem for distributed computing was published by Eric Brewer, This states that it is not possible for a distributed computer system to simultaneously provide all three of the following guarantees: 

1. Consistency (all nodes see the same data even at the same time with concurrent updates ) 

2. Availability (a guarantee that every request receives a response about whether it was successful or failed) 

3. Partition tolerance (the system continues to operate despite arbitrary message loss or failure of part of the system) 

 
The CAP acronym corresponds to these 3 guarantees. This theorem has created the base for modern distributed computing approaches. World's most high volume traffic companies (e.g. Amazon, Google, Facebook) use this as basis for deciding their application architecture. It's important to understand that only two of these three conditions can be guaranteed to be met by a system.