Try to mention word “refactoring” to a CEO and what you’re probably going to hear is “why didn’t you think of this during initial development?”. Well, it’s a valid question and there can be at least 2 answers. One will make you look like a fool, another will make you look like a star.

• Fool: I don’t know.
• Star: As a matter of fact I (or my team) has carefully reviewed all the options and considered two different approaches. We decided that based on initial system traffic/load/performance requirements we should go with option 1 (simple but effective) and therefore save 6 man months of development effort (or $90k). We determined that option 1 will serve us well for at least 2 years and allow room for ample growth before considering any changes. Over the last 1.5 years, as expected, option 1 delivered as expected. It’s probably not going to need changes for another 6 to 8 months, but, with some new frameworks or products, 1 developer can refactor the system in just 2 months. The result of this refactoring will give the system another 2 years of steady growth in traffic and users.

You just demonstrated that you saved the company $90k and you’re only asking to invest $30k now to make the system more robust – that’s net savings of $60k, not counting the fact that you delivered the product a few months sooner.

So you’ve built your website, launched it and are now adding new features and slowly enhancing the site. Suddenly, you get contacted by one of your users. He says that he loves the site. He has a business idea for a different site in a different industry and he feels that your site has more than 80% of the functionality required by his “idea”. He wants you to customize your site for his needs for a nice chunk of change.

Sounds good, right?

You quickly agree. It feels great that by building your own site you also created something that others would want to use with minimal customizations. You discuss the requirements, create a proposal and get the ball rolling.

There are two ways to approach this:

(1) Create a copy of your source repository and customize that “copy” for your new customer.

• PROS: Easiest and fastest in terms of effort and duration
• CONS: You need to maintain multiple source repositories. Changes to common code have to be applied and regression tested multiple times. Creating custom solution for customer #3, #4, etc may make the environment unmanageable in terms of resources.

(2) Refactor your original platform to be as generic as possible, but don’t go overboard. For example, make your services and database functionality generic, but create custom web pages. Make your platform a core foundation for the new platform. All the common code (say 80%) will stay in the same code repository and customer-specific code will have it’s own source branch.

So what’s next? Cloud computing. Companies started jumping on a cloud bandwagon a couple of years ago, even though cloud is just a new term for distributed computing infrastructure packaged and marketed differently. What made cloud a very attractive option for startups is (1) easy entry, (2) pay-as-you-go pricing structure.

There are 3 types of clouds:

• SaaS – Software as a Service, which is basically a way to rent software instead of buying it.
• PaaS – Platform as a Service, which provides an environment for developers to upload and host their code without worrying about the underlying infrastructure.
• IaaS – Infrastructure as a Service, which allows companies to select appropriate, fully managed infrastructure components and pay for them as-you-go.

Internet companies which have simpler requirements derive the most benefit from using PaaS.

More sophisticated sites will benefit the most from IaaS or a combination of PaaS + IaaS, which is exactly what Amazon offers via Beanstalk, EC2, RDS, S3 and several other Amazon AWS offerings.

It’s especially a no-brainer for Java based sites using Tomcat and MySql. Beanstalk allows developers to drop an application war file and have the site up and running in a couple of minutes. Here are the steps in a nutshell:
Create an instance of Amazon RDS (MySql database service). Go through normal process of creating a schema and importing data. I prefer to use mysqldump to move data around.

Create Beanstalk application and upload application war file to Beanstalk. This creates a new version for your application. You can have multiple versions of your application uploaded to Beanstalk.
Deploy application to the Beanstalk environment. This creates Amazon EC2 (elastic cloud) instance and deploys your war file into a pre-configured Tomcat 7 instance (or Tomcat 6 if you wish).

If your application runs completely of off MySql in terms of data, then you’re all set. You can access your website immediately. If, on the other hand you have more complex requirements, like allowing users to upload binary data, documents, images, etc, then you should take advantage of Amazon S3 (simple storage service) which has an api to use for storing and retrieving data.

