Visual architectingA Trace in the Sand

by Ruth Malan

 

 

 

 

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!!

 

Copyright © 2006 by Ruth Malan
URL: http://www.ruthmalan.com
Page Created: June 1, 2006
Last Modified: January 25, 2015

I also write at:

- Bredemeyer Resources for  Architects

- Trace In the Sand Blog

 

June Topics

- Leading with Leadership

- Software is Not Limited by Physics

- Architect Competency: Leadership

- StumbleUpon

- Eat Your Own Dog Food

- Architect as Statesman

- Architect as Statesman or Executor

- Outsourcing Downsizes our Innovation Engine

- Opening Up the Innovation Engine

- Break-through Thinking

- Leadership and Command-and-Control

- Joel on Software Managers

- Outsourcing Our Core Competency

- Women and Architecture

- Icy on CORBA

- Registration Pestilence and BugMeNot

- Not Enough Talent

- Derth of Women

- Booch at Home at Last

- StumbleUpon Right After Yahoo

- What Scott Berkun has to Say

- Is Design Dead?

 

 

Journal Archives

2014

- January
- February
- March
- April
- May
- June
- July
- August
- September
- October
- November

 

2013

- January
- February
- March
- April
- May
- June
- July
- August
- September
- October
- November
- December

2012

- January
- February
- March
- April
- May
- June
- July
- August
- September
- October
- November
- December

 

2011

- January
- February
- March
- April
- May
- June
- July
- August
- September
- October
- November
- December

 

2010

- January
- February
- March
- April
- May
- June
- July 
- August
- September
- October
- November
- December

2009

- January
- February
- March 
- April
- May
- June
- July
- August 
- September
- October
- November
- December

2008

- January
- February
- March
- April
- May
- June
- July
- August
- September
- October
- November
- December

2007

- January
- 
February
- March
- April
- May
- June
- July
- August
- September
- October
- November
- December

2006

- February
- March
- April
- May
- June
- July
- August
- September
- October
- November
- December