Here is a scene for you to imagine.

Imagine it is 1000 BC and a bunch of Sumerians are sitting around a table making impressions on clay tablets.  Others are taking the stamped tablets and putting them into ovens.  These are scribes in the hire of a merchant sitting across the table from them.  He is reciting the day’s sales to the scribes.  The scribes are tallying up the sales of sheep and bushels of wheat.

Lets jump forward 2000 years in time.  Now we are in medieval England.  A king has a bunch of scribes that are helping to account for the annual taxation of his subjects. They are doing more or less the same thing as the scribes 2000 years ago except now they are using crude paper or tanned hides.

Remember the scene at the beginning of the Monty Python film, “The Meaning of Life” where two buildings collide and armies of accountants fend off the pirates?  Now there are armies of scribes and the clay tablets have become paper ledgers and filing cabinets.

You know where I am going with this.  The methods of tabulating and communicating information resulting from business activities is age old, and has remained unchanged for a very long time.

However, in recent times, the method of tabulating and communicating information has begun to change drastically.  The scribe and the tablet bakers have largely been supplanted by information technology. Your data may be recorded on paper or clay, or a hard drive.  The tools change but the purpose remains the same.

That is all that IT is doing for you.

The clay table or ledger in paper form was walked from one office to the next.  Ledgers were passed along from one scribe to the other.  Today, the tools we use are spreadsheets, electronic documents, emails, databases in applications, and networks and the internet to transmit them to others and store the data in a central location. For the moment let’s ignore that a lot, too much, of business today continues to use paper and manual processes.  That’s another topic of discussion worth having though.

However, the information technology we use today is so complex, and often too arcane or specialized for most people to understand, let alone use.  So most of the people creating, implementing and supporting information technologies are not directly involved with the business.  The corollary to our forbearers would be like having clay tablets or pencils that used invisible ink, or that the scribes wouldn’t know how, or even be interested in how to record the numbers of sheep, but instead made clay tablets that met their needs first, and conformed to their arcane sensibilities.

While business has recorded and communicated its activities since almost the dawn of civilization, the introduction of information technology reset the clock.    Thousands of years of pervasive experience with relatively unchanging set of tools and processes has been completely replaced over the past 20 years or so.  We are almost literally starting from scratch.

This presents an enormous challenge.  In the past, business users had the knowledge of how to use a pencil or make impressions in clay sufficient to manage their scribes to focus most efficiently to achieve business goals and objectives.  However, today, IT is a black box.  This interchangeability of function would be like unthinkable today.  Business users cannot swap place with technology workers.

The resolution is simple:  IT workers must learn what the business does, and business users must learn what IT does.

The domains of knowledge and capability of business and IT are not synchronous in terms of understanding and contributing to the business goals and strategies.  In fact they are rather mutually exclusive.

The IT ‘black box’ (as seen from the business side) is full of technical skills, experience and knowledge and rarely has elements that extend into the business domain.  In contast, the business ‘white box’ elements do go into the IT domain generally in roles of business analysts and project managers who work on IT projects.  It is true that there are IT relationship managers that extend into the business domain but they are more focused on IT interests.

It is crucially important that the IT black box be bust wide open, and that IT extend its knowledge into the business domain.  Cross-training, measuring IT contributions in terms of business success, Agile development, are some of the ways to do this.  Critically, business and IT management must recognize this and encourage the extension of IT into the business domain.

IT is very poorly defined. Inside most organizations, IT is often poorly understood in terms of what it does, what it can deliver, in support of the business’ goals and strategies.

This Forrester Research article points out that it is connection of business strategy to how IT can help that is the issue.

This is clearly a communication issue. People in IT need to be able to articulate their potential contributions to their business counterparts. There is too much jargon and technical detail that leaks into this communication. That is where the obfuscation fog rolls in. Also, there is a special kind of nuance and perception required for understanding business strategy that requires focusing on the ‘big picture’ which is something IT workers often never do.

