Apps optimize

When architecture meets the sales model


There has been tons of talk over the last few years about Software as a Service (SaaS). Quite frankly, I am not a huge fan of the idea, mainly because I do not like to put that much faith in third-party vendors (TPVs). The idea itself is not bad, I just do not trust them, mostly from my experiences both using them and working for them. For example, this weekend I finally brought my DNS and SMTP servers "in house" (as in, onto my server in my closet) because my ISP was too incompetent to run a DNS or SMTP server capable of looking up "www.techrepublic.com" or sending e-mail to "cnet.com" and "techrepublic.com" addresses. I do trust a TPV to provide a service that is commoditized, can be easily replaced if I have problems with the vendor or their product, and is not an absolutely critical part of my business. This brings me to my point regarding SaaS -- well, a point or three about XML and software architecture.

"Ages" ago (circa 2000), what we currently call SaaS vendors were called Application Service Providers (ASPs). There was a huge run up on the stock price of any company claiming to be an ASP. Everyone claimed that ASPs would knock traditional software vendors off of their thrones. And guess what? The ASPs went out of business. The companies that survived provide services, such as code components and databases of data, or sell a component of a bigger system.

When XML came into its own, there were a zillion and one big ideas for it. Remember UDDI? I vaguely do. The idea was that application developers' stuff would be so standardized through the magic of XML that we could look up a service in a UDDI "phone book," automatically connect to it, grab the WSDL, and our applications would instantly adapt to a new provider. Our application could pick a vendor in real time, based upon ever-changing factors like feature set and pricing. What a dream. Microsoft shut down its UDDI server recently. No one ever used UDDI.

What we got instead was a smattering of (hopefully) industry standard XML specs, like HR-XML for the human resources industry. The problem is, when all of the input and output your application deals with is defined by the industry, so is your feature set. Just as you cannot write an application that parses the Word format and do something that Word cannot, you simply cannot provide functionality that the industry standard does not support. This kills innovation on the part of the vendors; the only "secret sauce" they can brew up is better processing on their end of the deal, customer service, pricing, etc. In other words, industry standards for XML data exchange drive commoditization. This is a recipe for mediocrity. The alternative is just as bad. If a vendor bucks the industry standard (or does "embrace and extend"), you get a combination of painful integrations and vendor lock-in. Neither of these are things that anyone wants.

After we started seeing vendors moving to providing "services" over XML, there were two new fractures in the industry. The first was the rebirth of ASP as SaaS. The other is "Web 2.0." Don't believe me? They both address the problem of being innovative, while reducing the customer's pain of dealing with something that works outside of the industry standard XML specifications. SaaS basically says, "Hey, forget about integrating with me, just hand over all of your data to me through this Web site, and I will take it from here." "Web 2.0" (side note: I still have a hard time taking this term seriously) is a different twist: "Since I follow a format that may or may not be standard, just make a reference to me, and not only will I handle the processing, but I will handle the presentation layer too!" To put it another way, SaaS removes the need for integration, and "Web 2.0" makes the integration as painless as possible.

Where does this leave us developers? Well, I think it leaves us in a great spot. If we start taking a serious look at service-oriented Architecture (SOA) at our application/business logic layer, our applications have prime marketplace positioning. We build out our own presentation layer on the SOA architecture and sell SaaS. We can sell the bare Web service (or the components to hook into it for an additional fee) to customers who would rather do the presentation themselves, whether it be a small portion of the functionality or the whole business layer, depending upon the customer's needs. And we can build "Web 2.0" components that represent individual, discrete functions to be sold to the customers that want zero integration of services without buying the whole application. And for anything that does not need to expose a public interface (the "Web 2.0" and SaaS pieces), we can do our innovation there, unhindered by the need to follow the industry standards for everything.

While I am not too keen on XML for technical reasons (particularly for applications that will never be publicly exposed), it does allow us to provide true services to our customers. As a result, it increases our sales opportunities, provided that the application is carefully architected. Until the boom of the services industry, architecture was primarily a technical concern. But now, the overall system architecture is something that can make or break the sales model. Building your application with SOA principles can leverage your existing code to support sales that a strictly "Web 2.0," SaaS, or traditional model could never get on their own, and expand your potential market significantly.

J.Ja

About

Justin James is the Lead Architect for Conigent.

10 comments
Justin James
Justin James

If so, what are yoru experiences with it? If not, why not? J.Ja

Gast?n Nusimovich
Gast?n Nusimovich

In the past, Business Rules were taken hostage by applications (ERP systems, HR Systems, SFA systems or CRM Systems, BPM solutions, etc.) The SOA approach allows IT organizations within companies to "expose" Business Rules through a public interfase (the web service) while maintaining the advantage that the rules may actually remain at a certain application. This works both for other systems within the company, and for system integration with suppliers and customers.

Gast?n Nusimovich
Gast?n Nusimovich

... over the corporate Web Server. It requires a thorough plan, including a complete revision of the Enterprise Architecture, and a thorough architecture and design of the integration of services whose facade to the "outside world" is the web service. We are using a SOA approach for a distributed application, where clients are both at customer sites as well as inside our corporate WAN. Because some of the use cases require "real world" data entry capabilities, we have deviced a smart client instead of a thin web client. We tested a web client prototype to check data entry performance, but even with AJAX it could not cope with the heavy data entry loads required. To make short a very long story, if you are contemplating SOA as an alternative, you should think all your system in a "fire and forget" or "touch and go" way, lots of asynchonous parts: each client requests a service, and eventually (asynchronously) will get a notification and a detail of how did it go.

