Make IT appear as simple as possible, but not simpler

Sometimes I hear a complaint from an IT architect who wants to have direct conversations with “the business” or “the customer” but, for some reason (usually bureaucratic), they cannot.  There is a team of analysts or project managers that they are supposed to talk to. 

The original objective of having “layers” of people is to make IT appear simple.  We all agree that business constituents can become confused if they are dealing with a long list of people from IT, each of which have different concerns.  In the worst case scenario, a business user reaches out to an analyst to tell them about a software error, and the ‘problem’ gets handed off from person to person, adding time and confusing the user.

Many companies favor the “Single Point of Contact” approach. For each business unit, there is a single point of contact for all projects.  There may still be one more point of contact for “support” related concerns.  But that is all.  This hides some of the complexity from the business customer, but adds a layer between IT and the customer.

So where does the IT architect fit?  Does it depend on the type of architect?  Does the enterprise architect need to have direct conversations with business stakeholders? 

What about solution or platform architects?  Should they be talking “directly to the business?” 

It would seem obvious that business architects should, but how do business architects relate to business analysts?  There’s still the support side as well.  Does each application have their own support contact?  What happens when one application has the right data, and the next one over has the wrong data… who should the customer call?

So we have a problem.  That much is clear.  How to solve it?

I’d like to consider introducing a concept into the conversation: interdisciplinary teams.

The notion of an interdisciplinary team is not widely used in computing, but there are many examples in science.  Used widely in research, medicine, and public policy, interdisciplinary teams provide a way for specialists in many fields to work together to solve a problem.  Any problem can be addressed from many viewpoints, using an understanding that emerges from the unique combination of talent and responsibilities.

Many of the processes for collecting and describing requirements, including the well-understood “Joint Application Development” or JAD process, incorporate the same basic ideas, but do so in a less structured manner and only for a single “problem” (understanding requirements). 

What I’d like to see done is to use the concept more consistently.  For Information Technology, and for consulting, this is quite doable.  Instead of having a single person represent IT to the business, have a team of people.  They meet the business on a monthly basis, and the concerns of each of the people can be brought to the monthly meeting.  All of this is coordinated by a single “IT Engagement Manager” or “IT Relationship Owner.”  However, unlike the bureaucratic processes we see in some companies, there are a few rules that apply.

The interdisciplinary team will have predefined roles.  The list of roles cannot be reduced by either the IT engagement manager or business stakeholder.  One person can fill more than one role.  However, the IT engagement manager does not assign IT staff to those roles.  That is up to IT leadership to do.

This kind of interdisciplinary structure can allow a more direct flow of information, communication, and shared commitments than is possible with the “single point of contact” model.  At the same time, the business stakeholders don’t get randomized by multiple requests for the same information or by the miscommunication that comes from collecting different information at different times in different contexts to apply to the same problem.

In many ways, using a single point of contact is an attempt to make the relationship, between IT and the business, simple.  It is too simple… to the point of ineffectiveness.  I believe that a broader approach is often a better one.

Comments

• Anonymous
  May 24, 2009
  I've talked to people who are simply replacing BAs with Solution Architects embedded in the Business Units.  They seem to be quite happy with the results.