There is a real irony here that some of the strategic benefits are found in details. For example, a strategy may be to define products in a unified manner across an organization. The IT contribution is to get very detailed in tables and application code to ensure that product references align with strategy.

This highlights how IT could really increase their contribution by relating what they do and how the bits and pieces of IT can help meet strategic goals.

Of course, the business must also come half way. Strategic communications could be better phrased or aligned in IT terms, to focus on how they will be delivered, which is often via IT, eg by updating application pick lists (updating product types).

Business-IT alignment is one of those persistent ‘Top 3′ CIO issues. It has been this way just about as long as I’ve been in IT. You would think this has been solved by now. After all, you put in business-driven IT governance, relationship managers, and some really nice dashboard, and you’ve covered about 90% of the advice out there. I’m going to suggest that business-IT alignment is being held hostage by complexity. Not technology complexity, since business leaders seem to be coming to terms with that. And not the mind-numbing spaghetti charts that show how complex our application and infrastructure landscapes are. The complexity I’m referring to lies between their goals and the ‘stuff’ IT delivers. They don’t see the connection.

Forrester – A Different Kind of Complexity Holds Business-IT Alignment Hostage

It is just not possible to do anything related to IT without IT. Full stop. Someone involved needs information technology skills and experience. Ideally, though they do need to know the business. Maybe when we get artificial intelligences.

That same, tired storyline is playing out once again—as it has with other enterprise software apps in the past, such as with SaaS CRM and salesforce automation. This time around it’s business intelligence.

The tale goes something like this: Business meets recession; CEO cuts IT spending. But users want new data insights! But IT can’t spend resources! Then business meets SaaS company, users like functionality, and LoB manager likes price. Sold! IT stays in the dark.

People without IT skills may be able to perform tasks using the software, but this will be very limited. It is rare that any business or organization can find a perfect fit for its operations and business processes in an off-the-shelf application.

So, stop dreaming! Engage your IT people in your business. Business people, start learning about IT. Share desks, do some shoulder surfing. Cross-train. And most importantly, management needs to take the lead!

A recent CIO.com article  Does this Sybase Study Matter? highlights the obvious:  “IT investments can boost its overall business performance”.

That yet another study and subsequent discussion reveal this ‘startling’ observation can be viewed as either frustratingly maddening or delightedly confirmatory.

Another CIO.com article Taming the ERP Integration Beast: A Work in Progress presents some of the technical complexity that challenges organizations to get all of their various applications to interact with each other.

The key challenge is that, as a rule, most applications have proprietary processes of working with data and storage of data.  Consider the following simple example.

Application #1 only allows you to view cars by their model name.  It has no data field for a model’s colour.  If a new car is added to the database using this application, it can only be categorized by its model name, not by its colour.

Application #2 only allows you to view cars by their colour.  It has no data field for a model’s name.  If a new car is added to the database using this application, it can only be categorized by its colour , not by its model name.

If you now want to have both Application #1 and #2 work with each other seamlessly (or as the article notes “integrate”), you have a challenge.  You need a way to translate between model name and colour.   The obvious solution to this challenge is to make sure that both Application #1 and #2 have the ability to record a model’s name AND colour.

However, imagine that instead of the simple example above, with just one categorization difference between two applications, you have many categorization differences between many applications.  The variety of differences can range from subtle to stark.  This disharmony arises for a number of reasons including:

• Marketing thinks of a product or service differently than does the engineering department
• Applications bought “off the shelf” simply do not have the required fields to categorize a product or service as specifically as required
• The business has changed its categorization, adding new categorizations or revising existing categorizations
• IT workers create IT-centric categorizations in an application code or database that emerge into the business side via the application user interface or reporting

Given this disharmony it is not surprising that an entire industry has developed to address this. It is one of business’ biggest challenges surrounding its use of information technology.

