“Trust is the lubrication that makes it possible
for organizations to work.”— Warren Bennis
In a previous Advisor (“The Core Architecture – Via Deduction, Induction and Seduction”), I wrote: “Deductive and inductive reasoning are part of the mix, but passion, emotion, and human drives cannot be ignored.” Enterprises try to drive seeds of ideas down to reality from the ivory tower, while the gravity exerted by on-the-ground implementations pulls toward a different kind of reality. Many enterprises, nowadays, have cross-organizational functions that seek to make changes from the top, downwards. Of course, bottom-up forces have always been present in every organization, since that is where things are made: in the forge of execution.
But there is always more to it than meets the eye. There is the “dark matter”; the stuff that is present but unseen, and therefore ignored. I sketched out this concept in an Executive Update, “Darkitecture: The Edge of Architecture.”
The key insight is that our view of architecture is incomplete, and that forces that lie beyond our architecture blinkers may drive what ends up happening within enterprises. Would it not help to somehow get our arms around these forces, as we conceive, plan, and execute changes designed to improve our enterprises?
Architecture’s Hidden Forces Call for Leadership
Architecture is an organization function, just like the many other functions. And, it therefore needs to deal with many of the same issues that, say, finance, needs to deal with. Many of these issues are readily apparent if we get in touch with the intrinsic nature of organizations and what they consist of. Sometimes, this “dust” isn’t as visible because it is often swept under the wide rug of “architecture leadership.” This would be OK as long as there is a clear understanding of what architecture leadership is, but if it becomes just an amorphous catchall, it may end up hiding important organizational behaviors and patterns that lie unaddressed and untapped.
Countless books and articles have been written on the subject of leadership. This indicates both sustained interest in the subject, as well as the difficulty of getting our arms around what must be a slippery concept. In this Advisor, we won’t go there. Instead, we will call out one issue that is behavioral in nature — trust — an issue that prevents architecture from being what it can be. There are, of course, other such behavioral issues. We need to deal with all of them in some way or another. If the term, “architecture leadership” serves as the grab bag for the way to overcome these things, so be it.
Architecture Often Suffers from Trust Issues
Architecture does not really exist until it is implemented in the structure, components, and interactions within the enterprise. Implementation of nontrivial changes in enterprises typically requires many different people and teams to put in their pieces of the architecture puzzle as part of the work they do. But such architectural contributions are only a part of what each individual or team does. A marketing team’s goal, for example, may be more about achieving an immediate revenue lift via a marketing campaign than about implementing some architecture-driven change that seeks to position the enterprise for a new business model, two years out into the future. There is, in this example, an inherent conflict between the goals of the architecture team and those of the marketing team. There are, likely, other similar situational forces as well. The enterprise compliance team, for instance, may be concerned about SOX compliance, which might affect both the architecture team’s and the marketing team’s goals. This is the kind of behavior-influencing situational context that architecture typically needs to operate in: with multiple parties that have conflicting goals.
Trust is not a given when there are opposing goals; in fact, these kind of situations start the trust equation with a negative balance. But it gets worse. In many organizations, the relationship between architects and other groups may have a history that is not conducive to trust. A lack of trust may not be because of anything that any of the parties willfully did. Where people are involved, perceptions are not far behind. If not managed with some care, things can get political across organizational boundary lines. Building and nurturing trust is something that architects need to pay close attention to.
The Architecture of Trust
If we broaden the definition of architecture to include its implementation and the behavioral aspects of implementation, we now have a new “nonfunctional requirement” that needs to be considered alongside things such as extensibility, availability, and such. And, as with those things, the specific situational context, legacy issues, and the components (people and mindsets) will drive the design of trust.
Is your definition of architecture broad enough? Do you consider trust as an important aspect of architecture and its success in the organization? Do you consciously design for this? Do you put the right kinds of things in place to operationalize trust?
What's Your Reaction? Tell me what you think at bprasad@cutter.com, or post your comments below.
