Guidelines for Preparing Solution Architecture Principles

Gyaan ( The General Wisdom) 

For any organization which deals with the software architecture there need to have a software architecture standards which will be used for taking architectural decisions.

So how do we go about creating a software architecture standards that can be circulated across an organization. 

1. Identify the purpose of this document why this document is required.
2. Have a good understanding  of the existing technologies used across the organization. 
3. Identify technical constraints which are there in the organizations and the principles should be in line with those constraints.
4. Follow a structure for penning down the principles. For instance a principle should contain a the following The intent of the principle, Rationale of the Principle and the Implications of the principle.

This kind of a structure information can be circulated to the teams so that they can use this document to take critical decisions in the project. 

Application to Real life Situations.

Enough of prophesying, lets get cracking and apply this to develop some principles for real life problems which we come across in our work.

Lets assume we are being entrusted  with making a solution  architecture principle so that it can be used as a guideline for teams.  

As a first step we need to understand the technology landscape of our organization, when i say technology landscape let me restrict myself to software technologies.

Software Landscape Assessment.

Current technology Landscape includes solutions  of three platforms 

• Microsoft technologies (the old VB6 and ASP). This is largely my legacay suite of applications.
• JAVA/J2EE technologies which is used for building my custom applications.
• Any CRM/ERP related products which are used for out of the box solutions for finance, HR related domains.

Once i study the technology landscape, we need to have a closer look at the application landscape.

Lets assume we identified that most of the applications built are on top of all these technologies. And the applications are tightly integrated since the business process are tightly integrated.

Constraints Identifications

We figure out that we don't have a proper integration middle-ware. 

Since we have used COTS(Commercial Off the Shelf ) products, some of them don't support open  standards.

Legacy applications are used for some of the critical business process so we will not be able to replace those with new systems since we have some external stakeholders and management intervention.

Lack of central reference data has caused data duplication which is scattered across the applications.

Principles samples

This sections list out some sample principles in accordance with the constraints which we have mentioned and based on the application landscape.

Statement

Legacy systems/services will be replaced but only when there is a valid business case for doing so

Rationale

• Legacy systems are not inherently bad and a whole-sale approach    to replace them with the latest technology be avoided.
• Replacement of existing legacy systems will only be done if there is a valid value proposition to do so and if the risks have been properly evaluated.

Implications.

• Legacy system will continue to exist in the organization and  it should be noted that this position will not change over time.
• Only the specifics of which system are legacy will change.   i.e. the systems introduced today will be deemed legacy at some point of time in future.
• The functionality will be scattered between the new systems and the old systems.
• Integration between the legacy system and the new systems  has its own cost and maintenance cycle.

Statement

Solution architecture should be designed to use asynchronous mode of integration to deal with system integration except where real time response is required or the systems to be integrated  have the same availability.

Rationale

Asynchronous communication offers more flexibility than synchronous communication in terms of 

• Decoupling.
• Availability.
• Throttling.
• Fault-Tolerance

Implication

• Asynchronous messaging requires a distinctly different design. It is implemented  with a very basic set of message oriented middle-ware commands
• Lack of ESB (Enterprise Service Bus) implies either to depend on point to point integration  or building some in-house custom mediation module on top of existing third party frameworks for messaging requirements.
• Asynchronous solution requires services/components to be stateless

Statement

Solutions should be architect-ed considering interoperability within a heterogeneous environment.

Rationale

• Interoperability is the capability of software located on different hardware, potentially from different vendors, to share data.
• Interoperability,  allows applications or services the ability to use or access other applications or services regardless of the technology  or the platform they are deployed upon.

Implication

• Interoperability standards and industry standards will be followed unless there is a compelling business  reason or a technical limitation to implement a non-standard solution.

Statement

The architecture should  have clear functional layer  to access the data residing in other applications. The data would be referenced if the data source resides in the same database.  If the data is located in different data source then a copy would be made.

Rationale

• The heterogeneous technology landscape makes the data access difficult and error prone.
• The layering would ensure the complexity will be encapsulated and shield the dependant layers.

Implication

• This will avoid duplicates and lesser reliance on the data synchronization  with in the same data source.
• The heterogeneous environment and lack of common reference data  will lead to have multiple copies of data maintained across different environments.

Conclusion

The enterprise undergo rapid changes in business cycles and business models. To meet this challenges it has been widely acknowledged that defining an IT architecture is the most important phase in planning any major development of re-engineering effort.

Solution Architecture  is a foundation component of any architecture program and defining proper standards can be a major driver for flexibility and innovation