Explained thoughts on how the Software development starts and evolves from requirement, Architecting and Designing

1. Art of creating good software
Prasad Narasimhan – Technical
Architect

2. 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.

3. 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.

4. 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.

5. 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

6. 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.

7. 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

8. 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

9. 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.

10. 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

11. 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.

12. 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 others
We have huge technical debt which makes the
monolithic system difficult to change and maintain.

13. 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.