One new learning / day - however small it is

• Read a blog / or article
• Watch TED talk 
• Read a small self-help book (many free eBooks available with less than 100 pages/can be completed in 1-2 days)
• Explore on how things works - on variety of domains
• Watch documentary on your favorite subjects
• Get to know new healthier life style habits
• Find a ways for digital detox
• Look at the ways to improve your existing good life style habits
• Relook and try to practice your childhood passion that you left long back due to your professional commitments / busy life 
• Subscribe to good YouTube channel
• Watch webinars
• Attend online free courses
• Watch TV on new travel destinations
• Understand/Read new culture around the world
• Learn ancient wisdom

Why Tech Upgrades?

Context

As technology plays key role in enabling core business objectives, it does make sense to review the technology portfolio periodically for possible enhancements. This will bring in better ROI in-terms on lower running costs, increased productivity and better customer service or scale to achieve ever-demanding business requirements.

There are many reasons why one need to continue investing in technology – and consider regular upgrades and make this as essential part of strategic decision. Following are few focus area one should consider while upgrading the enterprise wide applications.

Reduced productivity

In many enterprises, most of the application, built decade ago, lacks support of development platform, and associated best practices. These applications not updated with latest platform specific security patches, enhanced language/framework capabilities for robustness and reliability. This is leading to breakdown of the applications frequently. Hence, overall team productivity is reduced and causing challenges around customer service.

Lack of developer community support

As technology is ever evolving and most of the developers would prefer to work on latest breed of technology stacks. The legacy stacks will always pose challenges to find right talents to support such applications. It is important that, key applications would go periodic technology upgrades to harness power of latest platform capabilities along with good community support and availability of talents to support such application portfolio. It will lead to boost the morale of the staff with latest periodic technology trainings. Otherwise, many frustrated individuals (specifically millennials) would leave the job.

Better User Experience

Most of the time legacy applications missing good user experience. It is very important to engage the application users with better user experience. Most of the applications lacks responsive design with multi-channel support – like mobile devices. The strategic decisions shall be applied to overhaul the UI layer of the key applications with organization specific UI ergonomics / guidelines.

Unified Hosting & Release Model

Enterprise applications deployed in heterogeneous environments. It is very important to bring all application deployment to uniform platform – such as Azure PaaS. Also, leverage modern application deployment architecture using frameworks such as Docker and Kubernetes for standardized release trains. This would help release application fixes / features in more reliable manner.

Remove On-premises Mainframe dependencies

In order to overcome the latency issues, it is important that, tee intermediate Azure SQL / Cosmos DB shall be designed to make periodic updates from on-premises legacy databases to Azure environment. This will enable applications to make call natively in Azure environment. In addition, SOAP Webservices to be remediated to REST API. Moving towards REST based API eco system would help to modernize the service layer with latest architectural patterns leading to better service.

Leverage modern architecture style

Most of the applications follow old monolithic style and lacks good design specifically around long processing jobs leading to sub optimal performance. However, apps moved to cloud but underlying technical debts remain same. It is very important that we refactor applications to be cloud native by taking scale and performance of azure services to have better performing apps.

Better Maintenance

With good code refactoring of key modules and providing comprehensive unit test suites would lead to better diagnosis of production issues. This will increase the quick turnaround time of production tickets, as replay of unit test suites would identify application abnormal conditions quickly.

Streamline of knowledge

The uniform technology stacks and deployment/release environment would help to streamline the knowledge on applications. In addition, this would help better organize the trainings for new joiners.

Who is real stakeholders for Enterprise architecture?

OUT SIDE IN – in the following order

1. Layer – End customers of your enterprise services
2. Layer – Your enterprise executive team / sponsors
3. Layer – Project and program teams in your company
4. Layer – Finally your own EA team members

Azure Security

Azure VMs (IaaS) security steps –

1. Applying NSGs (Network Security Group) on Subnet or at VM level to control Inbound and Outbound traffic by providing IP range and rules
2. Blocking Ports that can be a threat and not needed to expose to other Azure Services or public traffic. RDP can be blocked and if someone still needs to do RDP on VM for any administrative work, then make use of Jump Server
3. Use of appropriate DMZ and making use of 3rd party firewalls like Barracuda
4. Azure RBAC and Policies in place for better control and governance

Azure PaaS (App Service) security steps –

