Enterprise software is accessed through a client: the program installed on the user device. They come into two flavours: thin and thick. This refers to the amount of business features that are present on the user side. On the thin side are the historical text terminal of mainframe applications, and also most web-based applications: they just display the page layout sent from the server. A thick, or fat client will include some of the business logic locally, and can also be used disconnected from the server. A Mechanical CAD system is a typical thick client: while it can connect to a vaulting server to store models, most of the action happens on the client program. Today, the clear consensus for most enterprise software is to build web-based applications. That is a solid choice, but not ideal.
Security of data is a major concern in many respects. Keeping secrets is key to most research & development, but this is also true of most commercial data: no company likes that the results of price negotiations becomes public. Keeping customer and employee data safe is also a legal requirement in many jurisdictions. Preventing fraud and sabotage is also a very valid concern. And there is a huge grey zones between malicious acts, and employees just trying to optimize the administrative burden that slows their daily work: some may, in good faith, try to tweak some rules sincerely convinced it is the best for the company, but often unaware of the risk taken. Any business logic or security layer that runs on the client can be relatively easily tampered with. Technical and scientific applications may be perfectly safe with calculation done on the client side. However, for data processing applications, the core concern of this site, keeping a good level of security naturally drives all business logic to be on the server side where it is safer, and the client to be mostly a display device. So at this point we already voted for a thin client.
This architecture has another advantage. Business rules implemented in enterprise software evolve often. In a recent system I have been involved on, there are around 4 major deployments each year and 10 to 20 minor ones. It is much more simpler to perform such changes if the logic resides on the server, where patching software can be a 30 minutes task. On the other hand, deploying a software update to a community of 1000 users is a mini project of two weeks to take into account various workstation configurations, and all the special cases of people in holidays, on a business trip, or having special requirements for their machine. This does not mean there will be no upgrade, but I would expect one upgrade every 3 to 5 years to update the client technology, and not 15 per year.
So you might rightly wonder at this point why we just do not agree the internet web-client. and close the post. The first reason is linked to the rapid evolution of internet technology. Web browsers are extremely complicated pieces of software integrating many components. It is extremely prone to obsolescence. In the enterprise world, a big cause of obsolescence is security flows, which may justify a relatively quick upgrade.And web client is not just the browser, but also the tool kits used in the presentation layer of thin client architecture: most of them try to bridge the gap between the web original intent, hypertext browsing, and its usage now as an universal client for applications. In this space, maintaining a complex web-based application requires to change this technology every 2 to 4 years. Accordingly, most packaged software vendors support their products around 5 years.
All this is fostering innovation in the consumer internet, but is not adapted to the enterprise software. Despite all the buzzwords about quick evolution, corporations have a software update life-cycle where the basic unit is the decade. There is a simple reason for that: deployment of a new application is often a 3 years endeavour. This includes a launching phase constrained by the yearly budgeting process, and a significant ramp-up phase where users discover the new system and are less productive as a result. During those three years, the initiative is basically a cost for the business, and to recoup that cost, the deployed system should stay in production at least a decade. There is also often no need to change as most business processes are stable for decades. Also, at a given point in time, a single user will have to access applications that are of various ages. The browser has the disadvantage of not allowing easily several versions on the same user device: this is some of my worst headache right now. So clearly, the web client does not fit the bill here.
As mentioned above, internet technology was originally made for hypertext navigation, and it has painfully become an application client. While it is used on the consumer and enterprise space, it is the former that clearly drives the evolution of the platform. This means the features are not adapted to enterprise users, who have different needs. The first gap is on the priority given in the application design to casual or experienced users. In the consumer space, the former is extremely important, as ergonomics for casual users will drive adoption, and also, most consumer applications are not so intensively used: think about an hotel booking website you will use 2 or 3 times a year. On the contrary, an enterprise software application will have a majority of experienced users, who should be as productive as possible. They may need features like key short-cuts which, when learned, can be 10 times more productive than the standard mouse interface. The web browser is not, by design, an ideal tool for this.
Also, enterprise software most common transactions involve managing medium-sized arrays, think a few hundred to a few thousand elements. That would be the size of the bill of material of a system, or the number of customer interactions a salesman would have had in a year. This is the area of spreadsheets, who are by far the most popular tool in companies. A productive enterprise software client will allow easy manipulation of those tables, and copy-paste features from and to spreadsheets. In most cases today, entering 50 elements in a business application is a chore.
There is a last element missing in the web browser that has a direct impact to the cost of maintaining applications: the easiness to record and automate business tests. They are typically one third of the total cost of running an application. Internet technologies, mixing presentation and business logic make it almost impossible to perform this automation.
So while the web browser has it right on architecture, it is not the perfect fit for the job of enterprise application client. Longer life-cycle, the ability to fit better with enterprise data processing needs, and capability to automate business tests: all this is clearly possible. Several products out there, and prototypes on my own have convinced me it is only a relatively small investment, say 2 to 3 men.years of work, to build something better than the internet browser for the enterprise, with endless possibilities to extend it to more advanced components. A 300 billion dollar market at the heart of modern economies deserves in my opinion its own client technology.
No comments:
Post a Comment