|
June 2006
6/1/06
Ahhhh, a fresh start!
May was
a prolific month for my architecture journal!
The Resources for Software
Architects
site saw extensive updates too.
6/1/06 Leading with Leadership
I need to pull together thoughts and
resources on each of the architect competency bands, so why not lead
with leadership?
So, first up:
Lominger Leadership
Architect. Interestingly, they have a comprehensive set of
competencies for leadership and these map well onto
our architect
competencies, for the most part. And these competencies have been
strongly validated by the ongoing
competency-versus-performance study that Lominger has been
conducting for several years.
6/1/06
Software is Not Limited by Physics
In "Who
Needs an Architect?" (IEEE Software, 2003) Martin Fowler
states
"Software is not limited by physics, like
buildings are. It is limited by imagination, by design, by organization.
In short, it is limited by properties of people, not by properties of
the world. “We have met the enemy, and he is us.”
I would say that software is indeed limited
by the properties of people, and by the
properties of the world—computational resources and distribution,
resource failure, and so on. We make decisions about our system within
bounds set by our resource budgets and properties of the physical
computing environment.
Practically speaking, we may be more
constrained by our ability, for example, to work together to create
large complex software than by budget for computation resources, but the
complex interactions between software and resources in the computing
environment presents a tough set of challenges. It is an area that needs
scientists to develop theory and engineers to create better
tools to address. We can
(though few do) apply stochastic processes to better understand resource
contention and model performance. Wouldn't it be nice if we had
something like computational fluid dynamics simulation tools to study how
our architecture performs under various assumptions about processing
capacity/bottlenecks/transaction volume/etc.?
Booch's article on
limits and forces (you have to register before it will be visible)
in software is worth reading.
6/2/06
Architect Competency:
Leadership
The Bredemeyer Consulting
Architect Competency Framework was created in 1999, and extended
with competency elaborations in 2002/3, and is now under revision. It
spotlights leadership as a key area of competency for architects.
Subsequently, Microsoft developed a rather similar framework that also
recognizes leadership as a competency. In setting certification
expectations, Microsoft looks for the following:
"Leadership:
Candidates demonstrate that they develop partnerships with stakeholders
across the organization on their projects; that they can mentor others;
that they develop and form strong teams; and that they achieve
successful results.
-
Able to ask thought-provoking
questions that translate into actionable technological
patterns/solutions
-
Actively mentor others
-
Provide thought leadership by enabling
others to see things from a different and better perspective
-
Influence decision makers
-
Champion structure, process, best
practices and standards
-
Promote the capture and reuse of
intellectual capital
-
Effective in building mutual
partnerships and networks with parties or organizations"
Microsoft
MCA Review Board Criteria
TOGAF says that "IT Architect Technology, IT Architect Data, IT
Architect Application and IT Architect Business" need to be level 3 on
the leadership attribute, where the knowledge and proficiency levels are
1:background; 2:awareness; 3:knowledge and 4:expert. Leadership is
characterized as:
"Leadership:
Communication and team building are key
to the successful role of IT Architect. The mix of good technical skill
and the ability to lead are crucial to the job. He or she should be
viewed as a leader in the enterprise by the IT organization, the clients
they serve, and management."
TOGAF Architecture Skills Framework
This contrasts with the Bredemeyer
framework, which takes into account the different demands on leadership
as the architect's scope of influence and responsibility increases. The
broader the scope, the less the architect can rely on direct authority
and the more the architect needs to rely on leadership and persuasion,
vision and alignment. Anyone who has to enroll diverse groups to
contribute to the accomplishment of goals is going to need to be a good
leader. And architects generally have to do this without the positional
power that a manager has. This speaks even more to the need to be adept
at persuasion and influence, grounded, naturally, in technical and
business smarts and personal integrity.
The competency level you need to be at,
depends on the scope of the effort (how many people does it impact; how
diffuse are the groups impacted; etc.) and the strategic importance of
the effort (is it a mission critical, bet-the-business project that has
to succeed). The component owner that leads a small team of 2 or 3
engineers to design and develop a component has a different leadership
problem than, for example, a platform architect who is trying to get
project teams, all marching to the tune of their own independent release
drums, to contribute to a cross-organizational product platform
architecture and infrastructure initiative.
6/4/06 StumbleUpon
Well, I stumbled upon
StumbleUpon and
"redflux" was nice enough to say of
The Resources for Architects
site: "THE best generic software
architecture site on the net!"
 6/4/06
