Data modeling has long been one of my requirements analysis tools of choice for custom operational applications.  To me, using data modeling techniques in requirements analysis reduces errors by improving requirements completeness, consistency, and communication, and provides unique continuity between analysis and design.   As David Elliott told me in conversation, “development of a data model uncovers many opportunities for clarification of existing requirements, or uncovering of additional detail.  At the very least, it confirms to one’s business customer that the BSA understands and can graphically demonstrate many business rules and relationships.”

I’ll hasten to add a these caveats.  (1) Perhaps strangely, conceptual data modeling is not useful in the same way in requirements for informational systems like data warehouses and marts (I’ll save that discussion for another post).  (2) Requirements definition for commercial off-the-shelf (COTS) applications follows a different methodology in which data modeling might be less applicable.  (3) This post is not about database design, but rather about use of conceptual data modeling as a tool for organizing and validating requirements.

Conceptual vs. logical data modeling

It is easy to see why in practice there are varying definitions of the different types of data models.  The Wikipedia entry on data modeling reflects the standard terminology based on the ANSI four-level database architecture, but features a confusing diagram that to me blurs the distinction between conceptual and logical models. The entries on Logical Data Model and Conceptual Data Model make them sound like the same thing: implementation-independent representations of business data.  Then, the entry on Database Design contradicts them by stating that the logical model “contains all the needed logical and physical design choices and physical storage parameters needed to … create a database.”

For this post I’ll follow the definitions offered in Simison and Witt’s Data Modeling Essentials:

• Conceptual data modeling identifies a set of data structures that will meet requirements, focusing on business and not on technical or DBMS-specific concerns
• Subsequent logical data modeling maps the conceptual model to structures supported by the particular DBMS, finalizing the design in DBMS-appropriate constructs but not yet optimizing for performance, which comes next in physical modeling

Use of data modeling in requirements definition

Conceptual data modeling is hardly an outlier technique in requirements definition:

• Perhaps in reaction to problems experienced by adopters of Structured techniques in the 80s, data modeling was the cornerstone analytical technique in Clive Finkelstein’s and James Martin’s widely-adopted Information Engineering methodology.
• The BABOK includes class modeling, data modeling’s object-oriented cousin, in its chapter on data modeling.  Class modeling is a core technique of object-oriented analysis.
• Scott Ambler’s Agile Modeling site offers conceptual (or “slim”) data modeling as an option in the initial envisioning stage.
• Informally searching requirements definition templates available on the web, I found that about a third recommend including conceptual data models.

Benefits of data modeling in requirements analysis

The BABOK separates requirements gathering from requirements analysis, defining requirements analysis as an essential step to organize, prioritize, and validate elicited requirements. Elicited requirements are the business objectives of the system. The analysis step organizes those objectives in a way that both makes sense to the business and guides subsequent application design.  Conceptual data modeling in this stage helps ensure requirements completeness, consistency, and communications:

Completeness: In my experience most requirements analysis is process-based, and the most common tool the “swim lane” activity diagram.  While such techniques are essential for understanding complex processes, they can miss requirements that aren’t directly involved in the process itself.  For example, a complex process might reference federal, state, and local tax rates by zip code.  Analysts who are heads-down in defining the process might neglect the need for at least annual refresh of the tax rate tables.  Data modelers thinking in terms of business objects and events and their life cycles would be less likely to miss that one.  This kind of review is formalized in the “CRUD Matrix” a table identifying which business activities create, read, update, or delete which business entities.

Consistency: Another challenge with process-oriented techniques is, for large systems, the risk of inconsistency in definition of business objects and events.  For example, I worked on requirements definition of a specialized order processing system.  Separate sub-teams defined field and headquarters processes, and as a result there were incompatible definitions of critical concepts like “customer” and “order”.  Time pressures made it difficult for the two sub-teams to work together to make their work consistent.  A separate data modeling sub-team can provide a reference point for object and event definitions and promote consistency between separate process analysis teams (on COTS installations the product database itself serves as the reference data model for separate process definition teams).

Communications: Data management professional Peter Carr recounted to me his experience as a consultant on a large project: “the Conceptual Diagram helped us think about all the current state situations, and broadly about the relationships between entities in the organization.  It helped us to ask questions of the business when they were looking to enhance or build new systems to solve business requirements.  Paraphrasing executive colleague Rich Hartt, “the enterprise data model is like a piece of art, it provides a picture into the business that offers new insight through its drawing and interpretation’.  He went on to tell the key business leaders that the enterprise data model will continually be changing, but that it helped them gain understanding of their business in a different way than written business rules”.

