In the first part of this post, we explored these “rules”:
- Allow Architecture to Emerge
- Treat it Like a Product
- A Picture is Worth…
- Everyone IS an Architect and Everyone OWNS the Architecture
Now, I’d like to continue sharing the final set of four rules for your consideration in your agile architectural travels.
#5) Keep it Simple and Connect to the Customer
This one is quite near and dear to my heart. Why might you ask? Because I really like complexity. I like engineering complex solutions to simple…complex customer problems. And it’s also quite comfortable for me to fall into that over-engineering, gold-plating, doing more than is required mindset.
Why?
Because I can. And because I’m an engineer. The more complex and elegant the solution, the better I feel about my capabilities. It makes me smile.
And I think lots of engineers are like me. But it’s the wrong approach. And it’s often easier than thinking really deeply about the problem or challenge and then finding the “simplest possible thing” that could satisfy your customer.
One way to combat this is to focus on MVP-like language. Words like minimum and viable can more narrowly focus our efforts. That, and including your customer in these discussions.
Another important activity is sitting down with your customer(s) to understand the WHY behind their requests. People often describe this as a challenge, in that they (the customers) are “too busy” to explain their needs. I’d argue that if they’re not too busy to spend corporate funds on solutions, then they shouldn’t be too busy to ensure that those solutions meet their needs. Whether they’re internal customers, external customers, or both, it’s often more excuse than it is a reality.
If appropriate, including UX activity is an important part of the discovery and design process. Far too often, I see groups doing either too little or too much UX. That is, either they skip it and dive into solutioning far too soon. Or they go into an analysis paralysis state and do UX for months without truly engaging the teams and customers directly.
There is also one important part of customer connection. Can you guess it?
Yes, that’s right. It’s ensuing that they get into the demo’s and verify/sign-off on the solutions the teams are providing. This notion of demonstration, feedback, discovery, and ultimate acceptance is crucial for closing the delivery loop. That and the customers sticking to their word when it comes to sign-off.
#6) Prototype for Learning & Discovery
One of the first things I’d like everyone to acknowledge in software architecture is that we often (most of the time) haven’t done what we’re being asked to do before. That is:
- We’re clueless about what the design approach should look like;
- We’re clueless about the tools and techniques we’ll use;
- We’re clueless about the environmental considerations;
- We don’t understand the UX implications, and what the customer truly needs’
- We’re clueless about the performance implications;
- We’re clueless about how to test our solutions;
- And, we’re clueless about how long it will take to complete our work.
I think the most important acknowledgment or statement we should all agree to early on in ANY architectural discussion is that…
We don’t know
Out of this level of openness and honesty, comes the need for prototyping, discovery, and learning. It’s hard to do that if we don’t all look each other in the eyes and say – we don’t know, let’s find out.
Once we do, then the focus needs to turn to learning, which is actually something we all can do. Here are some techniques for approaching this learning:
- Working code is the great leveler. So, as much as possible, we should be pulling prototype code together to learn. The prototypes should be cheap and fast. They’re not production code. Instead, they’re learning code. Experimentation code. This includes paper prototypes and such from a UX perspective.
- User Story spikes are the way to capture these activities. Write a spike for each and every (major) learning activity. And take the time to clarify the acceptance criteria for each. In other words, what key things will we “deliver” in order to more fully understand this aspect of the architecture?
- SAFe has the notion of architectural runway or architectural look-ahead. So, not only do we need to capture spikes and write code, but we need to forecast it enough in advance so that we’re “ahead” of our product development needs.
Consider working code your ultimate “picture” of your architecture. So, aspire to code over studying, documentating, and yakking about the architecture. Instead, build prototypes as soon as possible.
#7) Demo Your Architecture
If you listen to the Meta-cast where Josh and I established these rules, you’ll hear us disagree on this point. I feel like it’s really important to (try) and demo everything we build – including architecture. However, Josh’s experience (and feelings) are inherently the opposite.
In a nutshell, Josh’s experience is that most stakeholders (executives, customers, managers/leaders) don’t really care about your architectural, infrastructural, automation, and other “plumbing-oriented” types of work. They care about customer-facing features (MVP’s) and things they can see, understand, and charge for.
They view demonstrations of this sort of stuff as:
- Too technical and hard to understand;
- A self-serving exercise that only benefits the teams;
- Boring and a waste of their time.
I understand that position and I’ve experienced it first-hand in nearly every organization I’ve been a part of. And that “attitude” is what’s convinced Josh to not bother.
But I like to confront this and try to influence stakeholders to (try) understand and engage with more technical demonstrations.
Why?
Because they should care. They’re paying for architecture and they should try and understand the complexity and infrastructural demands of their products. Surely not the way the teams do. But from a business perspective, value/impact perspective, competitive perspective and investment perspective, they need to…care!
And demonstrating this is a wonderful way to provide them training and guidance towards this improved understanding. Over time, they’ll start to get a feeling for:
- Architectural investment percentages;
- Costs associated with their demands/decisions;
- Trade-off decisions;
- Risks associated with architecture (implementation AND delaying updates);
- The drivers behind refactoring;
- The investment “mix” of features vs. architecture that is inherent to each of their products.
All towards improved understanding, empathy, and respect of ALL ASPECTS of their products. I’ve found that stakeholders who engage in all aspects of their products, make far better decisions.
So, at the risk of aggravating my friend Josh. He’s wrong.
#8) Change is Constant; Refactor Everything
I’ll start explaining this rule with an analogy.
I’m a homeowner in North Carolina. Our climate causes specific types of degradation in my home. And then there is simple aging to contend with. So, I find myself annually investing in the upkeep of my home and its systems. I view it as a “pay me now” vs. a “pay me later” decision, and I like to keep my home nice, so I tend towards paying me now.
Some of my neighbors have the reverse philosophy. For example, in house painting. I’ve been painting on a regular, every 5-year schedule. But some of my neighbors only paint when things are obviously falling apart. For example, exposed wood, wood rot, and severely peeling paint.
My strategy is more of a preventative approach and the costs are frequent but low. My neighbors, on the other hand, have less frequent payments, but when they do pay, it’s quite costly. For example, replacing all of their siding because they haven’t painted in 10+ years.
The other point is that I try and update to new technologies as well. For example, a few years ago I updated my HVAC systems to much more efficient units. Not only are they more reliable, but I’m saving money based on the new efficiency.
Now switching back to software and architecture, I always recommend the same strategies for software development products and applications.
We need to acknowledge that software ages AND our approaches & tools evolve so that we want to be continuously investing in the care & feeding of our products. That investment needs to be part of our business case and factored into the ROI. And this isn’t just at a feature level. I’d argue that it’s even more important to keep the plumbing (infrastructure, tooling, automation, architecture, design, integrity, performance, maintenance, etc.) up-to-date as well.
Sure, your customers may not always “see” this investment. But they will “experience” whether you are, or are not, making it.
And finally, I’m a proponent of asking my teams about technology evolution and trends and determining whether we want to invest along evolutionary curves as well. This includes new technology, new tools, and new approaches. And it’s important to LISTEN to your team and TRUST your team in these recommendations.
They’ll know far better than you what the relevant trends are and the value that it can bring to your business and customers. Point-being, don’t wait until your house crumbles and you have to rebuild from the ground up ;-)
Wrapping Up
This article series was inspired by this InfoQ article that compliments this one - https://www.infoq.com/articles/architecture-five-things
But it was also inspired by a Meta-cast discussion that I had with Josh Anderson. We exposed these eight rules, principles or thinking points really, in that podcast. You can find it here, and I believe it will complement this article as well.
It may seem that architecture is a simple by-product of executing in an agile way. And quite a few organizations seem to take that approach. I hope this article series had helped you think of agile architecture in a new light.
Not in a traditional software architectural view. But not with a hand-waving view. Instead, I think success is somewhere in between. And that we have to take agile architecture somewhat seriously.
Stay agile my friends!
Bob.