Those known for expertise are particularly prone to this ailment.
Some of us, having learned one subject in great depth (in my case the
behavior of electric fish), use that experience to recognize our lack of
depth in other subjects.
But then there are those who figure their expertise in anything make
them worth listening to about everything.
If they limited their indulgence of this hobby to bars, pubs, and
taverns they'd be less tiresome. But sadly, some use blogs and other
forms of on-line presence instead.
Take, for example,
McKinsey & Company, which recently published a
missive titled, "Why
business needs should shape IT architecture,"
(Helge Buckow and Stephane Rey, McKinsey Quarterly, April, 2010).
This Highly
Original Thought
(HOT) was considered obvious more than a dozen years ago, when I led
development of a technical architecture management methodology for Perot
Systems. The proposition hasn't become more controversial, nor more
worthy of elaboration since then. Whether business needs should shape IT
architecture isn't and never has been in question.
The question isn't whether. It's how, and
McKinsey's solution -- put a
CTO with political acumen in charge so business executives can read an
executive summary and not have to understand anything complicated (I'm
paraphrasing) -- is, shall we say, somewhat less than complete.
Not to brag or nuthin', but more than a decade ago I published a
book
(IS
Survival Guide, Bob Lewis,
Macmillan/SAMS, 1999), containing this profundity: "The scope of
technical architecture ... begins with an understanding of business
goals and ends with the establishment of specific standards."
It also provides a somewhat more thorough methodology for
traversing
this complex landscape.
And the landscape is complex, for three major reasons.
The first is that Enterprise Technical Architectures are
intrinsically complicated. A typical mid-size business will find that
its three architectural layers (application, information, and platform)
will be required to provide several hundred technical functions and
services to get the job done. That's functions, not products.
If the distinction isn't clear: One platform-layer function
might be "provide secure remote access." To provide that function, IT
can choose from among at least these three competing technologies:
classic VPN, SSL-based VPN, and remote desktops. Once it has chosen its
preferred technology (remote desktop) it's then ready to standardize on
just one solution (Citrix).
It's this thought process that leads to an organization's target
architecture -- the functional view, resolved to classes of
technology, for which specific standard solutions have been chosen.
Creating and maintaining the target architecture is one of the core
responsibilities of any enterprise technical architecture management
practice.
That's the first driver of complexity. The second is that there
is no
straight line connecting business goals and architectural decisions.
The lines connecting the two describe a many-to-many relationship --
each business goal affects many different architectural decisions; each
architectural decision must take into account many different business
goals.
This means there is no purely analytical way to derive the
ideal
enterprise technical architecture from business requirements. The
process takes more than analysis -- it requires synthesis, a far more
challenging thought process.
The third driver of complexity comes from business executives
being
human beings, IT having to depend on those human beings for financial
support, and those pesky human beings' having bought into the capitalist
philosophy of "what's in it for me?" as part of how they approach
business life.
It's this: Good architecture doesn't happen through the
chartering of
architecture improvement projects. It happens by investing in
architectural improvement as part of all of the projects a company would
undertake anyway.
That investment adds time, effort and money, and doesn't
benefit the
project sponsor at all. The better architectural decisions implemented
in projects A, B, and C this year will benefit the sponsors of projects
Q, R, and S several years from now -- their projects will cost less to
achieve the same outcomes than they would have with an accidental
architecture, because that's what good architecture does for companies.
As an ancient Greek proverb has it, "A civilization flourishes
when
people plant trees under whose shade they will never sit." For
businesses to achieve excellence in enterprise technical architecture
management, they first must be civilized.
It's something that doesn't happen by accident. In the world of
business, far too often it doesn't happen at all.
