If you want to completely by-pass the traditional phone company and receive a kick-ass business phone system - without the hassle of buying PBXs and getting circuits - you should really look into Vocalocity right now.

A little background first. About a year ago, the company known as Vocalocity and Zivva merged to form the new Vocalocity as it stands today. I was the founder and CTO of Vocalocity and we were squarely focused on building the next generation telecommunications platform and licensing it to software providers on an OEM basis. We had made great traction in the market with customers such as Microsoft and Siemens. Zivva was an VoIP platform provider and had made great traction in building out a IP-PBX platform and needed to upgrade their technology. Thus, the merger.

However, when we moved into our new office in Buckhead about a little over a month ago - I decided (like an idiot) to listen to the building owners and try and get a deal with the provider that was already in the building. I was sold on the speed of having the suite pre-wired and ready to go. I signed a contract - honestly, too busy with many other things and thinking it was a slam dunk based on the premise. Boy, how wrong I was. 4 1/2 weeks later with no phones - and a very unhappy set of people that couldn’t talk with customers - I was desperate. We needed to find a phone system and we needed it fast.

I turned to Vocalocity after continuing to hear about how great they were doing. I decided to cold-call the 1-800 # and try it out as a normal customer would. And, I must say - the response and turnaround was incredible. Incredible. You might think I’m biased because of my previous involvement. But, honestly, I wasn’t.

We spoke with Vocalocity at 2:30pm after finding out from our current provider that they still were unable to tell us (after 4 1/2 weeks) when we’d get our circuit and phones installed. Within an hour, we have a very detailed quote and selection of phones and features and ordered everything. By 9a.m. THE NEXT MORNING, we had 12 phones and dial-tone. We simply had to plug the phones in to our CAT-5 jacks in all our offices and cubes and then we had a very simple, web-based UI for configuring the voicemail and extensions. I promise you - it was that fast and that simple.

Now, I’ve had been deep in the telecom industry for the past 6 years. I’m pretty much out of it today. I can tell you, this just isn’t typical. My experience with our previous provider of waiting around with empty promises and B.S. is. That’s the normal telco experience. You wait, you big, you plead. Nothing happens. It’s been largely the result of big companies and monopolies.

Not anymore. Vocalocity is redefining that. What they’re doing - is making it work the way it should be. This experience is how it should work. Vocalocity is proving that you can deliver quality customer service and a quality telephone system that exceeds the expectation of customers. I wish Boris and team the best of luck. I’m now their biggest fan and loyalty customer.

Tech Tags: vocalocity vocalocitypbx pbx voip phonesystem

Day 2 of Startup Weekend Atlanta and we’re making some decent progress on our idea. The name of the idea is Skribit. It’s basically a user-generated topic suggestion for bloggers. More on that to come. Interesting experiment so far.

Tech Tags: atlanta, skribit, startupweekend, web2.0

Nolan just posted a well written piece on why he thinks model-view-controller (MVC) based designs for web applications are dead - and I agree. Also, Chris Haddad posted “MVC Matrix and the Red Pill”

As architects of the web, it’s easy to continue to evolve things as they’ve always been without making much adjustment to the fundamentals of the design. Refactoring allows us to continue tweaking something to make it better - and often you get incrementally better improvements. But, sometimes, when you take a step back, you’re looking at a big hairball of a design. That’s where we are with web architecture these days - and why I believe lighter-weight frameworks like Ruby on Rails have been wildly successful. But RoR only solves part of the problem, but not the fundamental problem of how apps are built and how services are accessed.

Try to do a simple web app in Java these days - name your framework? Arghhh. Puck. XML config files, web flows, JSPs, controllers, models and DAOs, WAR files, JARs, blah blah blah. And want to refactor your layout? Forget about it. Cut up the HTML again into pseudo-HTML via tag libraries, inline code and templates - and let’s try it again. Look okay? Ok, let’s do that again and again. Well, you won’t because it’s too painful and you’re app suffers. You compromise because the process isn’t broken as much as your architecture.

Enough is enough. We need to really rethink MVC on the server side as a way of building Rich Internet Applications. Let’s take the opportunity to actually do service-oriented architecture (SOA). SOA shouldn’t just be a webservices bolt-on. It’s not an afterthought - or yet another set of crap in the middleware stack. No, it’s central to the design - it’s the main act.