Eat You Own Dog Food versus
Insights of an 8-year old
Last month I remarked that my 8-year old son
wanted his (future) company to use competitor's products in their daily
jobs to learn by living with them how to provide better value. In the
current (May/June 2006) issue of IEEE Software, Warren Harrison offers
arguments for and against
eating your own dog food (where software companies use their own
products). Good advice, in both cases. As is "go live with your
customers."
You'll start to see a pattern: my son is an
excellent predictor of where things are headed.
6/6/06 Architect as Statesman
We talk about politics and the architect's
need to be aware of political currents and networks of influence, and
the architect's need to use influence and persuasion to get big things
done through others, to implement business strategy through
architecture. But the worst of politicians, both in the politics of
nations and states and in the politics of companies, have sullied the
terms "politician" and "politics." Brad Culter is to be commended
for
wanting, instead, to be a "technological statesman." Lawrence Reed
explores the qualities of statesmen, and though written from the frame
of reference of US politics, his observations are generally useful in our context:
"What qualities define a statesman? He (or
she) doesn't seek public office for personal gain or because it's the
only job he knows how to do. ... He stands for a principled vision, not
for what he thinks citizens will fall for. He is well informed about the
vicissitudes of human nature, the lessons of history, the role of ideas,
and the economics of the marketplace. He is a truth-seeker, which means
he is more likely to do what's right than what may be politically
popular at the moment. You know where he stands because he says what he
means and means what he says. He elevates public discussion because he
knows what he's talking about. He does not engage in class warfare or in
other divisive or partisan tactics that pull people apart." from
Lawrence Reed, "Statesman:
A Most Worthy Cause," MacKinac Center for Public Policy, June 2002.
6/16/06 Architect as Statesman ... or Executor ...
As much as cost-cutting is important in this
era of intense competition and squeezed margins, I get really
uncomfortable when software development is seen as a cost center rather
than an innovation center. Everywhere I look, software innovation is
driving out the old order and ushering in the new. It has made new
things possible in every industry, from heavy metal to services, not
just in industries that the non-software person would readily perceive
as being dependent on software.
I am a firm believer in simplicity, but to
assume that the world must be seen in binary terms is an error of
immense proportion. Generally, we cannot say we are either a cost center or an
innovation center. We have to say: What is strategic, where do we need
to innovate, and how best do we enable that? And we have to say: What is
not strategic, and how do we cost-manage that so that we meet our
business imperatives but don't overspend in areas that are important to
our viability but not our competitive advantage?
Strategic conversations need to be had to
reach answers to these questions. The architect who is brought into the
strategy conversation is the architect who is empowered to be a
statesman. The architect who is simply told to execute, without a place
in the strategic conversation, has the odds stacked against her in her
efforts to serve as a statesman.
Technical companies need technical
statesmen, and it is the rare company these days that does not have a
strong reliance on technology. They may see themselves as retailers, as
financial organizations, as "big iron" manufacturers, but increasingly
their competitiveness is coming from technological innovation enabled by
software. The strategy team has to be made up of strategically-minded
leaders on the fronts on which we compete: operations excellence,
marketing, ..., and technology innovation, which increasingly means
software innovation.
6/17/06
Opening up the Innovation
Engine
Corporate and product identity is important in helping customers narrow options and make
choices in a flooded marketplace (Malan
and Bredemeyer, June 2005). Identity is a market simplifier.
And it means that we have to think about markets and marketing
differently. Take the iPod. It is all about identity. The iPod is cool,
the iPod is at the innovation edge, the choice to go iPod is a
no-brainer. Give your teenager or 20-something college kid another MP-3
player and you'll whither in dismay at the ungratefulness of the progeny
you raised.
Tom Asacker goes even further. He makes the point that in a world
characterized by information flood, people make decisions based on gut
feel. "You’re not in the real goods business any longer;
you’re in the feel goods business."
The important point is that in
marketing and product development, we are going to have to pay attention
to how consumers really make product choices, and factor that
into our product and product family design, not just our marketing strategy.
We can't expect marketing to create brand miracles no matter what
products we create, and we can't expect our sales force to create
customer relationships and sell our products even if they generate bad
feelings by delivering a shoddy customer experience!
Customer experience is important in a world
where direct referral (whether through blogs or personal relationships)
is a major force in purchase decisions. Architects need to understand
these factors; it is not just the role of marketing to sort out how to
make products competitive. It is the role of the multi-functional team
involved in product (and service) innovation.
We have to break down the walls that prevent
us from thinking about customer experience, product and company
identity, and features, holistically. Serializing requirements
(marketing), architecture (architects), and detailed design and
implementation (software developers) with over-the-wall hand-offs
between phases and disciplines is (like wires) "so yesterday"—it is a mechanistic
process for a simpler, slower, more rationalized age.
To compete today, we have to be
differentiated in customers' perception. And in today's complex
world filled with overwhelming choice, perception is shaped by
subjective experience, stories, feelings—not a rationalized conjoint
analysis of the feature set. We architects need to take this into
account; great software, that is software that makes products and
services great, is not just a technical matter any more. We have to
integrate customer experience into our value-cost strategy and
design decisions.
6/17/06 Innovation
6/17/06
Break-through Thinking
6/17/06 Leadership or Command-and-Control Autocrats?
In
March
2006, Business Week announced “Skip the
touchy-feely stuff. The big-box store is thriving under CEO Bob Nardelli's military-style rule.” Just 3 months later, under
ex-GE executive Bob Nardelli, Home Depot is losing favor among customers
and shareholders alike (Business
Week, June 19, 2006).
David Wolfe writes "Command and control management is as out of date
as a 10 cent first class postage stamp." Actually, it still has a
foot-hold in modern business; time will tell whether command-and-control
corporate cultures will survive in the 21st century.
What is clear, is that when command-and-control managers are put at
the helm of companies with a delegation-to-the-roots-of-innovation
culture, trouble ensues. In the past, Home Depot succeeded by delegating
the customer experience to all the salespeople on the floor, and backed
that up with ensuring the staff was competent and committed—ensuring
that customers interacted with sales assistants who came across as
competent to home improvement novices and experts alike.
Nardelli not only stands for command-and-control decision style, but
also for cost-cutting without attention to the people-centered value
propositions of the business. Command-and-control alienates in a culture
accustomed to decisions by consensus and delegation. Add to that
cost-cutting the eliminates the people who have the experience and
caliber to make strategic decisions wherever they arise, and you
completely shift the value centers of the business. This might work, if
you know what your value center is going to be, but if all you are
shooting for is reduced cost, you're shooting the company right out of
the value side of its competitive position. And competitive positioning
is at least as much about value as it is about costs.
6/17/06 Leadership
-
The 360° Leader, by John
Maxwell, published by Nelson Business, 2006
-
Why Should Anyone be Lead by You?,
by Robert
Goffee and Gareth Jones,
Harvard Business School Press, 2006
-
Why Leaders Fail,
by Mark Sanborn
6/17/06
Joel on Software — Managers
Joel Spolsky has a deservedly popular blog.
The software industry needs a few good entertainers (just caught a
Freudian slip there—wrote "god" instead of "good"), and Joel Spolsky
and Martin Fowler certainly pound out some winners, even if they leave
some bruises... for example,
Joel
quips: "...
in the world of ... large companies who
rely on overpaid management consultants to think for them, chew their
food, etc." I "grew up" in a
large company, and I can tell you, with certainty, we chewed our own
food.
Anyway, if you're looking for an
entertaining story, with some telling insight, Joel's latest post
reminiscing on his days as Excel program manager is worth a few late
night minutes, at least.
6/18/06 We're
Outsourcing and Off-shoring
our Core Competency: Software and the Innovation Engine
In "Hitting
the High Notes," Joel Spolsky makes the point that "the
conventional wisdom in the world of ... large companies ... seems to be
that the most important thing is reducing the cost of programmers."
He goes on to explore differences in productivity among programmers, and
concludes "The real trouble with
using a lot of mediocre programmers instead of a couple of good ones is
that no matter how long they work, they never produce something as good
as what the great programmers can produce."
Joel focuses on exceptional programmers
versus "mediocre" programmers. One dimension of greatness is sheer
intellectual horsepower (a phrase I'm borrowing from Microsoft). But
there is also the dimension of experience. Experience in a domain plus talent
plus passion/motivation/energy are the ingredients of
productivity and creativity.
Great designs are the products of great
minds. Great minds exist in every country. The world will continue to be
filled with great, innovative products. That is not my concern. My
concern is that we are reducing the incentive for great minds to enter
and stay in software development careers in the US.
Software is a huge driver in
innovation—everywhere you look. Cameras. Ok, that's old. How about oil
paintings? For a Father's Day gift, we just bought a photograph printed
on an oil canvas that looks like a hybrid of an oil painting and a
photo, and it is. On the surface this may not seem to be much of a
software breakthrough, but printers rely on software all the way down to
the embedded software in the ink cartridges. I'm not saying software is
the only source of the innovation, but it is a key partner in
innovations in industries that we would not necessarily associate with
software for product innovation and excellence.
I'm expecting the next movie that is set ten
years out will have a small (satellite dish-size) wind-turbine on the
roof of every house. To work as a device that will solve the energy
crisis at least in windy states like Indiana, such wind turbines will
have to produce enough energy to more than recoup the cost of the
installation and maintenance, and be simple to install and
operate. Yes, a hardware device that relies on software so that the
ordinary person can operate it.
So, innovation depends increasingly on
software. If we lose our software innovation engine in the US, it
logically follows that innovative new products will increasingly be
coming from outside the US. Our national identity as the font of
innovation will be lost.
"Innovation fosters the new ideas,
technologies, and processes that lead to better jobs, higher wages and a
higher standard of living. For advanced industrial nations no longer
able to compete on cost, the capacity to innovate is the most critical
element in sustaining competitiveness.
The United States stands apart from the
rest of the world in its record of sustained innovation over decades,
across industries, and through economic cycles.
But the United States now finds itself at
a potential inflection point—facing new realities that pose significant
challenges to our global innovation leadership.
How the United States responds to these
realities is critically important and is the goal of the National
Innovation Initiative."
from the
National Innovation Initiative
Vision
The Innovation Council is asking this
question more generally (Innovation
Skills Working Group Report page 4):
"America’s leaders must now ask whether we
have effectively 'off-shored' our long-term capacity to innovate."
I have always been excited by the capacity
of global companies to integrate world interests. Global companies
will have a stabilizing and equalizing impact on the world because they
create human relationships across country boundaries, they have strong
vested interests in peace and economic stability around the globe, and they open up economic opportunity
to those who need it, while expanding markets for goods and services.
But I also see folly in the rush to
off-shore in massive scale our software capability.
First, we should be careful about
outsourcing capabilities that we depend on to create competitive
advantage. If we go to a third party to build components that fit into
our differentiated architecture that is one thing. Outsourcing our
product is another. Does the third party understand our customers? Do
they care; I mean really care, or is it just a set of contractual line
items to them? Obviously outsourcing does not necessitate
off-shoring; but the conjunction is common these days.
Second, if we follow corporate vogue and
willy-nilly off-shore software development we produce the situation
where demand for experienced talent has to outstrip the supply—not
because the talent is missing but because the broad experience-base has
not been built yet. Without the experienced talent, we will not
achieve the cost savings we are chasing. Sure salaries may be
significantly less, but
software costs are a factor of productivity, not sheer man-months.
And worse, corporate survival is not solely
about cost savings, otherwise we could eliminate the workforce entirely!
Corporate success is about value that customers are willing to pay for.
Cutting costs in misguided ways cuts customer value, so less revenue is
earned and costs remain disproportionately high despite the cuts.
A balanced approach, rather than a panicky
rush to copy everyone else's cost-cutting strategy, is what is needed.
There are many advantages to off-shoring—in
addition to the striking salary differences. Distributed teams work
round-the-clock, taking advantage of time-zone differences to keep the
project moving forward 24 hours a day. Rather than being hamstrung by an
increasing scarcity and hence higher cost for software engineering
talent stateside (and in Europe), companies have a whole world of talent
to look to. Yes, our world is becoming ever more globalized: time and
distance is becoming immaterial to global collaboration; global labor
markets give businesses access to huge volumes of talent, at lower costs
into the bargain.
My quibble is not with off-shoring and
outsourcing. That does not make the least bit of sense. My
quibble is with a rush to pull out the underpinnings of the stateside
software engineering capacity and build it off-shore, or go even
further than that, and outsource to an off-shore vendor, software that
we depend on to differentiate our products and services.
I believe in differentiation as the heart of
free competition, and if we pursue cost differentiation rather than
value differentiation we get into a very tough battle for corporate
survival. Truly global teams, that take advantage of talent and give
exciting job opportunities to architects, software and quality engineers and
project managers, offer huge promise in this global market that
encompasses invention, production, and consumption of goods and
services. We just need to be watchful that in the pendulum swings that
characterize corporations' tendency to overcorrect in response to market
indicators, we don't destroy the software capability we have stateside.
[1/31/07: See also: "Going
Grey," by Jack Ganssle. Thanks for the pointer Daniel.]
6/18/06 Women and Architecture
Generally I keep my mouth well and truly
shut about gender differences. Mostly, it comes across as whining if you
point out any way in which gender differences propagate a situation
where the evidence points to women getting the short end of the stick.
And with a 6-year old (female) in the house, I'm especially sensitive to the
unpleasantness of whining!
But reading the National Innovation
Initiative's report emboldens me to comment. The marketing world is getting clued into
the
cumulative clout of women in the marketplace. The engineering world needs to
get clued in to the inventiveness and integrative power of women, but
how can it, when women are discouraged from entering engineering and
computer science careers? Take a look at this (S&E = science and
engineering):
"Women and minorities, the fastest growing
segments of the U.S. labor force, continue to be underrepresented in the
overall S&E workforce. Prospects for expanding the innovation talent
pool depend upon more successful recruitment among these groups.
-
There are few female full professors
in S&E; across all fields the percentage of women among full
professors ranges from 3% to 15%. In all but one discipline
surveyed, the highest percentage of female faculty is at the level
of assistant professor.
-
The traditional S&E talent pool of
white, non-Hispanics is projected to stop growing completely by 2030
at a peak of 210 million and then slowly decrease. In contrast, the
Hispanic population is projected to contribute 44% of U.S.
population growth from 2000 to 2020, and 62 percent from 2020 to
2050. In 2001, underrepresented minorities (black, American Indian
and Hispanic) comprised only 15.7% of S&E bachelor's degrees
awarded."
from the
National Innovation Initiative Report
In software and enterprise architecture
there are very few women. It is not uncommon for me to be the only woman
in the room in meetings among architects in IT and product
development alike. If there is another woman, she is expressing this
observation—usually she is the only woman in the room. (The same is true for
Hispanics, with generally 0 or 1 Hispanic architect in any meeting or
architecture workshop.)
What does this mean? As a gross
generalization, women and men have different styles (and given the
differences from woman to woman and man to man, in interest and in style
I am more like some men than many women). Technology is a means to an
end to me, it is not the holy grail itself. My brain works on
relationships among things, patterns, strategies. What I add to the
process is the ability to analyze and synthesize. These capabilities made me a hugely
productive programmer and a good system thinker. But I don't talk and act like
most of the male architects I work with.
Let me give you a concrete example. When two
architects are arguing about whether the CIM (Common Information Model)
is the same as a metadata model, I look for why they are choosing to see
the differences rather than the connections. I don't push myself into
the foreground and point out that we can translate from CIM to XML using
an off-the-shelf tool (like MDI Workbench or CIM2XML), or to a
proprietary metadata schema by writing a conversion tool. Instead,
I focus on understanding what the real point of the tension is. Then I
understand that the architect who has the proprietary schema legacy
problem is feeling that the issue shouldn't be treated as a
brush-off, hence the emphasis on the gap between CIM and the metadata
schema. That gives me much better insight into what it will take to move
to CIM as a standard across the organization. My approach is
architecturally significant. Its not what you would do. But that's what
makes my contribution important. That's what teams and diversity are all
about.
So why are there so few women architects?
First, how are you framing up technical careers
for the girls and young women you influence?
And how are you framing up women in your
technical community?
As much as affirmative action makes me
uncomfortable, disconfirming action is worse.
6/19/06
Icy
on CORBA
Once again, Kevin Furbish's
Architect's Linksblog sent me
on an interesting blog trail: Michi Henning's "The
Rise and Fall of CORBA," (From Component Technologies, Vol.
4, No. 5 - June 2006) is a superb assessment of CORBA's contribution and
shortcomings. Now I want Michi's assessment of SOAP and WSDL (there's a
partial assessment on
ZeroC's site), and I want Michi's assessment of web services as a
composition technology not just an orchestration/integration solution. I
get the feeling that Michi could do a good job of that. And then I'd
have a better sense of how Ice™
will stand the heat from SOA's day in the media sun.
And if you think Ice is nice, but think SOA is safer then you might
want to take a
look at NextAxiom™. I'm sorry, you'll have to "register to learn more."
6/19/06 Registration Pestilence and BugMeNot!
Why, why, why do companies and individuals want people to
register to access their site?
Tom Asacker's words come to mind: "You’re not in the real goods business any longer;
you’re in the feel goods business." Having to register makes
me feel bad. I can't tell you how many sites I simply ignore
because they have this urge to monitor who visits. I don't want push
marketing. If I did, I could volunteer to give them my contact
information. But to make registration a requirement for the privilege of
being sold on their product, makes me turn away from a vendor's site.
Yeah, I could use bugmenot.com
assuming someone else has created an account for the site in question,
but that's a workaround to an intrusive practice that I'd rather was
eliminated at the source.
6/20/06 Not Enough Talent
At the same time as I keep running into
software groups facing the huge emotional and economic wallop of lost
jobs to outsourcing and off-shoring, I also keep hearing that it is hard
to find enough software engineering talent to fill open positions (Joel
is always rattling the blogosphere for talent, and Microsoft program
managers, for example, are likewise indicating in their blogs that
they've had trouble filling open jobs). Partly, this is because the
human population is not homogenous, and the remarkably talented are
rare. And partly, we just have fewer people going into software:
"Students once saw computer-science classes
as their ticket to wealth. Now, as more technology jobs are outsourced
to other countries, such classes are seen as a path to unemployment.
New data show students' interest in the
discipline is in a free fall. The number of newly declared
computer-science majors declined 32 percent
from the fall of 2000 to the fall of 2004, according to a report
released this month by the Computing Research Association, which
represents computer scientists in industry and academe. Another survey,
from the Higher Education Research Institute at the University of
California at Los Angeles, shows that the number of incoming freshmen
who expressed an interest in majoring in computer science has
plummeted by 59 percent in the last four
years.
Students' waning enthusiasm for the field
worries technology companies that must work harder to fill vacant
positions, as well as researchers who need a steady supply of
intellectual talent to fuel scientific breakthroughs. Computer
scientists are already struggling to maintain basic research despite
sharply reduced financial support from government agencies."
"Student
Interest in Computer Science Plummets," The Chronicle of Higher
Education, May 27, 2005.
These things are related. Labor supply and
demand is a system. When we send jobs overseas en masse, we create
a labor shortage there, and, ironically, we create a labor shortage
here! We make the career unattractive here, and that has down-the-road consequences.
I'm all for creating great jobs everywhere
in the world; raise the standard of living for more people, give people
creative and intrinsically rewarding jobs, and more. But blindly rushing
to send jobs somewhere else to reduce short term labor costs
is going to have systemic, ill-effects that reverberate around the
entire global software labor system.
The young people of
this country, are not, generally, seeing software as an invigorating and
fulfilling career choice. A student working for me told me he was
majoring in Informatics rather than computer science at IU because he
didn't want the long hours of a programming career. I had the wind quite
blown out of me! What a misconception! We in software work long hours
because we are absorbed by it, passionately swept up in it. It is not a
chore. It is not by
fiat and
threat. It is a choice we make. Generally speaking. (I know, I've seen
project pressure-cookers that turn agile into fragile.)
So multiple forces are at play: most young
people stateside don't see the software engineering career as exciting,
and of those that do look into it, many are scared off by the tales of
massive job cuts in the US.
And that derth of Women thing, again
The same article goes on to say:
"In response, the National Science
Foundation and some colleges are stepping up efforts to promote computer
science — especially to women and some minority groups, whose
representation in the field is minuscule."
"Student
Interest in Computer Science Plummets," The Chronicle of Higher
Education, May 27, 2005.
They said it, not me. I just had to quote
them. But having done so, I have to reiterate:
How are you framing up technical careers
for the girls and young women you influence?
When I took computer science classes all
those eons ago, nobody had ever mentioned software development to me as
a career to consider. Fortunately, the (male) engineering students I hung out with on campus were
always programming all night and I wanted to get into
something that was that exciting.
6/20/06
Booch at Home at Last
I've checked in on
Grady Booch's blog several times since his heart surgery and for a
while there I was pretty worried by the silence. He has expressed
concern about the global population explosion, but I was hoping he
wasn't making a personal contribution to redressing that problem at this
point. He has important work to do for our field, and he is personally
uniquely capable, and personally in a unique position, to pull it off.
So, phew, it was a great relief to read that he is
back home and recuperating after some post-operative issues with
red-blood cell generation. In the end, it might not even set his
Architecture Handbook timeframe back at all—I'm expecting that with
priorities in clear focus following this set of challenges, he'll be
able to say no to more of those client/travel demands.
6/24/06 Conversations on the Sidelines
Many people tell me one-on-one, on the
sidelines, about their concerns around off-shoring. If the topic is
broached, managers firmly indicate the topic is not a matter for
discussion. There is merit to demonstrating leadership by good
following, and ranting about a direction chosen by senior management is
not good following. So the manager is just reinforcing the message: this
is the direction our business leadership has chosen, and we're not going
to undermine the strategy; the discussion is out of scope.
But there is enough uneasiness generated by
the topic, that it keeps coming up, despite the clear signals to "not go
there." So the conversations happen on the sidelines, and it is
harder to tackle them head-on. These conversations, I
hasten add, are not about less capability in any other country.
What is generally being pointed to is the difficulty in managing
distributed software development. And concerns about losing capability
and jobs in the US.
So I think the way out of this situation is
to make it work for everyone. Make outsourcing/off-shoring work so well
that it opens up more and better opportunities stateside, and more and
better opportunities off-shore. Make software engineering an attractor,
by showing up to everyone with enthusiasm for what software already makes
possible, and will make possible over the coming years.
And in the meantime, I'll make sure I give
my daughter equal opportunities to learn programming (I have begun teaching my 8 year old son). Like her
brother, she is already talking about technologies she's invented in
concept, that she will make real when she's older.
It is exciting that the architect career has
emerged in product R&D and IT, as this will appeal to the designer in
many girls. They won't have to see fashion design and interior
decorating as the only career streams fitting their design
inclinations—provided that we all take it as a responsibility to share
with them what this career is, and how to prepare for it, that is.
6/28/06 Smarter Offshoring
I just picked up my June 2006 issue of
Harvard Business Review (it came in the mail a few weeks ago, but I was
too swamped to even look at the ToC). In it, there is an article by
Diana Farrell titled "Smarter Offshoring." The article begins as follows:
"The most
popular offshore sites for service functions are overheating. Now is the
time for companies to explore a world of opportunity beyond those hot
spots and to base investment decisions not just on costs but also on
talent, markets, strategic aims, and appetite for risk."
Diana Farrell,
"Smarter Offshoring," Harvard Business Review, June 2006, p. 85
Turnover is already an issue in Indian
cities that top the popularity lists for offshoring—Farrell cites
30%-40% turnover in IT staff in the banking sector there.
But that doesn't mean the pressure is off
for stateside software developers. The McKinsey Global Institute has
"accessed the supply of college graduates suitable for employment by
multinational companies in 28 low-wage countries." They found that "more
than 90% of the talent is outside the current offshoring hot-spots."
Multiple considerations come into play: Farrell identifies cost,
availability of skills, environment, market potential, risk profile, and
quality of infrastructure.
This is interesting: the salary differential
between one bank's home-based software engineers and those in its Indian
offshore location (one of the "hotspots") is currently 80%. They
calculated that "even if inflation was to run rampant, there would still
be a 40% differential in 20 years." Actually, that
is true if you assume an inflation rate of 12.5% on a starting base of
$10k (versus $50k in the US, with 4% inflation in the US). But if you
think "rampant inflation" in software engineering salaries is more
likely to be in the vicinity of 20%, then you get to equalization at
12.5 years. This is improbable for fresh college grads perhaps, but not
so unrealistic for those with a few years experience to surf the salary
wave on.
A 5:1 salary differential is a big deal in
cost-sensitive markets and companies trying to survive in them have to
pay attention.
6/30/06 Is Design Dead?
Martin Fowler wrote a paper by this title (Is
Design Dead?) back in 2000, and it was last updated in May 2004. In
this paper, Fowler explored some of the contradictions that have arisen
in his personal journey: he has written books and been a proponent of
UML and patterns, yet he has become a proponent of Agile and XP, which
is quite broadly seen as de-emphasizing, or downright ignoring, UML,
patterns and everything else associated with up-front design.
This paper is quite balanced, and lends
insight into both the general debate around up-front design, as well as
Fowler's evolving perspective. He even confides that his home-life
influences his resistance to the "architect" title. His wife is a
structural engineer. She apparently treats building architects with some
degree of derision and animosity. This taints the "architect" label for
Martin Fowler, who wants to retain his wife's respect. But doesn't
Fowler see that this makes the title all the more appropriate? There is
always a tension when disciplines and roles overlap, so venting about
the failings of the other discipline, especially in the safety of the
home, is to be expected. It is no reason to shy away from the title for
a role which in our field also produces its share of animosity and
derision among some individuals in overlapping roles who perhaps feel
somewhat undervalued.
I have for quite some time thought that the
architect versus structural engineer distinction is going to arise in
the computing systems field, because as systems become more
complex, we will need disciplines that focus on sub-sets of the
concerns. So far we have divided focus more along the lines of
distinguishing different types of architect: system architect, software
architect, infrastructure architect, etc. As we get better and more
sophisticated about architectural mechanisms and build a theory behind
them, we may see our field creating a "structural engineer" focus in
educational curricula, practices, and professional certification.
However, the technologies move so fast in our world that it is hard to
get a stable base of theory under our feet before all is revolutionized
by the next wave of technological and process advancement. So we tend to
have to rely on the art and experience (and often courageous audacity)
of the architect.
Reading Fowler's paper reminded me of some
of the important contributions of the
Visual Architecting
Process:
-
the
minimalist architecture
principle emphasizes
deferring all decisions that can
be deferred (to the person or
team who has the expertise and
information, in the timeframe in
which they have it) without
compromising the architectural
objectives.
-
the
process iterates through (just
enough) architecturally
significant requirements,
architecture design and
specification, and architecture
validation, diving into details
if and as necessary to resolve
architectural risk, but pulling
back up to the architecture
views to consolidate decisions
and mature the architecture. The
process is fluid. It
specifically discourages a
waterfall approach, and does not
prescribe a strict ordering to
activities, though it does
recommend an initial ordering,
and it does describe what
decisions generally need to be
made and recorded (architecture
decision model).
-
architecture validation
activities start very
early, and continue throughout
the life of the architecture.
Architects need to validate
assumptions about business,
market and technology direction,
customer needs, and technical
imperatives, and the validation
discipline starts with vision
and architectural strategy.
Keeping to a validation rhythm
and discipline serves to
mitigate risk by bringing in
expertise and fresh perspective
to help identify deficiencies in
the architecture before it is
"hard-baked" in code. It also
serves to broaden understanding
of the architecture and
participation in bringing it to
excellence. This rhythm
continues in construction
cycles, and through subsequent
releases, keeping the
architecture vital and in sync
with requirements redirections
and hard-won lessons about what
does (not) work.
The
paper also reminds me to reinforce
some of the advantages of
architecture:
-
by
decomposing the system into
architectural elements with
clearly identified
responsibilities and
relationships, we can isolate
areas of risk and
experimentation, areas that
require innovation from areas
that are well-understood and
stable, areas that require
specialist focus, and so forth.
-
Comment 7/1/06: I ran out of
June, not ideas on advantages of
architecture!!
Feedback
Welcome: I
welcome discussion and feedback
on any of the topics in this
Journal.
Restrictions on Use: All original material written by Ruth Malan on this
page is copyrighted by Ruth Malan. All other material is clearly quoted
and ascribed to its source. If you wish to quote or paraphrase fragments
of material copyrighted by Ruth Malan in another publication or
web site, please properly acknowledge Ruth Malan as the source, with
appropriate reference to this web page. If you wish to republish any of
Ruth Malan's or Bredemeyer Consulting's work, in any medium, you must
get written permission from the lead author. Also, any commercial use
must be authorized in writing by Ruth Malan or Bredemeyer Consulting.
Thank you.
|
A Trace in the Sand