Outsourcing on Ulitzer

Software businesses that engage in offshore outsourcing face a number of risks.  Of particular importance to the software architect, is the risk associated with the architectural fidelity of the company’s software products.  Small and mid-sized enterprises (SMEs) and ISVs face greater levels of difficulty than do their large enterprise counterparts when it comes to managing offshore outsourcing.  To deal with this issue, I have developed a context model that can be used to help the small company find the right resource mix; enabling it to maintain an appropriate level of manageable risk while enjoying the benefits of offshore outsourcing.

Risks

Along with its many benefits, offshore outsourcing brings with it a number of risks.  Some of the more high-profile risk categories include intellectual property (IP) risk, continuity and geopolitical risk, product quality risk, and data security risk.

There already exists a significant body of work describing various risks and mitigation techniques related to offshore outsourcing.  I won’t rehash them here.  This article focuses on a particular aspect of quality risk from the perspective of the software architect.

Large versus Small and Mid-sized Enterprise

Small and mid-sized enterprises (SMEs) face greater levels of difficulty than do their large enterprise counterparts when it comes to managing offshore outsourcing.   This is largely a result of the different mitigation strategies available to large and small businesses.  The options differ dramatically based on cost and budget.

For starters, the large enterprise looks upon offshore outsourcing giants Infosys, Wipro, and Tata as viable options.  The small ISV or enterprise can no more afford to engage those service providers than they could Accenture or Deloitte.

The larger offshore outsourcing houses have already in place the people, processes, and tools necessary to reduce many of the associated risks.  However, this intrinsic risk mitigation comes at a premium.  These large offshore outsourcing firms are typically beyond the budget of SMEs. 

The SME must typically engage the smaller, less robust offshore outsourcing outfit.  In these scenarios there are typically no risk mitigation scale economies from which to benefit.  In other words, the SME must either bear the cost of risk mitigation alone, accept reduced risk mitigation measures, or forego them altogether.

The Software Architect’s Dilemma

Whether engaged in new development or product maintenance, there are a number of product engineering activities that must be carefully managed when leveraging globally distributed software development teams.  A sampling of these activities are listed in the chart below.

The software architect must ensure the architectural fidelity of the company’s products.  This requires that consistency of vision permeate through the architecture, design, and development of those products.  The final output of the development activity must

1. match what was designed,
2. fit within the prescribed architecture,
3. meet the requirements, and
4. deliver on the vision.

Product quality is directly related to the degree of architectural fidelity.  Ultimately, the software architect is responsible for delivering quality products.  However, one must manage through external pressures, as well as supply chain issues, in order to achieve desired outcomes.  As a result, the software architect must perform a delicate balancing act.

The decision to pursue offshore outsourcing is typically the result of external pressure to reduce cost.   On top of that, time-to-market pressures normally loom large in any software endeavor.  In the absence of proper discipline, these pressures can lead to cut corners; which threatens architectural fidelity and product quality.

Additionally, managing the supply or developer mix can be very challenging.  Offshore outsourcing comes ready-made with cultural and communication issues.  The ability to be in the same room or, at least, start off on the same page is not always possible.  If the business has diversified its offshore outsourcing mix across multiple countries (in order to mitigate geopolitical risks), then the issues are compounded.  Unresolved communication challenges and cultural differences can cause a negative impact on architectural fidelity and product quality.

“With globally distributed software development teams, quality issues are always a risk”, says Inspector IT CEO Antonio Chagoury; who manages a software development team distributed across three (3) different continents.  “Quality can be managed with people, processes, and tools.  At the end of the day, you get what you pay for.”

For the SME, the people + process + tools = quality equation is primarily influenced by budget.  Budget will influence the available options and hence the decisions made around the product engineering activity mix.

SME Product Engineering Context Model

In the previous section, four (4) categories of product engineering activities were highlighted as particularly critical when it comes to maintaining product quality with globally distributed software development teams.

As depicted in the diagram below, these categories of product engineering  activities can be arranged into a context stack.  Understanding at the top of the stack requires the broadest context.  Activity at the bottom of the stack requires narrow but deeper, more granular understanding.  In other words, as you move down the stack the activities change from requiring a strategic to a tactical context.

Architectural fidelity of software products will be at risk if there is a disconnect between the various managers and teams responsible for vision, architecture, design and development activities.  Keeping these groups closely aligned, therefore, becomes a critical function of the software architect.

Large enterprises dealing with large offshore outsourcing firms can afford, oft times, to outsource the entire product engineering activity stack; reducing the risk of misalignment.  SMEs typically do not have that luxury.  Considering its offshore outsourcing options, the SME would increase its risk were it to outsource the entire stack.  The SME software architect must manage the distribution of roles and responsibilities along the product engineering activity stack across a mix of globally distributed resources.

At a minimum, the SME software architect should maintain onshore all activities related to product vision.  Using this position as a starting point, there are a number of potential pitfalls associated with decisions to maintain onshore or delegate offshore the architecture, design, and development activities.

The mix depicted in the diagram above is what I consider the SME offshore outsourcing sweet spot.  Technical thought-leadership is maintained onshore within the SME while the tactical development and implementation activities are performed offshore.

Maintaining onshore the vision, architecture, and design ensures that architectural fidelity is baked into the product blueprints.  Eliminating cultural, communication, and proximity issues within this portion of the activity stack drastically reduces the potential for increased risk in the software development process.

In what I defined as the SME offshore outsourcing sweet spot, the largest potential risk to architectural fidelity and, thus, quality is the context switch that occurs when software designs are handed over to offshore resources for development and implementation.  Limiting the potential for increased risks to this single point within the activity stack increases the impact of the tools and processes that are deployed in order to mitigate that risk.

Conclusion

Small and mid-sized enterprises are forced to do more with less.  As a result, they don’t have available to them the same offshore outsourcing risk mitigation options as their large enterprise counterparts.  Using the product engineering activity context model, SME software architects can customize their offshore outsourcing activities to achieve their desired acceptable risk level.  Ultimately, these decisions impact architectural fidelity; which has a direct impact on product quality.

What I have presented is a working model that will continue to evolve.  I would love to hear feedback from other managers and architects that are dealing with these issues in order to gain further insight.

Photo credit Trumpeteer 01.