You can do many more things with Amazon AWS. Do you run processes which require massive resources and process lots of data and run all night to produce some reports or calculations by start of business day? You may already be using Hadoop for that. Amazon Elastic MapReduce (Hadoop customized by Amazon and configured to run in the cloud) will make your life so much easier. Hey you can now compete with large financial institutions who spend millions of dollars to manage sophisticated infrastructures to run portfolio analytics and other calculation rich services. Not that you want to do that, but you can.

You should of course decide how to configure your cloud services in terms of load balancing and failover. Estimate your traffic and growth trajectory and request desired configuration. Don’t go overboard because you’ll be paying for more complicated setup. But also don’t discount the risks of a server going down. It will go down one day and most probably the day you have lots of traffic. So make sure to have at least 2 servers and possibly even spread the environments across 2 different geographical regions (e.g. East coast and West coast).

Good luck.

To the cloud!!!

So, now that we all know what business agility means, I’d like to share the top 4 things a technology startup must possess in order to be agile (based on my personal experiences with several startups).

1. Executives that jell well and are open to new ideas

This one is really self-explanatory. If one of the partners is not flexible then quickly changing business direction or even introducing modest changes can become “mission impossible”.  In most cases, conflicts arise due to a startup experiencing some kind of problems. How do you solve problems? Discuss, analyze and agree on course of action. “Agree” is the key word here.

2. In-house expertise to make intelligent high-level decisions

Even if the team jells and agrees it doesn’t mean that an intelligent decision has been made. Their must be in-house decision makers to cover strategy and decisions in business development, sales, marketing, technology, and other relevant areas. Outsourcing should only be considered for executing decisions, but not making them.

3.  Enough money to implement new ideas and weather the storm

Ok, so the decision has been made. Now it’s time to execute. Regardless of what the decision is it’ll take time and money. Nothing new here.

4.  Flexible platform architecture and design 

Let’s say startup’s management team agreed to introduce a new revenue stream, which changes some of the initial business plan assumptions. This may seem straightforward to a non-technical executive. Well, it isn’t. Sometimes introducing just one feature can completely negate existing business processes. I like using legos as an example of flexibility. You can replace various pieces without breaking the integrity of the final product. In software these pieces are called services and components. (i) Each service/component must be designed in a way that it can function independently of the surrounding environment. All the service or component should care about is the input and the output, but the logic itself is encapsulated within. (ii) Another important feature is for the service to function exactly the same whether it is executed synchronously or asynchronously. (iii) Finally, it is important for a service to be able to run on either the same physical machine as the calling service/component or on a completely different machine. These 3 principles will allow the platform to change, scale and even integrate with other platforms.

I originally designed the platform to handle all the events as they occur, synchronously because of the obvious time and budgetary constraints associated with building an Internet startup. This was sufficient in the beginning, but it became apparent that even with just over one thousand firms in the system, synchronous event-handling would not scale beyond the physical constraints of the hardware it is running on. For example, a single deal posting event may trigger business logic to process hundreds of automated deal match notifications and hundreds updates of the “Activity Stream” for hundreds of firms and members. Similarly, other events in the system trigger hundreds or even thousands interactions.

So I decided to do what I’ve done when I worked on Wall St. developing trading systems and high volume number crunching algorithms – I developed an asynchronous event-handling framework for PE-Nexus. To stay true to my believes that every software application should be as simple as possible I decided to use a simple yet powerful messaging framework Apache ActiveMQ as oppose to its commercial competition from Tibco, IBM, Oracle and other heavyweights that are unreasonably more complex to use and in many cases lock one into the vendor’s other offerings.

Now in it’s final stages of testing, PE-Nexus event-handling framework demonstrates significant improvements of the overall performance of the platform. It now easily scales horizontally across multiple servers and handles hundreds and as business grows thousands business events asynchronously, simultaneously and in real-time, without effecting the end-user experience.

