New dimensions in system design

The technology environment is changing. The change is significant, affecting the basic dimensions with which we measure systems.

The center of the old technology world was Windows. Manufacturers built PCs to run Windows. Suppliers built software to run on Windows. Systems were local -- that is, they ran in a single location. Before the internet era, everything lived in your data center. Even with the internet, systems ran in a single data center. (Or possibly two, for redundancy.)

With everything in one data center,  

The age of "Windows as the center of the universe" has passed. Today, we have multiple environments. The simple universe of one technology has been replaced by a universe of multiple galaxies.

Today, systems that are spread across multiple hardware installations. Systems consist of one (or several) front end "user clients", possibly for the iPhone, Android phones, and web browsers. The back end consists of not one but many cooperative services, each handling a small portion of the work. These can include web servers, database servers, queue managers, and content distribution networks.

But the change is larger than that. The set of basic elements is changing. In the old world, systems were built from a database, access, and programs written in a specified language. Those "dimensions" of the application defined its "space" in the data center. Vendors were defined by how well they met the needs of the organization in those dimensions.

In the new world, systems are more complex. Instead of a single database, a system may use several. Instead of a single web server, an application may use multiple, depending on the transaction being processed. We use virtualized processors to host servers, and cloud computing to manage the virtualized servers. We no longer think of a system as "a Java application"; we think of it as "a Java, Javascript, SQL, NoSQL, message queues, and some HTML and CSS" system.

In such a complex world, we design our systems with a new collection of "building blocks", and we look for vendors to provide those building blocks. Those elements of system design are: hardware, software, content, and services. These are the dimensions for system architecture and vendor offerings.
Let's look at the big providers:

Microsoft clearly supplies software: Windows, Office, Visual Studio, and many other packages. They are getting into the hardware game. Microsoft has offered hardware for years, in the form of the Microsoft Mouse, the Microsoft Keyboard, and today with the XBOX, the Kinect, and the Surface. They also offer cloud services and content (music, books, and movies).

Google offers some hardware (the Nexus phones and tablets) but also works with manufacturers. They offer the Chromebook hardware that runs their Chrome browser. They offer cloud services. They have also gotten into the music and video markets, with Google play and YouTube.

Amazon.com offers hardware, but only the the form of the Kindle. They do not offer PCs or phones. They have a rich offering of services with their cloud systems.

Apple offers hardware, software, content, and little in the way of cloud services. Their MacBooks and iPads (and the operating systems) are respected by all. They provide content in the form of music, movies, books, and newspaper subscriptions. Yet their focus is on consumers, not the enterprise. This is clear in their iCloud offerings, which are designed for individuals.

In this light of hardware, software, services, and content, the other "big names" of the tech world are lacking:

Barnes and Noble offers hardware (Nook tablets and e-readers) and the software to run them, but nothing for development or the office. They offer content but not services.

IBM offers hardware and software but not content. They don't sell books or music. They offer cloud services, in addition to their old-school consulting services.

Facebook offers services and content, but not hardware and software. (This is why the rumor of a Facebook phone keeps returning.) Facebook uses cloud computing for their servers but doesn't offer it to customers. They offer other services, such as a platform for games and an authentication service for web site log-ins.

Yahoo offers services and some (limited) content but not hardware or software.

I'm not claiming that a vendor needs all four of these components to be profitable. IBM and Yahoo are doing rather well. (Barnes and Noble not so much, but that is a problem specific to their market.) But the presence (or absence) of these four components is important, and decides how a vendor can assist a client.

The new dimensions of hardware, software, services, and content affect hiring organizations too. Systems will need all of these components (to one degree or another) to satisfy a customer's needs. When looking for solutions from vendors, and when looking to hire, companies will have to weigh the strengths of the vendor (or the candidate) in all of these areas.
The smart, big vendors are offering all services. The smart, small vendors will offer a carefully selected subset and ensure that they can provide quality. The same goes for candidates. The heavyweights will have expertise in all areas, the middleweights light expertise in all and strength in a few, and the lightweights will be capable in one or two.

The task for vendors (and candidates) is to build their skills along these dimensions, and present them to clients.

Windows 8 is like Y2K, sort of

When an author compares an event to Y2K, the reader is prudent to attend with some degree of skepticism. The Y2K problem was large and affected multiple platforms across all industries. The threat of mobile/cloud computing (if it can even be considered a threat) must be large and wide-spread to stand against Y2K.

I will say up front that the mobile/cloud platform is not a threat. If anything, it is an expansion of technical options for systems, a liberalization of solution sets.

