/bin/recykl

After a while my first enterprise prototype is finished and I have to summarize what was right and what was wrong during the period of prototyping.

Really nice surprise for me was the way of communication. The requirements were formulated more precisely then any requirement before, but not from the beginning. When I did start, the requirements were very vague, but after first screens and first few features the communication was excellent and clear. This was the phase of fundamental principles and relations creation.

After some time, the flow of requirements was stronger and stronger. It was necessary to start requirements management – yes, it is true. You cannot get rid of it.

In the middle of development users started to use it and a new set of “handy little” features was requested.

Later the system became very important and the users started to solve real production issues using the system.

Now, the system is almost finished. I mean – the necessary features are there, but sometimes it is not consistent. Especially the stuff that is used rarely. The enterprise is pushing me to pass it into production regime.
And what are my lessons learned?

• The start will be painful. Be prepared to completely redesign the code and model.
• Scaffolding is for some time more than enough.
• It is not necessary to focus on good graphical desing from the beginning. Focusing on features is more important. In my case I did implement a nice design after 80-90% of features was implemented. And in fact, I did it because the environment was really ugly, not because customer did ask me to do it.
• Make sure you find the right group of people to prototype with. It is impossible to create a prototype without business experts.
• It is not important how much you boost your performance using good tools. You will always have more requirements than could be implemented. Requirements management is a must.
• Communicate clearly that you are working on a prototype. Otherwise you will be forced to make it a real application. Here I started to think about using grails for prototyping. Nevertheless, I have no experience to decide if it was a good idea or not.
• Be prepared for success! The application that will be created is in line with the requirements and heals the biggest pains of the business users. It is highly probable that the users will love it.
• Do not stick with one technology. Anything that makes the process faster is valuable. Eg. I did use Sybase PowerDesigner to generate “history keeping” triggers automatically. Adding a new table to my model was just few clicks and assigning the right trigger template.
• And last, but not least. Listen! Listen more! And make sure you understand that you are not the one who knows the business. You came there to help them to communicate their needs, not to show them how to do their business.

Now I must say, that Ruby on Rails is a great tool for project communication. It is able to communicate user requirements very efficiently and precisely.

Ruby is great! Ruby is cool! It will penetrate in enterprises within few months.
These are some of the ideas that occupies one’s mind during the RoR excitement period. But things are not always so simple.

Enterprises does not behave same as small companies do. Their IT complexity reached one of the highest level and the only way how to manage it, is to follow internal standards and management rules. Complexity is the reason why the big companies are often so rigid concerning new platforms.
The enterprise IT managers expects

• Strong partner that can help in case of big troubles
• Wide specialist support on market, not to be too dependent on one vendor and to be able to expand system built on new technology themselves
• Technical support, bug fixes, hot-line… simply, a set of services that guarantees quick production problem fix
• Consolidation – the managers does not want to add new platform to the enterprise. And if they add one, they expect at least one platform will go away

Fortunatelly, there are still oportunities for new platfoms. If there is a need for certain functionality and the only acceptable is built on a new technology, it is probable that the new technology will come into the enterprise.

Prototyping

And RoR covers a need that is very important and currently does not have any reasonable alternative. RoR could be used for prototyping.

• You do not need a strong partner for prototyping, because the prototype should never go into production.
• You do not really need a wide specialist support. If the enterprise does not have the RoR specialists, it can behave the same as before
• There is not high demand for technical support. Simply, if something minor does not work in prototype, nothing happens. Business will understand it.
• Consolidation is also “no issue”. The platform is needed for a short period of time, it will never be in production and thus does not cause addiditonal mess in IT environement.

I have discussed this issue with few companies delivering to enterprises. They currently use prototyping, but it is based on java or .Net. They create a set of screens that is used for further application generation. I can see few weak points in this approach

• Prototype is not part of the development phase, but part of the analytical phase. Its main purpose is to communicate user requirements. No user will tell you what he/she wants without your help. The best help I can see is a working application. Once something works, users starts to imagine the possibilities.
• Prototype should be thrown away. It should not be used for further development. Simply, during the prototyping phase there is a lot of garbage code created.

Why Rails?

Let me do small +/- analysis

Positives

• It uses enterprise design patterns like Active record, MVC (Model View Controller) and what is the most important, it is hard to avoid it!
• Since the RoR uses the patterns, it will be a solid base for high quality design of the final application
• RoR is build on ruby. Thus the prototype must be thrown away. I know, managers does not like to throw anything away, but from my experience, the best pieces of code are the ones that were lost and I did rewrite them completely.
• Increases productivity (I have seen a comparison of ruby/java productivity. It was around 10:1. Nevertheless, from my experience, creation of an application skeleton in RoR is faster than configuration of hibernate)

Negatives

