Enterprise System Spectator blog: ERP and enterprise system vendor evaluation, selection, and implementation.

The Enterprise System Spectator

Tuesday, September 19, 2006

Business Technology (BT): a better acronym for IT

George Colony, CEO of Forrester Research, has been on a one-man campaign to change the use of the term "information technology (IT)" to "business technology (BT)." I first heard Colony talk along this line earlier this year at Forrester's conference in Las Vegas. At the time, I didn't pay much attention, thinking that it was just another attempt by a consultant to give a new name to something old.

DP, EDP, MIS, IT
This time, however, I find myself more open to the idea. What we call the IT function today has already gone through a number of name changes, from data processing (DP) in the 1950s and 60s to electronic data processing (EDP) 70's, to MIS in the 1980s, to IT in the 1990s.

I'll date myself and admit that I'm old enough to remember each one of these acronym changes. Each reflected a change in thinking about our profession. DP was all about data--whether in the form of punched tape, cards, or mag tape. The transition to EDP reflected the shift from mechanical data (cards, paper tape, etc.) to electronic data. The rise of the acronym MIS reflected the view that our job was not just about data, but about information--and especially management information, information used to manage the business, including early forms of decision support and planning systems, such as MRP. Eventually, the acronym MIS fell out of use in favor of IS or IT, reflecting the realization that the information we managed was not just management information but all sorts of information.

But what all of these acronyms have in common is that they are centered on "data" or "information." Colony's point is that the job of IT today is not just about managing information. It is about supporting the business in all aspects--from managing information, to facilitating communication, to automating business processes, to enabling collaboration. It even involves digital communication with things, such as equipment, inventory items, and vehicles that are electronically enabled through technologies such as RFID.

Therefore, it is getting harder and harder to separate the business from the technology. In the late 1990s, the term "e-business" was popular, denoting a new way to do business--electronically. Today, though, no one really talks about e-business. It's just business.

I'm mixing Colony's thoughts here with my own. But putting it all together, it's clear that "IT" is no longer sufficient to describe what we expect from IT. A better term is Business Technology (BT), denoting simply the application of technology in business.

From CIO to CBT
If IT is now BT, then it follows that the Chief Information Officer (CIO) must be something new. Colony proposes Chief Business Technologist (CBT). A bit of a tongue-twister--I might suggest Chief Business Technology Officer (CBTO). Either way, the point is that this C-level officer of the organization is responsible for more than managing the information of the organization, and more than even the technology. He or she is responsible for ensuring that the technology is actually used to the benefit of the business and that the business is enabled by technology.

Interestingly, Colony made one point that I fully agree with and seldom have heard from others. He said that the CBT probably needs to come from a technology background, not a business background. The technology is too important to not have someone at the head of BT without a background in technology. Of course, the BT needs to be fully immersed in the business as well. But it is easier for one with a technology background to become immersed in the business than for one with a business background to become adequately immersed in technology.

Some companies, frustrated by the lack of business acumen in their IT groups, have transferred someone from the lines of business to the CIO position, hoping to bridge the communication gap that too often exists between IT and the business. But such a strategy only moves the communication gap, to a gap between the CIO and the IT organization. A better strategy is to develop today's CIOs to be truly CBTs or CBTOs, with knowledge and experience in both technology and business, responsible for ensuring the success of both.

Related posts
Marketing IT like a business
IT decisions that are too important to leave to the IT department
Escaping the ROI trap
Escaping the ROI Trap, Part 2

by Frank Scavo, 9/19/2006 01:35:00 PM | permalink | e-mail this!

Subscribe!

 Reader Comments:

When I read this post I got a little bit scared. Not because I was thinking that I had to learn something about business in order to stay in the IT field (could be scary for some people). But, I thought for a minute that I had another senior moment and forgot that I had written something on a blog.

For people that have known me for a while I have been saying that I didn't like being considered an IT consultant because it doesn't accurately state what I do. For most of my clients I am the bridge between the business people and the IT people. So, I have been calling myself a Business Technologist. Not officially, as I didn't think people would know what that meant, but I have told many about this unofficial title.

I have one rub about this, though. I have met many people who think they perform this bridge work between business and IT, but they are not really prepared to do it. After all, we've all met CIO's that aren't really CIO's, but got there through attrition or just by staying around long enough. Maybe we can get the academic world to create a new degree (BS or BA?) in Business Technology.

