How Value-Stream-Oriented Architecture Can Help You Create Better Software
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In the modern era, it is understood that designs must emerge in the course of development rather than be specified at the outset of a project. Eighteen months ago, I firmly believed that the role of "software architect" was nothing more than a relic from when Big Up-Front Designosaurs ruled the Earth. Then my company slapped the word "Architect" after my name. I'd been a technical leader for many years but I'd never been called the a-word. Well, not that a-word, anyway.
Most developers have seen examples of how "sketching" out an architecture becomes Big Design Up-Front, which becomes long-term planning, which becomes a commitment. In the best case, that commitment causes a lot of wasted effort. In the worst case, it can wreck customer relationships when the plan is scrapped so the company can focus on new priorities. At first, I only reluctantly agreed to this new role as a means of limiting the harm that would be done to my team and its product.
However, it didn't take long for me to realize that architects are expected to produce architecture. Since expectations have to be fulfilled in order for paychecks to be cut, I reluctantly decided to start forming plans. I was determined to fulfill the intent of my unsought role while delivering something that was lightweight and flexible enough to adapt to changing circumstances. I also wanted the output of my efforts to stand a chance of actually being useful.
Ultimately, my search for a better way to do and express architectural thinking had an unexpected outcome: The output was a hit, not just with the intended audience either. Managers, customer-advocates, and even developers who had been snickering at my new title, all understood, appreciated, and were energized by the plan.
There was even an admission that it was a valuable effort from the harshest critic of the architect role I knew: me.
The result wasn't a final architecture but enough detail to drive us in the right direction. It said "This is the value we want to deliver and this is one way we could possibly deliver it." It was a way to ensure a workable architecture would ultimately be produced while prioritizing customer value over comprehensive documentation.
...and I owe it all to my religion: lean thinking.
The Good Architect
I can safely say I've run the gamut of developer-architect relationships. I've been a developer who respected architects and one who did not. I've also been an architect who is unworthy of respect, as well as one who, I hope, is a helpful contributor.
I think I have enough perspective to distill the role of architecture down to the value it is supposed to provide. Simply put, an architect ought to do two things:
- Ensure that the parts of a system work together to provide customer value.
- Defend a system from bad technical decisions so value can continue to be delivered.
I have a lot of thoughts on how to accomplish the second item. However, those thoughts will have to wait for another time. The place where I've noticed architect-type people doing the most damage has typically been in their attempt to achieve objective number one.
The traditional mechanism for ensuring a coherent technical strategy throughout a system has been an attempt to prescribe that strategy well in advance of when (at least some of) the work will be done. Often this results in some monolithic design artifact, perhaps a drawing with many boxes and lines or a highly-structured Word document with many nested layers of headings and dozens of top-level categories.
Just like when developing a single application or component, this kind of Big Design Up-Front is extremely dangerous. It practically guarantees that important decisions will be made long before the knowledge required to make them is acquired. Furthermore, centralizing the decision-making fails to harness the intellect of everyone on a software development team. These forces decrease the quality of the decisions that are made.
A good architect is someone who helps all the elements of a system work together without prescribing implementation details too far in advance. The key to doing that lies in lean thinking.