Is IT-Business/Domain Knowledge [While Offshoring] overrated? ... Continued
Among my recent blog posts, the one asking ‘Is IT-Business/Domain Knowledge overrated?” generated a fair number of comments, as is to be expected. After all, “Business IT Alignment” is the holy grail of management thinking with even academic and business media spending reams of newsprint to the topic.
My question was rhetorical as I was trying to draw on my observations and past experiences in the field. Vikas Ohri comments “Knowing domain helps to break communication barriers, appreciate the business need, relate to impact of your system in the overall scenario even when it is not explicitly stated….. Analysis of failed IT programs does provide some insights... ”
Similarly, Robert Rojas comments “It sounds like you're saying that a shortage of domain expertise means it should not be sought after. … Just because the expertise is not there does not diminish its importance.”
Ram posted a comment asking if I might want to take up "common" domains like Banking or Retail, argue the same case and see how much sense the article makes in that context. Therefore, let me illustrate my thinking with another example.
In my past life (before joining Infosys to begin my offshoring odyssey) I spent a few years working with a large Telecommunications giant in the American mid-west. The systems my group was focused on was to do with managing “Access Service Requests” (ASRs) which are industry standard ‘forms’ used by Telcos to communicate network access details with each other. ASRs are complex forms defined by the Ordering and Billing Forum (OBF), used by long-distance carriers to communicate requests with Local Exchange Carriers (LEC). In the broader business context, my company had to pay the LEC for each network request and would get paid by billing customers.
The “IT” part of the world involved managing complex databases, UI, business rules, workflow and systems to enable network engineers and operators to request access for customers and to ensure that the ‘end to end’ connectivity of customers, switching, networking etc would be transparent to everyone involved. The systems had taken years to design and develop and had to be dynamic enough to provide for periodic changes coming from OBF : The representatives met every six months to define new set of interchange standards, which would require modification to the ‘forms,’ in turn the systems - workflow, business rules and 'logic' - at different ends (our Telco, LECs etc). A process of continual change, if you will.
Even after spending years at the Telco, I will not claim to be an expert on ASRs or OBF or even the systems that fascilitate the interchange between the Telcos. The point I was trying to make in my earlier blog post was this: It took me about 5-6 months at the Telco to understand the jargon -- the three and four letter acronyms -- and figure out the different pockets of knowledge. The ‘business’ folks in the team were either folks who had risen from the ranks of call-center or were network-engineers from the field. The ‘years’ of business knowledge many of them brought to the table was primarily with regards to the fluency with which they could utter the jargon, especially as the OBF standards were also constantly changing. For instance, this was the time DSL technologies were going mainstream and standards for DSL interchange were being incorporated into ASRs. The marketing folks at the Telco were really wired-up (pun intended) on ensuring that we lead the pack in providing DSL packages to our customers. The ‘business’ folks - the technicians and network engineers in the field, call center folks and others – were also learning about DSL, just as we were coming to grips with intricacies involved in providing for access to it.
Now, let us switch gears and extrapolate this as an offshoring scenario. Following thoughts/queries come to mind, based on the comments my earlier post generated:
a) The focus of the IT team was on re-engineering the ‘system’ (UI, Databases, middleware, interfaces etc) to accommodate the new business channel, in this case DSL.
b) The same ASOG guidelines (300/400 page reference manual) that the business was studying, was available to IT. The ‘business rules’ and intricacies also were documented in it.
c) In this scenario, given that both the ‘IT’ and ‘Business’ folks were learning to come to grips with implications of DSL technology, could the IT component -- re-architecture, design, development and testing -- not be done offshore?
d) The Telco's team was already geographically distributed. Business was located in Virginia, IT in Colorado and Texas with users all over US....so I am guessing that having another IT team a 'few more' time-zones away would not be a real challenge
e) For the argument, assume that 'normal' interaction and communication between business and IT folks continue, using tools and techniques used in managing globally distributed teams.
This argument is by no means rigorous or conclusive, so let the debate continue.
Comments
I think the future of business process outsourcing must include more use of business rules. The ability to run a fairly standard process and then use business rules-powered decision services to flex it for each customer seems compelling to me with the added benefit of putting the business more directly in charge of their logic.
Posted by: James Taylor | May 11, 2007 10:54 PM
Mary Lacity (who I assume you have at least heard of Mohan) has been presenting some very interesting findings on domain knowledge from her latest outsourcing research. In short, and not surprisingly, Domain Expertise means two completely different things to IT suppliers and their clients. To IT suppliers, it is considered "industry knowledge" (Finance, Health Care, Tech, Retail etc), but to clients it is taken to mean specific knowledge about there individual business including it's own unique idiosynchrasies (including politics and the inevitable irrational aspects).
No easy answers on this topic :-)
Posted by: michael | May 15, 2007 07:14 PM
Michael,
I have been intermittently following Mary Lacity’s work on the topic….and as you rightly say 'No easy answers on this topic'
;-)
Posted by: Mohan | May 16, 2007 01:30 PM
The core objective of any IT project should be to drive Business agility, innovation, improvements and value. In order to achieve the said objective a deep knowledge of business –unit operations and core processes is extremely useful. Typically, line of businesses and IT have a very narrow channel of communication that results in delays in getting new products and services rolled out to customers. This also impacts the ability to make changes to existing products and services to maintain their competitive edge. To increase business agility, enterprises need to increase the channel of communication and the speed of change between business and IT.
Companies should therefore concentrate on building IT professionals with core business process knowledge ( we need to collapse the BA and IT into one role), they would have the necessary business knowledge and are IT savvy to deliver on the commitments promised by IT to business in terms of innovation, agility and value
Posted by: Chetan Bhor | May 20, 2007 03:34 PM
Chetan,
While your theory reads soundly, I think it in fact it is wrong, or at least far too conservative to be complete. I will borrow from a bit of chaos theory here and suggest that if you agree core goals include increased pace of change and agility in virtually any enterprise today, deep knowledge of business could be argued to be as detrimental as useful.
Firstly, most reliable businesses are change averse, so on that level deep expertise can act as an obstacle to accelerated change (although admittedly and paradoxically likely an operational benefit). In nature and quantum physics we have learned that often times to achieve a higher level of order, chaos is an integral ingredient as it acts as a catalyst. Organizationally this means that innovators who understand broad IT capabilities and directions (whether SOA or AI) are an important ingredient in the business/IT mix. They are not as invested in the status quo and can provide vision to help inspire the plunge towards an uncertain future.
In general, although it may need to be organizationally repositioned or at least utilized more effectively, deep business process knowledge is already present in sufficient quantities to drive the status quo and incremental change. Agility calls for marrying that with bolder change, and that may often require a degree of ignorance of all that can go wrong. Fail forward fast is a play on words, as it really means "Go forward fast" and smart self organizing individuals will begin to solve business problems in a totally new way that, although occasionally "bumpy" (the "fail" part), is far more in line with the unprecedented competitive demands of today.
In a different vein, but with the same conclusions, take typical ERP systems (please ;-). These huge ambitious software systems are nearly ubiquitous in large enterprises and represent staggering investments, yet a closer look reveals that roughly 50% of them fail to realize stakeholder expectations. Add to this that they often are but one component (albeit the largest) in a spaghetti like hodge podge of heterogenous tools that have theoretically solved the niche business problems outside of the larger enterprise level solutions, but have made interoperability a hugely complex and costly pursuit only addressed in theoretical IT solutions like SOA that require entire reconceptualizations of IT architecture throughout the enterprise. The dirty secret here of course is that hype and potential are still the norm and true digitization and sophistication remain on the horizon. Getting there will require some degree of business knowledge to be sure, but that, like a DBA or a java resource, can be viewed increasingly as more of a commodity (if not occasionally, as I have hinted, a liability). Versatile change freaks relentlessly beckoning everyone into the unknown are a far more critical ingredient if we are to get there. As these dynamics are still in very short supply on the inside of large enterprises, more an more we will see IT fail as an internal function and thus the inherent chaos of outsourcing will be used as catalysts for broader, accelerated change as much as anything else.
Thriving means embracing and stoking the chaos, and too few of us are prepared to openly admit that because "good at creating chaos" is not yet viewed as a critical organizational skill.
Posted by: michael | May 23, 2007 08:49 PM