1. Applying WAF (Web Application Firewall) to protect your applications
2. Enable Threat Protection for Azure SQL DBs
3. Manage SAS Tokens and Keys effectively for Azure Storage and keys of other APIs
4. Implement Multi-Factor Authentication for applications
5. Implement AD Authentication to enforce policies
6. Use Azure Key Vault to store secret keys (including passwords of Azure VMs)
7. Ensure to run OWASP Top 10 testing for your application and align as per OWASP Top 10 policies
8. Restrict IP address by adding your resources to Virtual Network
9. User Azure DDoS protection and Azure Pen Test to ensure highest level of security for your applicatio

Life Cycle of Agile Architecture

Any process that is designed to be “agile” in nature will have longer sustenance.

Overview:

If software architecture is a key business asset for an organization, then architectural review/analysis must also be a key practice for that organization. Why? Because architectures are complex and involve many design tradeoffs. Without undertaking a formal review /analysis process, the organization cannot ensure that the architectural decisions made are sufficient and don’t pose any significant challenges to quality attributes associated with the project.

Why do we need?

As the saying goes in the medical field, “The prevention is better than cure”. In similar lines, the modern enterprise applications are very complex in nature and require reviews of the software architecture blueprint on a periodic basis. The architecture review helps the project teams to align architecture vision throughout the development cycle. Otherwise, the mistakes around architecture would become very costly and can lead to catastrophic failures during application maintenance / or its life cycle. In addition, review during inception phase would help to establish the early feedback loop to respective stakeholders before engaging in development with a full-fledged team.

How can it be performed?

Any process that is designed to be “agile” in nature will have longer sustenance. Any rigid/formal ceremonies will have less buy-in from teams. So keeping this in mind, the architecture artifacts that are developed and analyzed in the form of sketches, decision trees, technical spike resolutions etc…would become primary communication channels for the review. The simple iterative workshops containing high-level steps as outlined below would be sufficient to complete the exercise.

Step-1: Project Manager / Scrum Master invites external architect [Outside person] for the review

Step-2: Product owner the / Project Manager / Scrum Master / BA would provide high-level business context/business drivers associated with the project

Step-3: Architect would present the artifacts that solve business drivers

Step-4: External architect would engage in discussion with team – primarily with the product owner and project architect.

Step-5: Workshop will be completed with recommendations and suggestions / risk mitigations to improvise the architecture blueprint [If any] with notable rational behind such amendments.

This cycle would last in a single day with multiple workshops. Can be scheduled typically every 3-4 sprints once, to re-look at original decisions and identify any gaps in the implementation for better alignment. This kind of exercise is better suited for complex application architectures that would require at least 10+ sprints for realization.

Challenges:

The architecture review is not an easy job, as it requires a lot of maturity among the people involved in this process. There are many challenges organization might face when trying to implement this practice. Among them are some key considerations one must be aware mentioned below-

1. The organization's architecture practice is very novice; leading to little or no information found on architecture decisions on the application that is under review. This makes an extremely complex endeavour for external experts to review the architecture, as there is no contextual information available.

2. Lack of architecture experts to understand the business/technical complexity and provide meaningful feedback that brings value-add to project stakeholders

3. Open-mindedness of project teams to receive, acknowledge and implement the feedback in right spirit

Conclusion:

As companies embark on high stakes of enterprise applications and integration initiatives, often the results will be in question. Appropriate investments in the form of periodic architecture reviews would result in a better risk mitigation safety net and prevent costly mistakes post project realization. Thus, periodic architecture analysis/review would help project teams to receive honest feedback on the current state of the project and helps to develop a roadmap to actionable items, for future iterations for better alignment on stated quality attributes and initial architecture vision.

Microservices Architecture Style

As traditional enterprises work to embrace business deployment agility of new age internet companies and innovations in engineering practices, the modern application development has grown increasingly complex. The large, monolithic codebases that traditionally power enterprise applications make it difficult to quickly launch new business capabilities. The application users are empowered and more demanding than ever – the modern enterprises need to scale effectively and enable continuous deployments to ensure customers are provided with high performance with the seamless user experience.

Due to these trends, there is a demand for a new software architecture pattern/style that can address the requirements of the modern age enterprise apps. The Microservices architecture style is the answer to business agility in the form of scalability, modularity and rapid deployments.