SOA based applications, what Nolan calls SOUIs (Service Oriented UIs) are really already becoming popular in the commercial and social web space with mashups and the popularity of REST. It really looks a lot like the older days of desktop applications - something we used to call “Client-Server” Programming. I’d suggest it’s really now “Client-Service programming”. Where the “Client” can be a variety of application types: RIAs, offline web apps, machine-to-machine apps (via service-to-service integration or “mashups”), Desktop Apps, etc. And “service” isn’t some set of capabilities bolted-on to the side of an MVC framework with AJAX, REST or SOAP bypasses.

The original Web Architecture model by Tim Berners-Lee is still very appropriate and I think is really the simplest form of the Client-Service architecture. Let’s get back to simple. Let’s get back to what really matters - creating applications. Enough of the complicated server architecture. Enough of the layering of the stacks on top of each other. Can’t we just all get back to a sane process for quickly building applications?

We’ve come a long way over the past 10-15 years. A lot has evolved. We need to take a step back and think about how we can build apps for the next 10 years and learn from what we’ve accomplished. MVC is dead. It’s not yet in the grave with all the millions of programmers and thousands of frameworks. But, we need to start preparing for that day. MVC is old and sick and feeble. We need to start thinking about the funeral.

Tech Tags: ajax, appcelerator, architecture, design, dhtml, mvc, rubyonrails, seam, soui, web1.0, web2.0

Nolan just posted a well written piece on why he thinks model-view-controller (MVC) based designs for web applications are dead - and I agree. Also, Chris Haddad posted “MVC Matrix and the Red Pill”

As architects of the web, it’s easy to continue to evolve things as they’ve always been without making much adjustment to the fundamentals of the design. Refactoring allows us to continue tweaking something to make it better - and often you get incrementally better improvements. But, sometimes, when you take a step back, you’re looking at a big hairball of a design. That’s where we are with web architecture these days - and why I believe lighter-weight frameworks like Ruby on Rails have been wildly successful. But RoR only solves part of the problem, but not the fundamental problem of how apps are built and how services are accessed.

Try to do a simple web app in Java these days - name your framework? Arghhh. Puck. XML config files, web flows, JSPs, controllers, models and DAOs, WAR files, JARs, blah blah blah. And want to refactor your layout? Forget about it. Cut up the HTML again into pseudo-HTML via tag libraries, inline code and templates - and let’s try it again. Look okay? Ok, let’s do that again and again. Well, you won’t because it’s too painful and you’re app suffers. You compromise because the process isn’t broken as much as your architecture.

Enough is enough. We need to really rethink MVC on the server side as a way of building Rich Internet Applications. Let’s take the opportunity to actually do service-oriented architecture (SOA). SOA shouldn’t just be a webservices bolt-on. It’s not an afterthought - or yet another set of crap in the middleware stack. No, it’s central to the design - it’s the main act.

SOA based applications, what Nolan calls SOUIs (Service Oriented UIs) are really already becoming popular in the commercial and social web space with mashups and the popularity of REST. It really looks a lot like the older days of desktop applications - something we used to call “Client-Server” Programming. I’d suggest it’s really now “Client-Service programming”. Where the “Client” can be a variety of application types: RIAs, offline web apps, machine-to-machine apps (via service-to-service integration or “mashups”), Desktop Apps, etc. And “service” isn’t some set of capabilities bolted-on to the side of an MVC framework with AJAX, REST or SOAP bypasses.

The original Web Architecture model by Tim Berners-Lee is still very appropriate and I think is really the simplest form of the Client-Service architecture. Let’s get back to simple. Let’s get back to what really matters - creating applications. Enough of the complicated server architecture. Enough of the layering of the stacks on top of each other. Can’t we just all get back to a sane process for quickly building applications?

We’ve come a long way over the past 10-15 years. A lot has evolved. We need to take a step back and think about how we can build apps for the next 10 years and learn from what we’ve accomplished. MVC is dead. It’s not yet in the grave with all the millions of programmers and thousands of frameworks. But, we need to start preparing for that day. MVC is old and sick and feeble. We need to start thinking about the funeral.

Tech Tags: ajax, appcelerator, architecture, design, dhtml, mvc, rubyonrails, seam, soui, web1.0, web2.0