Now that I am back from the Gartner ADI Summit in Los Angeles, I thought it was time to post some musings on the questions which came up during my presentation sessions and face-to-face meetings with clients. One common thread to these questions I received involves the #1 attendee issue identified by our Gartner pre-conference surveys – collaboration between IT and and business. Not surprisingly, my most highly-rated session was “IT & Business Collaboration: SOA, BPM and MDM”, which looked at the inter-dependencies and leverage points between service-oriented architecture, business process management and master data management.
Interestingly (at least to me) I discovered that since attendees were filling a large variety of roles for their organizations, though most had some degree of concern about IT and business collaboration their viewpoints on what the problems were and – perhaps more importantly – why these problems mattered varied widely. For example, many enterprise architects thought the lack of collaboration resulted in an ability for them to design a good technology architecture which met both the current and future needs. Data architects and analysts were concerned about data quality and inconsistency problems with which they dealt on a daily basis yet the business seemed to be ignoring. Developers seemed mostly concerned about how to get the business to specify correct requirements so that they build applications more quickly, while application architects were mostly concerned about how to fulfill their role in removing redundancies caused by the business units funding the building and maintenance of siloed applications (instead of focusing in shared and reusable software services).
Or to say it a different way – each of the attendees wanted to improve collaboration to solve THEIR problems as opposed to those which the business perceived as the most important to them!
I told a joke (which I will shorten here) to illustrate this point. A couple of hikers are near a farm and come across a large, deep hole. In order to find out how deep it was they threw a heavy railroad tie near the hole into it in order to hear the depth of the thud at the bottom. All of a sudden, a goat came running at breakneck speed out of the woods and dove into the hole headfirst (with an accompanying “splat” sound when it hit the bottom). The local farmer showed up and asked the hikers if they’ve seen his goat, which was on a long chain attached to a railroad tie. Ta-dum….
My point of this joke to the audience was that the business believes its only concern and responsibility needs to be the care and feeding of the goat. The business perceives IT (SOA, MDM, AD, etc) to be that big deep hole – and aside from cost issues and getting solutions they need, the business considers the hole to be the domain and responsibility of IT. It is not until the business understands that there are inter-dependencies between the hole and the goat that they care. So, the trick becomes in turning the answer to the “why is IT and business collaboration important” question from one which has relevance to me into one which has significance to the business.
I generally talk about 2 key enablers of IT and business collaboration. The first is at the conceptual/planning level of detail where there needs to be a representative from the business who brings the plans and needs of the business units to the table to be considered in the context of the other viewpoints of technology, data and application. Once the business sees how this collaboration can expedite the delivery of solutions, improve agility of change, help decrease costs or allow them to be more efficient or competitive, they finally begin to see the relationship between the goat and the hole and the need for collaboration.
The second enabler getting the business to work on (re)designing their business processes and workflows using service-oriented methods as part of BPM initiatives. Note: Much as the business perceives hole as an IT responsibility, too many IT organizations see BPM (in support of the goat) as a business responsibility. IT needs to enable BPM initiatives since these result in greater collaboration across business units and, in turn, results in projects which specify requirements to break down the silos which exist in IT systems between applications and their data. Or to say it more directly – BPM is the most important enabler of change for driving greater collaboration of the business units across application systems (and therefore with IT) because the need for sharing creates a greater need for collaboration.
At a minimum, IT personnel need to make sure they ASK the business what aspects of collaboration they feel are negatively impacting them – either from a business cost or efficiency perspective or in terms of holding the business back from being more competitive or generating more revenues. And then, whenever possible, IT needs to assign resources based on priorities agreed upon with the business to address those issues in order to build trust greater trust and to enable greater future collaboration.
Read Complimentary Relevant Research
Predicts 2017: Artificial Intelligence
Artificial intelligence is changing the way in which organizations innovate and communicate their processes, products and services. Practical...
View Relevant Webinars
The Mobile Scenario: Taking Mobility to the Next Level
The definition of "mobile" in the post-app era will involve new interactions such as bots and conversations, new devices such as wearables...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.