Another important aspect of PE-Nexus event-handling framework is the fact that every important business action onthe platform now triggers an event. That event gets routed asynchronously to the appropriate event handler. New event handlers can be introduced without affecting any of the customer-facing functionality. In other words, new event handlers can be developed, turned on or turned off at any time.

It was challenging to have a day job as Director of IT at Sensei, mobile software company, while working nights and weekends building PE-Nexus. It is especially challenging doing all that and still finding enough time to be a good husband, farther and son.

My life has been hectic since February 2009, when I met my partners and started working on PE-Nexus. From a professional point of view though nothing compares to being a co-founder and CTO of an Internet startup. It is an invigorating, exciting and rewarding experience.

I’m looking forward to making PE-Nexus a “household name” for Middle Market M&A professionals across the Globe.

Z2762J2XCZB6

My technology group (currently 9 people) was gathered via a meeting invitation to participate in SWOT analysis. Most of us either never heard of it or only read about it in books or on the web. The organizer expectation was to conduct and complete SWOT analysis in 2 hours. Everyone was given a stack of post-it notes and we all started writing one thought per post-it about what we individually feel are our Strengths, Weaknesses, Opportunities and Threats.

It took us about 15 minutes to exhaust our thoughts and to stick those post-its on to 4 large sheets of paper on the wall, one for each letter in SWOT.

Then we started discussing each of the notes in reverse order – TOWS.

I personally enjoyed the discussions, heated at times, because we all expressed our opinions and created a unique team atmosphere. Some participants were more vocal than others, but overall it was an interesting team learning and sharing experience.

Needless to say, 2 hours was not even close. We have gone through Threats and Opportunities in the first 2 hours. We continued on another day and spent almost 2 hours covering a couple of Weaknesses. Then on another day additional hour and a half to cover a couple more Weaknesses.

This is where we are now. We only completed 25% of Weaknesses and haven’t even touched Strengths. My guess is it’s going to take another 5 to 6 hours to get to the end.

But that is not important. What is important is that I discovered an excellent tool which I’m planning to use in the future on a regular basis. Of course it is only going to be fruitful if the results of the analysis are used to create short-term and long-term plan on minimizing Threats, embracing Opportunities, converting Weaknesses into Strengths and continuing to expand on existing Strengths.

I look forward to completing this exercise and suggest everyone to try it.

It is understood that nobody needs a support or an executive dashboard application if you have no users in the system. You can always get to it when the traffic picks up, right? Wrong! This is not the right train of thought.

I’ve made this mistake myself and from now on I will dedicate enough time and effort to creating administrative, support and executive reporting functionality so that developers don’t have to react to every request coming from non-IT staff and start querying production database or even worse updating it directly.

Simple things like deactivating or clearing user accounts, or displaying how many users are using the system and what is their demographic. This stuff is simple to develop. Support personnel and business executives will be happy because they can see what’s going on or research issue with a few clicks. Developers will be happy because they can concentrate on development work, and not on ad-hoc requests coming from non-technical staff.

Now, when it comes to the functionality, it’s no longer “it works” or “it doesn’t work”. It’s the opinion of the stakeholders. The more stakeholders, the more opinions. As technologists we’d like to say that we implemented all the functionality specified in the initial requirements. And that might be true, but there were numerous “drive-by’s” by stakeholders with new requirements. The project maybe took 6 months and along the way market conditions might have changed. So by the time developers think they have completed the project, stakeholders want to change and add a bunch of features to improve the final product.

The risk here is you can “miss the boat” if you try to deliver a perfect product on the first pass. Think of all the solutions you use on a regular basis. Microsoft Office Products, Social and professional networking websites, Online banking, etc. Were they perfect day one? Of course not, but they had enough important features for you to start using them. Over time, new features and improved functionalities were added and these products matured and became even better.

Just use a Pareto principle (the 80/20 rule) when in doubt.