For relational database applications, data modeling applies the same conceptual tool throughout the development cycle.  A conceptual data model used to define the problem domain uses the same structure and symbols as a physical database design, although of course it uses fewer.  On the other hand, activity diagrams and data flow diagrams are fundamentally different in nature from the software that they describe.  In effect, process designers need to translate analysis artifacts into a different language.  Logical and physical data modelers use exactly the same language as the business analysts who complete the conceptual data model.

My colleague Grayson Gorman cites “Poorly Defined / Missed Requirements” as a key contributor to IT project failure.  In my view making data modeling a more prevalent part of requirements definition could help by improving requirements completeness, consistency, and communication with business participants, and promote a seamless transition from requirements to design.

To put cards on the table, while Mr. Cho is a dedicated dual-career professional who plays jazz at the highest level, I’m a dedicated IT professional who spends some evenings as a serious amateur at local watering holes and private parties.  To me, Mr Cho really nails it.  He groups 14 principles into four categories on how teams can effectively work, collaborate, execute, and innovate together, bringing honed skills, “big ears”, trust, and commitment to deliver successful outcomes.

Does the Jazz Process work?  Only time will tell if it catches on in the business world, but from my experience the Jazz Process does describe how musicians work together.  The two concepts I particularly like are the importance of developing a technical base and the need for humility.  Mr. Cho quotes Vijay Govindarajan, who wrote: “The more humble you are, the more you know what you don’t know; you seek to learn” - something John Coltrane might have said.

From the point of view of a jazz-playing IT guy, however, two important topics seem to be de-emphasized in the Jazz Process:

Those who don’t know history don’t know how to repeat it

Every jazz player I know is also a jazz historian, and knows that Coleman Hawkins’ version of “Body and Soul” is a landmark of harmonic improvisation, and if they heard Pentangle’s song “I’ve Got a Feeling” they would know it as Mile’s Davis’s “All Blues.” An accomplished jazz improviser might weave into a solo phrasing or melodic fragments borrowed from jazz greats of the past, which jazz aficionados would recognize and applaud.

How many application developers know that during the early ’70s Larry Constantine first conceived the concepts basic to Object Oriented design, and how many know the (perhaps apocryphal) story that he borrowed them from the social sciences?  How many know about Edsger Dijkstra’s landmark article called “Go To Statement Considered Harmful”?

If I’ve stumped you, don’t worry, you could probably stump me just as easily.  The point is that, unlike jazz musicians, we in app development have a culture that tends not to respect and build upon the past.  As we gain new tools and methods we seem to discard the old ones (does anyone remember Warnier-Orr diagrams?), and we often forget the hard-won lessons of the past (how many process analysis and redesign projects skip logical modeling, causing the new process to retain unnecessary steps related to old systems?)

Play it for the people

In a very real and direct way, the audience is a huge part of any musical performance.  The jazz player is not only aware of the style needed for the gig (background, dance, concert, etc) but also of the “feeling in the room”.  There’s a gestalt in the performance space that is difficult to explain but very apparent to a musician.  Jazz musicians not only constantly listen and  interact with each other, but also constantly feel and feed the vibe in the room.

Similarly, excellent development teams are constantly aware of and constantly cultivate good feeling in their organizational community.  I was fortunate enough to be involved in a development effort where key business people we were building the application for worked overtime so they could be involved as testers, in part because the system was critical to their process but also because it was a really dedicated and energized group.

–

Mr. Cho’s book is not yet available at the time of this writing, but there’s a wealth of information at www.jazzprocess.com.  I’ll look forward to learning more and applying this method at work.

I stumbled upon that quote following links on the role of the architect on an agile project. Maybe one important role of the architect is to help the team avoid groupthink.

Groupthink is a situation where a team’s decision process breaks down and the team reaches decisions that aren’t fully vetted and evaluated.  Both Watergate and the Bay of Pigs fiasco are cited as examples (here).  I’ve seen groupthink operate on IT projects, and to me the agile method’s effectiveness in enabling groups to work together means agile projects are particularly susceptible.

This post reviews groupthink then discusses how the architect on an agile project might help prevent it.

Groupthink

