Risks with the cloud
How to make your Twitter header pixel perfect
How to harness the app revolution
Why data warehouses don't work
Why CIOs should report into CEOs
How to build your first website (in 20 mins with no special software)
There's nothing nebulous about the cloud: it's row upon row of giant computers, run by a company for profit. There are many clouds, all different.
It isn't really the cloud, it's a cloud. One of many.
When you save a file, it takes up disk space somewhere. The physical location of that disk space is all that changes when you 'move to the cloud'. And often we users can't tell the difference at all.
Perhaps you save files to a G: drive at work, and they used to sit on a big computer (server) in your office basement. You still save to the G: drive, but now the files sit in Finland. You're not even aware of the change. In fact it makes no difference to you - but it makes a big difference to your firm's risk.
It is likely that you have a product or service that has been resold to you. Perhaps you have a mortgage from the Post Office, which is actually a contract with the Bank of Ireland. Maybe you have a mobile contract from a supermarket, which is really delivered to you by one of the big mobile providers. And if you hold car, home or life insurance, it's almost guaranteed a policy will have been resold.
Finance and telecoms markets have been working like this for years: a small number of providers with a far larger number of resellers. Cloud services seem to be going the same way. Soon a few providers will have secured the cloud market and all the other brands you see selling cloud services will actually be resellers. Behind the resellers will probably be wholesalers, who never meet the end customer. Services will be bundled, split and sold on, many times.
If this sounds familiar, it should. It rings subprime alarm bells to me. Bundling, slicing and dicing, reselling - it's just as likely with your data as your mortgage payments. Economies of scale invite it. But unlike debt, these data risks stay with the originator and not the reseller.
There might even come a time when half your data is stored with one company in Finland and the other half with a different company in Canada - even though you have just one relationship with one cloud "provider".
Data efficiency could be greatly increased with this set-up, where servers are so specialised that they only suit part of your data. It's a nerd's wet dream. But your firm has a new set of risks that are very hard to measure.
Let's say we're in 2020 and there are only three major cloud providers globally. What happens to the world's data if one provider goes bankrupt? What if one provider is hacked? Or one provider is based in a country that goes to war? What if there's a natural disaster?
Server sites are picked with care and decent firms will have recovery sites and remote back-up. But if the San Andreas fault goes, it could do far more damage in a world with big clouds than with little ones.
There are a few more alarmist scenarios to consider. If someone wants to attack capitalism, a data centre will make a pretty good target in 2020. A submarine cable makes another. There are surprisingly few of them. Your data might be safe but if you can't access it, you can't run your business. And there's always infiltration at the server centre. This might seem unlikely, but you haven't vetted the people - you're not even sure where they work.
There are also mundane - but likelier - risks around foreign exchange. You might have an agreement with a cloud "provider" in the UK, who is actually selling services from a wholesaler in Finland. Without knowing it, indirectly you are exposed to sterling falling against the euro. The cloud company is exposed in the opposite direction. The reseller takes the brunt of this risk but ultimately it passes on to you.
There's also the bizarre possibility that someone manages to stop the feed of data from your cloud provider and replace it with a data stream of their own without your knowledge. We've seen cloned websites. Maybe we'll see cloned data feeds.
It sounds like a Hollywood movie plot, but a cloned data feed could be used to "remote control" any firm that acts on the basis of data. And if the public sector were to move to an insecure cloud (God forbid!), someone could delete their criminal record, or delete all traces of a hated ex-lover. Retail banks using the cloud could see emptied bank accounts. You might find yourself uninsured, uneducated and underpaid if you're hacked.
So cloud data storage comes with risks. It's not surprising, really. "Cloud" implies remote and third-party - the two sources of new risks.
There is something we can do, however. Some of these risks go away if the end user always knows where the data came from. Others, such as geopolitical risks, do not lessen but can at least be measured if you know where your data is physically located.
Every device attached to the internet (using "internet protocol") has an IP address. This can be used to identify and verify the source of the data, down to the company, building and server. This information should be visible to the end user, not just to the IT department. It should be shown prominently in the software you are using and not hidden in a menu.
With this method we could effectively barcode cloud data. We will have ever greater need to verify our data the market develops.
CIOs might heave a sigh of relief when they jettison their servers and move to the cloud. No longer do they have to worry about outages or flood - it's someone else's problem. But being able to sue your cloud vendor for deleting your data will be small consolation when your own business is going down the pan. From a risk perspective, the CIO's job changes from worrying about server performance to worrying about cloud vendor performance. Personally I'd prefer to worry about server performance: at least I have decent data on it.
Using the cloud is fantastic if you are a fast growing company and you need rapid scalability. You don't want to be popping to the server shop every two minutes. It's also great if your business is run by accountants who want to shift fixed costs into variable, and reduce their assets.
But if you're a mature organisation with predictable data needs, why use the cloud? It doesn't reduce risk, after all: just changes the type of risk and reduces your ability to measure it. There's nothing a cloud server can do that a server in your basement can't. It might be sited, cooled and maintained more cheaply. But technically, you can run a better server locally if you wish. Using the cloud won't fix any software issues you have.
In the mad rush to outsource our data, we might miss the alternatives. If you have sensitive data, consider keeping it in-house. If you hold public data, consider using the government cloud, which presumably has higher levels of security. If you're trying to consolidate data from multiple locations, keep one server centre and create your own private cloud to service the other places.
If you do use a third-party cloud provider - and there are many good reasons to do so - research the provider. Consider only working directly with the cloud provider, avoiding intermediaries. Check the legal bumpf to make sure your data will be where you think it is, and not resold. It's also a good idea to visit the server centre, and check disaster recovery plans, just as you would if you had your own servers.
Moving to the cloud is not a risk-free option for your firm, and as more people move to the cloud, data risk is shifting globally. As there are fewer, bigger cloud providers and more middle men, transparency will fall and risk will increase. We should take steps now to label data with its source, and limit some of these risks for the future.
Twitter now allows you to upload a header image, which is a banner-style image that sits behind your (square) profile photo.
This single image shows up in three places: (1) as a banner on the 'Me' page of your web Twitter; (2) as a mini banner on the 'Home' page of your web Twitter; and (3) as a banner on your mobile Twitter. You can only upload one image for all three jobs - but, get this: all three spaces are different sizes! In a nutshell, the web banner is wide but short, while the mobile version is narrow but tall.
So, although the Twitter guidance tells you to upload an image 1500 x 500 pixels (px), it's a bit more complicated than they let on, if you want to control the layout. This post gives you a method to lay out your header image so that it will serve all three purposes. The method worked for us and we assume it is standard - but if you come across any problems with it, we'd love to know!
The pink area is your image, and you can see that only 350px of it is visible between the white information bars. (The dark grey surround is not part of your Twitter image - that's just to show you the measurements.) The pink area to the top of the higher bar, and below the lower bar, are simply lost to cyberspace. The white bars themselves cover up the rest of the 150px lost.
You can also see the positioning of the (square) profile photo. We read that this was 240px square and was placed 100px from the left hand side. However, we found it to be 228px square and 110px from the side - and we tested it by uploading the image above as our Twitter banner.
On your Twitter 'Home' page, there is a left column listing Trends. On top of that, your header image is again reused. This time it is used in full.
It's a pretty boring one. The important thing from a layout point of view is how much larger the (square) profile photo appears against this header image. If you're planning on putting images or text on the left hand side, bear this in mind.
The mobile version of Twitter cuts off 240px from both left and right, but shows the full height of the image. It also places your profile photo and some text in the centre of the header image.
Whichever colours and pictures you pick for your header image, bear in mind that in the mobile version, Twitter will add a linear darkening gradient to your banner and a further darkening overlay to the bio page.
Hope this has helped!
Yes, as long as you have a computer, you can make a website in about 20 minutes with no prior knowledge. Below are the instructions.
If you're in a hurry, just follow the instructions, which are coloured and indented. The regular text is explanation.
• Open notepad. (Start menu > Accessories > Notepad. It has a blue icon.)
• Type <html></html>.
These are called tags, <opening> and </closing>. They will tell your browser that it is looking at an html document.
• Click in front of the closing tag </html> and hit enter a few times to move the two tags apart.
• After the <html>, type <head></head>.
• Hit enter and type <body></body>.
All html documents must have a head and body elements. The idea is that the body contains the content of the webpage (what you will see in the browser) while the head contains descriptions of the webpage, called metadata.
• Within the <head> tags, type <title></title>.
• Within the <title> tags, make up and type in a title for the page, e.g. Joe Bloggs' first webpage. Do not use quotes.
Best to keep the title snappy, as it will be displayed at the very top of the browser software and also in Google search results, if you were to publish your webpage publicly. Only a certain number of characters will show in both cases (the number varies with search engine and browser software).
• Within the <head> tags but below the <title> tags, type <meta name=”description” content=””>. Within the double quotes after content=, you should write a description of the webpage.
Notice that the <meta> opening tag does not need a closing tag. Note also that there is no <keyword> tag (which is a great pity). A lot of this sort of <head> information, such as author, is captured in <meta> instead of having its own tags. 'Meta' is short for metadata.
Unlike the title, description should be written using full sentences. It's used by Google et al. to work out what the page is about. Description is also what shows up in search engine results: in Google results pages, it's the small black text under the title (which is shown in blue).
As an aside, it is a rule of html code that you should never muddle your tags. The order in which you open tags should be identical to the order in which you close them.
So this is good code:
And this is malformed and will throw an error:
As long as you don't muddle your tags, you can place them in any order within <head>.
• Another tag to go in the <head> tags is the comma-separated keyword tag: <meta name=”keywords” content=”LinkedIn, SEO, html, coding” >. You can replace the words listed in content= with your own keywords, separated by commas.
Keywords are (arguably) used by search engines to work out what the page is about. There are rumours that they are a lot less important than they used to be in Google's secret search algorithm, but it doesn't hurt to have them.
So, that's the <head> sorted, for now. Onto the <body>. You will recall that the <body> tags contain the actual content of the webpage, what will show in the browser. Some of the code in the <body> is actual text, while other code tells the browser where to place the text, and other code still tells the browser how to format the text.
You could leave the <body> blank, and publish a perfectly well formed webpage. It's a radical marketing strategy to have a completely blank page, but from a browser's perspective the page is perfectly coherent without any <body> content. Bit dull, though.
• Within the <body> tags, type hi my name's [insert your name] and again, do not use quotes.
• Now within Notepad, go File > Save As and save to your desktop as site1.
The document will save as a text file and for now this is just fine. So now on your desktop you have a site1.txt saved, and you have site1.txt still open.
• Again go File > Save As and save another copy to your desktop as site2.txt.
So now you have site1.txt and site2.txt on your desktop, and site2.txt still open. This is because we are creating more than one webpage today, to show you how the difference it makes to put in certain tags. All instructions now refer to the open document, site2.txt.
• Now, between the <body> tags, type <div> before the text you just wrote and </div> after it. In other words, place the text "hi my name's..." within <div> tags.
Div is short for division and creates a horizontal division across the webpage. HTML, and browsers, work top-left to bottom-right when they draw up and display ("render") a webpage. It's similar to how a TV screen works.
In other words, HTML likes horizontal and isn't so keen on vertical. Whenever you see a vertical box or line on a webpage, a coder has worked against the natural inclination of HTML to create it. They might have used <div> or <table>, though the latter is pretty unpopular these days.
Several <div> tags used together can create almost any page layout you can imagine and this is the current best practice in creating a webpage. It won't look much today - just a thin line - but if we expand on this tutorial, we can make <div> tags quite powerful.
• Go File > Save. Then go File > Save As and save a copy site3.txt.
Now you have three txt files on your desktop and your open document is site3.txt. Instructions now refer to site3.txt. Now, we need to modify the <div> opening tag itself to tell the browser to make it look different.
• Replace <div> opening tag with this: <div style="background-color: orange; text-align: center">.
Now your line of code should look like this: <div style="background-color: orange; text-align: center">hi my name's Emma</div>.
Most opening tags can usually have additional instructions added within them like this: it is not peculiar to the <div> tag. In effect, the code within an opening tag contains metadata about the content of the tag, just like the <head> contains metadata about the <body>. It is always the opening tag, never the closing tag, that contains these instructions. Multiple instructions can be listed, separated by semi-colons.
In this case, we are asking the browser to fill in the background of the area of the webpage that the <div> takes up, and colour it orange. We're also asking the browser to centre the text within the <div>. Since this <div> is the full width of the webpage, the text will appear centred across the entire webpage.
Notice the American spelling of 'color' and 'center'. This is standard in HTML.
• Go File > Save to save site3.txt and then close Notepad.
• Now go to your Desktop.
• [Method 1] Click once on site1.txt so that the name of the file highlights and allows you to edit it. Delete the .txt extension and replace it with .html, so you are saving a document site1.html onto your desktop. The shortcut should change from a blue notepad to the symbol of your default browser software.
• [Method 2] It is possible that your pc is configured to prevent you modifying - or even seeing - extensions. If this is true for you, double click on site1.txt to open it. Click File > Save As and look for a dropdown at the bottom of the dialog box. It is located under all the filenames, in the grey part of the box. It will currently say "All documents" or "Text documents". Click this dropdown to select .html or .htm (they are the same).
• Repeat this process for site2.txt and site3.txt too.
Depending whether you have edited the filename extension, or used the Save As method, you will now have either 3 or 6 files on your desktop.
Double click on site1.html and your browser should open up. This webpage will be white except for your text, which will show up on the top left of the page. Notice the title you put in the <head> tags is showing at the top of the browser.
• Double click on site2.html. This webpage will look much like site1.html, despite the <div> tags.
It depends which browser you use as to whether site1.html and site2.html appear identical, or whether there is some spacing difference. This is because browsers adopt default spacing for different html elements (a <div> is an html element, as is a <table> or an <img>). The different approaches of Firefox, Microsoft, Safari et al. cause all sorts of problems for professional coders.
You can check the <div> tags are there by right clicking on the site2.html webpage (the white bit, not the address bar) and click View Source. You should see the code you just created all written out neatly. You can do this with all webpages and it is a very useful way to learn to code.
• Double click on site3.html. There should be an orange banner with your text centred in the middle of it.
Congratulations on making your first webpages! If there is interest, I can write more advanced chapters. Please let me know.
N.B. I've simplified some code in the <head> tags, such as declaring doctype and lang. These can be covered in later posts if there is interest.
CIOs brave enough to move from systems to apps can secure huge competitive advantages for their firms - but only if they move quickly enough and do it right. If they do it wrong or leave it too late, they might find themselves outmanoeuvred, permanently.
We know what an app is, right? We have smartphones.
Well, let's debunk some myths. An 'app' does not need to run on a phone, and it is not dependent on 3G or 4G coverage: mobile apps are only one type of application. There are also web apps, which run in your browser, and application software, which runs on your desktop.
There are three types of apps, then. And this is not to say that an app can be distributed in three ways: it is more confusing than that. Web apps and application software cannot run on phones, and vice versa. Application software has been around a long time; phone apps are relatively new. These three types of apps have different coding languages, different purposes, and very different futures.
Today's post will argue that senior executives must understand the difference in order to appreciate what the (web) app revolution can do for them.
Grizzled IT buffs will tell you that 'application software' refers to what we typically think of as a 'system': MS Excel, SAP or graphics software. They will contrast application software with the term 'system software', which refers to operating systems such as XP or Linux.
This terminology is as outdated as your 20-year old master data system, languishing unloved on an old server. These old systems might well be 'application software', but few of us would call them 'apps'.
The word app has modern, fresh connotations, largely thanks to phone apps. But I would argue that we can draw a very useful technical distinction between application software and apps. This is the difference that can revolutionise your firm.
Let's upset the IT old-timers, and redefine some terms. For the rest of this post, a 'system' will refer to the classic software launched from your desktop. With systems, megabytes of software typically sit on your C: drive. In large firms, software updates arrive unannounced on a Monday morning, and installing them can easily chew through a whole morning. With systems, the IT department typically buys and distributes one license per user.
Within systems, there is a further useful categorisation to be made. Call to mind Excel, Word and Access: these are generic software packages that users tailor to their needs. These 'generic systems' do not share a common database across an organisation.
Contrast this with enterprise-wide software such as SAP, or HR data. With these systems, the user logs in to a common system sharing a common database. Let's call these 'enterprise systems'.
The power of apps, as I shall come to define them, lies in replacing enterprise systems.
For the rest of this post, 'app' will have a specific meaning. An app will refer to software in which a single database drives multiple user interfaces, or 'front-ends', across an organisation. Such an app might be run on phones, web browsers, or from your desktop.
The apps we are discussing here might usefully be called 'enterprise apps' as we are talking about apps that are used across an organisation.
In classic system architecture, systems are defined by content. You probably have one HR system, one accounting system and one customer data system. These systems can't talk to each other. Each system has its own database hardcoded into it, and the user interface (front-end) and database (back-end) are bound to each other for life.
If you delete your HR system, you delete your HR data at the same time. This data risk provides a strong disincentive to replacing your system, which becomes a big job involving data migration. And all that effort to replace your system only lands you in the same position: a closed-off HR system that won't let you update its fields and which doesn't talk to other systems.
Using an enterprise app structure, the HR app can be deleted without losing a single byte of data. This is because the app, or front-end, is separate from the database. They are linked, obviously, otherwise the app would be rather empty. But they are not bound for life.
Indeed, in moving from enterprise systems to enterprise apps, the database jilts monogamy in favour of polygamy. The database gets around, having relationships with as many app front-ends as possible. The more, the merrier. This is the core difference between old and new, and its implications are radical.
Systems were differentiated by content, but apps are separated by purpose. There is no longer a single HR system: there might be three apps drawing from HR data. One app is for staff to access and amend their personal data; the second is for managers and HR to track performance; and a third, built for Risk, draws in HR holiday data and internal project data to see which projects are likely to be under-resourced.
Multiple systems are bad news, but multiple apps are a healthy sign. With almost zero set-up and running cost, it becomes good to experiment and iterate. Apps are disposable: they can be built, tested and thrown away in-house (if you hire your own coders).
The most important benefit is that data can truly be integrated going forward. You don't even need to anticipate which data fusions will be useful: you just need to adopt a systems architecture that lets you create them later. There are almost infinite combinations possible with all the data you hold.
So, enterprise apps are great. But they can be mobile, web or desktop launched: which should you choose?
In all three cases, you would have a large, centralised database, hosted securely in your organisation or on the cloud. The database can be identical in all three cases, so there is no data security preference. The question is which user interface do you want your staff to use, and which works best for your organisation?
Desktop apps would launch from a shortcut on the desktop, and look very much like a classic system. They would not be able to run on a smartphone or tablet without being rebuilt. Creating a desktop app would typically be a specialist job, relative to other types of app. There might be benefits in terms of security, however, depending how your firm is set up. For me, the desktop app is probably too restrictive to win first prize.
Mobile apps would launch from a smartphone or tablet. They would look just like the apps currently available on your smartphone. Some consultancies have already created such apps for their consultants to update while they are working with clients. Mobile apps are portable and they have access to a number of features such as GPS, camera and Siri, which regular computers cannot use.
However they cannot be run from a desktop without being rebuilt. Many techie people believe that firms will move entirely to smartphone usage in the near future. Staff will be issued with phones instead of laptops, and these phones will pair with a keyboard, mouse and screen using bluetooth: the ultimate in hotdesking. For the next 5-10 years, though, the inability of mobile apps to run on desktops is a limitation. Also, creating a mobile app remains a specialist task, compared to creating a web app.
Web apps would be accessed via a URL in your browser. Web apps have the advantage that they will automatically work across devices: desktops, phones and tablets can all use the same app. Web apps are easy to build and update: they would probably be built in html, which is one of the easiest languages to pick up.
Web apps should also be automatically secure, if they are placed on your firm's intranet, as they are within the firewall. Unlike the two other types of app, web app software does not need to be downloaded by the user, making software updates slick. With the advent of html5 - which takes video, audio and interactive graphics in its stride - web apps seem to me a good option. They are, at least, a good place to start the conversation.
Information is not operational. Finding it, making sense of it and reporting it sum up most business activities in today's service-led UK economy. Whether you work in a bank or for the police, most of your day is spent processing information. Storing information, like housing staff, is an operational matter. But the information belongs to the business, and processing it is the business itself.
Why, then, do many chief information officers report into the operational head instead of the business head? One argument – and there are of course others – is that CIOs are hired largely from the IT fraternity. And this, in turn, occurs because not enough senior business people “speak” IT.
As a result, it falls upon the CIO to learn to “speak” business, and to perform the inevitable translation between the business and IT. This gives the CIO enormous power, and an effective veto on any system decision. CEOs who outsource their information give up far more than they realise. The unhappy result of Ops-led information is that the business stops taking ownership both of their data and of their interface with the data. Over time, both data quality and the suitability of systems decline.
This post argues that the business needs to reassert ownership of their information. CIOs should be hired from the increasing pool of people who work on the business side of things but speak IT fluently. Senior executives – including the CEO – should receive considerable training in IT, and securing this outcome should be one of the principal responsibilities of the CIO. The other, of course, is that the CIO should identify what information the business needs and how it should be presented.
The CTO – keeping the lights on on the servers – should continue to work for the COO but with a dotted line to the CIO. This structure would have its own risks, of course: one person is permanently in request mode with the other permanently in support mode, and this is open to friction if not abuse. The CIO might ask for the impossible, blaming the CTO when it can't be delivered.
Several measures can be adopted to prevent this. One is that the CIO should be highly IT literate, aware of the current system architecture and quite specific in their requests. High level, vague or impossible requests should simply not be made. The other is that there should be joint objectives and bonuses for these two roles, to bind them as a team. When all else fails, money can structure behaviour quite effectively.
The potential difficulties between CIO and CTO/COO should not inform the organisation structure. An organisation should be structured according to its objectives, not according to what feels comfortable. Praise incentives and financial incentives can be used wisely by the CEO to reduce friction if necessary. And the reward for this should be a more productive business, a tamed IT department, and a smaller gulf between the two.
Most large corporates have data problems. I have seen calls for “joined-up thinking” and “integrated data” from CEOs at banks and regulators alike.
A standard response to this need has been data warehousing. But people are gradually realising that this approach does not work. Let's take one organisation I know well, which has 323 systems. They need about five systems in total, but their IT department says such a consolidation is “too big” and that a better business intelligence system will do the trick. Senior execs need to understand a bit about systems in order to hold the conversation - and push back - on the systems design their business needs.
For many senior execs, their system set-up is a foreign land: they don't know what it would look like if they went there, and they're pretty sure they wouldn't speak the language anyway.
In these cases, it can be useful to visualise your systems architecture. The best visual analogy I have found is to think of each system with data as a house with books. People share books between houses, just as staff email data to each other between systems.
Houses, like systems, can be poorly designed, where you have to walk through the bathroom to get to the bedroom, for example. Houses can be big or small, new or old, and well or poorly maintained. They can be extended, but although you can increase the floorspace of a two bed cottage, you simply cannot make it into a detached manor. And - crucially - if you have a large group of people to accommodate, buying 20 small cottages will never work as well as buying one large property that can house them all.
Systems are the same. Some are well designed, while others make it hard to access the data. There are old systems and new ones, and some that look old before their time through poor maintenance. You might be able to extend some of your old systems, or tweak the use to which they are put - but there is every chance you will end up with an unsightly mess. And, if you have groups of related data, housing them in 20 separate systems will never work as well as consolidating them into one.
So how should you picture your 323 systems? Imagine a village with 323 buildings. They are big and small, old and new, and some in a tumbledown state. Some are on the main road, and others off the beaten track and quite difficult to access. These roads represent information, flowing (or not flowing) between systems. It's so difficult to travel between some properties that in effect it never happens.
One property is so cut off from the others that your IT department have ruled out any further maintenance on it. They say they will knock the building down and replace it in about a year.
There are a few problems with this decision, however. First, this year-long timeframe is a moving target, and has already slipped several times. Second, in this coming year the staff in the property will continue to be unproductive and the books will still be out of reach for other staff. Third, it is IT that is calling the shots in the design of what is fundamentally a business activity, i.e. how staff interact and share information. And fourth, IT's “strategic” plan to replace the shack will still leave the organisation with 323 houses, or systems.
Given a blank sheet of paper, the CEO would surely design a single building to replace most, if not all, of the 323. This building would allow staff to access each other, and each others' books, with ease. But the IT department says that this design is too hard. They say a data warehouse will work just as well, if they can only replace their old data warehouse software – which doesn't quite do the job – with some new data warehouse software, which has a whizzier interface but is otherwise unimproved on the old one.
We can think of a data warehouse as a mezzanine level built across the entire village, over the rooftops of all the buildings. It contains a library that houses duplicates of every book from every house. The books are categorised by house name, rather than by content, because no-one took the time to read the books and label them.
A library might sound appealing, but it has some serious problems. First, the data warehouse duplicates data, and when changes are made to the original they do not always update the copy. Second, a new member of staff would need to understand the composition of 323 systems in order to work the data warehouse – and almost certainly without being given a map. Third, staff are still trapped in their houses. They might have access to other data if they are intrepid enough to find the library and hunt for new books, but their day-to-day worldview remains squarely focused on their own property. And fourth – the most damning indictment of all – is that data warehouses line up but do not integrate data.
Let's say our tumbledown shack held books on staff data, while a newer, larger house held books on customer data. The simple question "Which staff are working on which client accounts?" is impossible to answer with a data warehouse. There is no common key tying the books together.
The CEO does not know that there is an alternative to his problem. He is not an IT expert and he has placed his faith in the CIO. For her part, the CIO might not realise that there is a problem. She is likely to have a background in IT rather than in the business side of things. She might consider her data warehouse a job well done if it is technically well executed, without regard to its usability – and she will probably be supported in this view by her boss, the COO, whose goals are essentially to prevent anything breaking down.
Meanwhile, staff in the IT department are busy increasing the number of systems, in response to decentralised and locally focused staff requests. IT departments increasingly employ project managers rather than coders, who know nothing about designing systems but lots about buying them. As we might expect, instead of tweaking existing systems, new ones are bought, compounding the problem.
The CEO believes that information is an operational issue, rather than a business one. It is an odd assumption. The same CEO believes that organisation design - how staff report to each other - is a business activity.
These assumptions work really well in production lines, where the machinery is an operational activity and sharing information upwards rather than sideways works efficiently. But in an information-processing organisation - whether it is banking, police work or marketing - these assumptions do not hold. The machinery - computer hardware - should not be confused with the information it holds, or how that information is shared. In an information-processing organisation, information is what the business does.
Your system architecture - like the design of the village - determines how your staff interact. If your organisation can't seem to shake its silos, take a look at your systems structure before tinkering with your divisions. The CEO should be instrumental in shaping systems structures, albeit at a high level. And given a blank sheet of paper, most would choose a single building to house their staff rather than a data warehouse.