22 Mar 2017 by mallyanitin
Unable to make a decision quickly? If you are analyzing options, assessing current state, making trade-offs, communicating to stakeholders, incorporating feedback, achieving consensus, and/or validating ideas; its clear that your work type is of a software architect. Titled or not.
Traditionally, in waterfall projects, architecture was an upfront exercise, and a time consuming one. The architect had to think through requirements, system views, x-cutting perspectives, and generate architectural descriptions for review and/or communication purposes. In today’s world, architecture is still documented, not formally (unless regulatory or corporate mandate); but remains minimal. As the system evolves, and new concerns emerge, architecture evolves & adapts. Not continuously, but continually.
So, it’s necessary to make decisions quickly.
- Which cloud? Eh. Google. AWS. Azure. Eh. Eh. AWS!
- Which NoSQL Database? Eh. MongoDB, Couchbase, DynamoDB. Eh. Eh. MongoDB
- Which Messaging Service? Eh. Kafka, AWS SQS, RabbitMQ. Eh. Eh. SQS!
- Where is interface definition for this component? Eh. Will get you version 0.01 by EOD.
Yay! Go build.
Oops we don’t have MongoDB Skills! Eh. Eh. DynamoDB. Go build!
Oops we are paying too much for DynamoDB in the cloud for development. Eh. Eh. Use DynamoDB on developer machine. No testing in cloud, and cloud resources should be consumed only when absolutely necessary. Be a miser. Spend more than $10, and it will come from your salary!
This is the norm in the industry today. Speed in everything. As the saying goes: “A good product, is a great product, if fast enough”
Some architects “feel” that such an approach will have an impact to software quality. Search for quality on google, and you get this … Quality software is reasonably bug or defect free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable. ISO 8402-1986 standard defines quality as “the totality of features and characteristics of a product or service that bears its ability to satisfy stated or implied needs.”
Given this definition of quality, it just seems that its more of pursuit to quality (just like pursuit to happiness).
- Eh. Defect free?
- Eh. Delivered on time?
- Eh. Delivered within budget?
- Eh. Meets explicit requirements?
- Eh. Meets implicit requirements?
Pretty damn tough! How to correlate speed of architecture decision to this definition?
If architecture decisions can be made with speed, and pivoted (if found to be problematic) with speed, then architectural impact to software quality could be minimized?
- Yes. Definitely.
- No. If there are too many pivots (statistically > 3). Spinning will loose time.
- Maybe. If architecture changes are not prioritized alongside features.
For a modern architect,
- All analysis has to be done yesterday, and choices have to be made for projects ASAP AND/OR
- The team culture has to adopt architectural changes to meet new needs or architecture changes due to bad but quick decision.
Improved delivery platforms/ecosystems, and improved libraries in the industry, will help to build above and around, with some quality attributes taken care by design. The remaining ones can be time-tested through quick failures (pivots).
By Bayes Theorem,
- B = Software Quality is BAD.
- E = Architecture decisions are made quickly.
- p (B/E) = p(B) * p (E/B) / p (E)
Go find evidence and compute!