gsikora01
gsikora01

Regarding ..."We tested a web client prototype to check data entry performance, but even with AJAX it could not cope with the heavy data entry loads required", can you expand on the type / amount of data entry to which you refer? We have a new development contemplated, and heavy data entry requirements is one of our concerns in trying to decide between smart client and thin client. FYI, 90% of the users will connect via LAN with the rest connecting via the web.

Gast?n Nusimovich
Gast?n Nusimovich

As I have detailed in a previous post for this discussion, we do not have statically defined data entry forms, that is, the design of this data entry forms is not defined at design or development time, but is defined at run-time (our code instanciates form controls and subscribes each control to certain event handlers at runtime) according to some metadata persisted at the application database (smart clients access App Server through Web Services). This metadata is supported by a custom engine that we have deviced, so the metadata administrator can define, for a given class of metadata, the name of each field, the data type, and the value type (either a unique value, or List values where the list of values is persisted with the definition of the metadata). The UI defined at runtime creates a text box for each field that is unique value, a combo box for List Values that are mutually exclusive, or a List Box for List Values that are multi-select, and each combo or list box adds the corresponding list of values defined at the metadata. The typical class definition has between 10 and 20 fields with a mix of unique values and list values. So, you may figure out the type of data entry workload: on any given day, our users may have to enter between a few dozens of objects to a few hundreds of objects, where each object may have between 10 and 20 fields of data. The form UI defined at runtime includes shortcuts for fast access to each field, so data entry can be done very fast by any person with enough practice with these forms. For most data entry users, it takes just one day of data entry to get used to it. This type of functionality with the required performance could not be sustained by a web client (that is what we tested with the AJAX prototype). Hope this can help you define the type of criteria for the business case and non functional reqs of your design.

rklaassen
rklaassen

Curious as to what path you have taken to create your rich client? .Net or Java? In the interests of full disclosure I do work for IBM and am interested in whether you contemplated the use of Lotus Expeditor (or perhaps you might have heard of it under its former name of WebSphere Everyplace Deployment).

Gast?n Nusimovich
Gast?n Nusimovich

MS SW factories could be very helpful on certain cases. The EntLib is really helpful in terms of supported functionality and versatility (very customizable through config, good configuration tools), but it is very heavy in terms of total assemblies' size required. Another aspect to be considered is the learning curve that must be traversed by architects, designers and devs to be proficient with the use of these tools. Each team will have to balance between (custom) code construction and third party code adoption. This is a typical Build or Adopt type of decision (I prefer to use the word Adopt instead of Buy, to include both Commercial and Open Source Libraries).

Justin James
Justin James

... I have found that Microsoft libraries either need way too much tweaking (and are rather inflexible) to work the way I want them too, or they are extremely heavy. The first case sounds like your experience with the Smart Client SW Factory, and I *know* that the Enterpise Library is extremely heavy. But, they both seem to be good, as long as you stick with working within their systems. J.Ja

Gast?n Nusimovich
Gast?n Nusimovich

Well, to start with, I work at EDS. Being this an internal project (that is, EDS as customer), we chose .NET as platform for this application (some corporate standards strongly apply in this sense). When this project started, .NET Framework 3.0 was not yet ready for release, even though we tried it, with the beta for the Smart Client Software Factory. This Smart Client Framework is a very fine tool for most projects, but this project has some tough requirements to accommodate, like CRUD screens defined at runtime based on some specific metadata persisted in the app database, as well as some graph representations of data that required the use of an API like GDI+ or similar. We tested the Smart Client SW Factory in a prototype, and found out that a major customization would be needed to make room for these capabilities to be included. We have very tightly scheduled iterations (who doesn't these days?), so the risk involved in this large customatization of the smart client software factory needed to include all these singularities was high enough to choose otherwise. We developed a custom smart client from scratch, but used many of the App Blocks from Enterprise Library 2.0 right from the start, and now we have moved to Framework 3.0 and EntLib 3.0. Our decisions do not imply that other platforms or choices should not be explored or used. Our decisions make sense within the particular constraints of this project, but other projects should feel free to explore as many walks as time and resources allow, just as we did.

Neon Samurai
Neon Samurai

Internally in an enterprise it makes perfect sense: - workstations need only a browser and network connection - enterprise software is centralized for management of user access and version updates - end user only sees what the webapp offers Internally everything belongs to the enterprise so sure, setup a central webapp server and get your geek on. Externally webapps are madness: - your files stored and indexed on third party servers - your software limited by the development whims of third party provider - your access limited by connectivity which is not always available - your bandwidth and monthly transfer rates take a hit constantly transfering "program" screens between the user and webapp - your data constantly floating back and forth through the inherently insecure http protocol and network medium For me, it's primarily that I just don't trust third parties that much either. I thank Google for the website utilities I make use of but have no interest in the whole Google remote office. I've even less interest in being locked into the MS remote office. I think the last time I used any such thing it was Netdesktop or something similar to that though I've never been able to find the website again.