Architecturally Significant Requirements - Design Part 4
Welcome to part 3 of my design with the BTABoK Series. If you are unaware, the authors and contributors are writing a set of scenarios like this series to discuss using the BTABoK toolset in practical ways.
I
In fact I often describe great architecture as
“making great business technology decisions, at the right velocity, in complex ecosystems with a complex set of stakeholders.”
But what makes a decision great or even architectural? And if this is so important why do we not do a better job of it?
Design Canvases from the BTABoK
| Taken from BTABoK Design Article: [Design | IASA - BTABoK](https://iasa-global.github.io/btabok/design.html) |
If you haven’t read the BTABoK article and Part 1, you may want to familiarize yourself with those first. Always keep in mind the BTABoK is open source. If you don’t like the article, change however you want (no delete sorry 😊) and do a pull request and the editorial team will review and accept/reject. Also, we are shamelessly looking for volunteers for special BTABoK projects, like the Pattern Library.
So where do all these options come from and how do we as architects keep up with them? The short answer is a) we study constantly and b) we don’t - we simply learn to work with technical experts in a way that fundamentally supplements systems thinking.
Architecture Requirements Card
This used to be called the T-Shaped Architect. We were depth experts in a single area of technology, then realized that it connected with so many other parts that we began to split out. Maybe we were java and spring experts but then had to do a .net project. Then we had to integrate the two. Maybe we started with data then moved into larger solutions and began programming. But technical breadth has turned into what I like to call the Tree-Shaped Architect. The simple truth is technology has grown into a behemoth of options and we go down branches of depth and then cross over to other branches. We have no hope of knowing it all but the key is to keep learning. The hardest truth for the lifelong architect is we can never stop practicing new technologies.
Requirement Characteristics
The
Decision Reversibility - Too Slow or Too Fast?
Technical
Decision Velocity - Too Slow or Too Fast?
Technical
Decision Information - Too Slow or Too Fast?
Technical
Decision Effort - Too Slow or Too Fast?
Technical
Decision Style
Technical
Decision Ownership
Technical
Decision Style - Too Slow or Too Fast?
Technical
Decision Style
Technical
Final Decision, Rationale and Consequences
Technical
Decision Record Types
Let’s face it, tk!
Patterns and Structure
Chris
Business Technology Components
So the
Products
So howupdated and sharpen your technical skills
Decisions and Agility
For
What is Agile Architecture
As y
The
Facilitation over Command and Control
Anyone
Last Responsible Moment
Decisions Fallacies and Anti-Patterns
The
We Don’t Need Decisions
The Team is the Architect
Top Down and Early is Better
Using Only TCO, Time or Resources
BTABoK References
| [Design | IASA - BTABoK (iasa-global.github.io)](https://iasa-global.github.io/btabok/design.html) |
| You can find all of these canvases in a mocked-up miro board of the Iasa canvases we will be covering in these articles here: [Miro | Online Whiteboard for Visual Collaboration](https://miro.com/app/board/uXjVORNRx4s=/?share_link_id=155880042988). |
I am looking forward to this Design Series based on the BTABoK. Here is my current thinking on the order they will come in:
1. Dissecting Design – And Introduction - Done
2. Options, Options, Options – So Many Choices - Done
3. Decision Rights Rule the World – Why Agile Architecture is so Hard
4. From Cornflower Blue Buttons to Architecturally Significant Requirements
5. Views and BEYOND – Thinking, Facilitating, and Communicating
6. I Like Patterns – Patterns, Reference Models, and Conformance
7. Assessments, Tests, and Chasing Perfection – How Governance and Assessment are Different