I do agree with the idea that the IT trained person is better suited for becoming a BT. I started in this business as a FORTRAN and COBOL programmer (now I've dated myself, too). But, the IT person has to have a real interest in using technology to better a business, not just using technology. In my experience we are a rare breed.
 
BT is still too technology focused. When I speak about applications (vs. DB, middleware, hardware) I like to emphasize "technology enablement of business processes". Although not short and snappy, this phrase puts the emphasis where it should be on supporting the business with tactical solutions that in turn support strategies and goals.
 
Its interesting to note that there are already college courses that are hybrid in nature and jobs too that requested for such BT personnel.

But still, I suspect many of those who migrated more towards regarding themselves as business-like rather than IT-like is the fact that the hardcore software part of IT is not everyone's cup of tea.

I, originally a COBOL programmer, been in IT-related business myself for 25 years that has held responsibilities covering pre-sales, vendor evaluation, business development and branding, has known many colleagues who aplogised for been non-technical and couldnt understand software.

Thus I see BT as more suited for them. As for me, somehow blessed with the ability to cut code, now in java, suddenly find myself not atuned to the business part of things, and would only handle that part when faced with a career decision.

That leads me to wonder if John Pellegrino is an even more rarer breed than he originally thought.
 
Thanks red1, I like being a rare breed.

Although I can still "cut code" this is limited to minor changes or debugging of code already created by people that spend 10 - 12 hours (or more) every day doing coding.

The good BT is able to take the business needs (not just requirements) and craft a solution considering all factors (time, dollars, simplicity, etc.). Then they can turn the solution into a specification that coders can work with.

After the solution is created they then can do first level testing before passing it on to the business people.

Coders appreciate someone that can "talk" their language and understand their limitations. That's why I think someone who has done it over the years is better suited for this BT role. There are plenty of business people, but the BT has to be the bridge between the 2.
 
I do agree that BT is more appropiate term to reflect the job nature of people to provide traditional "IT" services in business organisation, no matter in-house or external consulting.
I am an ERP consultant, which is, traditionally speaking, a IT work. But, in my daily work, I spend most of time on helping my client to resolve process or management change as adopting ERP system. Undoubtedly, it is not a "IT" work.
I also agree those BT should have certain "technical" experiences such as programming, configurating hardware and setting up networks. Those learning IT from business school usually just know the "theories", not really know how to make the technology works.
 
I still don't see how the business technology function is supposed to grow beyond its traditional role as cost center providing necessary services.

If we've learned one thing in the fifty years since Frank (and I) started in the technology business, it's that technology creates value. The important word is "creates". I'm all for modernizing the scope and vision of the BT function. But unless its influence in the executive suite catches up with the value it creates, I don't think much will change – except that the job will get even harder.

A senior product manager or sales executive is seen as a rainmaker, because you can trace their value directly to the top (not the bottom) line. Somehow, the BT executive must join them on that pedestal.

It would be easy to say that he/she must earn a spot there. But fifty years of experience tells me it's not going to happen until they're also invited.
 
Post a Comment
 

Links to this post:


 

Powered by Blogger

(c) 2002-2014, Frank Scavo.

Independent analysis of issues and trends in enterprise applications software and the strengths, weaknesses, advantages, and disadvantages of the vendors that provide them.

About the Enterprise System Spectator.

Frank Scavo Send tips, rumors, gossip, and feedback to Frank Scavo at .

I'm interested in hearing about best practices, lessons learned, horror stories, and case studies of success or failure.

Selecting a new enterprise system can be a difficult decision. My consulting firm, Strativa, offers assistance that is independent and unbiased. For information on how we can help your organization make and carry out these decisions, write to me.

For reprint or distribution rights for content published on the Spectator, please contact me.


Go to latest postings

Custom Search

Join over 1,700 subscribers on the Spectator email list!
Max. 1-2 times/month.
Easy one-click to unsubscribe anytime.

Follow me on Twitter
My RSS feed

AddThis Feed Button


Computer Economics
ERP Support Staffing Ratios
Outsourcing Statistics
IT Spending and Staffing Benchmarks
IT Staffing Ratios
IT Management Best Practices
Worldwide Technology Trends
IT Salary Report
IT Help Desk/Service Desk Management

Get these headlines on your site, free!


Awards

2013 Best ERP Writer - Winner

Alltop. We're kind of a big deal.
 
Constant Contact 2010 All Star Technobabble Top 100 Analyst Blogs


Blog Roll and Favorite Sites
Strativa: ERP software vendor evaluation, selection, and implementation consultants, California
StreetWolf: Digital creative studio specializing in web, mobile and social applications
Vinnie Mirchandani: The Deal Architect
Oliver Marks' Enterprise 2.0 Blog
Si Chen's Open Source Strategies
diginomica
CISO Handbook


Spectator Archives
May 2002
June 2002
July 2002
August 2002
September 2002
October 2002
November 2002
December 2002
January 2003
February 2003
March 2003
April 2003
May 2003
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
September 2008
October 2008
November 2008
December 2008
January 2009
February 2009
March 2009
April 2009
May 2009
June 2009
July 2009
August 2009
September 2009
October 2009
November 2009
December 2009
January 2010
February 2010
March 2010
April 2010
June 2010
July 2010
August 2010
September 2010
October 2010
November 2010
December 2010
January 2011
February 2011
March 2011
April 2011
May 2011
July 2011
August 2011
September 2011
October 2011
November 2011
December 2011
January 2012
February 2012
March 2012
April 2012
May 2012
June 2012
July 2012
September 2012
October 2012
December 2012
January 2013
February 2013
March 2013
May 2013
June 2013
July 2013
September 2013
October 2013
December 2013
January 2014
February 2014
March 2014
April 2014
Latest postings