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

August 29, 2008

SOA Liberates Productivity

Harvard Business Review (HBR), June 2008, has a wonderful article (by Ric Merrifield, Jack Calhoun, and Dennis Stevens) on how SOA is “the next revolution in productivity.”

SOA defined:

“It is becoming possible to design many business activities as Lego-like software components that can be easily put together and taken apart…service-oriented architecture [is] a relatively new way of designing and deploying the software that supports a business activity.”

With SOA, business activities can be accessed via the Internet through web services. Rather than build proprietary, redundant business services, our organizations can re-use standardized services, developed internally or outsourced, as components that plug and play into our enterprise.

“Virtually all large companies suffer from an enormous duplication of activities; they continue to create and perform hundreds of non-core tasks that would ideally be outsourced; and they are spending exorbitant amounts on IT projects in order to support redundant and nonstrategic operations and to update core processes.”

How does this differ from other quality improvement initiatives?

Prior quality improvement efforts like Total Quality Management (TQM) and Six Sigma have focused on reducing waste and defects and eliminating unnecessary tasks and integrating disparate ones.

“For the most part, however, reengineering has involved recasting processes and the information systems that support them in a proprietary, rather than a standardized, form—that is, customized for individual organizations. Such designs make it difficult and expensive for business to share, consolidate, and change processes.”

Now with the Internet and web services, we can access standardized services that can be shared and re-used throughout disparate business units in the same enterprise and across organizations globally.

The result is business units and organizations that can simply plug and play to make use of needed services, eliminating proprietary processes and redundant systems and enabling outsourcing of noncore mission functions and activities and easier upgrades to new superior services as they come online.

What are some of the issues holding SOA back?

Firstly, many people do not truly understand SOA, what it is, what benefits are possible, and what the challenges are to doing it right.

Second, SOA is viewed by many executives as yet another hype or bubble that will cost the enterprise lots of money, but fail to provide the promised return. So, they are wading into SOA only enough to “deploy it in a limited fashion,” but without first rethinking the design of their business.” However, to really reap the benefits of SOA, organizations need to transform from “collections of proprietary operations into a collection of standard plug-and-play activities,” and this requires redesigning not only IT systems, but operations.

In designing SOA-based processes, the unit of analysis and reengineering is no longer the task (as in Frederick Taylor time and motion studies of the late nineteenth century) or the department, or even the division. “In the age of the Internet and SOA, the unit of analysis is not a company’s way of conducting its operations at all; it is the primary purpose or desired outcome of each activity no matter how that activity is accomplished.”

Where are we today with SOA implementation?

“Unfortunately, few companies are using SOA to create more productive and focused organizations or to slash costs by purging duplicative operations and technologies. They are not revisiting the fundamental design of their operations.”

To overcome the obstacles in reaching SOA enabled organizations, we need a strong dose of enterprise architecture to identify and decompose our performance outcomes we are driving toward, the business processes to achieve these, the information required to perform these, and the systems that can serve them up.

According to HBR, our business model activities can be categorized into the following for SOA implementation:

  • Primary (I would call this core mission)—those that should be kept in-house and are “top priority of programs to improve operations and technology” (i.e. through business process improvement, reengineering, and the introduction of new technology).
  • Shared—those that “can be shared with other divisions” (i.e. through common solutions).
  • Shifted—those that “can be transferred to customers, suppliers, or operational specialists” (i.e. outsourced).
  • Automated---those that can be “automated so they can be turned into web services.”

All but the primary activities are ripe for SOA-based enhancements. And according to HBR, only about 20% of activities are primary, so that leaves plenty of room for a SOA plug-and-play.

The idea is to cease defining our noncore mission processes and activities as proprietary, requiring elaborate and expensive customized solutions for these. Instead, we should use standardized “swapped, bought, or sold” services. Then, we can truly focus our business process reengineering and IT investments on our organization’s core mission activities—working to to differentiate ourselves and develop unsurpassed competitive advantage.


Share/Save/Bookmark

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