Art of creating good software

Prasad Narasimhan – Technical Architect

System Definition

• More attention and listening has to go in creating the system.

• How to properly listen and understand is an art• How Henry Ford came with a design of Car when

everyone was thinking of a Cart pulled by Horses. • When we define the system we need to think

that system evolves incrementally has to be thought about.

Business users world

• Business users think system as means of doing business.

• Some time typewriter may be best fit than a laptop.

• Need to think in their terms, no one knows the long tail story what we develop once developed and introduced into market the system takes its own avatar which founder may not even think off but try to justify.

Putting Square peg in round hole

• Business defines what’s the tool is supposed to do.

• Not the technology like Social , Media, Analytics & Cloud defining how the business application should look applying the advancement in this technology.

Big Picture

• System Blueprint has become a Holy grail every architect including the technical architect and application architect needs to know it.

• The application is not a silo it interfaces with other systems since data flows, process flows and all the applications communicate no more silos

• Understand the Big Picture even when a small one is done it helps in integration, reusability and maintainability

Where IT can complement

• Once an Architect is Technology agnostic, who has used the technologies in solving the problems.

• Once Architect able to make representation of business patterns into Technical patterns and visualize system.

• Based on Visualized system comes with Gaps in terms of data flows, interaction, technical fitments, look from multiple dimensions is something missed.

• 70 % accuracy at this stage is great if the system can be created with minor alterations , some new interfaces can be plugged , it can be extended its good.

Now its IT table

• Architecture style and pattern selection should evolve based on business need not on the expertise of architect or the one which is famous in market.

• Architecture Traceability should cover all the business features with the third dimensional mapping to Non Functional Requirements

• Schematic representation of Data model, system model, context, Framework (comprising of design patterns) should be well defined

Architectural & Design Patterns

• Since we are reusing time tested Design patterns that should be properly assembled in Architectural patterns mapping to Business Features covering the NFR’s

• E.g. In Insurance – Policy Management, claims Management, Underwriting , Banking – Payment, Mortgage. This has predefined set of flows and matching data consumption which could be very easily compartmentalized by design patterns

• Change in system would be extension of patterns

Analytics and its impact

• Previously system used to dump their data into tables without much consideration how its going to be used and table metadata is not much bothered about.

• Information Governance should be continuously monitoring what goes in is right if not only Garbage out. Hence this takes a great significance now.

Architectural Views

• 4 + 1 views would a nice place to start with since it helps us in understanding & validating from the view points of Logical correctness, Physical implementation and infrastructure capability.

• If the application is going to be part of SOA system nice to mention how it fits in SOA Blueprint which area and how it would be connected

Design Views

• Architectural view if it could be used to generate the Design model such as class & sequence diagrams some Industry best tools help us doing it. This help us in not missing anything

• In absence of Factoring or conversion of legacy system if there could be a inventory mapping to all the Architectural mapping to design elements it would be very ideal.

Big Ball of Mud

• As System evolves and design changes and rapid incremental changes comes in the design inventory , architecture blue print not referred.

• Addition of features are done based on code analysis and where the scope of object is available for making changes violating– Single Responsibility principle– Liskow substitution principle and othersWe have huge technical debt which makes the monolithic system difficult to change and maintain.

To be continued

• I am just sharing my experience in industry I have not touched on coding, testing and other areas intentionally would like to continue this journey of sharing my knowledge as an Architect.