What Is Microservices?

It is an architectural style to develop a small/coarse grained services separated by business boundaries. Thus each service is autonomous in nature and can scale independently. Each service can communicate each other via REST APIs and can be deployed remotely or locally.

Monolithic pain points

Before Microservices, a common approach to design an application was to use a monolithic architecture. In this mode of development, the application is deployed as a single deployment artifact. Following are pain points associated with classic monolithic codebases.

1. Large monolithic code base will have the challenge to release new services and also difficulty in maintaining large code base
2. Modules can’t scale independently
3. Enable / Disable services without affecting existing features will be always a challenge
4. Any small change in the code will introduce many regression testing/complex deployment scenarios.
5. Will have challenges in continuous deployments

Difference with SOA

At outset, both architecture styles look similar. But there are subtle differences, the noteworthy are:

1. SOA uses ESBs while Microservices can leverage lightweight message gateways
2. Microservices are stateless implemented via REST APIs while SOA can be stateful
3. SOA focuses on reusability wherein Microservices is for decoupling

Tool support

Lightweight containers like Docker will provide provides a runtime environment for deployment and provides isolation with other services. There is many open sources / COTS tooling support available for Microservices enablement.

Pros / Cons

Following table summarizes briefly about Microservices advantages/disadvantages. The Microservices architecture can’t be suited for each app. The recommended approach is to gradually convert highly customer facing modules to Microservices, stabilize the rapid deployment cycle and gain the experience by maintaining these services over the period of time. This will have less impact on development teams/organization change management activities as teams have to adopt new way of developing the apps.

Advantages

1. Decoupled services can have isolated life cycle
2. Faster time to market; less regressions
3. Modular in nature, hence flexible development and deployment plans
4. Can scale independently

Disadvantages

1. Monitoring the many services
2. Developer skill set – For example: Microservices are distributed in nature. Hence there will be added complexity such as network latency, network unreliability, also understanding the DevOps culture
3. Technology learning curve – new set of tools to learn

Minimilist Architecture Development

Introduction

The new age enterprise application development is very challenging and poses significant design/analysis thinking before one could develop the new system. In the process, the architecture/design team would carry many architecture/design workshops and create architecture descriptions. But the problem with these teams is that descriptions are very elaborative in nature with lot more granular details covering existing “As-Is” information rather than “To-Be” system. Thus, creating lot more divide and less buy-in from project teams.
This blog would discuss how to adopt minimalist architecture description so that it will have all necessary information from the Sprint-1 onwards to kick-start the development. As a rule of thumb, the architecture description should be less than 20 pages. If we try to combine many architecture views/stakeholder’s details, it will be cluttered and understanding architecture decisions would become difficult.

The “minimalist” description

At the bare minimum, architecture description shall contain:
1. Architecturally Significant Requirements (ASR) – From the requirement perspective, scout all architecturally significant requirements and prepare catalogue out of it.
2. Architecturally Significant Decisions (ASD) – Would contain decision taken for each of the ASRs with the rationale behind for each such decision.
3. Architecture Views – Shall contain the solution, technology, data and deployment views. In addition, each view can briefly highlight the technical spikes identified / outcome of such exercises to validate decisions.

Architecture development steps

In order to achieve the minimalist useful architecture descriptions, an architect can follow ordered development steps. Following mind map would describe these steps (Personally I prepared this mindmap and use this as quick reference guide!!)
Depending on the individual application requirements, one can omit the steps – if it not found to be so useful. But in general, following steps would ensure that all critical steps under architecture design are covered.

Conclusion

As saying goes “less luggage more comfort”, carrying heavy architecture descriptions would be the pain for all the members involved in the engagement. So it is imperative that architecture teams would adopt “minimalist” approach as described above so that these artifacts would look neat and tidy with significant key takeaways.

Cloud Transformation Journey

CONTEXT

Every enterprise would like to mark its presence in cloud to be part of digital transformation journey. The cloud platform would offer enterprise services in best economical scale that is otherwise priced heavily when it done on-premises. The cloud transformation offers many distinct benefits, in particular

·       Cost of ownership

·       Design innovative solutions by leveraging latest cloud services

·       Business Continuity / Availability

·       On-demand scale

Concisely, need was to move applications out from on-premises data center and derive cost for running each application under enterprise portfolio.

CHALLENGES