From the Wikipedia article on groupthink, “groupthink is a type of thought exhibited by group members who try to minimize conflict and reach consensus without critically testing, analyzing, and evaluating ideas. Individual creativity, uniqueness, and independent thinking are lost in the pursuit of group cohesiveness. During groupthink, members of the group avoid promoting viewpoints outside the comfort zone of consensus thinking…Highly cohesive groups are much more likely to engage in groupthink, because their cohesiveness often correlates with unspoken understanding and the ability to work together with minimal explanations.”

In my experience risk of groupthink can manifest in several ways on IT projects:

• Not Invented Here: Successful teams that work through conflict can settle into a shared culture that resists new ideas from outside the team.
• The Know It All: Less successfully integrated teams can be dominated by a single strong-willed individual, and can habitually avoid conflict by accepting without question the ideas of that one dominant team member.
• The Abilene Paradox: Team members sometimes collectively decide on a course of action that no one on the team likes, when each member actually disagrees with the decision but mistakenly believes that their own preferences are counter to the group’s.

The Agile Architect

According to the Psychologists for Social Responsibility, the standard remedies for groupthink include this: “At least one articulate and knowledgeable member should be given the role of devil’s advocate (to question assumptions and plans)”. Of course the architect is an integral part of the overall project, but the skilled practitioner participates with the Agile team while maintaining separateness in order to remain a source of ideas from outside the team, and therefore provide a counterweight to groupthink by recognizing it and taking measures to prevent it.  Andrew Johnston’s site agilearchitect.org describes some of the ways the architect is in but not totally of the team (here). Among the architect’s responsibilities, he or she:

• Ensures “the delivered system is consistent with the agreed architecture, and will meet the requirements”
• “Is frequently an evangelist for new or different technologies, processes or solutions”
• “Acts as a bridge between developers, managers and other communities, and spends much of his time translating and mediating between them”
• “Recognizes the wide range of stakeholders, and their needs and concerns.”

While core agile team members are immersed in the scope and design that defines the current sprint, the architect retains a larger perspective that encompasses alternative designs, emerging technologies, business fit, stakeholder concerns, and more. The architect is therefore uniquely positioned to recognize groupthink effects on the team’s technical activities. Here are two examples of how that works on agile projects:

• Estimations and retrospectives: Mark Needham, in this post, cites risk of groupthink in agile estimation sessions and retrospectives.  The architect can address both of these risks. In estimation, the architect brings the diverse perspective that Mr. Needham says is important when team members estimate incorrectly due to incorrect team-shared assumptions. In retrospectives, the architect can be the one to increase the “safety” of different perspectives by raising or encouraging others to raise “things that have gone well, not gone well, and things that are confusing”.
• Work product reviews: I’m an advocate of code walkthroughs and design reviews, and making them explicit sprint tasks. The team can set aside an hour or two a week to review one or two representative work products in order to share ideas, ensure quality, and uncover overlooked errors or opportunities. In this forum the architect has the opportunity to reinforce quality work that is aligned with the requriements and architecture, or supportively correct deficiencies.

Of course there are risks:

• The architect shouldn’t be the know it all: In some cases the architect can be the strong-willed individual who stifles creativity and causes the team to avoid conflict.  Strong teamwork and interpersonal skills are core to the agile method, and those who staff the project must include those skills in selection and evaluation of the architect.
• Keep the architect different: If the architect is a core member of the team, he or she can become integrated into the group and therefore part of a groupthink dynamic.  For this reason, I advocate architects being assigned part-time to agile efforts. Otherwise, the architect risks becoming the extra developer, as near term sprint tasks expand to fill the available team bandwidth.  Consider sharing the architect among two or three projects, or assigning him or her responsibility for technical strategy and planning.

I recently read Testimony, Solomon Volkov’s controversial publication of the memoirs of Dimitri Shostakovich, the great 20th century Russian composer.  There were three different individuals in the book who demonstrated three different ways of “leading”, or behaving with character within a group.  (See the note at the end of this post on the question of authenticity)

The Cheerful Individualist

Volkov presents Modest Mussorgsky, known to most of us today as the composer of Pictures at an Exhibition, as an eccentric but cheerful individualist who would listen attentively to criticism as “everyone who felt like it harangued and criticized him…When he was criticized, he kept quiet, nodded, almost agreed.  But the agreement lasted only as far as the door; once he was outside, he took up his work again, like one of those dolls you can’t knock down.”  Mussorgsky was a unique individual with a unique musical voice, and in Volkov’s account had the confidence to overcome negative reaction to harsh feedback.