As most IT shops know all too well, “integration challenges are often the foremost obstacle to getting the full value from packaged ERP solutions,” as the Forrester report notes. If CIOs can actually overcome today’s integration challenges, just think how easy it’ll be demonstrate IT’s value and align IT’s efforts with the business once and for all.

But going back to the simple example of a car colour and model, the obvious solution was to make sure that both Application #1 and #2 have the ability to record a model’s name AND colour.  If we consider the reasons disharmony arises, is it possible that an organization could nip a lot of this disharmony in the bud by mandating that all applications “speak the same language”?

Before answering, consider that this disharmony is not really an IT issue but one of organizational goals and strategies, relating to how an organization categorizes its products, services, employees, customers, partners and activities.

If everyone in an organization was aware of the strategic and practical implications of categorizing the organization’s products, services, employees, customers, partners and activities, a lot of disharmony would vanish – and integration of IT process and data would be much easier.

It could be mandated that ANY categorization of a product be done ONLY in a way that aligns with strategic goals.  This would include references to that product internally, in marketing material, in supply chain procurement, etc.  Too often, and to the productive detriment of an organization’s bottom line, there are numerous ways of referring to its product, services, activities, employee or customer groupings, etc.  The inherent inefficiencies are obvious.

It is worth noting that these fundamental organizational issues are highlighted by IT.  Information technology, specifically applications, databases and reporting are very rigorous in that they require specific categorization of products, services, people and activities in order to properly group, sum, and perform operations.  Before IT became a core business tool,  categorization of products, services, people and activities didn’t have to be as rigorous.  Grouping, summing and performing operations were manual processes, and people could ‘fudge’ the data to make it fit.  The topic of this article, ‘integration’, is essentially an automating this formally manual process.  It is also worth noting that it is likely IT workers doing the ‘fudging’ now whereas in the past it was done by business workers, and that business workers can probably make informed judgments about fudging the data and process than can IT workers!

Put in this light, it is clear that the challenges discussed in this article arise from much more fundamental organizational issues, and that addressing these challenges as an IT issue is not sufficient.   To properly address integration challenges, the direction needs to come from the business side, and specifically from the leadership of the organization.

A CIO.com article A Different Kind of Complexity Holds Business-IT Alignment Hostage touches on how the ‘complexity’ of an organization’s goals and strategies presents a big challenge its IT team.

The complexity I’m referring to lies between their goals and the ‘stuff’ IT delivers. They don’t see the connection.

One of the most important issues that this article highlights is the lack of communication within an organization, and specifically the fact that IT is often left out of loop when it comes to communicating business goals and strategies.

One of the tools that this article suggests would be useful in communicating with IT are Business Capability Maps.

Business architecture helps IT-business alignment by helping execs clarify goals, strategies and the needed changes in the business operating model, and by helping IT understand and deliver to these goals, strategies and needed changes. There are several approaches to doing this – we believe that Business Capability Maps [can help].

Indeed, Business Capability Maps are a useful tool.

Forrester defines a business capability map as “A model of the firm associating the business capabilities, processes, and functions required for business success with the IT resource that enables them.“ (Capability Maps Anchor Business Complexity, Bobby Cameron, Forrester, November 16, 2007) link

However, not to dismiss Business Capability Maps, but there are still other more fundamental reasons for the lack of effective communication and understanding between the business and its IT group that need to be addressed first.

IT must first be a willing to communicate.  I think  IT often keeps itself out of that loop.  This happens simply by default.  IT is a ‘black box’, its technical aspects ward off understanding by non-IT parts of organization.   This keeps it separate from the organization in many respects. IT literally speaks a different language.

In addition, many IT groups purposefully keep themselves segregated from the organization at large for a variety of reasons.  Lack of time for engagement is the big culprit here, combined with lack of ability or sanction to take time out to sit with business workers and really understand their requirements.  In order to deliver on often narrowly defined scope of work, IT must avoid understanding too much because requirements could increase or worse business expectations could be raised too high.

