On Gaps, Technical Debts, and Outsourcing Strategies

Earlier, we said that Enterprise Architecture is not only about technology capability development, since its mission of alignment to target business outcomes makes the business capability development the true goal. Clearly it now makes sense that EA has that larger scope.  However, in this reflection, I'd like to place the focus back on the technology side, still along EA's original primary mission of aligning technology development towards business outcomes, but more of fixing the technology capability gaps to address the organization's information needs.

When we talk of technology gaps, we can mean those which are freshly discovered and gets high priority and placement into an early current initiative; or those which have been previously discovered, but needs to wait for proper timing before they can be acted on, as part of the later initiatives. And then, there are also cases of these technology gaps which were supposed to be done as per previous IT strategy and initiatives, but the dynamics and constraints of the organization could just not pull it off, and work can only be resumed on these for later initiatives.  These are those promises of future vision that are left behind, and as of yet, are placed as technical debt.

Technical Debt At the Architectural Level
David Norton, in his Gartner blog in 2011, reports that technical debt will accumulate its worth to about a trillion dollars through 2016, i.e. a trillion dollars of development work to remove bad code, fix poor architecture, correct a badly-formed technical strategy, or simply catch up to good design and original intents. Norton adds that the pace of business and technical change combined with faster delivery methods like agile and "citizen development" (super-user/developer), will only add to the speed on technical debt accumulation.  Agile can indeed be a double-edged sword, which when done right can have the quickness to remove technical debt and stop it being introduced in the first place; but when done wrong can be a "technical debt generating machine."

If we think about it, the technical debt metaphor is really just part of the so-called gaps that we need to close to move the current state architectures to the future-state architectures that we envision for the enterprise. Certain initiatives will incur debts (work that has to be done or "paid-off" eventually), because the transition to future-state can be incremental, possibly as a needed compromise, to move from an architectural stage to another as part of a viable strategy.  And although the debt metaphor is normally expressed in the context of the detailed applications development, we can also think of these technical debts in a bigger way, particularly when debts are incurred at the architecture level, where the foundational structures are incorrect or poorly established.


Sweeping under the rug.
A few years ago, our software company was going through a major shift in technology platforms, which brought all the architects to the table, forcing everyone to bring out the technical debts.  It's amazing how these debts can grow, and can catch everyone by surprise if not properly tracked amidst the whirlwind of development activities.  The making of a monster debt is usually when the complicit cabal will sweep the "stragglers" from previous projects under the rug, where all the collective technical debt is truly waiting for the ultimate "collector". It's when folks, particularly those higher in the ladder, do not have the courage to bite the bullet, and deal with technical debts prudently, rather than just looking for the next fall guy to blame the problem when these debts collapse. The boss of my boss, has many dead bodies of previous fall guys in his closet, but eventually was himself kicked out. To be honest, it was a bit of justice long overdue.


Outsourcing: The Supposedly Easier and Logical IT Strategy
At one level or another, Ross et al argues that outsourcing should be part of every organization's strategy, and devotes the whole of chapter 7 to outsourcing, explaining how to use Enterprise Architecture to guide outsourcing.  The story of Campbell's transformation, both from a technology and business perspective, demonstrates the use of outsourcing by enabling the organization to focus their management capacities to core activities such as customer collaborations, trade promotions, R&D, and innovation -- rather than constraining their leaders with computer operations.  Consequently Campbell completely outsourced their infrastructure to IBM, who has the capabilities to address and resolve the technical debts quicker than Campbell could on their own.

Not all outsourcing will be successful, as Ross warns us of the need to apply our understanding of the enterprise's operating model, as well as use the EA framework for effective outsourcing decisions, in order to achieve the benefits that strategy can bring. And although Ross points out that an organization should not outsource the management of its architecture development, they can definitely outsource the construction of that architecture, while focusing their energies in understanding how to move the organization incrementally through the changes and architectural stages. As a final caveat, Ross notes that while the technical challenges of architecture can be outsourced and transferred to a vendor, the organization must be ready for the relationship challenges that will replace those technical challenges.

