Agile Zone is brought to you in partnership with:

I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 638 posts at DZone. You can read more from them at their website. View Full User Profile

Web applications as enterprise software

  • submit to reddit

Usually I have no shame in using PHP for everything I do as a freelancer, because it's the language I and the people I work with know best. PHP however is a web scripting language, thus it implies that you are developing web applications with it.

In our work, a typical example of using PHP in the enterprise is a web application in an intranet of a company, that replaces an old legacy management applications (or fill the vacuum of a manual process).

We had many successful cases of applications that manage restaraunt or autobus reservations, revision services or even schools (grades, attendances and holidays). Every time they replaced something that was in place or sustitute a manual, paper-based annotation process.

In this article we'll focus on a case study on enterprise software where the porting failed, to list the issues of introducing a web application into the enterprise, and hopefully pave the way for future successes. This is kind of a written retrospective.

The advantages

Some pros of using web applications instead of desktop ones are become classics:

  • easy portability: there is no client to deploy on different machines, but only a browser is needed to access the application.
  • The previous point also results in an automatic upgrade. 37signals had great success with small business web-based software oriented to small businesses.

An additional point for enterprise software is that you can enforce or refer to a particular browser (for instance Firefox) as the policy of the company requires. Cross-browser compatibility won't be an issue in this particular case.

The case study

The case study is the replacement of a legacy application, which unfortunately failed. The original application was based on Microsoft SQL Server and on Access clients. We had no access to the source code as it was a commercial product, adapted to the situation of this particular company with some patches.
There are a lot of issues that came up.

Complex domain

Enterprise software usually involves money, taxes and invoices (and millimeter-perfect generation of PDF files). I bet the financial system in your country is as complex as Italy's one. The rules are strict (you have to comply with the law), so for example automated id generation for the invoices is not going to make it.

As a side note, in another project the client has already bought 10K preprinted sheets (with an empty table), so we had to tune our report page to fit perfectly into it. It seemed like forgering school documents again, but adapting our solutions to the business domain is one of the thing of highest value for a client. Their processes are what makes money, so they aren't going to change because of an interface which does not seem intuitive to us (at least not yet, maybe in later cycles after real users have torn apart the application and give some feedback).

Data portability

When you are replacing a legacy application which contains financial data, every single database record must be ported into the new application, even if you change the database schema.

We used Doctrine 1 reverse engineering and fixture tools to access the database and generate a Yaml schema, plus a dump of all the data in Yaml format. The beautiful thing about this process is that once you have Yaml files, you can more or less insert it into any database (ours was MySQL.)

The Yaml models were horrible instead, with fields like parcel1, parcel2, parcel3, but were a start that provided an initial domain model. At the time of this project, Doctrine 1 was the only option that achieved both portability and a serious object model, even if it was based on Active Record.

File sharing

Dealing with file transfers in browser it's not always viable. HTTP does not provide transparent solutions to access remote files.

We thought of using L:\ (remote file system) links to provide access to a shared resource, or extending the browsers with some plugin like Google Gears. But we haven't got at that point before the project was cancelled in agreement with the client because of lack of results and lot of elapsed time.

The most important issue: monumental requirements

We were not employing agile practices at the time, aside from a bit of unit testing. Trying to apply a waterfall approach with some feedback inserted in it was the issue that ultimately caused the project cancellation.
We were working with the client, but only for gathering the requirements, and with no quick feedback on the screens of the application.

Not all requirements are required: writing them in the form of user stories would have helped. The problem was replacing a legacy application which was costly to maintain, and it would have been tackled one step at the time.

There were unrealistic expectations, like the one that the whole application could be duplicated: not only it was not possible without some years of work, but it is not proficient at all since some features are never really used. In retrospect, a backlog of prioritized user stories would have been a charm.

If only I have read Agile estimation and planning before! And a challenge in the future would be also adapt the relationship with a client to follow an agile process. For example, when I started out fixed-price and fixed-scope projects were the norm. While this approach can work on smaller systems like a restaurant or a shop, it breaks down in the complex environment of businesses run with more than 15-20 people.

If we want to introduce web applications in the enterprise, which is a large business domain to tap into, we must adapt our approach to solve the issues that come up from time to time, due to the essential complexity of the domain in which companies are run: they make money out of this complexity. Agile practices are only the first step:

Agile does not solve problems: it makes them emerge earlier. -- Francesco Trucchia, phpDay 2010


Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Ivo Jansch replied on Fri, 2010/07/16 - 2:32am

The most common reason for web applications to fail in an enterprise environment is the lack of an enterprise compatible process. An application of a certain magnitude needs things like a technical design and a well thought through architecture. Agile is not a holy grail here; you would've run just as hard into the large file problems.

My advice would be to start with a couple of proof of concepts, where you tackle the challenging problems such as the large file, the connectivity and the interoperability with the legacy database. A good approach to the latter for example is to create a service layer where you abstract the database away from your application.

You mention 'a complex domain' but is that really a reason why a 'web application as enterprise software' would fail as your title suggest? If you're dealing with a complex domain make sure you create a proper domain model, user patterns such as the data mapper to abstract things away and use unit testing to ensure that calculations and business rules are correct.

A recommended read is Martin Fowler's Patterns of Enterprise Application Architecture; it may help you build applications using architectures that are suitable for the larger scale that enterprise apps may require.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.