- The Software Architect
Architects play a critical role as a connecting and translating element, especially in large organizations where departments speak different languages, have different viewpoints, and drive toward conflicting objectives.
The worst-case scenario materializes when people holding relevant information or expertise aren't empowered to make decisions, whereas the decision makers lack relevant information.
Some of the valuable things an architect does are:
- Connect the dots, interdependencies are well understood.
- See trade-offs.
- Look beyond products.
- Articulate strategy to suport the business strategy.
- Fight complexity.
- Deliver.
Staying grounded in reality and receiving feedback on decisions from real project implementations is vital for architects. Orherwise, control remains an illusion.
Architects work closely with technical staff on projects, but are also able to convey technical topics to upper management without losing the essence of the message. Conversely, they understand the company's business strategy and can translate it into technical decisions that support it.
The value of the architects in the elvator metaphor shouldn't be measured by how "high" they travel but by how many floors they span.
Allowing architects to only enjoy the view from high up invariable leads to the dreaded authority without responsibility antipattern. This pattern can be broken only if architects have to live with, or at least observe, the consequences of their decisions. To do so, they must keep riding the elevator.
Lift boys are folks who ride the elevator down merely to pick up buzzwords to sell as their own ideas in the penthouse. They ride the elevator but don't get out. They benefit from the ignorance in the penthouse to pursue a "technical" career without touching actual technology.
Being a disrputor is not easy. Both the penthouse and the engine room might actually have grown quite content with being disconnected: the company leadership is under the false impression that the digital transformation is proceeding nicely, whereas the folks in the engine room enjoy the freedom to try out new technnologies without much supervision. Such a disconnect between the two resembles a cruise ship heading for an iceberg with the engines running at full speed ahead.
I was once critized by the engine room for pushing corporate agenda against the will of the developers while at the same time corporate leadership chastised me for wanting to try new solutions just for fun. Ironically, this likely meant I found a good balance. - Gregor Hohpe
Exaggerated expectations can paint a picture of someone who solves intermittent performance problems in the morning and then transforms the enterprise culture in the afternoon.
Architects are pulled into several roles that clearly miss the puspose of being an architect:
Becoming an architect and a superstar engineer are two different career paths. Architects tend to have a broader scope, including organizational and strategic aspects, whereas engineers tend to specialize and deliver running software.
Architects are expected to be able to troubleshoot and solve any crisis based on their broad understanding of the current system landscape.
Needless to say, architects shouldn't ignore production issues, because they provide valuable feedback into possible architectural weaknesses. But running from one fire drill to the next won't allow time to think about architecture. Architecture isn't operations.
Architect's decisions take into account -and affect- project time lines, staffing, and required skill sets. As a result, upper management often comes to rely on architects for project information. It's valuable work, but it distracts from the architect's main responsibility.
Architects need to sport a sharp intellect and must be able to think in models and systems, but the decisions they make impact real business projects. Architects produce more than paper.
Lastly, although scientists may get their papers published by making things sound complex and difficult to understand, an architect's job is the inverse: making complex topics easy to digest.
Architects deal with requirements that aren't stated anywhere. This includes context, tacit assumptions, hidden dependencies, and other things that were never spelled out. Unearthing these implicit requirements and making them explicit is one of an architect's most valuable contributions.
It is a common misconception that developers deal with functional requirements, whereas architects deal with nonfunctional requirements (i.e., scalability, maintainability, availability, interoperability, and so on.).
In the end, most architects exhibit a combination of these prototypical stereotypes. Periodic gluing, gardening, guiding, impressing, and a little bit of all knowing every now and then can make for a pretty good architect.
All-knowingness turns out to be too ambitious for humans. Leading to poor decision-making and all sorts of other porblems. Even if the architect is a super-smart person, they can base decisions on only those facts that are known to them. In large companies with a complex IT, it would be impossible to stay in touch with all technology that is in place.
They'll therefore inevitably need to rely on presentations, documents, or statements from management on the middle floors. Such an information channel to the supreme decision maker has severe challenges: every floor through which such a document passes understands its value as an influencing vehicle, meaning they will be tempted to inject their favorite messages and project proposals. Further up, any real technical content or potentially controversial topics are sure to be removed.
As a result, the top architect is being fed indirect, distorted, and often biased information. Making decisions based on such information is dangerous.
The role of the gardener is to trime and prune what doesn't fit and to establish an overall balance and harmony in the garden, keeping in mind the plants' needs.
A good gardener, just like a good architect, is no dictatorial master planner and certainly doesn't make all the detailed decisions about which direction a strain of grass should grow. Rather, gardeners see themselves as the caretaker of a living ecosystem.
An architect as a tour guide, someone who has been to a certain place many times, can tell a good story about it, and can gently guide you to pay attention to important aspects and avoid unnecessary risks. This is a guiding role.
This type of architect needs to "lead by influence" and must be hands-on enough to earn the respect of those whom they're leading. The tour guide also stays along for the ride and doesn't just hand a map to the tourist.
Architects can sometimes be seen as wizards who can solve just about any technical challenge. Although that can be a short-term ego boost, it's not a good job description and expectation to live up to.
Amir Shenhav from Intel appropriately pointed out that instead of the superhero we need "super-glue" architects: the guys who hold architecture, technical details, business needs, and people together across a large organization or complex projects. An architect being a catalyst.
Being the glue means understanding a good bit about the things you glue together.
If an IT system can still absorb high rates of change after many years, the project team probably included a good architect.
It's about designing software and solving problems within a specific organizational context, and being aware of what's happening around you, so that you can successfully navigate and influence that context where necessary.
Architects need to communicate and influence at different levels, with different audiences, both inside and outside of their immediate team environment.
Avoid the "business versus IT" mindset. Learn how to see the bigger picture to map and influence the organizational landscape, how to deal with vendors, and how to communicate across all levels of an organization.
Riding the architecture elevator is how my team and I spend our time.
Racing from one part of our organization to another, connecting, explaining questioning, and trying to make good decisions about complex systems with imperfect information. The elevator takes us from code to business strategy and back again, all within the same day.
If you're not taking meaningful decisions, making them explicit, and helping people understand them, you're not doing architecture.