Showing posts with label Outsourcing. Show all posts
Showing posts with label Outsourcing. Show all posts

June 13, 2008

What Goes Around Comes Around and Enterprise Architecture

As an enterprise architect, I have always wondered about the trend of outsourcing our manufacturing jobs out of country-- where as a nation we erode our manufacturing base and ship this capability to China, India, Mexico, and other countries where labor is plentiful and cheap.

Yes, in the short term we are taking advantage of the lower costs of manufacturing in other countries, but long term, I always questioned the viability of this strategy thinking that surely every nation needs to maintain a core of critical manufacturing and service capabilities and infrastructure to guarantee self-sufficiency, protect itself from eventual global disruptions, and ensure the continuity of its existence.

I believe that some day (and maybe relatively soon), we will regret the near-sightedness of our decisions to move production abroad for the sake of the dollar today.

Interestingly enough, I read in the Wall Street Journal today, 13 June 2008, that “stung by soaring transport coasts, factories bring jobs home again.”

“The rising costs of shipping everything from industrial-pump parts to lawn mower batteries to living-room sofas is forcing some manufacturers to bring production back to North America and freeze plans to send even more work oversees.”

I thought to myself—Hallelujah!

No, I am not happy that oil prices are soaring and that inflation is looming everywhere, but I am cautiously relieved that perhaps, we as a nation will wake up in time to secure our economic interests at home and not send our entire manufacturing base and capabilities out of country.

Ironically (da!), the further we move our factories away, the more it costs now to ship the goods back home.

“The movement of factories to low-cost countries further and further away has been a bitter-sweet three-decade long story for the U.S. economy, knocking workers out of good-paying manufacturing jobs even as it drove down the price of goods for consumers. But after exploding over the past 10 years that march has been slowing. The cost of shipping a standard 40-foot container from Asia to the East Coast has already tripled since 2000 and will double again as oil prices head toward $200 a barrel…In the world of triple-digit oil prices, distance costs money.”

The other thought that always kept coming to mind was that as we continue to move manufacturing abroad, the increasing demand for labor would drive the cost of labor up, and eat away at the cost differential making the overseas move a moot point.

Again, I read today in the Journal the story I always felt was bound to be told and to continue to unfold: “The cost of doing business in China in particular has grown steadily as workers there demand higher wages and the government enforces tougher environmental and other controls. China’s currency has also appreciated against the dollar…increasing the cost of products in the U.S.”

One problem with trying to bring the jobs back home…

“Much of the basic infrastructure needed to support many industries—such as suppliers who specialize in producing parts or repairing machines—has dwindled or disappeared.”

What goes around, comes around. The jobs (some) are coming home (although net-net, we’re still losing manufacturing jobs). As a country, we‘ve benefited in the short-term from outsourcing, but in the long-term, I believe we’ll have done ourselves a good deal of harm.

Does this sound unfamiliar?

Think national deficit—big time. Think gargantuan problems with social security, Medicare, health care, and so on.

All too often, we behave with short-sightedness and like infants, the desire for immediate gratification. But as enterprise architects, I believe we need to think long term and often defer gratification for long-term competitiveness, self-sufficiency, and survival.


Share/Save/Bookmark

May 18, 2008

Competitive Sourcing and Enterprise Architecture

Our economy is heavily based on ensuring a competitive environment to drive innovation, cost-competition, and consumer value.
One of the reasons why mergers and acquisitions are reviewed so carefully is to ensure that they are not anti-competitive, which would result in antitrust action.
Competition law, known in the United States as "antitrust law," has three main elements:
  • Prohibiting agreements or practices that restrict free trading and competition between business entities. This includes in particular the repression of cartels.
  • Banning abusive behavior by a firm dominating a market, or anti-competitive practices that tend to lead to such a dominant position.…
  • Supervising the mergers and acquisitions of large corporations, including some joint ventures. Transactions that are considered to threaten the competitive process can be prohibited altogether, or approved subject to "remedies" such as an obligation to divest part of the merged business or to offer licenses or access to facilities to enable other businesses to continue competing. (Wikipedia)
Competition law has been extended to the federal workforce as follows:
The Office of Management and Budget Circular A-76 mandates that “To ensure that the American people receive maximum value for their tax dollars, commercial activities should be subject to the forces of competition.” This includes the following activities:
“a. Identify all activities performed by government personnel as either commercial or inherently governmental.
b. Perform inherently governmental activities with government personnel.
c. Use a streamlined or standard competition to determine if government personnel should perform a commercial activity.”
The concept of A-76 is that without federal workers having to compete for their positions against for example, the private sector, then there is no way to ensure value for the American taxpayer. Where is the incentive for the federal workforce to perform if when they aren’t performing competitively, and they are not threatened with replacement by a better, more effective and efficient provider?
Federal Times, 12 May 2008 reports that “all indications are that as the Bush administration winds down, so too has its most controversial government reform: competitive sourcing.”
“Many in Congress have aggressively challenged the practice as being unfair and demoralizing to federal employees and last year they passed myriad reforms and restrictions that are already being felt.”
While I agree that competitions drive efficiency in the marketplace, I think A-76 has missed the mark in terms of reforming federal human capital.
Why?
Competing federal workforce against private sector contractors on a cost basis does not necessarily ensure best value. From an enterprise architecture perspective, we are missing something crucial in A-76 and that is the human capital perspective.
The human capital perspective on EA is one that was initially proposed by John Zachman, the founder of EA, and I am a strong proponent of it. Essentially, it says that just like the other business and technology perspectives of the EA, human capital is a filter through which you must make organizational decisions.
The human capital perspective of the architecture provides us an opportunity to optimize federal workforce performance in the first place, before getting to an outsourcing decision point. Additionally, if you can’t effectively manage your own workforce, what makes you think you can better manage a contracted-out function? (In the same issue of Federal Times, there was an article about how the federal procurement officials are resigning in droves!)
What can we do to first improve performance results from the federal workforce (and I’m not saying that there is any problem to begin with)? The same as with any organization—provide strong leadership to them. Provide them with a bold vision. Hire the best and the brightest. Accelerate the hiring and clearance processes. Make clear their roles. Inspire them as President Kennedy did when he stated “Ask not what your country can do for you, ask what you can do for your country.” Challenge the workforce and empower them. Provide training, career growth, and financial and other incentives. With these, the federal workforce can truly be competitive and best value—if not all the time, then certainly much of the time.
The enterprise architecture way to do this is to first, baseline your current workforce. Then, look at best practices, benchmark, and set the targets for your people. And finally, develop a transition plan to move your workforce from the baseline to the target.
There is much more work to be done in this area, and obviously this is just a cursory overview or sketch of what the human capital perspective of EA would do. On a personal note, this is an area of great interest to me and I look forward to exploring it further.
Share/Save/Bookmark