In some cases, outsourcing may not be the best option for the organization as it stands at a certain point in time. And perhaps the shared services approach will make the most sense, particularly when control is a top priority, and when said services are quite unique to the organization -- and brings a competitive advantage. However, success with the shared services approach depends on having adequate systems, skills, and capacities. If these are not on par with what an outsourcing vendor offers, it is hard for shared services to be competitive.  At any rate, EA can bring clarity for decisions, and provide options to make shared services a transition towards a full outsource paradigm.

Some Outsourcing Trends

Production workloads, and more, are getting transferred to cloud services. Amazon had the first mover advantage with the public cloud. Early adopters such as IT shops, who hopped on to the cloud first, did so with non-critical systems, i.e. testing the new environment. But in 2016, technology pundits agree that there will be more production workloads moving to the cloud, and not just on AWS. IT organizations recognize that the future of their data centers will need many platforms, so they expect to see more CIOs experiment with other major public cloud options, such as Microsoft Azure and Google Cloud Platform.

Integration challenges continue to surge.  I agree with those who observe that companies are adopting an ever larger number of emerging digital technologies, and will face an ever-larger integration challenge. From our experience with our own customers, I also see that many of the most powerful cloud technologies will require integration efforts very similar to those required to install ERP systems.  Surprisingly, but apparently a keen assessment, that most companies do not have employees capable of managing multiple emerging technology platforms, which makes it a logical strategy for these companies to outsource (or at least consult) for service integration, incident management, and change management. We can definitely expect increasing outsourcing partnerships among providers, as Ross has argued in our course book as well.

The cloud initiatives, while it can also have the "private cloud" flavor, are essentially an outsourcing paradigm because it is the external paradigm which makes the most sense when doing cloud.  This is clear to the outsourcing industry itself, which is more and more, shifting its business model to cloud delivery. Big Data handling is connected.  Not many organizations will have the kind of infrastructure that can really be optimized to handle Big Data.  Cloud allows the organization a cost-effective entry into big data benefits.

BTW, if you're still confused on why big data is such a big thing, read Mayer-Schönberger's  book on big data (book listed below).


Conclusion
Enterprise Architecture can improve IT and business alignment by integrating the EA practice with enterprise IT planning processes. By providing the clarity of alignment of future state architectures to strategies for achieving target business outcomes, EA can provide enabling guidance in formulating effective IT strategies. Moreover, as part of its methodology, the EA practice can identify the technology trends that would be strategically meaningful for the organization, determine the transition roadmaps towards innovations, and define outsourcing boundaries and strategies to quickly resolve technical debts and close the capability gaps.

EA can define the transitions needed towards an outsourcing paradigm suited to the organization's culture and operating model. Outsourcing typically will make the most sense for strategies that require fundamental change, with a high requirement for agility, and with cost reduction as a high priority. When an organization can acknowledge a vendor’s superior systems, and their advanced processes, skills, combined with capacities and the economies of scale -- the organization is not prudent not to take that strategy.



Readings:
Norton, D. (2011 Dec 04). The Ticking Time Bombing Of Technical Debt. Online Blog. Gartner Publication. Retrieved from http://blogs.gartner.com/david_norton/2011/12/04/the-ticking-time-bombing-of-technical-debt/

Overby, S. (2015 Dec 29). 10 Outsourcing Trends to Watch in 2016.  Online Article. CIO Magazine. Retrieved from http://www.cio.com/article/3018638/outsourcing/10-outsourcing-trends-to-watch-in-2016.html

Sako, M. (2010 July). Outsourcing Versus Shared Services.  Research Paper. Technology Strategy and Management, Communications of the ACM, Vol. 53 No. 7, Pages 27-29. Retrieved online from http://cacm.acm.org/magazines/2010/7/95037-outsourcing-versus-shared-services/fulltext

Mayer-Schönberger, V., Cukier, K. (2014 March 4).  Big Data: A Revolution That Will Transform How We Live, Work, and Think.  Paperback. First Mariner Books. Houghton Mifflin Harcourt Publishing, New York.