Factory

• Factory
• News
• Datasheet
• White Paper
• Road Map
• Tour (Screenshots)
• Installation
• Background
• Disclaimer
• Trademarks

There are 6 basic goals behind the initiative of the Factory project:

- 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 software that requires training and experience, and the free tools that copy the same concepts, look, and feel. These tools are generally helpful for planning in the very early steps of projects, but aren't designed for tracking. Most of the time, it's only a spreadsheet joined with a Gantt chart. I believe that most of the time, project leads need some kind of new, smart tool that provides good understanding of projects during every phase from planning to end, using best practices as guidance. This tool must be small, fast, reliable and easy, even if it doesn't cover every aspects of project management. There's a need for tools like this among 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 access to BIG commercial softwares. I also believe a project lead shouldn't focus on Gantt charts. When a project includes hundred of tasks over many months, there is no way to 'draw' a nice and flashy diagram. Gantt charts are useful for very high level presentations, but not so useful for designing a medium-sized project. Thus, I think the tool should focus on different views of the tasks, as a diagram is only a view of one plan. Moreover, from a lead's point of view project management is not synonymous to 'plans' at a very low level, or 'portfolio' at a very high level. In many projects, especially in IT, team members must collaborate and share information quickly, and the lead must react very quickly. Thus, the need is for a tool that is able to change the plans easily, sometimes daily. That's why in Factory, plans are version-based and the application integrates all versions in a transparent way.

- Be collaborative, but everything is a project. Today (2005, revised 2008), all the major leads in IT industry are thinking 'collaborative'. That's the new marketing concept, and I believe they are right. Many people using a laptop (designers, developers, consultants) manually aggregate 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 have personally been waiting for that since I started working. Only, I would like to introduce another concept used in so many organizations. This concept is the project. Today, companies are focusing on projects most of the time. Thus, the idea is to push the projects as 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 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 isn't to 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 work around junk messages. I think there are two 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 one 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 and combine project management, collaborative tools and CRM into a single tool, that must be easy to use.

- Back-end, toward a 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 difference is 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 of RAM). We can easily imagine this information 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 fewer, smaller messages on the network (HTML versus SQL). Thus, the idea is crystal clear: cut down the number of layers and reduce the message lengths. We can imagine a set of machines that keep all data in memory and serve the information using small messages. That means the clients should be smart. And if they're smart, that means they can serve the information, too. Thus, let's extend the grid to the clients as well. 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 shouldn't 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. Web-based applications, in my view, provide a good example to new generations about what the computer was 30 years ago: centralized, slow and ugly. I truly think there is a real ditch between 2 worlds: the applications dedicated to IT troops (very powerful and flashy, think new IDEs), and the applications dedicated to users (they are trained to copy and move files across networks and they enjoy double-data entry, think file managers and ERPs). Today, applications are either web-based or file-based. If they are web-based, that means you need to maintain at least a web server on your machine (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 need a database server, too. If they are file-based, you need to save information in a .xxx file somewhere on 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 file 'document1.xxx' in a shared directory, upload on a server, attach to an email, and so one. Thus, you get the idea; you need to control the environment, and it's not easy. Why aren't applications smart enough to keep your work in a safe place and share it with who you want? I really think users shouldn't 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, that'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 ...and in real-time because my manager is available somewhere on the network, or in different mode (my manager will get it when he'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 item of interest is its availability to so many different operation systems. Buy any computer you want today - with any operation system you want (better? cheaper?, I don't mind) - and it works. Another standard is obviously XML. Now, think about smart applications. I believe, using Java, that programs should be hard coded. Maybe it's heresy for many developers, but I think today (especially using object-oriented languages) it's really better to smartly hard-code a piece of logic rather than adding complexity and layers using an external setup. I believe the first option provides faster, most reliable results... and a smaller program.