We cannot solve our problems with the same
level of thinking that created them.— Albert Einstein
In an earlier Advisor, we called out an important function of architects: “to grapple with the elements of the enterprise that are disproportionate in their influence, and make them deliver [business value].” What is implicit in that statement is a recognition that “grappling” occurs because complex situations demand that we make the right tradeoffs and choices. It’s all about decisions.
Who makes these decisions?
When Silos Rule, Rulers Sigh
When enterprises grow and mature, they take a form that conforms to a fairly standard pattern: an organizational architecture consisting of various functions and lines — marketing, finance, HR, procurement, product development, geographical lines of business, and so on. Each of these organizational slices has its own terminology, processes, tools, and techniques; and each specialty has its own decision-making challenges.
While some decisions are unique to an organizational function, there are many that cannot be considered in isolation. The enterprise was never meant to operate as a collection of completely independent silos; the partitioning into silos is merely an expediency to help us deal with cognitive and representational limitations. But align and share, they must! The degree to which the different functions need to align varies, depending on that particular enterprise’s operating model, and even within that operating model itself. And yes, there is an operating model, whether or not that is consciously realized.
We think in silos because our minds are weak, but we would rather act in a more integrated manner because our aspirations are strong. To be able to act in concert, an enterprise must have the ability to think in concert and to sing in unison when the chorus lines emerge.
Executives are driven by performance-oriented measures. Finding the right themes that run across the enterprise matters; costs can be reduced, revenues and satisfaction enhanced.
The Enterprise Song’s Refrain
Teasing out the right chorus lines is hard work. It requires coming up with the right words that resonate and grab the attention and interest of people that may not otherwise be motivated to sing together.
However, themes don’t just emerge. The right talent must be put in place to “feel” the verses that already float around in some form; to come up with something that makes logical sense and also resonates with a critical mass of people.
Enter the “architect” and architecture.
A Composition Begs for a Composer
The need for some semblance of unity within a tangle of diversity has always existed. However, the problem needed to get worse before the need for a resolution would drive the emergence of architects. That occurred when we crossed a critical threshold of pain in the 1990s, as each of the silos in the organization began to deploy its own IT foundation. It became obvious that the challenges of technology complexity and change as well as the redundant costs across the silos could be better managed if there was a way to share some of the foundation across the silos.
There has been a fair amount of IT model oscillation within many enterprises, with the pendulum swinging back and forth between centralized control and democratization, pausing in the middle of the swing at some flavor of federation.
Is there a sweet spot in the arc of the pendulum — one that optimizes the total cost, revenue, and risk for the enterprise? Or, to go back to our music metaphor, what is the refrain in the enterprise IT song? When does the verse end at the local level, and when does everyone join in the chorus? These are the questions that the IT architect was brought in to help determine.
Is it fair to expect the IT architect to act as the composer that carves out the verses and the chorus?
Composing the Composer
IT was merely the harbinger of things to come; the issue of balancing global optimization and local nimbleness is a broader one. Business processes, platforms, and operations all have the potential to be architected in a federated model that balances the global/local mix. And, since all of business is underpinned by technology, we can no longer consider each of these balancing acts as separate efforts. That would be ironic, given that the intent of architecture was to transcend the silos!
We are no strangers to irony though. Walk into the IT organizations of large enterprises, and you are likely to find silos within IT — the cloud team, the vendor team, the security team, the shared services team, the architecture team, and so on. Architecture teams in large enterprises can themselves be siloed, and make decisions at various levels at various times, causing cascades to ripple up and down and across the organization. It gets worse as we extend the enterprise and change the definition of what the enterprise is, as outsourcing partners, hosting providers, and even customers become part of a “living organization.”
We have responded with the notion of an “enterprise architect” to consider this broader scope beyond IT. However, there are many other roles with the “architect” title, and yet others that are not tagged so, but which nevertheless make architectural tradeoff decisions that determine what becomes global and what can remain local. So, architecture itself is siloed, with the enterprise architect being merely one of several roles caught in the quagmire of a silo mentality.
Maybe what we need is a “meta-architect” — someone who architects architecture itself, so that we can break the silos that the silo-breakers build? Or, must we resign ourselves to doing precisely what we accuse others of doing? Maybe the siloing is in our mindsets; in our genetic blueprint?
Would it help if we called our enterprise architects “meta-architects,” and thrust upon them the burden of transcending what seems to be a native mindset that constantly traps itself in its old ways?
