White Paper

Factory
White paper
March 2005

- Hey project leads, what do you have today? The first goal is to provide to project leads an easy but powerful tool for team management and project planning. The idea is to avoid the complex and expensive commercial softwares that require training and experience, nor the free tool that copy the same concepts, look, and feel. These tools are generally helpful for planning in the very early steps of projects but are not designed for tracking. Most of the time, it's only a spreadsheet joined with a Gantt chart. I believe project leads need most of the time a kind of new smart tool that gives a good understanding of projects during every phase, from planning to end, using best practices with guidance. This tool must be small, fast, reliable and easy to use, even if it doesn't cover every aspects of project management. There are needs for such like tools from the project leads community in IT because they need to focus on the deliverables and quality, and most of them act in medium, small or micro organizations, without option to access to commercial BIG softwares. I also believe project leads should not focus on Gantt charts. When a project includes hundred tasks during months, there is no way to 'draw' a nice and flashy diagram. Gantt charts are useful for very high-level presentations, but not exactly to design a medium-sized project. Thus, I think the tool should focus on different views of tasks lists, and give information before to provide a diagram, which should be a result - or view - of one plan. Moreover, project management from a lead point of view, is not synonym to 'plans' in a very low level, or 'portfolio' in a very high level. In many projects, especially in IT, the team members must collaborate and share information quickly, and the lead must react more quickly. Thus, the need is for a tool that is able to change the plans easily, sometimes daily. In the very first releases of Factory, the plans are version-based and the application integrates all that versions in a transparent way.

- Be collaborative, but everything is a project. Today (2005), all the major leads in IT industry are thinking 'collaborative'. That's the new marketing concept, and I believe they are right. So many people today using a laptop (designers, developers, consultants) aggregate manually information coming from different sources. Ten years ago, we were all switching between phone calls, mails, faxes, internal staff notes and meetings. Today, we are switching between phone calls, SMS, phone or web conferences, emails, instant messages, meetings, CRM applications, intranets, web sites, forums and blogs. The new concept is to aggregate that information in a single system. That's very good news, I'm personally waiting for that since I started to work. I only would like to introduce another concept used in so many organizations. This concept is the project. Today, companies are most of the time focusing on projects. Thus, the idea is to push the projects in the center of collaborative work, because every single action is connected to a project. However, even if communication must be the centerpiece of project management, I consider it's a bad idea to communicate project plans (including assignments) to a whole team. My idea is very simple: to create links between tasks lists and to-do lists. I think the objective is to not assign a task to somebody, but to create actions based on tasks, then to assign those actions to the right person. Another perspective is to consider the project tasks as high-level objectives, and action plans as detailed objectives. Collaborative software should also workaround junk messages. I think there are 2 sources of junk communication: outside (Internet access is very permissible to high-tech hooligans) and inside (how many mails do you have in you inbox after 1 holiday week?). If you have more than an hundred of emails per day, you have a problem: maybe electronic mail is not the best tool for your job. That's why my basic idea is to forget the e-mail system and combine project management, collaborative tools and CRM into a single tool, which must be easy to use.

- Back-end, toward modern data architecture. Today, applications are designed on top of tens of layers. Let's think about operating systems, databases, application servers, web servers and browsers relying on many messaging mechanisms: IP, TCP, SQL, ODBC, HTTP, HTML, XML, SSL, RCP plus the proprietary messages... Let's introduce some new layers: CGI, ASP, JSP, .NET... I believe the industry switched from the mainframe concept to the client/server architecture to the 3-tiers architecture to the x-tiers architecture, and then is going back to the client/server. The only differences are the clients, the servers, the link between them, and the hardware. Today, we are thinking in terabytes for storage, gigabytes for memory and megabytes per second for communication. Let's think about a new way to design servers: enjoy large amounts of memory in order to keep the information ready for the clients (1 million objects that include 1 thousand bytes of information costs 1 GB or RAM). We can imagine easily this information could be served by a set of PCs (that's the grid concept). Then, let's think about messaging: web based applications are faster than client/server applications because they manage less and smaller messages on the network (HTML versus SQL). Thus, the idea is crystal clear: cut down the number of layers and reduce the message numbers and lengths. We can imagine a set of machines that keep in memory all data and serve the information using small messages. That means the clients should be smart. And, if they are smart, that means they can serve the information also. Thus, let's extend the grid to the clients too. Today, there is one example of a really good application that is able to serve a LOT of information to clients who use... the same program. It's Apple iTunes, and the information is music. Music requires lot of storage and network bandwidth. However, thanks to Rendezvous technology, iTunes is able to share music without any configuration. Why should we do the same for applications? One regular MP3 song is 3 MB while this document is 15 KB... See the difference?

- Front-end, toward a modern desktop. The web-based applications, for my point of view, gives a good understanding to the new generations about what was the computer 30 years ago: centralized, slow and ugly. I really think there is a real ditch between 2 worlds: the applications dedicated to IT troops (very powerful and flashy, you can think about new IDEs), and the applications dedicated to users (they are trained to copy and move files across networks and they enjoy double-data entry, you can think about file managers and ERPs). Today, applications are either web-based or file-based. If they are web-based, that means you need to maintain on your machine or in your organization at least a web server (of course you can ask your IT department, but it may not available when you are at home, in a traffic jam, at the hotel, or at home), and you probably needs a database server too. If they are file-based, you need to save information in a .xxx file somewhere in your hard drive. Your hard-drive contains tons of 'mydocuments', 'docs', 'home' and users directories / folders and sub-directories / folders. You need to replicate the information between your laptop, office desktop, personal desktop or laptop...even your pda or cell phone...using different operating systems. You copy the files 'document1.xxx' in a shared directory, upload on a server, attach to an email, and so one. Thus, you got the idea, you need to control the environment, and it's not easy. Why the applications are not smart enough the keep your work in a safe place and share it with whom you want? I really think the users shouldn't take care about their hard drive partitions, file servers or email accounts. Let's imagine: I need to work on a document; I only need to take a computer and work on it. Let's say that document will be available to my manager or my team when I decide. I don't want to worry about the files; it's my computers' job. My document should be available to others. It's up to the software the send the document to my manager when it's ready (in real-time because my manager is available somewhere on the network, or in differed mode: my manager will get it when it'll be in touch with the network).

- The same adaptive application. I really believe today, using some standards, there is a way to construct smart application softwares with only a few of code lines. One of the first standards is Java. Today, Java is able to provide rich, reliable and fast applications; they are tons of examples today. The very first interest is its availability to so many different operation systems. Buy any computer you want today, with any operation system you want (the better? the cheaper?, I don't mind), and it works. Another standard is obviously XML. Now, thinking into smart applications. I believe, using Java, the programs should be hard coded. It's maybe an heresy for many developers, but I think today, especially using object-oriented languages, it's really better to smart hard-code a piece of logic than adding complexity and layers using an external setup. I believe the first option gives faster and most reliable results, and a smaller program.