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.