The cloud transformation journey is not trivial and can pose adverse effects when it not assessed and planned properly. As part of the program, it is key to assess the “AS-IS” environment and identify the key challenges in “TO-BE” state. Following are few challenges present as we embarked the transformation.

o   Legacy applications developed in different timeframes (more than decade old apps)

o   Heterogeneous identify management solutions present at on-premises

o   Remediate applications to different runtime containers

o   Migrate database servers to different cloud database services

o   Refactor legacy applications to make it cloud compatible – In particular Platform as a Service (PaaS)

o   Harmonize the application build / release cycles

o   Centralize the application code base that supports modern DevOps practices / tools

SOLUTIONS

The Microsoft Azure chosen as part of the target state. All applications are destined to be part of PaaS service. The entire solution devised around people, process and technology to meet in best possible timeframe with minimal cost.

o   Re-organized the teams with unique skills on product/business owners, cloud infra engineering and application architecture / development

o   Application architecture/development teams divided into distinct technology streams with specific reusable solutions for each of those stacks

o   SCRUM adopted as engineering process with 02-week sprint duration. Teams are distributed and used Azure DevOps tool for end-to-end traceability and tracking.

o   The business/product owner team(s) is ahead of engineering teams with gap analysis on candidate apps. That is primary artefact available for DEV teams to kick start transformation activities.

o   Entire program is divided into distinct phases like pilot followed by bulk transformations. The pilot phase helped to unlock any technical spikes and baseline the target architecture. The theme for pilot phase was “fail fast and cheap”

o   All experiences and solutions recorded and made it as reusable solutions for repeated problems.

o   Many of the Azure services used for the betterment of the existing application. Created the automated environment for the application deployment and its monitoring. Few noteworthy Azure services used are - AppServices, Azure Deployment Slots, Logic Apps, Web Jobs/Schedulers, Key Vault, Redis Cache, Azure AD, Hybrid Connection Managers, Azure Portal Services, Application Insights, Azure DevOps CI/CD pipelines, Azure Automation Jobs, ARM templates, KUDU, Azure Storage accounts, Maven Feed, Azure SQL Managed Instances, API Management etc.

RESULTS

Many applications transformed to Azure PaaS with better application maintenance and monitoring with frequent release cycles. The dedicated environments for application development cycle created otherwise it was not available. On demand basis, the application wise costing /billing details are available with latest Azure capabilities. This has helped to make informed decisions on application future state.

Issue free books till 10th Standard

Can't govt take an action to issue free books for all students in India up-to class 10th. All students can return their books once they done!

It was in practice earlier in Karnataka state. But now that has been dropped. IMO, it will reduce cost and more importantly we can save lakhs of trees.

An simple idea to create low cost toilets in rural India

SBI and its associate banks has nearly 31 Cr savings bank accounts. If they deduct weekly 1.00 (One rupee) from each account, they can collect 124 Cr rupees monthly.

If they donate this amount for building low cost toilets in India, then we can build 82,000 toilets / month. To build a low cost toilet, it would cost ~12K.

Source:

http://www.thehindu.com/business/Industry/sbi-to-hike-minimum-balance-for-savings-account-hit-31-crore-people/article17417909.ece

https://www.giveindia.org/p-10147-sponsor-a-low-cost-toilet-for-a-poor-family.aspx

What is the difference between software architecture and software design? 

