1. Software Architecture Simplified
By
Prasad Chitta
Techno Functional Consultant

2. Agenda
Section1 - Section2 - Section3 -
Foundation Styles Standards

3. Software Architecture Foundation
• What is “software architecture”
– What is Software?
– What is Architecture?
• Why “Software Architecture” > software +
architecture?
• How “Software Architecture” contrasts and
compares with “Building Architecture”

4. Software, Architecture
• Software = that acquires, processes or presents
“data”
– Data = observed fact
– Appears as system, application, component, platform,
module etc.,
• Architecture = key decisions related to building
something NEW
– Vitruvius defines three principles - firmitas, utilitas,
venustas (durability, utility, beauty)
– Chiefly describes “structure of components” and their
“inter-relationships”

5. Software Architecture defined
• Architecture is the fundamental organization of a system embodied
in its components, their relationships to each other, and to the
environment, and the principles guiding its design and evolution.
[IEEE 1471]
– A system is a collection of components organized to accomplish a
specific function or set of functions. The term system encompasses
individual applications, systems in the traditional sense, subsystems,
systems of systems, product lines, product families, whole enterprises,
and other aggregations of interest. A system exists to fulfill one or
more missions in its environment. [IEEE 1471]
• A mission is a use or operation for which a system is intended by one or more
stakeholders to meet some set of objectives. [IEEE 1471]
– A stakeholder is an individual, team, or organization (or classes thereof) with interests in,
or concerns relative to, a system. [IEEE 1471]
– The environment, or context, determines the setting and
circumstances of developmental, operational, political, and other
influences upon that system. [IEEE 1471]

6. Software vs. Buildings
Software Architecture Building Architecture
Even after realization software is still After realization building is visible
invisible!
Durability means capability to adopt the Durability means capability to withstand
change the change
Software is dynamic and involves Buildings are static (no behavior!)
behavior
Aesthetics of software architecture Aesthetics of a building as well are non-
appear in non functional attributes of the functional
software
Goal is to achieve the purpose / function Same here…
of the software in most elegant manner
Multiple viewpoints from different Same here…
stakeholders

7. Viewpoints
Business
process Information
(logical / flow (data)
functional)
Application Deployment
(modules) (physical)
Software
A “Software Architecture” describes static and dynamic aspects of a system from multiple view
points for a common understanding between all the stakeholders involved.

8. Agenda
Section1 - Section2 - Section3 -
Foundation Styles Standards

9. Architectural Styles – a list
• Software is all about “data” and • Independent Components
its “processing” – Event Driven
• Data flow Styles include – Communicating processes
– Batch Sequential – Messaging Systems
– Pipes and filters • Publish Subscribe style
• Data Centered Styles – Peer to peer
– Repository
– Blackboard – Service oriented
– Shared nothing
• Virtual Machine
– Etc.,
– Interpreter
– Rule based
• Call & Return • Combining these basic styles,
– Main & Sub program heterogeneous and hierarchical
– Object oriented
architectural styles can be
derived
– Layered

10. Scenarios for Creating Architecture
• Descriptive Architecture
– “As is”
– Most of the times, a system exists, but the
architecture is not available in a usable format.
• Prescriptive Architecture
– “To be”
– A reference model is taken and style applied to
create a reference architecture, then a software
architecture and a system architecture are derived
from it.

11. But, Why?
• Non functional • Overall System • Other properties
Properties security and like portability,
visible at compliance flexibility,
runtime testability etc.,
Performance Security Portability
Creating an architecture considers the “quality attributes” beyond
functionality and usability. For the defined properties, different styles
provide proven and predictable results.

12. Good Architecture
• Focus on significant decisions
• Balances the conflicting stakeholder needs
• Optimizes available resources
• Considers scenarios from multiple view points
• And most importantly – evolves with the
environment!

13. Agenda
Section1 - Section2 - Section3 -
Foundation Styles Standards

14. Standards, Frameworks,
Methodologies, …
• Now we know, Software Architects produce “models” from
multiple viewpoints of a software considering various
functional and non-functional properties of the system.
• They use some well known styles, patterns which have
proven solutions for the common problems within the
domain of software solutions
• The overall process adds value to either building a new
software or modifying an existing software within an
enterprise.
• That means, multiple stakeholders need to understand the
architecture consistently across the globe in larger
organizations / enterprise.

15. List of Standards
• ISO 1471
• TOGAF
• DoDAF
• Etc.,
• Standards are good they give consistency of
notation
• Standards can be “open” or “closed i.e,
proprietary”
• Standards sometimes hinder the “creativity”

16. Framework, methodology
• A framework provides skeletal structure for
developing, documenting and visualizing the
architecture like templates etc.,
• Architecture development methodologies give
directives to build the architectures or review
the architectures by providing the checklists
etc.,

17. Agenda
Section1 - Section2 - Section3 -
Foundation Styles Standards

18. Human Aspects
• Practicing software architecture is just not a
science or engineering! It is an ART as well.
• Soft skills like interpersonal skills are very
important for an Architect
• Software Architecture influences and
influenced by the organization structure
• Sometimes it becomes political as well….

19. Case Studies
• Developing an elastic enterprise architecture
for a green field pensions provider on a pay
per policy model
• As is and To be architecture for a de-merger of
metering business from a gas utility
organization

20. Thank You
Reach Me on: http://www.linkedin.com/in/prasadchitta
Blog: http://technofunctionalconsulting.blogspot.com