by Jeff Tash, ITscout

A two-by-two matrix can be a very powerful analytical tool. It’s frequently been used by academics and management consultants like the Harvard Business School or McKinsey & Company. For example, the Boston Consulting Group grew wealthy by promoting its portfolio management model of “cash cows, stars, dogs, and problem children.” The two dimensions captured by BCG’s model are labeled “relative market share” and “industry growth rate.” Similarly, most everyone in IT is familiar with Gartner Group’s “Magic Quadrants” which consist of “challengers, leaders, niche players, and visionaries.” Gartner’s dimensions are “ability to execute” and “completeness of vision.”

For the purpose of pigeonholing IT people, let’s set-up a two-by-two matrix where the rows correspond to “business-oriented” while the columns represent “technology-oriented.” I call this matrix the “IT People Personality Profile.”

The upper left-hand corner represents the “suits” -- people who love to perform business analysis but prefer not to get their hands dirty by doing actual implementations. These individuals always approach their work top-down, focusing almost exclusively on external requirements, business drivers, and business processes. In earlier times, back when models of system life cycles resembled waterfalls, suits were often referred to as systems analysts. Also historically, back when there were still Big 8 accounting firms, suits were known as management consultants. To protect their partners against the possibility of liability lawsuits, those firms’ management advisory services eschewed any form of projects involving application implementation. Instead, for that grunt work they recommended body shops.

Next, let’s look at the lower right-hand corner of the matrix. This quadrant represents technology-oriented but not business-oriented. Here we’re talking about your classic propeller-capped “geeks.” You know the type -- application programmers whose idea of a perfect system is one without any end users. Corporate geeks -- typified by traditional COBOL programmers -- are truly an endangered species. Not only are they threatened by overseas developers willing to work for a fraction of U.S. wages, but the software industry has, for over a decade now, been undergoing a continual shift away from building custom software solutions and depending, instead, on commercial-off-the-shelf (COTS) application packages from vendors like SAP, PeopleSoft, or Siebel.

What about the lower left-hand quadrant? This corner of the matrix is best characterized by “big talkers” -- those people who flourish on the hype pitched at conferences and tradeshows by vendors and pundits. Purveyors of buzzwords thrive on FUD -- fear, uncertainty, and doubt -- often combined with the promise of great expectations (i.e., FUDGE). With big talkers, after all is said and done, a lot gets said but not much gets done.

Finally, look at the upper right-hand corner. Here the emphasis is on bridging the communication gap between business types and technology types. The people who fit into this portion of the matrix are called “agiles.” These are IT practitioners who create nimble software solutions -- systems that can adapt quickly and easily to evolving business requirements and/or rapidly changing market conditions.

Agiles are gifted problem solvers who intuitively recognize that the primary challenge persistently plaguing IT has always been -- and continues to be -- a combination of two separate issues. First, business users are not very adept at describing what they need. Show them what they can have and they can immediately tell you what’s wrong with it. But ask them what they want, and they’re basically incapable of responding coherently. Second, never overlook that the solution to a problem changes the problem. In other words, the development of a system itself elicits new additional requirements.

What are the characteristics of agiles? They invariably strive to deliver the simplest solutions possible that can meet all the requirements. Simplicity is paramount. So too are standards and modularity. Agiles possess the skills and talent needed to be able to look at both sides of a module’s curtain -- its internals as well as its externals. Additionally, agiles naturally solicit constant feedback from stakeholders.

Agiles do not attempt to create magical all encompassing ivory tower models. Unfortunately, the same cannot always be said of suits. It seems that the latter are forever in search of some holy grail framework. Most suits see it as their job to serve as intermediaries -- translating between the two diverse cultures of business people and technology people. They often fail, however, because their understanding of the business drivers and their knowledge of the technology drivers are both too superficial.

Suits who focus exclusively only on the external interfaces of information technology are loathe to discard the numerous artifacts associated with the internal models related to large application systems. Since they don’t understand what many of the artifacts are all about they’re afraid of throwing something away that might be really important. Their solution is to spend big money on expensive repository tools that promise to deliver complete comprehensive models that link together and interrelate everything about IT -- business processes, organizations, locations, data, applications, and infrastructure -- and that constantly monitor all changes in the IT environment to ensure that the repository is always automatically kept up-to-date. It’s a lot like the CASE fad a dozen years ago when vendors promised to automate automation. The problem then, as now, with this inwardly focused approach is that even over short periods of time, the volume and complexity becomes totally unwieldy.

By contrast, agiles are quick to discard models once they have fulfilled their purpose. To them, the primary goal is not the models, but rather the delivered solutions. Abstract representations of software are not what’s important. In the end, it’s only the executable code that really matters. Ideas that can be shown to actually work in practice are much more valuable than those that just exist in theory.

IT organizations should help their best and brightest agiles strive for simplicity by publicizing standards that can facilitate reusability. Arm them with better ways to communicate effectively, openly, and honestly so they can more easily bridge the gap between IT and business.