The Enabler

Alexander Glazunov, known as the “Russian Brahms,” was head of the Leningrad Conservatory from 1906 to 1928.  Glazunov was Shostakovich’s mentor during his time at the conservatory.  Glazunov enjoyed the company of young musicians, “performers came to his house every day”.  From Shostakovich’s account of Glazunov I’m reminded of a teacher I had who didn’t seem to teach at all, but by being welcoming, cheerful, and obviously talented and passionate about the subject matter, created an atmosphere in which we couldn’t help but learn.  More importantly, Glazunov saved lives during years of starvation and repression in Russia by “giving away his salary to needy students” and saving Jewish musicians from repression in their home towns by signing petitions for them to live in Petersburg without having them play for him.  As Volkov atrributes to Shostakovich after relating this story: “All things in life can be separated into the important and the unimportant.  You must be principled when it comes to the important things and not when it comes to the unimportant.”

The Supportive Subversive

Volkov’s Shostakovich lived bemused in a world of individual and institutional stupidity.  For example, one official order demanded “a quartet of 10 musicians.”  In this world  Shostakovich trod a fine line but never crossed far enough over to draw retribution.  Finally Shostakovich (among others) was denounced as a “decadent formalist” at the first Composer’s Congress in 1948, perhaps in part due to his 8th Symphony.  It was a solemn response to the end of World War II rather than the expected victory celebration.

Life during the Stalin years and World War II was characterized by deprivation and repression.  Many of Shostakovich’s friends and associates were denounced, exiled to Siberia, or killed in mysterious circumstances.  As a leading Soviet composer Shostakovich provided the soundtrack for the regime.  However, to the careful listener it seems not to celebrate the Stalinists but rather to channel the anguish of the people.  A telling example is his Fifth Symphony, ostensibly a joyous tribute to Party but arguably a veiled protest (see this analysis by Michael Tilson Thomas).

Volkov’s Shostakovich seems to have blundered on in spite of the worst possible conditions, sublimating his genius into musical irony and thereby doing what little he could in small ways to help his fellow Russians.

–

Many question Testimony’s authenticity, but this from the Wikipedia entry on the book might sum up a reasonable assessment: “the book gives a true picture of the political situation in the USSR and correctly represents his father’s political views, but [Maxim Shostakovich] continues to speak of the book as being ” ‘about my father, not by him.’ “  I’m neutral on whether or not Testimony is authentic, and whether Shostakovich was a toady of Stalin’s regime or an undercover dissident.  This post reflects subjective impressions from the book, nothing more.

Excerpt from "Show Me the Money: A DM/BI Business Value Primer", Bob Lambert and Tri Truong, Information Management Special Reports, March 24, 2009

1. Intangible benefits don’t count.
2. BI has no inherent value.
3. Senior managers often make decisions about future outcomes with insufficient data.

Intangible Benefits Don’t Count: An effective business case communicates tangible future value in a convincing way.  An argument has a chance of convincing a skeptical reader if the reader agrees that the argument’s assumptions are reasonable and that the conclusion follows logically from the assumptions.  Quantifying financial metrics like Return on Investment (ROI) or Net Present Value (NPV) help build the case, but such measures are credible only if readers agree with the underlying assumptions and the logic built upon them.

BI has no inherent value: We in the BI field believe that any organization’s fortunes would improve if it rationalized its data stewardship, integrated its data, and applied analytics creatively in management and operations.  However true, that view must ring hollow to senior business managers.  Without a compelling and motivating story about how a new system contributes to revenue or reduces costs, that system’s business case stops dead in its tracks.  Of course sometimes “someone at a high level” just wants BI, but organizations don’t often embark on BI efforts without first evaluating tangible costs and benefits.

Senior Managers Make Decisions about Future Outcomes with Insufficient Data: Although BI practitioners must make a convincing case for future business value, there’s room for uncertainty.  Executives and senior managers aren’t highly compensated for playing it safe, but rather for understanding current conditions and setting direction based on educated but sometimes courageous predictions of future conditions.  A successful BI business case matches or extends the executive’s knowledge of current conditions and expands his or her view of potential future outcomes of near term actions.

That said, it seems to me that there’s something missing.  Consider one BI manager I know who has fractious relations with his business customers.  I won’t go into detail, but trust me, relations have been rocky, and reviews from key business players poor.  What this person does extremely well is to build rock-solid, reliable systems, deliver on time, meet business needs, and ensure that the solution meets regulatory and audit concerns.  This BI group is essentially unchanged after many years, enduring even the recent recession in a devastated industry segment, and outlasting many of its critics.