• No big player supporting it. This is not a problem for prototyping. It could be a competitive advantage of smal flexible companies. And of course, this might change.
• Missing integration to enterprise systems like domain controllers, messaging systems…
• It brings a new platform into enterprise
• There is stil not enough specialists to build stable teams. There are specialised companies that uses RoR, but enterprises needs massive support.

Nevertheless, in prototyping, the mentioned issues are minor ones.

Future

So what should be expected in the near future? It seems, that developer’s community is growing. But not only in small companies. Our blog have hits from the biggest IT companies.
I expect that sooner or later the big consulting companies will add RoR into their standard portfolio of supported technologies.

About 6 months ago, I posted an entry on how integration was crucial to success of smaller web 2.0 applications.

Today Yahoo released Yahoo Pipes, which sounds like an implementation of the same idea. A platform for creating mashups. The web is evolving in interesting ways, and whether this particular service succeeds or not, we will see more mashups between smaller web 2.0 services.

This definitely is a great start and I am sure we see more in this space.

Looking back at the experience with enterprise IT architecture, I come to realize that in this area, IT mastery is just a prerequisite for delivering projects successful in the long run.

This relates to the two interest groups shaping the IT landscape of large enterprises: implementors and visionaries. Implementors are responsible for the success of individual projects within budget, time and scope. Visionary architects see the interaction big picture of the solutions delivered, which calls for standardization and a degree of purism in order not to clutter and jam.


In order to also prosper and grow, IT solutions must reflect the “social” impacts as well: software is made by people and companies, each with their own goals and priorities. These people’s general attitude will decide about the long term success of a technical solution. Thus, architects and implementors must align their pursuits. Choose a technically correct, open and best practice approach, but if there are multiple comparable options (which there mostly are) give a serious consideration to the people who will live with the solution, maintain and develop it.

Examples can be found at all levels – application design, SW infrastructure, enterprise IT components:

• it is important to design a clean object hierarchy, if there’s someone to extend it later (remember the story of developer acceptance of EJB 1.x through to 3.x)
• an enterprise should introduce a centralized and secure user identity management infrastructure, but it must be attractive enough for the implementors and maintainers of business IT systems to get involved
• it has become a best practice to delegate customer interaction to an enterprise-wide CRM, just don’t forget to make this best practice obvious to the users who should fill the system with precious data

Reading IT classics (Brooks, Parnas, Coplien), one can see that the awareness of these human aspects in IT architecture has been around from the beginning. Still, in the stress of real-life projects it is easily forgotten. It is helpful then to reserve time in the assessment and planning period of projects to evaluate the “social” impacts of the projects reviewed and planned. This also naturally brings together the two interest groups.

This week kiko decided to close shop and put their code and domain up for sale at eBay. The main reason, also mentioned by Paul Graham, is that they were going head on with Google Calendar. Paul advises not to get in Google’s way, but is Google really invincible?

Paul in his recent blog post correctly observes that it was not so much the kiko’s calender itself that lost against Gcal but the integration of Gcal with Gmail was the killer blow. I agree. Most Web 2.0 (or any other incarnation of business) services like wish lists, to-do lists, calendars, notepads etc. are not going to make it on their own. There has never been much of a marketplace for such standalone services, they belong to more complex solutions. Does it mean that independent entrepreneurs should not innovate in this space? Or the acquisition exit strategy is flawed because your target acquirer could just built these services on their own? I beg to differ.

Let’s look at what is happening here. Say you want to build a new calender and believe you can do it better than Google. But there is no way you can make money doing just the calender. Advertising is not enough and might be intrusive. Paid customers would not come if they can get similar (even less sophisticated) features with Google. One possible way would be to use online version of your app only as a testing mechanism and sell the product to the Enterprise or an Enterprise player, e.g. an eLearning solution provider could use your calender component. But there might be a yet another way, look around for other Web 2.0 (again, used for lack of better term) companies that could use your component. The infrastructure is there and one of the basic tenets of Web 2.0 is integrable services. So, why not partner with other similar small players. This is a win-win-win situation for you, your partners and your users.

As for calender, David posted his reaction to Paul’s post, where he states that 37 Signals also launched a calender recently and even charges for it. Of course, they wouldn’t be able to do so, if it wasn’t part of Backpack. It’s all about an integrated experience.

There are about 1000 Web 2.0 companies on Seth Godin’s Web 2.0 Traffic Watch List. Will all of them survive? I doubt it, but by collaborating with each other they increase their chances many fold.

So don’t give up on your dream and creativity. Kiko’s death doesn’t mean much in the larger context. It’s still remarkably cheap and easy to put together an Internet based business. My web hosting is cheaper than my bank account fees. The only significant investment you are making is your time and even that pays off. Just the lessons learned would be worth the effort. Kiko founders already have ton of job offers and investment for their next project.