In the extreme, I have seen IT groups that do not even attend social events held by organization because they fear having people use the social contact as a shortcut past the help desk to help resolve some desktop issue or past the business analyst to slip in a few extra requirements on the new build.

Which brings us to one of the most critical impediments for business-IT communication.  Most business-IT interaction happens at the help desk or through the key-hole view of the business via a narrowly defined project.  Often this is filtered through the perspective of an IT business analyst’s interaction with a handful of business side project members who themselves are not cognizant of wider business goals and strategies.

The complexity described by this article in an organizational issue.  Everyone, from both business and IT, needs to understand an organization’s goals and strategies and tools such as capability maps are important means of doing this.  However, when it comes down to it, the only way for people to understand and communicate is to have some kind of meaningful participatory interaction.

IT workers and business workers need to interact on a practical level.  The only way for this to happen is to literally have both sit side by side and learn practical aspects of the other’s routines.  Developers and analysts need to be given significant time to do business work alongside business workers as a means of understanding requirements.  No more key-hole views or filtered perspectives.

It can practically be guaranteed that application developers, database analysts and reporting analysts will have ‘epiphanies’ as they sit with business workers and actually use the applications and reporting (that they had a hand in developing) and participate in business process.  Of course, these epiphanies can only make their way back into the development, support and implementation process if the organization allows it to happen eg enable a process to record these epiphanies and time and money to enable them to be integrated into IT.

Complexity is often something that exists in the eye of the unengaged beholder, at least in terms of understanding and taking action.  Life is fraught with complexity but familiarity has a way of making the complex routine.

This Globe and Mail article Data dive reveals an ocean of trends provides examples of what are purported to be business intelligence (BI) and “analytics” but which I would consider to be just plain old reporting.

Consider the following example:

Say you offer 10 products, and you notice that sales of one of them are way down. By clicking on that line in the report, BI software lets you look at lower-level information – model or colour – and find that a certain item is not selling. Another click may show you that one salesperson’s volume, or lack thereof, is the problem, or it may indicate that you didn’t have sufficient inventory and couldn’t sell more.

You don’t need “BI software” to do the type of reporting described in the example above.  Can anyone honestly believe that no one reviewed records of sales prior to the introduction of so-called “BI software”?

A company could be manual tallying sales using paper and pencil and is surprisingly still the way many small businesses operate today.

More likely though many companies record their sales in something like an Excel spreadsheet.  They may use some bespoke or off-the-shelf application to record sales.  In both cases the data is being recorded in a structured format which can be easily accessed to retrieve the sales data for review and reporting.   Often this is a feature of the application in which the data was recorded or it would be relatively simple to export the application’s data, or directly link to the data, and do the reporting using Excel, Access, SAS, Filemaker or any number of database,  query and reporting tools.

“BI software” does more or less the same thing as the relatively simple methods described above.  Granted, some “BI software” does much more such as helping the user relate different data sources or properly format data but in order to really help a user, the user needs to have some level of awareness of what the software is doing in order to use it.  The key message here is that “BI” is not about the software, or any other tool, that is being used.  “BI” is really a process and methodology in which data is organized and reviewed in a way that delivers information about the activity that the data comes from.

Viewed from this perspective, “BI” has been conducted for literally 1000′s of years.  Some Mesopotamian trader in 3000 BC would have conducted a very similar review of sales data and he sure didn’t have “BI software” though he most surely would’ve used the same analytical process to review his business’ activities.

Calling this type of reporting “BI” is often misleading.  There is a degree of marketing hype that intimates that the software will minimize the need for the user to have a basic understanding of structuring, relating and formatting the data.  Marketing of “BI” and “analytical” software and related services make the promise that if you simply buy the software and services, you will magically be able to transform your data into accurate and useful information.