To me, building a good relationships is important, but execution is the sine qua non of IT/business alignment.  Think about it.  Say you hire a really nice contractor to fix a leaky roof.  However personable he is, you won’t hire him to replace your windows if the roof still leaks after you’ve paid the bill.

My view: if you want to do it right adopt Villar’s and Kushner’s excellent suggestions but the fundamentals remain the same:

1. Either (a) present a robust business case that all accept, or (b) pay attention to what you’ve been asked to do
2. Deliver what was requested/promised in 1
3. When things change go to 1

Whatever project management approach a team uses, sometimes everything falls apart, commonly due to work piling up at the end, but sometimes due to a key individual leaving, or a pivotal assumption no longer holding true, or many other reasons.  When that happens, the project can become like a whack-a-mole game, with leads working from issue to issue as they pop up faster and faster.

I served as one of many workstream PMs on one very large project where this didn’t happen.  Out of the seeming chaos the multi-million dollar IT project came in on time.  Here’s my view of what we did to succeed:

• Had very clear interim milestones that were generally known and served as reference points for discussion.  I’d characterize them as a milestone per workstream per month.
• Held seemingly interminable weekly risk/issue discussions.  These were open, no holds barred reviews of anything at all that could endanger achieving milestones.  Often risk/issue discussions are polite exercises in avoiding the fact that the emperor has no clothes, with team members carefully avoiding forbidden topics.  On this project everything was open for discussion.
• The program manager excelled at visibly not sweating the small stuff, directing workstream leadership to handle their localized risks and issues themselves, and focusing program energy only on those he judged to have overall impact.
• Each of the many workstreams had its own project schedule; the program insisted on detail where it mattered but not where the detail was irrelevant.  For example, there was a minutely detailed cutover plan for production migration.

Many of us were surprised when the chaos all came together on time with surprisingly few glitches. I attribute this program’s success to the program manager’s unflappable focus on milestones, encouragement of unfettered group risk/issue analysis, and ability to parse program from project concerns.

I’ve cited here the need to start data interface analysis early to avoid budget and schedule blow-ups when, as a result of not thinking early about interface complexity, data integration work turns out to be bigger and nastier than anticipated.

Early data study also helps business analysts elicit more detailed and accurate business requirements.  Say a mid-level football (soccer) team in the UK is looking to recruit a couple of strikers who can reliably punch home goals for the club.  The obvious data they seek is (1) the number of goals scored per game by each prospect, and (2) over their careers how much time have they spent on the bench due to injury.  At the same time, this club is building a strategic recruiting system to support growth into the higher echelons of English football.  A process-oriented requirements strategy (like the one described here) asks the team’s recruiters what they need to in order to get good people into the club, and often emerges with a list of statements about what the system will do (”The system shall provide an interface enabling entry of the following player statistics” or “The system shall provide a report ranking players by the following criteria:…”).

It isn’t necessarily wrong to start with process analysis, especially when backed up with formal techniques like use cases, data flow diagramming, or others, but addition of data analysis early provides ability to be far more perceptive into the real business needs.  Without interviewing anyone a data analyst can know that there are many goals in a game of soccer (OK, to some not nearly enough, but that’s another story), that the attributes of a game include location, weather conditions, date and time, whether it’s regular season or playoff, and more.  Attributes of a goal: time during the game; left foot, right foot, or head; did it come from a set play or in the run of play; from the left or right side of the field, and much more.

The analyst who knows the data and understands its structure can probe with questions like whether a player tends to score at the end of games, or would it be useful to find one striker who tends to score from the left side of the field and another who scores from the right?  By understanding the data an analyst can understand the business problem more deeply, build better rapport with business people  by asking more informed questions, and cross the business/IT communications gap to define the right requirements so that the right system gets built.

It may be just the organizations I’ve been exposed to, but in my experience data analysis isn’t typically part of the requirements effort.  Supporting this point, the author of the wikipedia page on business analysis entirely omits data analysis, apparently favoring a process-only approach.  On the other hand, object-based techniques offer a balanced approach, studying both data and process by representing things like goals, games, and players as objects with their own attributes and behaviors.  In addition, the International Institute of Business Analysts (IIBA) includes data-oriented along with process-oriented techniques in its Business Analysis Body of Knowledge (BABOK).