April 24, 2008

IT Roles Are Changing and Enterprise Architecture

These days, everyone likes to think that they are an architect and the ways things are going, soon this may become a reality.

ComputerWorld, 7 April 2008 reports that “New IT titles portend a revolution in IT roles.”

“Don’t expect to be part of an IT department. As a 21st century technology professional, your future—and most likely your desk—will be on the business side, and your title will likely be scrubbed of any hint of computers, databases, software, or data networks.”

Technology is being down-played and business requirements are in focus. This is good EA and common sense.

“IT is no longer a subset specialty. It is integrated into whatever work you’re trying to get done…IT is being disintermediated, but in a good way. It is being pushed farther up the food chain.”

IT is no longer being viewed as a mere utility to keep the network up, email running, and the dial tone on. Rather, IT folks are being seen as full partners with the business to solve problems. YES!

“No one know s exactly what to call these positions, but they definitely include more than pure technical skills. ‘If you’re a heads-down programmer, you’re at a terrible disadvantage.’”

The CTO of Animas, a web hosting company stated: “Outsourcing, globalization and the cost reduction for WAN technology all work to eliminate the need for systems administrators, help desk people, or developers. We don’t want developers on our staff for all of these technologies. We pretty much have kept only business-savvy people who we expect to be partners in each department and to come up with solutions.

Solving business problems requires the ability to synthesize business and technology and let business drive technology. Hence, the new glorification and proliferation of architects in today’s organizations.

David McCue, the CIO of Computer Sciences Corp. says “You’ll see titles like ‘solutions architect’ and ‘product architect’ that convey involvement in providing the product or service to a purchaser.” Similarly, the CIO of TNS, a large market research company, stated: “everyone is either an architect or an engineer.”

“Although job titles for all of these emerging roles have yet to be standardized, the overall career-focus seems pretty clear: It’s all about business.”

Wise CIOs are changing their focus from day-to-day technology operations to strategic business issues. That’s the sweet spot where value can be added by the CIO.

Enterprise architecture and IT governance are the CIO’s levers to partner with the business and plan their IT more effectively and to govern it more soundly, so that IT investments are going to get the business side, the biggest bang for their buck.


Share/Save/Bookmark

March 21, 2008

The Foreign Software Threat and Enterprise Architecture


Enterprise architecture is the developer and keeper of the organization's systems inventory, and it is the champion for system interoperability, integration, standardization, and modernization. Of course, all this within the framework of a secure information infrastructure.

What happens though when the security of systems is threatened from the inside—that is through malicious code itself?

Imagine a terrorist sleeper cell embedded in our country that can be activated at any time to cause destruction and havoc. So too, hidden malicious software code can be embedded in applications developed overseas or even by homegrown adversaries. And this code can be launched or used as a back door to disable our vital military systems for communications, weapons, navigation, and so on.

Military Information Technology, April 2008, reports that “DoD combats risks of a ‘mole’ in software written in other nations.”

According to a March 2007 report by the Center for Strategic and International Studies (CSIS), “malicious code, cyber-attacks, and espionage [are cited] as top threats facing the DoD and defense industry today, resulting primarily from software developed overseas, and to a lesser extent, from the global use of commercial software.”

Further, “the CSIS report noted that the number of U.S. companies outsourcing software development overseas had grown 25% from 2003 to 2006.”

“In September [2007], the Defense Science Board Task Force…came to similar conclusions” about foreign software exploitation. It states: “'while COTS development environments are more porous to attack than those of DoD custom development environments,’ subversion of the latter is more like to achieve adversarial objectives.”

Custom code does not get the same scrutiny as commercial code (especially open source) and so it is more vulnerable to exploitation via back doors or malicious code written into the software.

Dan Geer, the chief scientist and vice president of Verdasys, a security software firm, states: “Instead of trying to put a mole in the CIA, they try to put a mole in software.”

While “the technology industry has made progress at finding which writing patterns leave software vulnerable to inadvertent bugs…we don’t have as good a handle on what malicious programmers introduce.”

So how can we architect safer software?

  1. Scan—conduct vulnerability scans of software to identify known vulnerabilities.
  2. Patch—when vulnerabilities are detected, patch them quickly.
  3. Inform—have developers disclose what tools they are using and how they developed the code.
  4. Test—embed security testing and analysis in all phases of the systems development life cycle.
  5. Measure—develop metrics for software assurance so it can be rated and improved on.

Of course, we also need to ensure that developers are security-cleared to work on the software being developed or customized and that we layer our defenses and create redundant systems so that we mitigate risk from any single particular entry point.


Share/Save/Bookmark