This likely leads to many instances where companies who are jumping on the “BI” and “analytical” software and related services band wagon, would be much be served by simply implementing basic systematic and structured data collection and reporting.

Now all of that said, “BI” and “analytical” software sell related services are real and do have an important role.  Some of the other examples in this article more properly describe “BI” such as the following:

Mike Der, MAB’s manager of business intelligence systems, says the company purchases raw data on sales of its products and those of its competitors, sold both at retail and in the hospitality space, from places such as the Liquor Control Board of Ontario. It imports the information into its data warehouse and uses IBM Cognos tools to analyze what types of beverages are purchased, and when and where they are purchased, often down to the individual store level.

This example describes a higher level of data collection and reporting and purpose than simple operational and management reporting.  Still this could just be called more complex and focused operational and management reporting with a broadened scope to relate the company’s data to that of its industry peers.

However, I would call this work “BI” and more realistically, a company might be better served buying “BI software” to conduct this work.  “BI software” is developed to get data from various related but different sources and allow the user to match up similar things so that comparisons can be made for example matching up your company’s sales of beer to another company’s sales of beer.  It may be that your competitor tallies sales by month but your company tallies sales by week, or you may tally by province, but your competitor tallies by city.  “BI software” makes it easy for you to match up this different types of grouping of data.

“BI software” also provides built-in grouping, counting, statistical comparisons and analysis of the data in addition to built-in ability to drill-down into data to see greater detail.  Usually you get nice table and charting creation functions too.

As the article notes ..

Regardless of the solution you choose, Mr. Der advises, take baby steps. Know where the gaps exist in your data and look for a solution to provide insight into the information you have. Start with reporting, then grow into the other functions. “Then you’ll have confidence,” he says. “You’ll understand how the tool creates value.”

.. if your company is considering jumping on the “BI” and “analytical” software and related services band wagon, you would be best served asking whether you already have a systematic and structured means of collecting data and reporting on that data!

A very refreshing CIO.com interview with CVS Caremark CIO Stuart McGuigan CVS IT Chief on the Remedy for Business-IT Alignment highlights how business and IT should work together, and specifically how the CEO and senior management’s perspective of what IT should be …  (hint: IT is business!)

“Technology starts with really good business thinking”

Likely there are very few people who would disagree with the above statement but in practice this is not how most technology gets integrated into a company.  Very often, technology hijacks the business agenda.   McGuigan has a useful suggestion for business people to get involved and keep the agenda on good business thinking.

“[T]here’s the perception that [business partners] have to understand IT at some technical or mechanical level before they can have the conversation.”  However, McGuigan says: “Don’t get into the technology. Just be able to get a clear answer to the question: What will I be able to do after I build the system that I can’t do today?”

It is critical that this message about how to integrate technology come from the very top of the organization.  CVS’s successful use of  information technology is directly related to their CEO’s understanding of how to integrate it into the business and clearly communicates this to all senior management.

“In my first meeting on the BPC [business planning council], our CEO Tom Ryan said, and I remember this very clearly: Welcome and we expect you to contribute to the dialogue here and not just on technology questions.”

“So it’s not just encouraged, but our CEO insists that business, technology and operations all participate in that. And it is that mix, which is focused on key business strategies, that produces excellent operations and technology. You can’t do them separately.”

This top-down communication of how to integrate IT into the business is very different from the ‘alignment of IT and business’ school of thought.

“[IT governance structure] is actually business governance with IT as a component. It’s about recognizing that there’s no such thing as technology projects; they are all business projects with technology components. ”

“McGuigan: It is one of the things that has always amazed me over the years, in looking at CIO surveys: That IT-business alignment or strategy pops up in [those surveys] as the top one or two issue. Because if you don’t know how what you’re doing in IT is going to benefit the business, if you can’t even verbalize the connection in the investment in IT and a benefit to the business, then why are you doing it at all? “

At a practical level, McGuigan offers more detailed advice on how to manage all IT activity in a way that keeps a regular focus on business thinking rather than alignment.

