The original focus of IT was efficiency and accuracy. Today, the expectation still includes efficiency and accuracy, yet adds increased revenue and expanded capabilities for customers.
IT has been with us for more than half a century, if you count IT as not only PCs and servers but also minicomputers, mainframes, and batch processing systems for accounting and finance.
Computers were originally large, expensive, and fussy beasts. They required an whole room to themselves. Computers cost a lot of money. Mainframes cost hundreds of thousands of dollars (if not millions). They needed a coterie of attendants: operators, programmers, service technicians, and managers.
Even the early personal computers were expensive. A PC in the early 1980s cost three to five thousand dollars. They didn't need a separate room, but they were a significant investment.
The focus was on efficiency. Computers were meant to make companies more efficient, processing transactions and generating reports faster and more accurately than humans.
Because of their cost, we wanted computers to operate as efficiently as possible. Companies who purchased mainframes would monitor CPU and disk usage to ensure that they were operating in the ninety-percent range. If usage was higher than that, they knew they needed to expand their system; if less, they had spent too much on hardware.
Today, we focus less on efficiency and more on growing the business. We view automation and big data as mechanisms for new services and ways to acquire new customers.
That's quite a shift from the "spend just enough to print accounting reports" mindset. What changed?
I can think of two underlying changes.
First, the size and cost of computers have dropped. A cell phone that fits in your pocket and costs less than a thousand dollars. Laptop PCs can be acquired for similar prices; Chromebooks for significantly less. Phones, tablets, Chromebooks, and even laptops can be operated by a single person.
The drop in cost means that we can worry less about internal efficiency. Buying a mainframe computer that was too large was an expensive mistake. Buying an extra laptop is almost unnoticed. Investing in IT is like any other investment, with a potential return of new business.
Yet there is another effect.
In the early days of IT (from the 1950s to the 1980s), computers were mysterious and almost magical devices. Business managers were unfamiliar with computers. Many people weren't sure that computers would remain tame, and some feared that they would take over (the company, the country, the world). Managers didn't know how to leverage computers to their full extent. Investors were wary of the cost. Customers resisted the use of computer-generated cards that read "do not fold, spindle, or mutilate".
Today, computers are not mysterious, and certainly not magical. They are routine. They are mundane. And business managers don't fear them. Instead, managers see computers as a tool. Investors see them as equipment. Customers willingly install apps on their phones.
I'm not surprised. The business managers of the 1950s grew up with manual processes. Senior managers might have remembered an age without electricity.
Today's managers are comfortable with computers. They used them as children, playing video games and writing programs in BASIC. The thought that computers can assist the business in various tasks is a natural extension of that experience.
Our view of computers has shifted. The large, expensive, magical computation boxes have shrunk and become cheaper, and are now small, flexible, and powerful computation boxes. Simply owning (or leasing) a mainframe would provide strategic advantage through intimidation; now everyone can leverage server farms, networks, cloud computing, and real-time updates. But owning (or leasing) a server farm or a cloud network isn't enough to impress -- managers, customers, and investors look for business results.
With a new view of computers as mundane, its no surprise that businesses look at them as a way to grow.
Showing posts with label business processes. Show all posts
Showing posts with label business processes. Show all posts
Tuesday, July 26, 2016
Tuesday, June 10, 2014
Slow and steady wins the race -- or does it?
Apple and Google run at a faster pace than their predecessors. Apple introduces new products often: new iPhones, new iPad tablets, new versions of iOS; Google does the same with Nexus phones and Android.
Apple and Google's quicker pace is not limited to the introduction of new products. They also drop items from their product line.
The "old school" was IBM and Microsoft. These companies moved slowly, introduced new products and services after careful planning, and supported their customers for years. New versions of software were backwards compatible. New hardware platforms supported the software from previous platforms. When a product was discontinued, customers were offered a path forward. (For example, IBM discontinued the System/36 minicomputers and offered the AS/400 line.)
IBM and Microsoft were the safe choices for IT, in part because they supported their customers.
Apple and Google, in contrast, have dropped products and services with no alternatives. Apple dropped .Mac. Google dropped their RSS reader. (I started this rant when I learned that Google dropped their conversion services from App Engine.)
I was about to chide Google and Apple for their inappropriate behavior when I thought of something.
Maybe I am wrong.
Maybe this new model of business (fast change, short product life) is the future?
What are the consequences of this business model?
For starters, businesses that rely on these products and services will have to change. These businesses can no longer rely on long product lifetimes. They can no longer rely on a guarantee of "a path forward" -- at least not with Apple and Google.
Yet IBM and Microsoft are not the safe havens of the past. IBM is out of the PC business, and getting out of the server business. Microsoft is increasing the frequency of operating system releases. (Windows 9 is expected to arrive in 2015. The two years of Windows 8's life are much shorter than the decade of Windows XP.) The "old school" suppliers of PC technology are gone.
Companies no longer have the comfort of selecting technology and using it for decades. Technology will "rev" faster, and the new versions will not always be backwards compatible.
Organizations with large IT infrastructures will find that their technologies are less homogeneous. Companies can no longer select a "standard PC" and purchase it over a period of years. Instead, every few months will see new hardware.
Organizations will see software change too. New versions of operating systems. New versions of applications. New versions of online services (software as a service, platform as a service, infrastructure as a service, web services) will occur -- and not always on a convenient schedule.
More frequent changes to the base upon which companies build their infrastructure will mean that companies spend more time responding to those changes. More frequent changes to the hardware will mean that companies have more variations of hardware (or they spend more time and money keeping everyone equipped with the latest).
IT support groups will be stressed as they must learn the new hardware and software, and more frequently. Roll-outs of internal systems will become more complex, as the target base will be more diverse.
Development groups must deliver new versions of their products on a faster schedule, and to a broader set of hardware (and software). It's no longer acceptable to deliver an application for "Windows only". One must include MacOS, the web, tablets, and phones. (And maybe Kindle tablets, too.)
Large organizations (corporations, governments, and others) have developed procedures to control the technology within (and to minimize costs). Those procedures often include standards, centralized procurement, and change review boards (in other words, bureaucracy). The outside world (suppliers and competitors) cares not one whit about a company's internal bureaucracy and is changing.
The slow, sedate pace of application development is a thing of the past. We live in faster times.
"Slow and steady" used to win. The tortoise would, in the long run, win over the hare. Today, I think the hare has the advantage.
Apple and Google's quicker pace is not limited to the introduction of new products. They also drop items from their product line.
The "old school" was IBM and Microsoft. These companies moved slowly, introduced new products and services after careful planning, and supported their customers for years. New versions of software were backwards compatible. New hardware platforms supported the software from previous platforms. When a product was discontinued, customers were offered a path forward. (For example, IBM discontinued the System/36 minicomputers and offered the AS/400 line.)
IBM and Microsoft were the safe choices for IT, in part because they supported their customers.
Apple and Google, in contrast, have dropped products and services with no alternatives. Apple dropped .Mac. Google dropped their RSS reader. (I started this rant when I learned that Google dropped their conversion services from App Engine.)
I was about to chide Google and Apple for their inappropriate behavior when I thought of something.
Maybe I am wrong.
Maybe this new model of business (fast change, short product life) is the future?
What are the consequences of this business model?
For starters, businesses that rely on these products and services will have to change. These businesses can no longer rely on long product lifetimes. They can no longer rely on a guarantee of "a path forward" -- at least not with Apple and Google.
Yet IBM and Microsoft are not the safe havens of the past. IBM is out of the PC business, and getting out of the server business. Microsoft is increasing the frequency of operating system releases. (Windows 9 is expected to arrive in 2015. The two years of Windows 8's life are much shorter than the decade of Windows XP.) The "old school" suppliers of PC technology are gone.
Companies no longer have the comfort of selecting technology and using it for decades. Technology will "rev" faster, and the new versions will not always be backwards compatible.
Organizations with large IT infrastructures will find that their technologies are less homogeneous. Companies can no longer select a "standard PC" and purchase it over a period of years. Instead, every few months will see new hardware.
Organizations will see software change too. New versions of operating systems. New versions of applications. New versions of online services (software as a service, platform as a service, infrastructure as a service, web services) will occur -- and not always on a convenient schedule.
More frequent changes to the base upon which companies build their infrastructure will mean that companies spend more time responding to those changes. More frequent changes to the hardware will mean that companies have more variations of hardware (or they spend more time and money keeping everyone equipped with the latest).
IT support groups will be stressed as they must learn the new hardware and software, and more frequently. Roll-outs of internal systems will become more complex, as the target base will be more diverse.
Development groups must deliver new versions of their products on a faster schedule, and to a broader set of hardware (and software). It's no longer acceptable to deliver an application for "Windows only". One must include MacOS, the web, tablets, and phones. (And maybe Kindle tablets, too.)
Large organizations (corporations, governments, and others) have developed procedures to control the technology within (and to minimize costs). Those procedures often include standards, centralized procurement, and change review boards (in other words, bureaucracy). The outside world (suppliers and competitors) cares not one whit about a company's internal bureaucracy and is changing.
The slow, sedate pace of application development is a thing of the past. We live in faster times.
"Slow and steady" used to win. The tortoise would, in the long run, win over the hare. Today, I think the hare has the advantage.
Sunday, June 10, 2012
Limits to growth
The shift from desktop and web applications to mobile applications entails many changes. There are changes in technology, new services and capabilities, and integration of apps and the sharing of data. Yet one change that has seen little discussion is the limits of an app's size.
Desktop applications could be as large as we wanted (and sometimes were larger than we wanted). It was easy to add a control to a dialog, or even to add a whole new dialog full of controls. A desktop application could start small and grow, and grow, and grow. After a short time, it was large. And after a little more time, it was "an unmanageable monstrosity".
The desktop PC technology supported this kind of growth. Desktop screens were large, and got larger over time. (Both in terms of absolute dimensions and pixel count.) The Windows UI philosophy allowed for (and encouraged) the use of dialogs to present information used less frequently that the information in the main window. Thus, application settings could be tucked away and kept out of sight, and users could go about their business without distractions.
But the world of mobile apps is different. I see three constraints on the size of apps.
First is the screen. Mobile apps must run on devices with smaller screens. Cell phones and tablets have screens that are smaller than desktop PC monitors, in both absolute dimensions and in pixel count. One cannot simply transfer a desktop UI to the mobile world; the screen is too small to display everything.
Second is the philosophy of app UI. Mobile apps show a few key pieces of information; desktop apps present dozens of fields and can use multiple dialogs to show more information. Dialogs and settings, encouraged in desktop applications, are discouraged in mobile apps. One cannot simply port a desktop application to the mobile world; the technique of hiding information is dialogs works poorly.
Third is the turnover in technology. Mobile apps are generally client-server apps with heavy processing on servers and minimal presentation on clients. The mobile app platforms change frequently, with new versions of cell phones and new types of devices (tablets and Windows 8 Metro devices). While there is some upward compatibility within product lines (apps from the iPhone will run on the iPad) there is a fair amount of work to make an app run on multiple platforms (such as porting an app from iPhone to Android or Windows 8). Desktop applications had a long, steady technology set for their UI; mobile apps have a technology set that changes quickly.
This third constraint interests me. The frequent changes in mobile devices and their operating systems means that app developers have incentive to update and revise their applications frequently. Certainly one can write an app for the earliest platforms such as iOS 1.0, but then you lose later functions. And the rise of competing platforms (Android, Windows 8) means new development efforts or you lose those shares of the market.
I expect that technology for mobile devices will continue to evolve at its rapid pace. (As some might say, this rapid pace is "the new normal" for mobile development.)
If mobile devices and operating systems continue to change, then apps will have to change with them. If the changes to devices and operating systems are large (say, voice recognition and gesture detection) then apps will need significant changes.
These kinds of changes will limit the size of a mobile app. One cannot start with a small app and let it grow, and grow, and grow as we did with desktop PC applications. Every so often we have to re-design the app, re-think our basic assumptions, and re-build it. Mobile apps will remain small because will be constantly re-writing them.
I recognize that I am building a house of cards here, with various assumptions depending on previous assumptions. So I give you fair warning that I may be wrong. But let's follow this line of thinking just a little further.
If mobile apps must remain small (the user interface portion at least), and mobile apps become dominant (not perhaps unreasonable), then any programs that a business uses (word processing, spreadsheets, e-mail, etc.) will have to be small. The world of apps will consist of small UI programs and large server back-ends. (Although I have given little thought to the changes for server technology and applications. But let's assume that they can be large apps in a stable environment.)
If business use the dominant form of computing (mobile apps) and those apps must be small, then business processes must change to use information in small, app-sized chunks. We cannot expect the large, complex data entry applications from the desktop to move to mobile computing, and we cannot expect the business processes that use large, complex data structures to run on mobile devices.
Therefore, business processes must change, to simplify their data needs. They may split data into smaller pieces, with coordinated apps each handling small parts of a larger dataset. Cooperative apps will allow for work to be distributed to multiple workers. Instead of a loan officer that reviews the entire loan, a bank may have several loan analysts performing smaller tasks such as credit history analysis, loan risk, interest rate analysis, and such.
These business changes will shift work from expert-based work to process-based work. Instead of highly trained individuals who know the entire process, a business can use specialists that combine their efforts as needed for each case or business event.
That's quite a change, for a mobile device.
Desktop applications could be as large as we wanted (and sometimes were larger than we wanted). It was easy to add a control to a dialog, or even to add a whole new dialog full of controls. A desktop application could start small and grow, and grow, and grow. After a short time, it was large. And after a little more time, it was "an unmanageable monstrosity".
The desktop PC technology supported this kind of growth. Desktop screens were large, and got larger over time. (Both in terms of absolute dimensions and pixel count.) The Windows UI philosophy allowed for (and encouraged) the use of dialogs to present information used less frequently that the information in the main window. Thus, application settings could be tucked away and kept out of sight, and users could go about their business without distractions.
But the world of mobile apps is different. I see three constraints on the size of apps.
First is the screen. Mobile apps must run on devices with smaller screens. Cell phones and tablets have screens that are smaller than desktop PC monitors, in both absolute dimensions and in pixel count. One cannot simply transfer a desktop UI to the mobile world; the screen is too small to display everything.
Second is the philosophy of app UI. Mobile apps show a few key pieces of information; desktop apps present dozens of fields and can use multiple dialogs to show more information. Dialogs and settings, encouraged in desktop applications, are discouraged in mobile apps. One cannot simply port a desktop application to the mobile world; the technique of hiding information is dialogs works poorly.
Third is the turnover in technology. Mobile apps are generally client-server apps with heavy processing on servers and minimal presentation on clients. The mobile app platforms change frequently, with new versions of cell phones and new types of devices (tablets and Windows 8 Metro devices). While there is some upward compatibility within product lines (apps from the iPhone will run on the iPad) there is a fair amount of work to make an app run on multiple platforms (such as porting an app from iPhone to Android or Windows 8). Desktop applications had a long, steady technology set for their UI; mobile apps have a technology set that changes quickly.
This third constraint interests me. The frequent changes in mobile devices and their operating systems means that app developers have incentive to update and revise their applications frequently. Certainly one can write an app for the earliest platforms such as iOS 1.0, but then you lose later functions. And the rise of competing platforms (Android, Windows 8) means new development efforts or you lose those shares of the market.
I expect that technology for mobile devices will continue to evolve at its rapid pace. (As some might say, this rapid pace is "the new normal" for mobile development.)
If mobile devices and operating systems continue to change, then apps will have to change with them. If the changes to devices and operating systems are large (say, voice recognition and gesture detection) then apps will need significant changes.
These kinds of changes will limit the size of a mobile app. One cannot start with a small app and let it grow, and grow, and grow as we did with desktop PC applications. Every so often we have to re-design the app, re-think our basic assumptions, and re-build it. Mobile apps will remain small because will be constantly re-writing them.
I recognize that I am building a house of cards here, with various assumptions depending on previous assumptions. So I give you fair warning that I may be wrong. But let's follow this line of thinking just a little further.
If mobile apps must remain small (the user interface portion at least), and mobile apps become dominant (not perhaps unreasonable), then any programs that a business uses (word processing, spreadsheets, e-mail, etc.) will have to be small. The world of apps will consist of small UI programs and large server back-ends. (Although I have given little thought to the changes for server technology and applications. But let's assume that they can be large apps in a stable environment.)
If business use the dominant form of computing (mobile apps) and those apps must be small, then business processes must change to use information in small, app-sized chunks. We cannot expect the large, complex data entry applications from the desktop to move to mobile computing, and we cannot expect the business processes that use large, complex data structures to run on mobile devices.
Therefore, business processes must change, to simplify their data needs. They may split data into smaller pieces, with coordinated apps each handling small parts of a larger dataset. Cooperative apps will allow for work to be distributed to multiple workers. Instead of a loan officer that reviews the entire loan, a bank may have several loan analysts performing smaller tasks such as credit history analysis, loan risk, interest rate analysis, and such.
These business changes will shift work from expert-based work to process-based work. Instead of highly trained individuals who know the entire process, a business can use specialists that combine their efforts as needed for each case or business event.
That's quite a change, for a mobile device.
Subscribe to:
Posts (Atom)