Let's acknowledge it -- everyone is in love with information technology these days. From the ice cream cart owner who can now accept credit cards via Square, to the aerospace executive who now is able to monitor the health of aircraft engines in flight, 24x7, IT is opening up new possibilities and alleviating the pain of manual processes.
But there's also a tendency to go overboard as well, and with wide, often unfettered adoption of cloud, SaaS or mobile services, there's a risk of seeing IT as a cure-all for short-sighted or clueless management. To avoid the expensive dangers of simply throwing technology at problems, there's the discipline of architecture, both software and enterprise style.
Ruth Malan, IT architect extraordinaire, architecture consultant at Bredemeyer Consulting, and recipient of Carnegie Mellon's 2017 Linda M. Northrop Software Architecture Award, recently ruminated about what it means to be an architect. She makes this point that architecture often swims against the tides of organizational entropy, inertia and short-sightedness:
"Conway's Law asserts that the structure of the organization, and the communication paths it facilitates and inhibits, are powerful, even determining, shapers of the system. I paraphrase it thusly: 'if the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins.' Recognizing that's a law, like gravity, then, we can play along with it, and use team boundaries to maintain component or microservice boundaries, by lining them up. There is a but. We do have to remain vigilant, lest we get played by the very law we're using to game entropy. The forces we're using to protect and reinforce boundaries, increase inertial forces at the boundary -- it's harder to see when change is needed, and harder to change. Moreover, given what the communication paths foster and inhibit, we're going to have to put in explicit work, to ensure that we don't get scope creep within the component (microservice, etc.), and to manage duplication (with concomitant inconsistency) across components."
Bottom line, the job of the architect -- be it software architect, or enterprise architect, which we're going to explore here -- isn't just to design and plan out wonderful, elegant systems; it's also to educate, guide, and yes, sell these ideas and visions to decision-makers, who continuously need to re-examine what they're doing, why they're doing what they're doing, how they can do it better, and -- importantly -- recognize that technology alone won't solve their problems or open new opportunities. It takes visionary, forward-thinking management to do that. Enterprise architecture lays the groundwork and makes the right technology available for the right occasion.
This was true back in 1968 when Melvin Conway wrote his law, and holds even more so today as when shift to digital enterprises. A new survey from CompTIA, an industry trade association, asserts that "the critical nature of technology and radically new models for IT delivery are making architectural planning a necessity. Just as a business plan is required to chart the future of a company, an IT architecture plan is required to build success in a digital economy."
Let me take that a step further. An IT architecture plan is the business plan. And the business plan is the IT architecture plan. The two are one, and they are now inseparable.
In the CompTIA study, about 13% of executives consider their organizations to be "cutting edge" when it comes to the intelligent deployment of technology to advance their businesses. CompTIA says the cutting-edge companies have their management on board with smart technology decisions. "Among firms with more advanced technology utilization, 52% say that senior leadership which supports and funds technology initiatives is a key part of the advanced approach."
Among firms with less advanced technology utilization, 44% say that insufficient spending on technology initiatives (driven from budgets set at executive levels) is holding them back from a stronger approach. "In both situations, the vision/support/budget set by leadership is the primary factor in setting the mindset," the report's authors conclude.
Okay, how does one go about injecting some technology vision into their business leadership? The CompTIA authors describe what needs to be done:
"For IT professionals or IT solution providers, the challenge in building consensus around architecture planning is twofold. First, they must ensure that discussions start with business needs. Technical workers must understand the ultimate goals; 'We need a new communication tool' could mean 'We need to enable remote workers' or it could mean 'We need to connect internal activities with customer inter- actions.' The IT department may suggest different steps to a final solution based on the objective.
"Second, collaboration throughout the organization must extend to a basic understanding of the architecture. [There is] increasing technical activity among lines of business. The activity is growing as familiarity with SaaS products and other endpoint solutions rises, but it is also limited as business units do not have deep architectural expertise. As business needs drive technology decisions, that influence must drive all the way down to the interconnected systems that form the comprehensive IT environment."