Home‎ > ‎

Architecture

Here context is information technology not construction industry. Here are some terms most frequently used and their meaning IMHO.
Architect: Person responsible for defining architecture and its description.
Architecture artifact: Anything which describes some part or asepct of an architecture. For an example: models, analysis document, a report or any other document contributing in description of an architecture.
Architecture description: Set of artifacts documenting an architecture.
Architecture framework: A guide/structured information that suggests artifacts to be created and their relationship with each other.
Architecture methodology: An structured approach towards architecture. Methodologies were often defined and used to solve problems in an area.
Architecture process: Steps to produce architecture description and architecture.
Architecture taxonomy: A way to categorize and organize architecture artifacts.
Architecture: Organization of a system, its components and their relationship (to each other and their environment). Guiding principles on which system will be structured and will evolve.
Subscribe to posts

Non functional requirements in architecture

posted Feb 12, 2019, 6:38 AM by Jageshwar Tripathi   [ updated Feb 12, 2019, 2:04 PM ]

Architecture of software systems is driven by functional requirements, quality attributes and constraints.
Architect has to take design decision decompose a system as per requirements, lots of decisions are taken to handle quality attributes and limited by constraints. 

Focus on this writing is those decisions which are related to quality attribute (or NFRs). These decisions are often referred to as tactics (Bass et. al. 2003). A tactic is a design decision that contributes in addressing a quality attribute. Tactics influence architecture (structure and or behavior) but their impact in architecture may be smaller compared to patterns which majorly give share to structure of the software. Some of the tactics may be part of a pattern or in other words some of the tactics are applying pattern to achieve a quality attribute. 

Architecture methods provide a way to handle quality attributes. Some of the architecture methods are:
  • Viewpoints and Perspectives
  • Microsoft
  • Process of Software Architecting
  • ACDM
  • RUP
  • ADD
ADD (Attribute Driven Design) is one such method for defining architecture which focuses on quality attribute. 

Quality attributes

ISO/IEC 9126 (obsolete)

Functionality: Suitability, Accuracy, Interoperability, Security, Functionality compliance
Reliability: Maturity, Fault tolerance, Recoverability, Reliability compliance
Usability: Understandability, Learnability, Operability, Attractiveness, Usability compliance
Efficiency: Time behaviour, Resource utilization, Efficiency compliance
Maintainability: Analyzability, Changeability, Stability, Testability, Maintainability compliance
Portability: Adaptability, Installability, Co-existence, Replaceability, Portability compliance

ISO/IEC 25010:2011 (current)

Quality in use

  • Effectiveness, 
  • Efficiency, 
  • Satisfaction,
  • Freedom from risk
  • Context coverage

Product quality

  • Functional suitability
  • Reliability
  • Performance efficiency
  • Usability
  • Security
  • Compatibility
  • Maintainability
  • Portability

There are further sub categories within each of the above. 

CISQ (Software quality characteristics defined for code quality)

  • Reliability
  • Performance/Efficiency
  • Security
  • Maintainability

FURPS

  • Functionality
  • Usability
  • Reliability
  • Performance
  • Supportability

Interesting resources

1. How do architecture patterns and tactics interact? A model and annotation
http://www.cs.rug.nl/paris/papers/JSS10b.pdf
2. ADD 3.0: Rethinking Drivers and Decisions in the Design Process
https://resources.sei.cmu.edu/asset_files/Presentation/2015_017_101_438648.pdf
3. Decision Model for Software Architectural Tactics Selection Based on Quality Attributes Requirements
https://www.researchgate.net/publication/283953802_Decision_Model_for_Software_Architectural_Tactics_Selection_Based_on_Quality_Attributes_Requirements
4. Modeling Architectural Non Functional Requirements: From Use Case to Control Case
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.460.7189&rep=rep1&type=pdf
5. Rigorous Component-Based System Design Using the BIP Framework
http://www-verimag.imag.fr/~sifakis/RecentPublications/2011/ieee-software.pdf
6. Proposed Framework for Handling Architectural NFR’s within Scrum Methodology
http://worldcomp-proceedings.com/proc/p2015/SER3465.pdf
7. https://it-cisq.org/standards/code-quality-standards/
8. https://www.iso.org/obp/ui/#iso:std:iso-iec:25010:ed-1:v1:en
9. https://www.ibm.com/developerworks/rational/library/4706.html#N100A7
10. http://www.users.abo.fi/lpetre/SA11/SALecture2.pdf
11. https://resources.sei.cmu.edu/asset_files/TechnicalReport/2007_005_001_14858.pdf
12. https://resources.sei.cmu.edu/asset_files/TechnicalReport/2009_005_001_15101.pdf

Defining software architecture

posted Jan 29, 2019, 12:36 PM by Jageshwar Tripathi   [ updated Apr 7, 2019, 7:49 AM ]

Following basic principles are applied to define software architecture:
1. Identify drivers
The drivers can be functional requirements, quality requirements, constraints (e.g. expected schedule)
2. Define the strategy
Approach to structure software is identified. Use of architectural styles and patterns helps structuring the architecture.
3. Tradeoff analysis
Identify how the quality attributes will be achieved with use of strategies. Tradeoff analysis should be performed to prioritize quality attributes. 

Interesting resources

https://www.nasa.gov/pdf/637608main_day_2-david_garlan.pdf
https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=513862
(Views and beyond SEI CMU Template for SAD)
http://www.iso-architecture.org/42010/
(Comparison of Views & beyond template and ANSI-IEEE 1471-2000)
(Documenting Software Architecture in an Agile world)
(Conceptual model))
(Architecture frameworks table listing various frameworks)