In my view, software architecture is list of significant decisions taken on key business requirements (both functional and non-functional) and decision trade-offs between different viewpoints and stake holder interest. So Architecture = Decisions + Views Wherein design is how to implement those high level decisions. In way architecture provides reference context to design. Usually design is technology specific and implemented by experts in specific technology. I tried to compile few the comments from my practice on conceptual differences between architecture and design.
 1) Well in one liner, SW Design implements SW Architecture. SW Design typically covers functional requirement whereas, SW Architecture covers non-functional aspects (but not limited to) of it e.g. Scalability, Availability, Performance etc. So, in another one liner SW Architecture and Functional Requirements are input for SW Design.
 2) Architecture sets the principles, standards, constraints, and high level patterns of how solutions should be designed. Design sets the detailed implementation patterns and language specific standards of how the solutions should be built within the scope of a particular set of requirements.
 3) It is the collaborative effort between the delivery teams and the architects that comes up with the architecture for the system. It's a joint partnership with many gray areas. Key aspects of architecture are: software components and their composition, visible properties, Relationships, significant decisions with a large impact, providing a shared understanding and line of sight to enable collaboration, maximizing reuse, and defining the approach need to meet non-functional requirements.
 4) Architecture is abstract, conceptual detail. Design is concrete implementation. Architects plan to design; designers design to plan.
 5) Architecture is WHAT, Design is HOW
 6) Architecture is defined based on Organization's Strategic goals, be it technology or business, by laying out what makes up the IT infrastructure of an organization and serves as blueprint or framework for all application solutions within an organization. Of course, it is a design by itself. However, Design, which usually refers to application solution design, is the application of Architecture to develop solutions that solve a particular business problem of the organization.
 7) SW Architecture defines the components, interfaces, behaviors and its interactions in a SW system or SW package in a generic way that does not specifies a particular vendor technology/platform. The SW Design specifies the realization of the SW Architecture in the context of a particular software technology or platform.
 8) The primary feature of an architecture is to define structure and a structure is necessary in order to handle complexity (e.g. many modules, sub-systems, interrelated systems, etc.) and structure is also necessary to be able to evolve the "system". Architecture can (and should) depict the phases or releases (whichever you prefer) of systems and enable the transition between them. Software design constitutes the direct or indirect production of code in accordance with the architecture and functional specification. The particular code for a given functional module could be different between releases, or between identical functions that require different non-functional behavior, or different modules could share the same code for equivalent functions. A s/w designer knows how to get the best out of the particular language and platform to deliver the architectural and functional specifications and the s/w architect knows how to put all the components together, over a time span, to achieve the business goals.
 9) Architecture of any kind, is simply abstracted, structural design at the highest level in any context. It typically involves the specification and just positioning (and real-world compromises) of the major components of any system. Architecture is concerned with the 'black box' characteristics of the components rather than the detail of their internal functioning. The latter is detailed design and engineering, although there is no hard boundary to this other that what's indicated by the architecture itself. However, often an architect will need to explore a level down to ensure feasibility, particularly for relatively unknown or uncertain components. For software in particular, the scoping and bounding of highest level components is as much art (intuitive ability) as it is engineering.

JSF Life Cycle explained

Following diagram briefly explains

the JSF life cycle

Can Big Upfront Architecture Document will be beneficial for the team

At times big upfront architecture document say about more than 50 pages document may not grab the attention of developers/other concerned parties. So we architects should be aware of creating architecture documents which are short and to the point. There is no point in creating big documents which no body interested in to know/refer. In my opinion, the architecture document shall be
1) Shall be simple and shall contain key architecture decisions. In my opinion with few UML diagrams and brief description should solve the purpose.
2) Update the document only if deemed to be necessary/otherwise don't update

My Reading List

This is the live content I will be using as my reading list.

Technical
- Software Craftmanship - Currently reading
- The Design Patterns Small Talk Companion - Under progress
- Expert One on One - J2EE without EJB - Finished
- Agile and Iterative Development - Finished
- TOGAF 9, Pocket Guide - Finished
- Agile Project Mgmt with Scrum - Finished
- Java Server Faces - Currently Reading
- Applying UML and Patterns - Finished, but needs some revisits
- Evolutionary Arch and Design - Currently Reading
- Architecture Principles - Finished
- Information Arch and User Experience - Currently exploring
- Architecture Review (ATAM, SARA) - Currently Reading
-

Non-Technical
The Toyata Way - Currently Reading
Mega Living - Currently Reading
Discover Dimond In You - Finished
The World is Flat - Currently Reading
The Malgudi Days - Currently Reading
The Koutilya Arthasastra - Currently Reading

Concrete skills

Each and every individual professional in the IT must have self analysis on some concrete skills. Here what I mean by concrete skills is nothing but deep understanding on the subject which can be easily appreciated and recieved by your collegues.In other words, these concrete skills demonstrates your authorative knowledge and experience on the subject. For example, following are few subjects which myself analysed on my professional life mostly reflects my day to day actvities.

Mostly concrete
Architecture, OOA/D, General Programming skills, Review, Agile engineering practices, Java/J2EE, build scripts, unit testing, Documentation, Presentations on different subjects, Leadership, Pre-sales etc.

