View Full Version : Software as a Service
02-12-2007, 05:02 AM
Joe, you are an expert in all you undertake. Please, stop being so verbose in your writing. I know from experience that much can be communicated using fewer words than you usually use. I have difficulty reading your articles simply because they take so long to make a point. Remember, the secret to good writing is 'Rewriting'. First, throw all the words down on the page. Then move the sentences around. Add some. Remove some. Use as few words as possible to make your point in the way you wish it to be made. Finally, you have concise, written masterpiece. And maybe I will have the patience to finish something of yours.
02-12-2007, 05:53 AM
Wow! I am sorry that I can't keep your attention. It's funny, because I really do keep close track of my article sizes. I usually submit it right around 2500 words. I've also worked over the years on tightening up my prose, and my editor, Victoria, does an extraordinary job of making me a better writer. If you think what I write now is inane, babbling fluff, you ought to see what it starts out as! <grin> But seriously, I do apologize if my content is too long. I am by nature a verbose man. One of my favorite acquaintances in the programming world is a gentleman by the name of Barry; out of courtesy I won't print his last name (as he might not be willing to admit knowing me). One of the things we used to say about Barry was that if you asked him what time it was, he would tell you how to build a watch. Well, while this was true, I also learned a whole lot about application design and development from Barry, as long as I was willing to listen. And I started to model my own answers after his. Over time I learned that, at least as a teacher, answering a question usually did a lot more good if I provided some background. Over the years, that's probably gotten worse. I am in fact getting older -- I just picked up my first pair of reading glasses. So maybe I am starting to string too many words together; perhaps I'm starting to cross the line from teaching to preaching. But I did a little research, and here's what I found out: 2500 words is about 8-10 pages in a paperback novel. This is roughly one half of a chapter in "Star Trek: The Last Stand" (yes, I am a Trek fan). In those 2500 words I covered the history of client/server architecture for 30+ years. Too wordy? Perhaps. But at that rate, I could fit an entire millenium in one paperback <smile>. Joe
02-12-2007, 06:37 AM
...but a good read. I liked the background provided, thanks.
02-12-2007, 08:08 AM
Joe, you've written a brilliant mini-history of IT from the 70s till the present in about 20 paragraphs. My thoughts were the exact opposite of Mr Word Count. How do you pour out this good stuff week after week (or bi-week after bi-week as the case may be)? Having written an article or two I know how long it can take to hone it down to something readable.
02-12-2007, 09:06 AM
Please, if you think your criticism is worthy of mention, identify yourself. It is quite frustrating to spend time reading a post only to get to the end and find out that the author felt it unimportant to show his face. Even if you want nothing known about you, at least give us a moniker. Great article Joe---please continue writing. I have enjoyed all of your articles.
02-12-2007, 09:35 AM
Thanks for the compliments. Like I said, I've got a fantastic editor. And my wife would tell you that I like to talk. A lot. So writing really is an extension of my personality. But you need help to write, and I've gotten it over the years. I look back on some of my older articles, and it's obvious somebody has been helping me improve. I do find it interesting, though, that a lot of what I said back then still holds today, even if it wasn't written as well <smile>. For example, I used the "everything was written in the 60's" line back in 1999, and it's just as true today. As is the fact that RPG is still the best language for business transactions, and that RPG programmers really can continue to find work. At the same time, for web stuff you'll need to learn Java and JSP. And I wrote THAT back in 2000 or so! Joe
02-12-2007, 09:37 AM
No problem. Thanks for the kudos, and I'll keep writing until they pry the keyboard... Joe
02-12-2007, 09:40 AM
If you don't learn from history, you're doomed to repeat it. And honestly, I think that's part of what's happening: nobody realized just how good those old architectures were. We got caught up in a frenzy of "new is better" and only now are we starting to realize what economies of scale and total cost of ownership REALLY means. It will be interesting to see if this new Renaissance of the centralized multi-tenante computer will revitalize the System i. Maybe then finally IBM will pay it a little attention. Joe
02-12-2007, 02:55 PM
Joe, I posted a brief message on the Ignite/400 mailing list this morning, which I'll copy below. This afternoon I read your article. We've evidently been thinking along the same lines. This topic would be a good one to discuss at considerable length. --------------------- I think the System i could have a brilliant future if the trend toward "software as a service" continues to grow. By that I mean the option of signing-up for services on the Internet as opposed to buying, installing, configuring, integrating, maintaining, and supporting (often disparate) systems in-house. Windows and Intel systems are designed with distributed computing models in mind. It seems that whenever people claim that Windows and Intel systems are reliable, they're achieving a high degree of reliability by simplifying the configuration of each box as much as possible, and distributing databases and applications across multiple boxes, and distributing end-user connections across multiple boxes, and providing fail-over support. The problem, of course is the hassle and cost of supporting so many (often disparate) systems. In contrast, System i architecture manages complex workloads very well on a single server. It's not only capable of supporting many types of applications on a single server, but is great for supporting many companies and many runtime contexts on a single server, while providing separate, secure environments for each company. So the System i could play a prominent role in delivering software as a service, particularly if we figure out how to deliver highly interactive graphical user interfaces via browsers and low-cost appliance-like workstations via robust server-based applications. The System i offers unique value by scaling in terms of number of users, complexity of workloads, number of companies, and number of runtime contexts. Nathan M. Andelin
02-12-2007, 05:11 PM
Os, that's some kind of bug in this forum software. The first post from a Reader's Opinion doesn't include the poster identification and often doesn't show up in the All Posts view until a second post is posted. The first person slamming the article can do so anonymously. I don't know, depending on the developers, in some places they may call it a feature rather than fix it. :) rd
02-13-2007, 08:11 AM
Thanks for pointing that out to me. I apologize for my comments regarding the anonymous criticism since it truly was not anonymous.
02-13-2007, 08:16 AM
Lately I've been flooded with material about virtualization. It seems everything can be virtualized. One company said they were running a virtual grid on top of an application virtualization product, on top of a server virtualizer. The network was segmented with VLAN's and connections were via VPN. Storage was a SAN. They said that debugging service problems was complex and problematic (imagine that!). Now, I know that there's a place for virtual machines. I have used VM/CMS myself, a long time ago. However, you have to wonder if the market for virtual server systems is largely fed by small Microsoft/Intel systems (with obvious minor variations available). These create the need to have one box, with one application on it. Not as an absolute prerequisite, but in the real world it produces more successful implementations that way. So virtual machines allow application consolidation. Just like in the old days, except mostly we ran those consolidated applications without virtualization.
02-19-2007, 08:13 AM
The company I worked for immediately out of college used a service bureau, running an IBM MVS system. We paid a monthly fee, which included the cost of a leased line, which in and of itself was about $600 per month, in addition to the service bureau costs. One of the company Vice Presidents was the sole programmer. His software was considered highly strategic to the business, which served the Savings and Loan industry. The system was written in COBOL. The service bureau sent people out to our office to install the coax cabling. There wasn't any Internet, or even a local area network, so the service bureau was the only thing we could connect to. The way people think about Software as a Service has changed. It's delivered over the Internet. You can do a Google search to find out what's available, and may even be able to try the service on a limited basis for free. Email, which in the beginning was considered a strategic product, is now bundled in your ISP contract. A lot of people are using Yahoo and Gmail, where the basic service is free. A lot of computing is gradually considered more as a commodity, rather than a strategic asset, particularly as so many applications have so many comparable features, that using one or the other comes down to a matter of cost, performance, reliability, and support. While applications may be considered more of a commodity, their cost is still capitalized, along with the infrastructure required to support them, when purchased or developed in-house. Under Software as a Service, the cost is expensed rather than capitalized, which is more in-line with the concept of a commodity. IT departments, of course would prefer that their products and services be thought of as assets rather than expenses, and strategic rather than commodities, but the ubiquity of services over the Internet makes applications seem more like commodities. At present, expenditures for information technology may be channeled and approved by the IT department, and likely included in their "capital" budgets, which require a lot of planning and politicizing. As software as a service gains momentum, the manager of the fleet department may simply sign up for a service on the Internet to inventory, depreciate, and otherwise manage the fleet, and simply write off the expense, rather than going through the IT department, which might be saying something like, we're busy trying to modernize our applications, or we're busy fighting a political agenda, or we're immobilized by a dizzying array of technology choices and disparate systems that nobody seems to be able to agree on, or our budget plans are set, so contact us in September. How does this relate to the System i? Let's face it, Windows, Linux, Unix, and their associated infrastructure (including support people) are entrenched in IT organizations, and even dominate IT departments. If the System i has a presence in the organization, it's role is often diminishing. Trying to sell the company on a System i is an uphill battle. On the other hand, the System i is more reliable, scalable, and costs less, from a total cost of ownership perspective, and is ideally suited for software as a service, where things like reliability, cost, scalability, and functionality are given more weight than whether the platform is strategic to the company, or not. So the idea is to get more vendors thinking in terms of offering their applications as Internet services, rather than something that needs to purchased and capitalized and approved by IT departments, which are already predisposed to thinking of the System i as non-strategic. Nathan M. Andelin
02-19-2007, 09:02 AM
reliability, cost, scalability, and functionality... and performance is an attribute the System i brings to the table which is critical for fast responses to SaaS calls under load. rd
02-19-2007, 09:14 AM
WIKIPEDIA makes some good points about what's driving Saas, as follows: The traditional rationale for outsourcing of IT systems is that by applying economies of scale to the operation of applications, a service provider can offer better, cheaper, more reliable applications than companies can themselves. The use of SaaS-based applications has grown dramatically, as reported by many of the analyst firms that cover the sector. But it’s only in recent years that SaaS has truly flourished. Several important changes to the way we work have made this rapid acceptance possible. Everyone has a computer: Most information workers have access to a computer and are familiar with conventions from mouse usage to web interfaces. As a result, the learning curve for new, external applications is lower and less hand-holding by internal IT is needed. Computing itself is a commodity: In the past, corporate mainframes were jealously guarded as strategic advantages. More recently, the applications were viewed as strategic. Today, people know it’s the business processes and the data itself—customer records, workflows, and pricing information—that matters. Computing and application licenses are cost centers, and as such, they’re suitable for cost reduction and outsourcing. The adoption of SaaS could also drive Internet-scale to become a commodity. Applications are standardized: With some notable, industry-specific exceptions, most people spend most of their time using standardized applications. An expense reporting page, an applicant screening tool, a spreadsheet, or an e-mail system are all sufficiently ubiquitous and well understood that most users can switch from one system to another easily. This is evident from the number of web-based calendaring, spreadsheet, and e-mail systems that have emerged in recent years. Parametric applications are usable: In older applications, the only way to change a workflow was to modify the code. But in more recent applications—particularly web-based ones—significantly new applications can be created from parameters and macros. This allows organizations to create many different kinds of business logic atop a common application platform. Many SaaS providers allow a wide range of customization within a basic set of functions. A specialized software provider can target a global market: A company that made software for human resource management at boutique hotels might once have had a hard time finding enough of a market to sell its applications. But a hosted application can instantly reach the entire market, making specialization within a vertical not only possible, but preferable. This in turn means that SaaS providers can often deliver products that meet their markets’ needs more closely than traditional “shrinkwrap” vendors could. Web systems are reliable enough: Despite sporadic outages and slow-downs, most people are willing to use the public Internet, the Hypertext Transfer Protocol and the TCP/IP stack to deliver business functions to end users. Security is sufficiently well trusted and transparent: With the broad adoption of SSL organizations have a way of reaching their applications without the complexity and burden of end-user configurations or VPNs. Availability of enablement technology: According to IDC, organizations developing enablement technology that allow other vendors to quickly build SaaS applications will be important in driving adoption. Because of SaaS' relative infancy, many companies have either built enablement tools or platforms or are in the process of engineering enablement tools or platforms. A Saugatuck study shows that the industry will most likely converge to three or four enablers that will act as SaaS Integration Platforms (SIPs). Wide Area Network's bandwidth has grown drastically following the Moore's Law (more than 100% increase each 24 months) and is about to reach slow local networks bandwidths. Added to network quality of service improvement this has driven people and companies to trustfully access remote locations and applications with low latencies and acceptable speeds.
02-19-2007, 10:09 AM
Who stands to lose if SaaS gains momentum? Anyone whose economic foundation is based on desktop applications - Microsoft, for example. While Microsoft may be getting into SaaS, it will likely turn into a political battle there because the majority of their revenue is based on desktop applications, and the development of software with ever increasing desktop requirements (CPU, memory, etc.). In-house IT departments may resist SaaS. They have quite a bit of motivation to stay in the driver seat with respect to IT decision making, while SaaS gives more options to end-users (why use company email and collaboration solutions where somebody in IT is monitoring my messages, for example). IT departments are also pre-aligned with Microsoft, while other departments may be more open to the provider of the biggest bang for the buck. In-house developers may resist SaaS. That may include the majority of people reading these forums. Developers are predisposed to creating things in-house, and leveraging their intimate knowledge of company quirks and addressing them via custom solutions. Maybe some of that could be mitigated by SaaS providers allowing customers to deploy their own extensions to provider hosted applications. Nathan M. Andelin
02-19-2007, 10:12 AM
** This thread discusses the Content article: Software as a Service (http://www.mcpressonline.com/index.php?option=com_content&view=article&id=1039) **
Powered by vBulletin® Version 4.1.5 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.