If you ever asked someone or thinking aloud as to why a project initiative need an Architecture, then you should continue reading this post. Kewl, you are not alone.
Why Architecture?
It is a tricky question that might have varied and complex answers. This was my first question too when i joined as a fresher but my curiosity didn’t stop there and below questions kept popping up and I decided to explore further.
Architecture
What is it?
What does Architecture really address?
What are those boxes and arrows?
What are the governing architecture principles?
Who reads it?
Who cares for it?
I’m here today who truly believes and appreciates the necessity of ‘Software Architecture’ for modern business to innovate.
Ok, let me try and answer ‘What is Architecture’ in this post.
What is Architecture?
Industry Definition: 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. Usually captured as diagram.
My Definition: A shared understanding among various team members (business, product, development, operations) about an application or a set of applications, more often observed as delivery platform, that drives business by innovating and delivering capabilities that are robust, built flexibly – open for extension, composable by nature, and can be orchestrated to produce an optimal solutions to deliver a software product for the end business users.
Two Kinds of Architecture
#1) Traditional Architecture (a.k.a Waterfall Software Architecture)
Main Features
- Focus on big picture
- Compliance-Oriented
- Produces Blueprints
- Not much hands-on experience
#2) Agile Architecture (a.k.a Modern / Capability or Enabler Platform / Service-Oriented / Microservices Architecture)
Main Features
- Focus on big picture and now
- Hands-on Experience
- Produce reference-architecture (prototypes, if deemed necessary)
- Focus on sustainability (Dev Team buy-in)
What does Architecture really address?
It really depends on the software product but below fitness functions are generally considered. Usually covers Cross-Cutting concerns such as error detection, data validation, persistence, transaction processing, information security, caching, logging, monitoring, business-domain optimization, and others.
- High Throughput – Load, Max Req/Res, stateless vs stateful, TLS / TCP considerations, connection limits, etc..
- High Availability – Scalability, Resilience, Disaster Recovery, etc..
- Data Security – at rest and in transit
- Compliance and Legal Requirements
- Usability
- Monitor-ability
- Low Latency
- Production Cost Factor – Maintenance and Operation
- Configurability
- Audit-ability
- Deployment Platform
- Composability Index
- others
What are those boxes and arrows?
For a shared understanding we need a common language that everyone can understand hence diagrams which can capture the intent, problem being solved and the decision being made (tradeoffs / alternate solutions / technical debt).
What types of diagrams are used in Architecture?
- Usually block/component diagrams with arrows (subset of UML)
- Occasionally ‘Sequence and Activity Diagrams are used to capture some high level and low level designs
What represents a block/component? why lines and arrows?
- Block or component(boxes) generally represent a system/platform (software stack) that delivers business capabilities and features for one (or more) domain functions
- Relationships and contracts between the components are defined by lines
- Arrows represent the nature of relationships and/or data flow among components. want to learn more? read online about UML types
Governing Principles?
Very complex and a long list but below is my two de-facto standard principle what helps making decisions
- KISS – Keep it Simple, Stupid
- YAGNI – You Aren’t Gonna Need It
What these two principles try to enforce is to make us think if we really need a specific feature or decision at that very moment. If we can postpone making a decision to a later moment (a character of Agile Architecture), we will keep our architecture simple and hence easy to manage for a longer time. One common way software architectures become complex is by introducing abstractions – this could be a new fancy layer that copies data in one format and transforms it into another, or this could be creating many classes, interfaces, factories, etc., to ensure testability.
However, one pitfall when applying these two principles is that we tend to delay everything until the last possible moment. By then it may already have become too difficult to implement the required change. Instead our task is much more difficult, because
“we should take decisions not in the last possible moment, but rather in the most responsible one.”
What I usually do if I am about to make an architectural decision, is to do some small preparations that do not take much time, if the certainty of this decision is high.
Who should care? read?
Everyone (really? yes, at least PO, BA, Tech Leads, QA, Ops should) involved in project, both technical and non-technical, should care and empower software architecture in order to understand the business problem, solution and important decisions taken. Be involved in the process such as of product briefing, technical brainstorming sessions, whiteboard sessions and alternate solutions, decisions and its implications, documentations, Q&As, Dev & Operations Team sign-off, etc. Architecture empowers engineers, developers, business and product owners to collaborate better.
Coming up: My next post will introduce common architectural patterns that are widely adapted by current modern architecture community. Stay tuned!
kannandurairaj 