How To Bridge the Gap Between Technology and Business: A Best Practice Solution

by Jeff Tash, ITscout

For more than 25 years, CIOs have consistently reported that their #1 concern is the “alignment of IT with the business.” Over the past quarter century, lots of new technologies have come and gone. Much has changed technologically. Yet, in terms of the gap between IT and the business, precious little is any different today. The introduction of the personal computer may have shattered the “glasshouse.” But it also brought with it tremendous frustrations, misunderstandings, and confusion. Vendors have only exasperated this situation by frequently bypassing IT and selling directly to business management. Many of these buyers may feel they have more power and control over IT. More accurately, though, what generally has happened with respect to aligning technology and the business, has been the formation of ever expanding “black holes” that suck in money and resources while chasing increasingly complex vendor-hyped solutions.

Think back to 1980. How many “silver bullet” solutions can you remember since then that were supposed to have spanned this chasm between technology and the business? We’ve seen the emergence of relational databases, 4GLs, information centers, micro-mainframe links, DSS, EIS, AI, expert systems, object-oriented, client/server, 3-tier, n-tier, OLTP, OLAP, DW, BI, data mining, web browsers, portals, web services, EAI, BPM, SOA, CASE, CRM, ERP, SCM… This list is like the Energizer bunny. It just keeps going and going and going. We’ve barely scratched the surface of the smorgasbord of technical jargon and acronyms that gets in the way whenever IT tries to communicate with the non-technical business people we work with everyday. Consider SQL, XML, SOAP, WSDL, UDDI, IDE, .NET, Java, C#, C++, VB, ASP, JSP, ODBC, JDBC, ADO, JDO, PKI, SSO, VPN, P2P, B2C, B2B, etc., etc., etc. Honestly, we still haven’t begun to get esoteric. All of the aforementioned terminology is truly mainstream. We could easily continue our list with many additional identifiable technological terms that most IT people would readily recognize. And remember, nobody -- not even an end user -- likes to admit what they don’t understand.

Amazingly, I still haven’t mentioned what was probably the most expensive acronym of them all. Remember Y2K? How much money was spent primarily because of fear and ignorance? Don’t underestimate how badly the Y2K non-event damaged IT’s credibility with executive management.

Just imagine for a moment that you are a business executive. Ask yourself, what is your opinion of IT? Think about how much money has been wasted, how many promises have gone unfulfilled, how many dead end paths have been followed. Why do you think they refer to CIO as “career is over”?

So, what are you supposed to do? Today’s conventional wisdom says IT must be run like a business. CIOs need to be business leaders, not technology experts. Technology investments must be driven by business strategy. But, be careful what you wish for.

It almost always fails to run IT as a business inside the business. There are no market forces at play. IT has to get the payroll out. IT has to process orders. IT has to close the books. Selectively exposing IT to outside competition is possibly the worst strategy imaginable. It’s like the post office trying to compete against FedEx and UPS. The former is required by law to deliver the mail to every address everywhere -- including routes that are downright unprofitable. FedEx and UPS don’t have this restriction. In fact, nowadays, FedEx and UPS literally outsource their most unprofitable business to the postal service. In this analogy, internal IT is like the poor post office. Outside service firms can selectively cherry pick profitable opportunities and leave IT with the responsibility for performing all the costly, undesirable, unprofitable work.

Next, don’t undervalue the key role technology can play in shaping business strategy, particularly considering its ever accelerating pace of change. Keep in mind the maxim that says problems get defined in terms of available solutions.

As you move forward, be very cautious of large-scale, complex, long-term, and expensive enterprise architecture (EA) initiatives that involve layer upon layer of “abstractions.” These types of projects tend to be extremely high risk. They frequently end in failure rather than success.

A less risky way to bridge the gap between technology and business is to follow a simple, inexpensive, three-step approach that focuses on delivering “concrete” results quickly. Start with “consolidation.” Eliminate redundancies. Improve effectiveness. Be more efficient. Your immediate objective is to reduce the resources required to complete the work you’re already performing. The second step is “standardization.” Establish profiles for business processes and services. The goal is reusability. Find ways to apply these business processes or to apply these services to different needs. Finally, and most importantly, place a high value on “communication.” Create a common reference model. Define a common vocabulary. Make certain that both technical and non-technical audiences share a unified knowledgebase. A reference architecture spanning both technical and business issues facilitates the two-way exchange of ideas. It serves as a guidepost ensuring that technology decisions are driven by business strategy.

IT must be agile to support the business needs. But the business side has a responsibility too. They cannot simply tell IT, “Technology is your problem. Go figure it out.” Instead, a reference architecture helps put balance into the relationship between business and IT.

How should you proceed? Follow the simple three-step plan outlined above. Consolidate. Standardize. Communicate. Only then will your organization be ready and prepared to tackle the more difficult requirements associated with larger, more complex EA initiatives. Walk before you run.