Nor does the mobile/cloud platform have a specific implementation date. With Y2K, we had a very hard deadline for changes. (Deadlines varied across systems, with some earlier than others. For example, bank systems that calculated thirty-year mortgages were corrected in 1970.)

But the change from traditional web architectures to mobile/cloud is significant, and the transition from desktop applications to mobile/cloud is greater. The change from desktop to mobile/cloud requires nothing less than a complete re-build of the application: new UI, new data storage, new system architecture.

And it is these desktop applications (which invariably run under Microsoft Windows) that have an impending crisis. These desktop applications run on "classic" Windows, the Windows of Win32 and MFC and even .NET. These desktop applications have user interfaces that require keyboards and mice. These desktop applications assume constant and fast access to network resources.

One may wonder how these desktop applications, while they may be considered "old-fashioned" and "not of the current tech", can be a problem. After all, as long as we have Windows, we can run them, right?

Well, not quite. As long as we have Windows with Win32 and MFC and .NET (and ODBC and COM and ADO) then we can run them. But there is nothing that says Microsoft will continue to include these packages in Windows. In fact, the new WinRT offering does not include them.

Windows 8, on a desktop PC, runs in two modes: Windows 8 mode and "classic" mode. The former runs apps built for the mobile/loud platform. The latter is much like the old DOS compatibility box, included in Windows to allow us to run old, command-line programs. The "classic" Windows mode is present in Windows 8 as a measure to allow us (the customers and users of Windows) to transition our applications to the new UI.

Microsoft will continue to release new versions of Windows. I am reasonably sure that Microsoft is working on "Windows 9" even with the roll-out of Windows 8 under way. New versions of Windows will come out with new features.

At some point, the "classic Windows compatibility box" will go away. Microsoft may remove it in stages, perhaps making it a plug-in that can be added to the base Windows package. Or perhaps it will be available in only the premium versions of Windows. It is possible that, like the DOS command prompt that yet remains in Windows, the "classic Windows compatibility box" will remain in Windows -- but I doubt it. Microsoft likes the new revenue model of mobile/cloud.

And this is how I see mobile/cloud as a Y2K-like challenge. When the "classic Windows compatibility box" goes away, all of the old-style applications must go away too. You will have to either migrate to the new Windows 8 UI (and the architecture that such a change entails) or you will have to go without.

Web applications are less threatened by mobile/cloud. They run in browsers; the threat to them will be the loss of the browser. That is another topic.

If I were running a company (large or small) I would plan to move to the new world of mobile/cloud. I would start by inventorying all of my current desktop applications and forming plans to move them to mobile/cloud. That process is also another topic.

Comparing mobile/cloud to Y2K is perhaps a bit alarmist. Yet action must be taken, either now or later. My advice: start planning now.

The big bucket at the center of all things

A lot of organizations have a central database.

The database is the equivalent of a large bucket into which all information is poured. The database is the center of the processing universe for these companies, with application programs relegated to the role of satellites orbiting the database.

The problem with this approach is that the applications are tied to the database schema. When you design your applications and tie them into the central database, you can easily bind them to the schema of the database.

The result is a large collection of applications that all depend on the schema of the database. If you change the schema, you run the risk of breaking some or all of your applications. At minimum you must recompile and redeploy your applications; it may be necessary to redesign some of them.

Notice that this approach scales poorly. As you create new applications, your ability to change the database schema declines. (More specifically, the cost of changing the database schema increases.)

You can make some types of changes to the schema without affecting applications. You can add columns to tables, and you can add tables and views. You can add new entities without affecting existing applications, since they will not be using the new entities. But you cannot rename a table or column, or change the parameters to a stored procedure, without breaking the applications that use those elements. Your ability to change the schema depends on your knowledge of specific dependencies of applications on the database.

Cloud computing may help this problem. Not because cloud computing has scalable processing or scalable database storage. Not because cloud computing uses virtualized servers. And not because cloud computing has neat brand names like "Elastic Cloud" and "Azure".

Cloud computing helps the "database at the center of the universe" by changing the way people think of systems. With cloud computing, designers think in terms of services rather than physical entities. Instead of thinking of a single processor, cloud designers think of processing farms. Instead of thinking of a web server, designers think of web services. Instead of thinking of files, cloud designers think of message queues.

Cloud computing can help solve the problem of the central database by getting people to think of the database as data provided by services, not data defined by a schema. By thinking in terms of data services, application designers then build their applications to consume services. A service layer can map the exposed service to the private database schema. When the schema changes, the service layer can absorb the changes and the applications can remain unchanged.

Some changes to the database schema may bleed through the service layer. Some changes are too large to be absorbed. For those cases, the challenge becomes identifying the applications that use specific data services, a task that I think will be easier than identifying applications that use specific database tables.