As process/data balance early on in the application lifecycle becomes more widespread analysts should generate more insightful requirements and, other things being equal, the success rate of IT application projects should improve.

Here’s Paul’s description of the Sancho Panza test:

Think of Don Quixote [DQ] as the data-quality specialist or even the data management specialist or software vendor, bringing to the world his specialist’s perspective and vocabulary and enthusiasm, influenced by the books he’s read, visioning everyday business practices, with his value added, as goldmines for the organization.  Meanwhile Sancho Panza represents the person who does a practical job every day, who knows what works around here and what doesn’t.

I advocate to Data Quality (let’s call it DQ) consultants that they listen to this Sancho Panza, and consider themselves as Don Quixote.  Sancho doesn’t know much about data, but he knows what he likes… He’s open to listening, but slow to change, and he’ll tell you what he thinks.

Paul’s article reminded me that as a child I thought the problem with Don Quixote was that he tilted at windmills and attempted to ambush acting troupes because of his bad eyesight.  Of course this is not the case, but to me it provides a relevant perspective on data quality in many organizations.

Here’s the problem I’ve seen play out on a number of IT application projects:

1. A high level business study recommends replacement or improvement of a current application.
2. The organization approves the project described in a business case citing benefits named in the business study and costs detailed for infrastructure, package software, and application development, but data-related costs are glossed over or left out entirely.
3. The project begins with a requirements phase that collects hundreds of imperative statements (“The system shall…”)  from business people who will use the system.
4. Late in the requirements phase, the team finds that data integration work in system interfaces will be more complex than expected.  A common example: the project requires changes to a feeder application with no documentation and no in-house support expertise.
5. Project leadership goes back to the sponsor seeking more money.

In these situations the business case was incorrect because it did not account for all of the costs of data integration.  I’ve seen projects weather steps four and five well, but often discovery of previously unseen data complexity starts a disruptive chain of events.  (Sadly for the project manager, such situations are often seen as a failure of project management and corrected accordingly, but that’s a topic for another post.)

In my view the root cause of unforeseen data complexity on projects is the lack of a data constituency in current IT. It is only recently that success of companies like Google and Amazon have motivated emergence of data as a key business resource in the collective consciousness. Famous success stories notwithstanding (see this link), there are relatively few senior IT managers with data quality backgrounds.  Conversely, many rose through the ranks of the infrastructure, application development, or business (process) analysis groups.

It will be a while before, for example, a Mobil CIO’s predecessor jobs include definition of a metadata repository or elimination of multipurpose data, but in the meantime here’s what we can do:  add a business case to the application lifecycle as the last step in requirements.  Stop the project when the real costs are known, recalculate the cost/benefit, and ask the sponsors if the project should continue.  Give Sancho (in this case the project team) a chance to speak to the reality of the situation, and hand to Don Quixote (project sponsors) the eyeglasses of in-depth visibility into real costs. If the decision is to move ahead with the project, then all share the same vision and the sponsors have endorsed the actual project, not the fuzzy image from earlier on that might have been a windmill.

To me (speaking as an IT professional) IT should take the initiative to solve the problem.  Quoting Trembly, “business executives … make decisions, but they are for the most part mystified at the magical incantations and actions that produce IT results” and “IT people, on the other hand, are jealous of the sheer power wielded over them by business people who just don’t get IT.”  In other words, business people contend with an emotional and a substantive problem, “fear and lack of knowledge,” while IT people have only the emotional problem of jealousy.

If we take the emotions out of the picture (its just a job, right?) then that leaves IT folks with knowledge that business people need in order to maximize the value of IT and efficiency of business processes.  Ever since mainframes roamed the prehistoric rain forests of the ’60s application developers have often been the most knowledgeable about how business processes really work, understanding both the intricacies of the application logic and how business people use the system to get things done.  These individuals can add value to the business discussion by bringing their knowledge to the table in a way that business people can understand.

In many organizations IT manages the forum in which these conversations can occur: the requirements process.  In my experience a good requirements process is long enough for the business and IT teams to get to know each other, offers generous opportunity for both structured and unstructured conversations about business needs, and brings together knowledgeable business and IT participants.  IT is typically able to bring the insights of seasoned application developers to the fore in a well planned requirements effort.

Yes, everyone has responsibility to “cultivate personal relationships based on mutual need and respect,” but IT can and should bring substance to the relationship in requirements definition.