2.1. MOBIE

In 2001, our internal customer management, ecommerce, tracking, mailing list system was getting long in the tooth. As many had during the boom, we believed that accomodating runaway success was more important than flexbility. As such, this old system was a set of shared objects written in C++ and inserted into a custom scripting language core that we had created for speed. It was blazingly fast, but suffered from several key problems:

1. it required a very particular install environment and root access.

2. the scripting language, while blazingly fast, was duplicating alot of effort that was being done better elsewhere.

3. it required a ridiculously high degree of technical expertise to modify.

4. it had it's design elements hard coded.

5. any custom development we did for customers was done using other technologies like Perl and PHP meaning we couldn't leverage any of our existing code.

6. was very impractical to integrate with anything else because it “took over the page”.

7. It didn't help us manage the front-end websites which all still needed to be managed “by hand”.

We hate doing work that cannot be leveraged. All this work building a system that ended up being only for internal use was wasted effort. Because of it's very specific install requirements and because it used an entirely custom development language, we were endlessly re-implementing features in PHP or Perl that we had long since implemented in C++ before. There had to be a better way so that we could develop something once and reuse it many times in many places.

We had a vision for a replacement system which we would eventually call MOBIE. Our intent was that this new system would address all the shortcomings of the previous system. If we did it right we would be able to leverage this one codebase for all our work whether internal or external.

From a functionality point of view, MOBIE would integrate:

1. centralized contact, account and opportunity management.

2. calendaring.

3. business website effectiveness tracking and reporting.

4. advanced website content management where software features like forums, ticket lists, login, and client portals would be treated as “content” that can be configured and placed on the website through the webbrowser.

5. mailing list management tied into both the contact manager and the content manager.

6. multi-level granted based authentication.

We also envisioned that because each business is different, it would need to support:

1. customization on a per-client basis. To prevent us from being buried in support or non-leveragable per-client work, these customizations would need to be accomplished with a minimum of effort and then managed somehow as new versions of the core software are developed.

2. piece-meal reuse so that any functionality we developed for it, like authorization, could be reused in other projects. By not having to redevelop all those features each time, we would be more price competitive.

It was an ambitious vision.

Because we are a huge multi-national corporation of exactly 2 people, we desperately needed something that would let us significantly speed up the development process and reduce the amount of work. Otherwise, we would never get it done.

Essentially we wanted to do more, in less time, install it in many places, re-use it everywhere, and manage local changes without too much work all the while having something that would be approachable by our less technically savvy partners.

We considered developing MOBIE by hand. We considered using various existing frameworks. Nothing that we found would let us get this amount of work done with the few resources we had at our disposal.