No so concrete
Spring, JSF, Javascripts, CSS, HTML, SQL/PL-SQL, Installations, Debugging,
network, protocols, User experience etc.

This kind of analysis puts you to pritorize your free time towards reading.

Does architecture care about implementation?

Does really architecture care about implementation details ie. design realization and subsequent code development?

In my opinion, hands-on experience atleast to ensure reference architecture will provide great value-add to entire architecture. Otherwise it will be the quiet abstract activity which may not be well recieved by development community.

The reference architecture might contain:
1) The implementaion view of the core components
2) All application specific cross cutting concerns
3) Vertical slice of the one use case to demonstrate the architecture realization; kind of Reference implementation for the specification
4) Do's/Dont stuff on target technology stack; chosen one
5) Application build
6) Development best practices/process overview
7) Unit test strategy (atleast development front)
8) Major component/module interface specifications (if possible; generate
javadocs)
9) Usage of static analysers with in the build environment; it would be great if your tooling support best practices customization

It is very easy to slip from abstraction to implementation

During architecture development, sometimes we feel that it is very easy to slip from conceptual/pure architectural thinking to our faviroute technology specific/implementation specific thoughts. In my opinion this is very natural process; but care must be taken to ensure that architecture purity should not influenced by our pet technical jargons.

How create message queue using Spring 2.5.x and Oracle Weblogic Server 11g

Last week I spent some time on configuring JMS Message Queue using Spring 2.5.4 and Oracle Weblogic Server 11g R2.

Following are the step by step instructions to create queue.

1) Log into http://localhost:7001/console, supply weblogic/weblogic (default)
2) Create JMS Server using Oracle Weblogic Server. I used JDBC persistent store - MySQL based, to store the messages under db.
3) Name your jms queue and factory and let these refer to your newly created jms server which points to JDBC persistent store.

4) Now configure your spring jms file; which looks something like this:
































5) Create message listener class; which is influenced by traditional mdbs (J2EE 1.3 era..)

package amp;

import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageListener;
import javax.jms.TextMessage;

public class MyQueueListener implements MessageListener
{

public void onMessage(Message message)
{
if (message instanceof TextMessage)
{
try
{
String txtMessage = ((TextMessage) message).getText();
System.out.println("" + txtMessage + "");
}
catch (JMSException ex)
{
throw new RuntimeException(ex);
}
}
else
{
throw new IllegalArgumentException(
"Message must be of type TextMessage");
}
}
}

7) Create client class whcih produces huge message payloads; just to test

package amp;

import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.Queue;
import javax.jms.Session;
import javax.jms.TextMessage;

import org.springframework.context.ApplicationContext;
import org.springframework.jms.core.JmsTemplate;
import org.springframework.jms.core.MessageCreator;

public class QueueClient
{
private ApplicationContext ctx = AppContext.getApplicationContext();
private JmsTemplate jt = (JmsTemplate) ctx.getBean("jmsTemplate");
private Queue q = (Queue) ctx.getBean("jdbcQ");

public void sendMessage(final String m) throws Exception
{
jt.send(q, new MessageCreator()// inner class
{
public Message createMessage(Session session)
throws JMSException
{
TextMessage tm = session.createTextMessage();
tm.setText(m);
return tm;
}
});
//System.out.println("message sent to destination called "+q.getQueueName());
}
}

8) Finally call this class under web environment; to see the message output. I used OEPE pack to conduct these tests.

Hope this helps to configure message queues.

Care for simple architecture

We J2EE architects must care for simple architecture; few things might help do develop application which are long lasting and easy to accommodate future requirements.

For example; I tried with followings
1) Care for OO rather than standards/specifications
2) Create architecture against requirements in hand rather than technology specific
3) Do not distribute objects if requirements are not called for
4) Follow good architecture and design principles rather than just following patterns
5) Leverage on lightweight architecture like Spring centric which greatly helps in interface driven programming, container level capabilities, test strategies
6) Follow thought full analysis of business requirements and come up with list of high level components, its responsibilities and associated rationale
7) Follow whiteboard driven architectures to kick start the discussion
Care for executable architecture (RUP), spike resolution (XP) and vertical slicing to get confidence in the architecture
8) Come up with list of development standards, guidelines and implementation classes

Architecture development steps

I used mind-mapping technique to represent and structure the architecture development
steps.

It is being influenced by TOGAF and RUP architecture development guidelines.