“I consider a project that allows us to make better use of our IT assets, to be more efficient, reduce cycle time for deploying capabilities, make better use of capacity—even though it’s done entirely within IT—that’s a business project.”

McGuigan highlights that often IT has very little understanding of business needs and the critical requirement that IT know what the business does.

“For IT, you also need to be at least conversant with every area of the business you support, which can be many. So that is a challenge, which is one of the most exciting parts of job: You have to keep up with every aspect of the business and every area of technology, so that you can participate in those conversations intelligently.”

The challenge for an organization is how IT can become conversant with every area of the business.  I believe that the only way is through a regular program of secondment where IT workers get swapped into various business roles for a significant percent of their working hours.

The most important message from this interview is McGuigan’s dismissal of the discussion of ‘alignment’ of IT and business as “been there, done that.”  Instead he states,

“It’s about recognizing that there’s no such thing as technology projects. They are all business projects with technology components.”

So much productivity and value could be unlocked if all businesses paid attention to these simple two sentence!

A Forbes report Managing Information in the Enterprise which included surveys of both business and IT executives found that there is uncertainty about who is responsible for an organization’s data.

Managing Information in the Enterprise is based on insights from more than 200 business and IT executives at companies with annual revenues of $500 million-plus. …  It also identifies disagreements between line-of-business executives and IT professionals on how best to manage information. As a result, lines of business and IT may need to find common ground to give top management the economic incentive to push for strategic information-management solutions.

The issues exposed by this report highlight that a core challenge for the business side is their lack of awareness and/or ability to take ownership of the IT aspects of business.

A CIO.com review of this report Data, Data Everywhere, But Not Enough Smart Management provided a number of the issues identified.

While both business and IT side agreed that the business should treat its data as a strategic asset, there was a significant gap between the business and IT about how data quality issues were being addressed in their companies to address these challenges.

A key issue identified by this survey are differing perspective on the definition of ‘data’.  Data is a technical word and many default to thinking about data as a technical issue.  However, ‘data’ is nothing more than lists of things and activities that make up your business.  This difference in perspective on the definition of data is a primary reason for the gap in awareness of data quality.

Only 25% of business side reported awareness of initiatives to address bad data while  51% of IT side said their companies were engaged in data quality management work.

While it does appear that IT is more aware of what their companies are doing, this may be a technical jargon issue.  IT regularly uses the phrase ‘data quality’.  The business may well be undertaking initiatives that actually address data quality from a business process or strategic perspective, and may not report this when as if it is ‘data quality’ work.  Conversely, IT may be undertaking data quality work that simply may not be necessary or signficant in terms of helping the business meet its goals.

Further, databases and applications require strictly defined fields and steps for input and use.  Data quality is inherently an issue requiring strict attention.   The business side rarely gets into the hands on practicalities of defining data fields, describing process in step by step detail required to develop, operate and maintain applications.  The business thus has a fuzzier awareness of data quality.  If an application doesn’t have a required piece of data or an application or report uses an existing piece of data incorrectly, they ask for a fix, which may require addressing data quality, but only IT side is hands on involved in that.  This means that a lot of the data quality is addressed behind the scenes and often may be only loosely related to business side requests.

It is also probably very likely that while IT and business report that data is important, they are each actually thinking slightly differently about what ‘data’ is.  IT, who work with applications and databases, have a much more rigid perspective of what data is.  Business side is likely more focused on process and aggregates of data, desiring more ‘information’ focus.

Business need to take ownership of the data.  Addressing data quality issues almost always leads to insights in how data is being captured, which leads to business process, communication and training issues.  For example, if a data field regularly has different values that expected, it may be that that is what users want to put in that field.  Maybe it is a lack of communication or training that results in the wrong values being entered.  Maybe another field is required.  In all cases, it is business side issue at heart.  IT can assist but all decisions ultimately rest with the business.