Web applications as enterprise software
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.
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.
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).
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.
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