Why software architecture

posted Jan 29, 2019, 12:28 PM by Jageshwar Tripathi

Software architecture provides an opportunity to translate requirements in to structure of the software keeping in mind the constraints.

Structure

Software architecture defines structure of the target software system. Functions expected in requirements are assigned to different components (in other words target system is decomposed into different components). To achieve desired functional requirements and achieve other requirements, relationship and interaction between these components is defined. 

Quality

Expected quality from the target system is defined and trade-off between different quality attribute is performed. Based on trade off analysis quality attributes are prioritized. 

Architecture principles

Strategies, structure, size and tools are identified to achieve those quality attributes. Architecture helps achieving quality requirements. Known strategies, architecture styles, frameworks are identified and applied to the target system definition. 


Architecture review checklist

posted Jan 20, 2019, 1:58 PM by Jageshwar Tripathi   [ updated Mar 25, 2019, 1:30 PM ]

Review of an existing system architecture or review of an architecture document of a system to be developed is often asked by project teams and architects have to conduct the review. A check list can help conducting review without forgetting important aspect of the architecture. It can also give a structured approach to the review process. Here is a check-list for architecture document :

  1. Are the major system goals clearly stated?
  2. Are architecturally significant requirements identified and documented?
  3. Are measurable non functional requirements explicitly defined?
  4. The overall organization of the system can be understood after reading the architecture document?
  5. Does document describe all relevant architectural views?
    1. Logical view (class diagram per component expresses functionality).
    2. Process view (how control threads are set up, interact, evolve, and die).
    3. Physical view (how system will be deployed. Deployment diagram
    4. Development view (how code is organized?)
  6. Does the document provide rationale behind architectural approach?
  7. Is build versus buy analysis done and decisions are drawn from it (for selection of tools, products)?
  8. Does the document provide recommended tools and technologies?
  9. Does the document provide rational behind selected tools and technologies?
  10. Does the document provide alternate solutions other than recommended one?
  11. Does document provide functional view (functional decomposition of the system?
  12. Is functional view driven by functional requirements?
  13. Are all functional requirements covered by functional view?
  14. Are modules identified and all the requirements covered by one of the identified modules?
  15. Are interface to other modules defined for all the identified modules?
  16. Is  there good balance of modules (sufficient but not too many)?
  17. Does architecture defined takes care of changeability?
  18. Does architecture describes how re-usability will be achieved?
  19. Does architecture takes care of "avoid chatty interfaces for remote calls" principle?
  20. Does architecture takes care of "don't repeat yourself" principle?
  21. Does architecture takes care of separation of concern (by layering or other styles)?
  22. Does architecture provides data access layer to hide the data storage implementation from business logic?
  23. Is database model defined in sufficient detail?
  24. Are all key objects identified?
  25. Does document defines how user inputs will be handled and it is efficient?
  26. Does document define user interface design strategy?
  27. Does document consider modular user interface design approach?
  28. Does document define error handling strategy in sufficient detail?
  29. Does document provide sufficient detail about how I/O will be handled? 
  30. Does document provide sizing information? 
  31. Does document provide modules wise resource requirements (estimates)?
  32. Does document describe how system will recover after events of failures?
  33. Does document consider projected growth of the system and future needs and defines how system will scale?
  34. Does document describe main stakeholders of the system?
  35. Does document describe users/actors of the system?
  36. Does document consider regulatory and compliance requirements if any applicable?
  37. Does document describe interfaces to any other systems (if applicable)?
  38. Does the document describe how the system will be integrated with other systems (if required)? 
  39. Is rational behind selections of tools/technology/method for integration provided in the document?
  40. Does document describe how will system handle the long running transactions to avoid performance hit ( specially in cases where transactions cross system boundary)?
  41. Does document describe (if required): how high availability will be achieved ?
  42. Does document describe how external access will be provided to the system (if applicable)?
  43. Does document describe release management strategy?
  44. Does document describe component descriptions at sufficiently & precise level?
  45. Does document describe relationships between the components?
  46. Are cross-cutting concerns described and how they will be handled?
  47. Does document describe how initialization and reset will be performed?
  48. Is security design described?
  49. Does architecture define (if applicable,) how Internationalization (I18N) will be taken care of?
  50. Does document describe user help?
  51. Does document describe test strategy?
  52. If applicable, does document describes migration strategy?
  53. If applicable, does document describe  data loading strategy?
  54. Is system designed with low complexity?
  55. Is system designed with high cohesiveness ? (Every component has single responsibility)
  56. Is system designed with low coupling? (Components don't depend on internal detail of other component, abstraction is used)
  57. Is system designed with low fan-in and low fan-out?

Software Architecture Evaluation Methods

posted Jan 15, 2019, 12:54 PM by Jageshwar Tripathi   [ updated Jan 15, 2019, 12:55 PM ]

Early methods

 There methods are applied for evaluation of software architecture before implementation. Software architecture is evaluated based on quality requirements at the early stage of development and if specification of architecture takes care of quality requirements quality objectives can be achieved. There are scenario based and mathematical model based methods. 
SAAM (Scenario based Software Architecture Analysis Method) 
ATAM (Architecture based Tradeoff Analysis Method) 
ALPSM (Architecture Level Prediction of Software Maintenance) 
ALMA (Architecture Level Modifiability Analysis)
CBAM (Cost Benefit Analysis Method)
FAAM (Family Architecture Assessment Method) 
SALUTA (Scenario based Architecture Level UsabiliTy Analysis) 
SBAR (Scenario Based Architecture Reengineering)
SAAMCS (SAAM for Complex Scenarios)
ESAAMI (Extending SAAM by Integration in the Domain)
ASAAM (Aspectual Software Architecture Analysis Method)
SACAM (Software Architecture Comparison Analysis Method)
DoSAM (Domain Specific Software Architecture Comparison Model)

Late  methods

These methods identify the difference between the implemented and planned architectures. 
Tvedt et al.'s Approach
Lindvall et al.'s Approach 
Fiutem and Antoniol's Approach (Tool based) 
Murphy et al.'s Approach (Tool based) 
Sefika et al.'s Approach (Tool based) 

Interesting resources

1. https://resources.sei.cmu.edu/asset_files/TechnicalReport/1998_005_001_16646.pdf (this one os old)
2. https://resources.sei.cmu.edu/asset_files/TechnicalReport/2000_005_001_13706.pdf (this one is new)
3. http://lore.ua.ac.be/Teaching/CapitaMaster/ATAMmethod.pdf
4. https://www.win.tue.nl/oas/architecting/aimes/papers/Scenario-Based%20SWA%20Evaluation%20Methods.pdf
5. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.258.6953&rep=rep1&type=pdf
6. https://www.infoq.com/articles/ieee-pattern-based-architecture-reviews

What is software architecture?

posted Jan 14, 2019, 1:36 PM by Jageshwar Tripathi   [ updated Apr 7, 2019, 6:50 AM ]

There is no agreed definition of "architecture" in the IT industry. The subject was researched and introduced primarily at institutes likes SEI CMU and many authors contributed in definition of the discipline, later some of the organizations like IEEE tried adopting the subject and came up with some definitions. In this case we can't ignore authors, researchers, those organizations but this creates problem of no single standard. Industry and practitioners at the other hand had been coining their own terms due to lack of single standard body, and in practice it takes shape based on needs of various organizations in he industry. 

Simple definition of software architecture?

In simple words software architecture is organization of a system, its components, their relationship with each other and the environment around it. 
This organization of the system is driven by some principles based on which design of the system is achieved and these principles are used to evolve the system.
System may be set of applications or a subsystem or systems of sub systems or whole organisation. Environment influences the system. System System contributes in fulfillment of one or more objectives of stakeholders. Stakeholder may be an individual, group of people or an organization who have interest in the system.

Components in software architecture

Formal definition of component with respect to architecture is not strictly defined so it can be logical or physical, coarse grained or fine grained, technology specific or technology neutral. UML standard has a definition of a component with respect to UML scope. I recommend (and in practice they way people use it) to consider components  as basic building blocks of a system and these building blocks may fulfill a set of features or cover specific aspect of the system in question (this aspect may be related to  functional or non-functional requirements). Why I hesitate to take lower level technology specific artifacts as components at architecture level is because if they are considered here what will be the difference between scope of architecture and design. 

Prescriptive, descriptive and and implemented architecture

There are three context in which word architecture is mentioned:

1. Prescriptive

When architecture of a system going to be developed is defined. In this case what is produced should be considered as blueprint of target architecture. Often people are confused with the term and consider diagrams or a document as architecture but that is not the case. A document or diagram provides a way to communicate the target architecture but the architecture is structure of a system which is built. During identifying target architecture of a new system or system under transformation, important decisions are to be taken and documented in the document often called Software Architecture Document. This is the blueprint of the target architecture. Some authors call is prescriptive architecture because a target architecture is prescribed.

2. Descriptive

When architecture of an existing system is defined in a document, it is called descriptive architecture because it describes architecture of an existing system. A prescriptive architecture document may become descriptive if it is in sync with the system evolution and system is built, at that time an existing document describing its architecture is considered as descriptive or as is architecture document. 

3. Architecture of a system in running state

Architecture of an existing system or actual system structure with its behaviors and attributes and this is what is prescribed or described in the documents. This is actual architecture like we see in monuments and buildings.  Even if there is no document, architecture of a system exists.

Enterprise Architecture and other terms

There are couple of terms which have word architecture with them: 
Enterprise Architecture, Segment Architecture, Solution Architecture
Enterprise Architecture, Solution Architecture, Technology Architecture
Enterprise Architecture, Business Architecture, Application Architecture, Data Architecture, Technology Architecture
Information Architecture and Information System Architecture.
These terms are often used with Enterprise Architecture, scope of which is wider than software architecture. It is not limited to information technology or software but EA covers whole enterprise its vision, business, people, processes and IT is any. 
When it comes to standard, the first well known standard in the field of software architecture and system architecture was IEEE 1471, approved in 2000. Latest version of it is known as ISO/IEC/IEEE 42010:2011

Software architecture key drivers

Architecture drivers are those key factors which influence architecture of the system. 
  • Functional requirements
  • Constraints (business and technical), and 
  • Quality attributes 
Constraints are design decisions already made for the designers:
Examples of business constraints can be: Targeted market, time to market, cost, schedule constraints, human resources
Examples of technical constraints can be: An existing system to integrate the current system with, compatibility with older versions of software, operating system, existing hardware, network, software products, protocols, interfaces and standards. Constraints are those factors you don't have control up on and you will have to define the architecture considering limitations put forward by these constraints. 

Note: A side note about architecturally significant requirements: there are various sources of them such as requirement document itself, captured from a stakeholder from an interview or workshop and business objectives.

Interesting resources

https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=513862
(Views and beyond SEI CMU Template for SAD)
http://www.iso-architecture.org/42010/
(Comparison of Views & beyond template and ANSI-IEEE 1471-2000)
(Documenting Software Architecture in an Agile world)
http://www.informit.com/articles/article.aspx?p=2738304&seqNum=4
http://www.neverletdown.net/2014/10/architectural-drivers.html
https://www.slideshare.net/NghiaLe36/architectural-driver
https://www.linkedin.com/pulse/software-architecture-drivers-konstantinos-bakopanos/
Software Architect Handbook (https://books.google.co.in/books?id=6EZsDwAAQBAJ)
http://www.cs.uu.nl/docs/vakken/ie/ppts/ICTE06-Architecture.pdf

Fundamentals to Modern Day: Software architecture

posted Dec 3, 2018, 6:46 PM by Jageshwar Tripathi   [ updated Jan 26, 2019, 6:39 AM ]

Software architecture is not too old discipline compared to programming. Few years back it was considered as emerging discipline and since it was emerging, lots of things are added: new definitions, new scope and subjects. The way software were developed in 90's is different than the way they are developed now in year 2019. Tools, platforms and frameworks have changed and it has an impact on the way people used to perceive software design and architecture. Now you will have to consider modern days platforms, tools and opportunities while defining your architecture, still basic fundamentals of architecture and design remains same. One need to build his knowledge from basics to advanced new concepts. I have tried listing topics which needs to be learnt by some one who is interested to learn Architecture in IT/Software. This is to help those who wants to be an architect and the scope here is not enterprise architecture:

Architecture

Basic concepts and definitions

  1. What is covered in SAD (Software Architecture Document)?
  2. What is software architecture
  3. Why it is important to focus in architecture?
  4. IEEE 1471-2000 Recommended practice for description of architecture intensive system
  5. Views & view point
  6. 4+1 view
    1. Describe the use of each view
      1. Audience:
      2. Area: 
      3. Related Artifacts:
  7. C4 Model
  8. Different aspects (Business/Functional/Information/Solution/UX architecture)
  9. Architectural styles & architectural patterns
  10. Quality Attributes
    1. Availability
    2. Interoperability
    3. Modifiability
    4. Testability
    5. Usability
    6. Performance (performance and scalability)
    7. Security
    8. Robustness
    9. Adaptability
  11. Architecture trade off analysis method (ATM)

Defining architecture

  1. Identify and prioritize use cases
  2. Describe the functional requirements with a significant impact on the architecture (architecturally significant requirements
  3. Describe the architectural constraints of the system
  4. Define context level architecture as is and to be (Identify key abstractions)
  5. Describe the layers and subsystems of the application
  6. Tool & technology selection
  7. Build versus buy analysis
  8. Describe the most important use-case realization. Will contain the Analysis Model and the Design Model
  9. Describe design’s concurrency aspects
  10. Describe how the system will be deployed. Will contain the Deployment Model
  11. Describe any significant persistent element. Will contain the Data Model
  12. Describe any performance issues and constraints
  13. Describe any aspects related to the quality of service (QoS) attributes
  14. Rationale and Justification for Architectural Approach

Architecture review

  1. Troubleshooting issues in code, design and architecture
  2. Architecture review

Architecture in modern days context

  1. Architecture for Microservices
  2. Architecture for Big data and NoSQL
  3. Architecture in Cloud
  4.  Architecture for mobile applications
  5. User Experience 
  6. Integration techniques and architecture
UML Modeling
  1. Use case
  2. Sequence
  3. Collaboration
  4. Class diagram
  5. Data flow
  6. Activity diagram
  7. Data model
  8. Business process modeling
Object Oriented Analysis
  1. Analysis Model 
  2. Use case model
  3. Domain object model,
  4. Structures: generalization specialization, aggregation, hierarchies, 
  5. Attributes and behaviors (services)
  6. Principles
  7. Best Practices

Object Oriented Design

  1. Object responsibility assignment principles
  2. Use case realization (sequence and collaboration)
  3. Identifying software classes to achieve loose coupling, cohesiveness and other quality requirements
  4. Design patterns
  5. Best Practices

Implementation

  1. Translating design to code
  2. Coding best practices
  3. Continuous integration and testing
  4. Static analysis 
  5. Code smell

Deployment

  1. How to be ready for deployment from day 1: Avoid pitfalls of being in development mode
  2. Different deployment options
  3. Switching from development to deployment mode
  4. Cloud, Virtualization and Container based deployment
  5. Dev-Ops

Interesting resources

SAD (Software Architecture Document) Template:
https://wiki.sei.cmu.edu/sad/index.php/Software_Architecture_Documentation_Template
http://sce.uhcl.edu/helm/rationalunifiedprocess/webtmpl/templates/a_and_d/rup_sad.htm
http://sce.uhcl.edu/helm/rationalunifiedprocess/examples/csports/ex_sad.htm
http://www.ecs.csun.edu/~rlingard/COMP684/Example2SoftArch.htm

What is software architecture?:
https://www.ibm.com/developerworks/rational/library/feb06/eeles/index.html

Why is it important to focus in software architecture?:
http://csse.usc.edu/GSAW/gsaw2003/s13/northrop.pdf
https://sites.google.com/site/softwarearchitectureinpractice/2-what-is-software-architecture/2-4-why-is-software-architecture-important

IEEE Recommended Practice for Architectural Description of Software-Intensive Systems
http://cabibbo.dia.uniroma3.it/ids/altrui/ieee1471.pdf
http://iea.wikidot.com/ieee1471
https://en.wikipedia.org/wiki/IEEE_1471

Views and view points
https://iasaglobal.org/itabok/capability-descriptions/views-and-viewpoints/
http://www.mit.edu/~richh/writings/hilliard99-ifip.pdf

4+1 views
https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf
https://en.wikipedia.org/wiki/4%2B1_architectural_view_model
https://www.coursera.org/lecture/software-architecture/3-1-2-kruchtens-4-1-model-view-z65ZO
https://softwareengineering.stackexchange.com/questions/233257/mapping-between-41-architectural-view-model-uml

C4 Model
https://c4model.com/

Architectural styles and architecture patterns
https://techbeacon.com/app-dev-testing/top-5-software-architecture-patterns-how-make-right-choice

Software architecture review:
https://www.slideshare.net/NASAPMC/danieldvorak
http://lore.ua.ac.be/Teaching/CapitaMaster/ATAMmethod.pdf
https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=513908



Certifications related to architects

posted Nov 11, 2018, 3:24 PM by Jageshwar Tripathi   [ updated Dec 4, 2018, 3:23 AM ]

Certifications

Enterprise & IT Governance

  • TOGAF Certified Enterprise Architect
  • COBIT 5 training and certification (4 different exams)
  • Zachman Certified - Enterprise Architect

Cloud

  • AWS Certified Solution Architect 
  • Google certified professional (Cloud Architect)
  • IBM Certified Solution Architect - Cloud Computing Infrastructure V1
  • IBM Certified Solution Advisor - Cloud Computing Architecture V4
  • MCSE: Cloud Platform and Infrastructure

Specialist

  • Oracle IT Architecture Release 3 Certified Architecture Specialist
  • Oracle Certified Master, Java EE 6 Enterprise Architect
  • Oracle Application Integration Architecture 11g Certified Implementation Specialist
  • Oracle IT Architecture BPM 2013 Certified Architecture Specialist
  • Oracle IT Architecture SOA 2013 Certified Architecture Specialist
  • Cisco certified architect (for Cisco technologies not a generic one)
  • Red Hat® Certified Architect (RHCA (Upon obtaining either RHCE or Red Hat Certified JBoss Developer
  • MCSE: Mobility, MCSE: Data Management and Analytics
  • Pega Systems: Certified Lead System Architect, Certified Senior System Architect, Certified Pega Business Architect
  • CISSP-ISSAP: Information Systems Security Architecture Professional
Note: Some of the certifications are provided by IASA which was earlier known as International Association of Software Architects and now it claims that is is an association of All IT Architects. 
Certified IT Architect - *
where * may stand for: Foundation (CITA-F), Associate (CITA-A), Specialist (CITA-S), Professional (CITA-P)
IASA has published something called "IT Architecture Body of Knowledge" ITABoK. For more detail click here.

Courses and/or certifications from other sources

Graduate Certificate in Software Architecture: University of South Carolina
https://viterbigradadmission.usc.edu/programs/masters/msprograms/computer-science/grad-cert-software-architecture/

SEI Software Architecture Professional Certificate: Carnegie Mellon University, Software Engineering Institute
https://www.sei.cmu.edu/education-outreach/credentials/credential.cfm?customel_datapageid_14047=15203

Software Design and Architecture Specialization: University of Alberta through Coursera
https://www.coursera.org/specializations/software-design-architecture

Following are some online courses:
Free course Software Architecture & Design by Georgia Tech through Udacity platform
https://in.udacity.com/course/software-architecture-design--ud821
Free course The Software Architect Code: Building the Digital World at edX
https://www.edx.org/course/the-software-architect-code-building-the-digital-world-0

Interesting resources

1. https://www.zachman.com/certification/certification-overview
2. https://ce.uci.edu/pdfs/brochures/software_architect.pdf
3. https://online.usc.edu/programs/graduate-certificate-in-software-architecture/
4. https://www.sei.cmu.edu/education-outreach/credentials/credential.cfm?customel_datapageid_14047=15203
5. http://www.opengroup.org/certifications
6. https://www.arcitura.com/soa-school/
7. https://www.redhat.com/en/services/certification/rhca
8. https://aws.amazon.com/certification/certified-solutions-architect-associate/
9. https://www.microsoft.com/en-us/learning/azure-exams.aspx
10. https://education.oracle.com/oracle-it-architecture-release-3-certified-architecture-specialist/trackp_131
11. https://education.oracle.com/oracle-certified-master-java-ee-6-enterprise-architect/trackp_212

Books for aspiring architects

posted Oct 23, 2018, 8:10 AM by Jageshwar Tripathi   [ updated Nov 11, 2018, 2:57 PM ]

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

Author: Craig Larman
Category: Design
Level: Foundation
Suitable for: Beginner
Review: This is very practical and useful book. It takes you through life cycle of a project, teaches you how to do OOAD and also talks about use of patterns and UML. It was written long time ago but the material in the book has great depth. For some readers (who have less patience) reading may be very slow. Lots of patience is required to read and grasp the content. 
Rating: 4.9/5

Beyond Software Architecture: Creating and Sustaining Winning Solutions

Author: Luke Hohmann
Category: Architecture
Level: Advanced
Suitable for: Expert
Review: This is not a book for those who are aspiring to be an architect. This is for senior level people and even for techno managerial roles or solution architects. 
Rating: 4.2/5

Building Microservices: Designing Fine-Grained Systems

Author: Sam Newman 
Category: Architecture
Level: Advanced
Suitable for: Intermediate
Review: It covers the concepts behind Microservices and good for senior level people. The book not only covers Microservices but also discusses modern distributed systems architecture. This may be good for some readers but may not be liked by focused developers. Those who are focused in coding may be disappointed to see the book has not given them lots of  examples on how to implement code for Microservices. 
Rating: 4.1/5

Clean Architecture: A Craftsman's Guide to Software Structure and Design

Author: Robert C. Martin
Category: Architecture
Level: Advanced
Suitable for: Intermediate/Expert
Review: Suitable for senior level executives which can help them taking care of lots of things in their decision making or defining solution. It is not suitable for beginners or those who need specialized stuff on how to do the stuff. It brings lots of ideas around the subject which may be interesting and important for senior level executives but it will not teach you at detailed level how to create architecture deliverable. 
Rating: 4.1

Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation 

Author: Jez Humble, David Farley
Category: Continuous Delivery
Level: Advanced
Suitable for: Intermediate/Expert
Review: The book has redundancy/repeated concepts which may not be liked by some readers. The book has couple of good ideas but a modern developer may see there are tools now to deal with many things. 
Rating: 3.6/5

Design Patterns: Elements of Reusable Object-Oriented Software

Author: Erich Gamma et al. 
Category: Design
Level: Foundation
Suitable for: Beginner
Review: The only negative word about this book is it was published ages back. Still the same patterns are applicable today. It was the first of its kind book the original work published by authors and many others (copy cat) thought of writing books after seeing this book later. Great book if you are not already familiar with the patterns in this book.
Rating: 4.7/5 

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

Author: Martin Kleppmann
Category: Architecture
Level: Advanced
Suitable for: Expert
Review: Full of concepts and theory. Instead of depth it covers breadth. Often people coming from programming background become architects and data side of their understanding is less, if this is the case you should read this book. At the end book may feel slow. You may also find that it could have been written in lesser number of pages but that is a different thing.  
Rating: 4.5/5

Documenting Software Architectures: Views and Beyond

Author:  Paul Clements, Felix Bachmann , Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord, Judith Stafford
Category: Architecture
Level: Advanced
Suitable for: Expert
Review: Before reading this book you should read a foundation book on software architecture. You should also know what is the difference between architecture and design before reading this book. Objective of the book is to give you an idea how architecture should be documented. If you have already read this subject and core subject of software architecture, this book may look like repeating the same thing but for those who have never worked as an architect and don't know how to document software architecture this can be a good read. 
Rating: 4.3

Domain-Driven Design: Tackling Complexity in the Heart of Software

Author: Eric Evans
Category: Design
Level: Foundation
Suitable for: Beginner/Intermediate
Review: Good book with practical information about how to model domain objects and translate requirements to design.
Rating: 4.5/5

Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions

Author: Woolf, Hohpe 
Category: Architecture
Level: Advanced
Suitable for: Expert
Review: Good book about enterprise integration patterns. There are concepts now well known but for a first time reader it provides sufficient catalog.
Rating: 4.2/5

Essential Software Architecture

Author:  Ian Gorton
Category: Architecture
Level: Foundation
Suitable for: Beginner
Review: This book had tried coping up with the trends at the time this book was written (but those trends are past now), in this effort sometimes depth is lost. The book teaches basics of software architecture but if you have already got other books on the same subject you may not find everything new here.
Rating: 3.7/5

Implementing Domain-Driven Design

Author: Vaughn Vernon
Category: Design
Level: Advanced
Suitable for: Expert
Review: It is verbose. Covers DDD very well as well as written in light of modern concepts REST, Agile etc. Since I read another book and content on the subject I found it to be at 4.2 out of 5.
Rating: 4.2/5

Just Enough Software Architecture: A Risk-Driven Approach

Author: George H. Fairbanks
Category: Architecture
Level: Intermediate
Suitable for: Experts
Review: You need to know some very basics before reading this book. What is enough software architecture means how much modeling to do for architecture, if this is what I expected I got it here. I was trying to find risk driven point but I was not able to get the point. May be I missed the point or author. 
Rating: 4.2/5

Object-Oriented Design Heuristics

Author: Arthur J. Riel
Category: Design
Level: Foundation
Suitable for: Beginner/Intermediate
Review: It is a good read. All the heuristics may not be 100% applicable in all the cases which book didn't clearly mention and the reader should apply his brain/knowledge/experience. If you have got good understanding of the subject object oriented design, you can read this book as next content to refer to. Heuristics are not defined in a consistent format which is a missing point. Other books on object oriented design talk about basics but often developers have lots of questions and this book can serve as FAQ for those developers. Heuristics are heuristics, rules of thumb or guidelines which may be very useful in many situations but there may be some exceptions too. I recommend you read this book in you are a beginner. 
Rating: 4.4/5

Pattern-Oriented Software Architecture Volume 1: A System of Patterns

Author: Frank Buschmann, Regine Meunier , Hans Rohnert , Peter Sommerlad , Michael Stal 
Category: Design
Level: Foundation
Suitable for: Beginner
Review: Architecture Styles are described as Architecture Patterns. It may be confusion but this is how industry is. It covers basic architectural styles which are age old. It also has a chapter on design patterns, again those age old patterns. Book was also written ages back so nothing bad about it. It is just a hint that if you have already read all this stuff there is noting new but if you have never read a book on styles and design patterns you can read this book.
Rating: 4.1/5

Patterns of Enterprise Application Architecture

Author: Martin Fowler
Category: Architecture
Level: Advanced
Suitable for: Expert
Review: I liked this book because it has something which was not covered in ages old books on patterns. The problems an enterprise application developers face in day to day life. But this one was also written many years back and enterprise applications are different in many ways. Instead of "enterprise architecture" consider patterns for developers otherwise you may get disappointed. Lots of focus is on object relational mapping and database access stuff. The book is good but not great. Never compare with classic GOF patters book. 
Rating: 4.2

Reactive Design Patterns

Author: Roland Kuhn Dr., Brian Hanafee, Jamie Allen
Category: Design
Level: Foundation
Suitable for: Beginner
Rating: 3.2/5

Refactoring in Large Software Projects: Performing Complex Restructurings Successfully

Author:  Martin Lippert, Stephen Roock
Category: Code
Level: Advanced
Suitable for: Experts
Review: It is good book on the subject. There are other good boots out there so check and compare before selecting one. 
Rating: 3/5

Software Architecture in Practice 

Author: Len Bass, Paul Clements, Rick Kazman
Category: Architecture
Level: Foundation
Suitable for: Beginner
Review: Get it's latest edition because the book dates back to many years. It is a good book, one of the most loved and known on subject of Architect. 
Rating: 4.4/5

Software Architecture Patterns

Author: Mark Richards
Category: Architecture
Level: Foundation
Suitable for: Beginner
Rating: 3.7/5

Software Architecture: Foundations, Theory, and Practice

Author: R. N. Taylor, N. Medvidovic, E. M. Dashofy
Category: Architecture
Level: Foundation
Suitable for: Beginner
Rating: 4/5

Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

Author: Nick Rozanski and Eóin Woods
Category: Architecture
Level: Foundation
Suitable for: Beginner
Rating: 4.3/5

The Process of Software Architecting

Author: Peter Eeles and Peter Cripps
Category: Architecture
Level: Foundation
Suitable for: Beginner
Rating: 3.5/5

How to investigate performance issues in software?

posted Sep 29, 2018, 1:18 PM by Jageshwar Tripathi   [ updated Dec 1, 2018, 10:06 PM ]

Performance is one of the most important quality attribute of software systems. Often issues related to performance are reported/detected late and in that situation finding the root cause is very important. Without a clear approach often project teams keep looking at random places and try to apply random solutions which don't work. 

Few common types of performance issues reported

First of all understanding difference of following is very important which is often given name of performance issue in general:

Response time

When response of the application is so much time taking that it becomes difficult for a user to perform his tasks efficiently. Definition of good response time if not specified in requirement specification leads to argument. Expecting any response time is not reasonable. 

Some of the companies for their internal web applications adapt 2 second for login page, 9 seconds for other normal pages, 2 seconds for data base queries to execute at maximum. This is not a world wide standard and it can't be because an application may be self contained and independent but another may be dependent on other systems beyond its boundary to complete its own responsibilities. 

Important thing to consider is factors like network latency, response time from a dependent system or database before blaming an application for poor performance. 

Reasons behind poor response time

  • Network
  • Hardware
  • Software (which may be due to wrong architecture, design or code algorithm)

Scalability

This is the case when an application works fine in normal user load but it starts taking more time in response, stops responding or crashes when user load increases. 

Sometimes teams want to solve this problem by increasing the resources like memory or adding more node (scaling horizontally) but this may not solve the problem forever if there is something wrong in the architecture, design or code. 

Reasons behind scalability issues

  • Hardware
  • Bad architecture & design 
  • Code

Availability

System crashes at certain point of time or after some time. Some times is is just robustness issue which may expressed as performance issue by the users but some times it is not due to robustness but due to performance issues. 

Reasons behind availability issues

  • Memory leakage in code
  • Robustness of application due to issues in code
  • Hardware
  • Network

How to investigate performance issues in software application?

Before moving to conduct investigation there are few questions which need to be clearly asked and answered because often the performance issue reported by an end user gets diluted by the time it reaches an architect or developer. 
As part of the investigation too couple of questions needs to be answered. 

Questions to answer

  • How many users can work on the application with comfort?
  • What is the maximum, minimum and average user load? What is the number of concurrent as well as total in a day or so.
  • Which use-cases/scenarios have performance problem?
  • What is performance problem?  Examples are: Long initial loading, response on subsequent requests or server not able to cater to high volume of users?
  • What are these numbers (takes 5 minutes to load or subsequent requests take 3 minute, server crashes if users reach to 25 concurrent?
  • What are the server statistics right now? Total and used during memory during peak load. What is the processor utilization during peak load? 
  • What is the performance, application is designed for?
Most of the performance issues lie in database and network round trip. The network round trip may be from application layer to database or application communicating with other systems beyond its boundary. Hence any investigations should start with one of these areas (assuming capacity and latency related investigations are already conducted and it is sufficient)

Investigation for response time

Step 1: Database investigation

What to do? 

  • Database profiling
  • Static review of the DB code (automated + architect)

How to do?

  • Static  Analysis of code (DB) 
  • Database Architecture  review e.g. db queries/PLSQL, indexes, configuration.
  • DB Profiler /Tracing on. Tool available with MSSQL or Oracle

Examples checks

  • Time taken by queries to return the results in single user and concurrent user scenarios.
  • Checking whether right type of indexes are used properly. 
  • Queries are not going in full table scan. Cartesian products are not the result of queries where we intentionally don't want it.
  • Indexes are not made in a table column which is frequently updated. If such an index is created every now and then re-indexing will be done by DB and it will impact the performance of the DB.
  • Select * is not happening without need. (It must be avoided as much as possible)

Example recommendations

  • Use indexes on columns which are used in queries
  • Use joins instead of simply merging two queries which are making Cartesian product. 
  • Avoid too many indexes which are not used
  • Avoid select *

Step 2: Web/App Server side investigation

What to do?

  • Static review of the code for architecture design and code
  • Performance testing per scenario
  • Memory profiling 
  • Statistics of the system (processor utilization, memory utilizations etc)

How to do?

  • Static Analysis Tools
  • Profiler
  • Architect review

Example checks

  • Remote calls in loops
  • Common data is fetched each time from the database server or kept in user sessions which is bad.
  • Lots of data is kept in session scope
  • Pagination technique is used properly.
  • Chatty remote interfaces accessed from client side code (e.g. Angular layer accessing remote Rest services which are just wrapper of fine grained objects making couple of round trips for an operation.  
  • Fine grained access of database from server side code is minimum

Example recommendations

  • For coarse grained access from client, server side can provide Synthetic coarse grained objects wrapping fine grained objects
  • Avoiding remote method invocations as much as possible by software architecture changes.
  •  Make use of batch queries, prepared statements etc
  • Use caching for common data across application
  • Avoid heavy session state
  • Use pagination techniques (but don't load all the data to paginate in one go and don't keep it in session)
  • Co-located app and db service and having multiple nodes of such servers if we don't have any other choice left. In co-located scenario horizontal scalability is not possible (multiple nodes of collocated servers).

Step 3 : Client side investigation

What to do?

  • Static review of the code 
  • Network communication 

How to do?

  • Static Analysis Tools
  • Browser console/tools
  • Architect review

Example checks

  • Check if client side code is making multiple calls to remote services for a single operation.
  • In Angular: Watchers, $watch(), ng-repeat are expensive 

Example recommendations 

  • Java webstart in place of applets to avoid every time loading of the applets if this is the case (again even converting applets to standalone client will be a tricky task). These are ages old scenarios and hard to find in today's world
  • To avoid network round trip, fine grained access can be converted in to coarse grained access of the server side (if there is any such opportunity, in most of the cases this is already taken care of)
  • Thin client with RIA frameworks. 
  • If you are using UI/UX framework you must need to refer to best practices related to the framework for example  prefer $watchCollection() instead of $watch(),

Investigation for scalability

What to do?

  • Load Testing
  • After load test, architect review and even static analysis may be required to find out the root cause of scalability limitations found by load testing. 

How to do?

  • Load Runner or similar
  • Jmeter (open source)
  • OpenSTA
  • Manual testing scenario for small user load (when purpose is initial investigation only)
  • Architect review

Example recommendations

  • Architecture changes
  • Adding more nodes (clustering and load balancing etc.)
  • Adding more resources and going to 64 bit if 32 bit architecture is the limitation due to which we cannot add more resources.

Fact collection

Collection of facts is important for an architect to find the solution of performance and provide recommendations. Here are some sample formats of fact collection templates:

Define performance objectives

Please describe in measurable units, goals or objectives of performance:
Normally this should be part of non functional requirements of the specification. These are the needs of application owner/users.

Expected Response Time

 S.No.  Scenario/page   Response time in seconds
 1    
 2    

Throughput

 S.No.  Req/second  Transaction/second  bytes/second
 1      
 2      

Resource utilization

 S.No.  % CPU Utilisation  % Memory Utilisation  Network IO
 1      
 2      

Workload

 S.No.  Data volume  Transaction volume  Types of transactions
 1      
 2      

Key scenarios

 S.No.  Scenario  Description
 1    
 2    

Gather inputs from various teams

Application development/management team

S.No. Questions Answer
1 What is the performance problem?
2 Is it initial loading of the page or application which is slow?
3 Is every request to a page or scenario too slow? Which scenarios?
4 Is server crashing/going down/unavailable often?
5 If answer to Q4 is yes, with how many users server crashes?
6 If answer to Q4 is yes, does it happen when specific page/scenario is accesed?
7 Is caching used in DB access layer of the application?
8 Is caching used in application layer?
9 Is application using an ORM Tool?
10 Is pagination implemented in application?
11 If pagination done, is it getting page data every time from database or session?
12 Is remoting (RMI, RemoteEJB, .NET Remoting) used in application?
13 Is application server colocated with database server in the same machine/subnetwork?
14 Is loadbalancing used in the system? Hardware or software load balancing?
15 Is table partitioning used?
16 Are there long running transactions? Payment gateway or accessing many systems?
17 Are there federated transactions?

IT operations team

Inputs related to user load
S.No. Load type Concurrent Per day (any time in a day) Dominating scenario/usecase
 1  Maximum no of users      
 2 Minimum number of users    
 3  Average number of users (most common)      
 4  Maximum no of concurrent user load beyond which performance problems appear      

Inputs related to data volume

Inputs related to various systems

S.No. Web/App/DB Server Software
/Application deployed		 Application technology Physical Memory Processor Type of Hard Disc Memory Utilisation Processor Utilisation

Average Peak/Max Average Peak
 1                    
 2          

Business users

Information about poor performing scenarios
S.No. Use Case/Scenario Problem Time to complete scenario
Max Most Common Min
1
 2          

Testing team

Results of performance testing of various scenarios/screens/transaction
S.No. Page/Screen/Transaction Time to load/Response time in second
Max Average Min
 1        
 2        

Database management team (DBAs)


S.No. Usecase Query/Procedure Query/Proc execution time in second
Max Average Min
 1     
 2     

Interesting resources

  1. https://ieeexplore.ieee.org/document/5752531
  2. https://cdn.oreillystatic.com/en/assets/1/event/134/Forensic%20tools%20for%20in-depth%20performance%20investigation%20Presentation.pdf
  3. https://www.datadoghq.com/blog/monitoring-101-investigation/
  4. https://support.solarwinds.com/Success_Center/Server_Application_Monitor_(SAM)/SAM_Documentation/Server_Application_Monitor_Getting_Started_Guide/040_Monitor/Investigate_application_performance_with_Performance_Analysis
  5. https://techbeacon.com/perfguild-5-insights-your-performance-testing-team
  6. https://www.comparitech.com/net-admin/application-performance-management/

1-10 of 14