The view is particularly well-suited to recent efforts to break applications down into smaller components that can be re-used across the Internet via XML RPCs -- a movement better known as Web services. Most app stack advocates I've spoken to restrict their discussion to layers that are predominantly software. The word "application" makes that an easy trap to fall into.
If Web services get any traction, and it appears as though they will (every vendor has a Web services story), you can pretty much toss most of your IT principles out the door. In the same way that PCs took the load off of host systems, ushered in client/server-based distributed processing, and caused everyone to rethink their IT, Web services will evoke another fundamental shift. Web services will require new dimensions of security and application portability, while returning some of that load back to the host. This trend plays well into the limitations of wireless networks, small-footprint embedded operating systems, and the past decade's big improvements in host price, performance, and capacity.
So dramatic is the paradigm shift, and so substantial are forthcoming changes on the OS landscape (some of them inextricably linked to hardware), that your architecture reconsiderations could easily extend to every layer of the stack and include the hardware on the top and bottom layers. We've reached a unique juncture in IT history where virtually the entire enchilada is up for grabs.
In fact, I'd argue that the "stack" metaphor is already passé. ("Enchilada" is probably more like it.) But my vote would be for "matrix." "Matrix" solves the problem for traditionalists who like to think in layers, but also accounts for those critical IT ingredients such as security, storage, development, networking, and management that cut across some or all of the layers.
Dredging up the bottom layer, where big iron servers and their operating systems live, gives most IT managers the willies. But according to many ZDNet readers, the bottom layer could very well be due for a rip and replace. Between a renewed interest in 5-9's (99.999%) availability (after the September tragedies), continued vendor consolidation, and a rapidly changing talent pool, many of the bottom layers out there in IT-land are indeed due for a re-examination. By itself, the proposed merger between HP and Compaq has the potential to upset the center of gravity in the bottom layer. That's because so little is known about which of the industrial-strength operating systems (HP-UX, OpenVMS, NSK, Tru64, and MPE/ix) will be chosen to survive the merger, and which of those will actually endure over the long run.
Next up the so-called stack (within the matrix, of course) is a pseudo-layer where the virtual machines live. While the bottom layer is the application foundation that handles issues like scalability and availability, the trend toward server consolidation involves moving as many apps as possible to one very fault-tolerant machine -- even in situations where the native OS doesn't support the applications. This consolidation typically is accomplished by running another operating system within one of the partitions (on top of the native OS), or by translating the executables (either through recompilation or on the fly) via an interface that allows native binaries from one OS to run on another. Both IBM and HP, for example, make it possible to run Linux applications on non-Linux operating systems. While this pseudo-layer isn't necessarily up for a restructuring, datacenter managers who recognize the TCO benefits of server consolidation may end up choosing the foundation layer based on its ability to support and consolidate both native and non-native applications.
Depending on what foundation you're working on, your database may or may not come next in the stack. Why? Because some operating systems come with a database built-in. (In IBM OS/400's case, it's DB/2.) But whether or not the database is built-in, most of the stack's remaining layers depend on the presence of a database, so this is as good a place as any to insert the database layer. (Even if a database is built-in, there's no reason you have to use it as a part of your application stack. In many cases, you can elect to use an alternative.)
When it comes to industrial strength databases, virtually all Tech Update readers with whom I've corresponded are using Oracle. Although deployment can be difficult, they like Oracle's flexibility in terms of number of operating systems supported and pricing per processor (both of which, coincidentally, fit well with any consolidation excercises). Still, there are some challengers to Oracle at this layer, depending on what your consolidation methodology is -- particularly if you're considering Linux in the virtual machine layer. If there's one layer where I expect some resistance to change, though, this is the one.
With the Web services revolution still in its infancy, most strategic planners have some time to think about how they can recreate their software as services. More specifically, they must consider services that can be looked up in the Web services yellow pages (via UDDI), be crawled for their functionality (via WSDL), and be remotely called via an XML RPC. For the most part, there are two application server camps: Windows and Java (J2EE). Of all the layers where strategic decisions will have to be made, this is the one that will most likely cause angst for the undecided. This is especially true if your software isn't already broken down into components. For those of you in this pre-embryonic stage of Web services, the noise-level from the various players who want your business must be bewildering. If you're on Windows and you've already gone to the trouble of componentizing everything, then you made your strategic decision a long time ago. But in the J2EE camp, a plethora of offerings can handily take your Enterprise Java Beans (if you have them) and ready them for Web services.
This is where one of those layer-spanning matrix items comes in: the developer's toolkit. In the same way the virtual machine tail can wag the foundation layer dog, platform decisions have a way of forcing development teams down one path or another. This is especially so with highly integrated environments from companies like IBM, Sun, HP, and Microsoft that provide a soup-to-nuts offering on the server-side (everything from the foundation to the application server). Development tools from integrated players typically include platform-specific extensions. These extensions are a form of vendor DNA that makes it easier to glue together and deploy a single vendor's application stack. The most glaring example of this is Microsoft's Visual Studio .NET, which, for obvious reasons, will pair up with Microsoft's .NET and Biztalk servers quite nicely.
The application layer is, of course, where the fun is. (Well, someone's idea of fun). As the "swing" layer, it's another one of those layers where decisions can reverberate right down to the foundation, and almost always affect everything out to the client, including some of the matrix technologies like management and networks.
Are you home-growing your applications, or taking existing ones off the shelf? In either case, your choices may be dictating what happens down below. Or, perhaps the idea of giving someone else the headache of running your apps (xSP-style) makes more sense. It looks like you'll be renting software anyway. Perhaps you should rent it from someone who will also take worries of system scalability and availability off your mind. In fact, many of the options at the foundation layer that allow datacenters to deliver scalability, reliability, and lower TCO are the same ones that make it possible for xSPs to provide you with a reliable solution at a reasonable cost.
How do you know what to outsource and what to keep in house? If it's key to your competitive advantage, you have no choice but to keep it in house. Competitive advantage through IT is almost never built on canned solutions. If the solution isn't a key differentiator between you and your competitor, think about making the solution somebody else's headache. Worried about integration with your existing systems (or with other xSPs)? Don't be. The problem is only temporary, and some xSPs already offer rudimentary integration. In the spirit of Web services, virtually all xSPs will be componentizing their solutions to allow for integration with the external systems of their customers as well as other xSPs (especially managed security service providers). At the same time, don't take integration for granted. In addition to driving a hard bargain in your service-level agreements, make sure you ask for a Web services roadmap.
As far as applications stacks go, the application itself is like Wednesday. It's the hump after which you typically have lots of options that largely depend on who is accessing the data, how they are accessing it, and how they will need to interact with it. The general direction, however, seems to be toward presentation technologies that lighten the burden on both networks and clients.
Mobility seems to be the driving force behind this direction. The user experience is greatly degraded if a lot of code and data has to be pumped over wireless networks and into devices that are easily overwhelmed. Mobility as a corporate imperative is also late to the game. Many end users have already made personal investments in mobile technology. There's a lot of "you can have my [name your favorite PDA] when you pry it from my dead fingers" going around. Companies looking to avoid a revolt must find some sort of ubiquitous presentation technology that's available on most client platforms (from desktops to mobile phones). Standard markup languages like HTML and WML and the corresponding rendering engines (the browsers) come to mind, as does some sort of local, small-footprinted execution environment like Java when something more interactive is required.
In short, client platforms have been somewhat commoditized by presentation technologies that level the playing field. Personally, I don't see choices such as PocketPC vs. PalmOS or Windows vs. Linux (let alone the actual hardware that they all run on) being especially strategic from an application stack point of view. Tactically, those choices may be important because a lot of client software is still built without portability in mind. But that will change. What is strategic, however, and what could dictate the client platform, is the choice of management technology, especially where mobility is concerned. For example, Microsoft's Mobile Information Server may support WAP (thereby allowing it to work with a non-PocketPC-based, WAP-enabled devices), but companies using PocketPC are likely to see more robust functionality. For this reason, the matrix management layer is indeed strategic, and some options may excel on one platform (Microsoft's MIS) whereas others (like those from Extended Systems or Avantgo) are OS agnostic.
Many supporting characters in the solutions matrix are worthy of discussion. Other matrix technologies that cut across one or more layers include security, networking (local area, wide area, wired, and wireless), storage, and message-queuing. Some of these even have their own stacks.
The point is that with so much in flux, there's probably no time like the present to look up, down, and across to see if something is due for a change. Like the old layered OSI model, the beauty of the application stack, er, matrix, is that in many cases, the layers work independently of each other, giving you more options (many more than can be listed in this one story) and more opportunities to optimize your company for the 21st century. Seize the day.
What do you think? Share your thoughts with your fellow readers at ZDNet TechUpdate's Talkback, or write directly to david.berlind@cnet.com.
Got a great tip? An industry rumor? Or do you want to submit your own column to ZDNet TechUpdate? Send David your submission, and if we use it, you'll be compensated with some of the cool vendor schwag that arrives in our mailboxes on a daily basis.
