Blogs

Well, we did it… CODA’s first totally new finance system for around 15 years was unveiled at salesforce.com’s Dreamforce event in London on Wednesday. Jeremy Roche from CODA joined salesforce.com CEO Marc Benioff on stage during the keynote to talk about CODA 2go, the first accounting system to be developed on the Force.com platform, and demo the new application.

Demonstrating software live in front of 2500 people is always a risk, and sure enough the first click of a button produced an error message none of us had seen before. Our development team, watching back in Harrogate via the web, told us later their collective hearts stopped for a moment when that happened! However, turns out that that a glitch in the internet connection had taken the web browser off-line momentarily… so Steve Fisher on keyboards just had to refresh the browser and we were off and running.

The audience was certainly ‘wowed’ by the new offering - the CODA stand was mobbed for the rest of the two-day event. As we’d predicted, the salesforce.com community is hungry for a finance system that works seamlessly with their CRM.

We are currently working with beta partners, but when the solution goes on general release in the coming weeks we’re expecting a considerable amount of uptake. Watch this space, as they say!

Just one day now to the official unveiling of CODA 2go, at salesforce.com’s Dreamforce Europe event in London. Apparently registration broke the 2000 barrier some days ago so there will literally be standing room only when CODA’s CEO Jeremy Roche joins salesforce.com’s boss Marc Benioff on stage.

Jeremy will show some highlights of the ‘opportunity to cash’ process of CODA 2go, and discuss the product strategy and detail of pricing and availability. Shortly afterwards there will be a breakout where delegates can see the product in more detail.

We are briefing press all day today and tomorrow, so watch out for coverage around the world. Well know tech blogger Dennis Howlett got a preview last week and was highly positive - see his commentary on US site ZDnet or his own site, Accman pro.

We’ll blog more news over the next few days…

If you are familiar with our project through previous blogs you will be aware that the term “Velocity” in the Agile methodology refers to how many points of work the team can get
through in a given sprint. The higher the value, the more deliverable is the sprint. The easiest way to increase this as you would imagine is additional team members, however process improvement and increased effectiveness within the team can also help. Thus I am pleased to say that due to some new tooling around the Force.com Metadata API (part of the Development as a Service feature set) we been able to add an additional point to our sprints!

Not to be out done by Salesforce we’ve had a go at developing some of our own tooling. In doing so we have now added another form of Velocity to the sprint! This is in the form of the co-incidentally named Apache Velocity templating tool. Although it is still early days, through building our own set of Velocity templates we have started to reduce the amount of repetitive and ‘boiler plate’ coding we have been performing. Which does also reduce the possibility of errors, and as such improves quality.  To integrate Force.com into Apache Velocity, we have used an open source tool named Force Velocity.

Stephen, one of our developers, has developed a template that generates an Apex class that provides the same functionality as the DescribeSObject API call not currently available in Apex Code at present. Gareth, our Help author is also interested in understanding if it can help reduce duplication in the online help when field information is documented.

So who knows - maybe in a future blog we will start to see how Apache Velocity is impacting our own sprint Velocity in very real way!

A vital part of any application, especially a business app that will be used by many different people of different capabilities and background, is the Help system. CODA prides itself on its online, context-sensitive Help functionality for its on-premise applications, so we were determined to produce the same if not better for CODA 2go on the Force.com platform.

Gareth, from our award winning Technical Documentation team, tells how we did it… Read the rest of this entry »

We’ve started demoing the early product with internal and external people, and this week (5th/6th March) we’re going to be showing it to a global team of Salesforce executives in San Francisco, which is really exciting. The more we do this, the more we highlight how powerful this application is going to be, and also what benefits we’ve gained from being on the Force.com platform.

For example, in building our on-premise application release, Neon, we developed a new workflow system from scratch – and to be honest our development team did a really awesome job. But on Force.com, we just had to plug CODA 2go into the existing workflow that comes with the platform.

It’s a similar story with reporting – instead of having to build a reporting tool or data dictionaries into standard BI-type tools, they are already there with the platform. So that way we’ve saved loads of time and been able to focus more on getting the fundamental design right, and on meeting the challenges inherent with building a finance application in a SaaS world, instead of just a CRM…

This time last week we had no apparent ability to handle the classic CODA multis of multi-currency and multi-company on the salesforce platform.  Today we have a fully demonstrable solution, with some further worries about data security resolved beyond doubt.

Prior to that time we had spent several weeks researching the Force.com platform, explaining our requirements to our contacts at Salesforce and working through various proposals and counter-proposals. It was like trying to solve a problem that needed a high degree of collaboration and communication in a serial manner through a narrow bandwidth pipe. We even proposed a 2-3 hour conference call with the Force.com team but somehow with the time difference and conflicting schedules we could never make it happen. And the beat of our development drum was moving on, we already missed one deadline for clarity on currencies that meant we were starting sprint 6 with some assumptions whose validity was not proven.

Clearly we had to meet face to face with the Force.com team. Read the rest of this entry »

At CODA we are heavily into the implementation of design patterns within our Java and .Net based products, and as such found ourselves quickly wanting to benefit from them on the Salesforce platform as we embarked on our CODA2go project to build a new Finance system. To date we have implemented Domain Model, Unit of Work, Identity Map, Lazy Load, Data Mapper and Service Layer. The platform also provides a solid implementation of the Model View Controller pattern through its new Visualforce technology.

It’s very likely that CODA is amongst the first, if not the first software vendor to implement these patterns on this platform and I’m pleased to say despite the infancy of the Apex language they have taken very well. For those unfamiliar with design patterns, think of them as generic cook books for developers that describe solutions and strategies to building well structured and critically, well defined, consistent and thus maintainable implementations. This Wikipedia article is a good general reference. The above links are taken from Martin Fowler’s excellent site.

Implementing these patterns alongside a representation of our product’s domain model has also been critical to our desire to keep code relating to aspects such as business logic, data representation, querying, persistence and user interface code separate. This approach has been base architecture design for all CODA products ever since our first client server application, CODA-Financials.

Read the rest of this entry »

Being an ISV working on the Force.com platform has, its fair to say presented a few challenges we didn’t expect to face, relating to things we take for granted within an ISV development environment on previous platforms. Such as team working, source control management, overnight builds, packaging and deployment out to our internal teams. Since starting the project last year, we’ve worked closely with Salesforce to create the best solution we could using the tools we’ve had to date, allowing us to progress through a number of sprints successfully.

With their recent announcement we finally see a true ISV focused development toolset emerge.

Read the rest of this entry »

We’re now several weeks into the implementation phase of CODA 2go and have really started to get into the depths of the Force.com platform. 

CODA has a strong investment in web technologies mainly based around Java and .NET and the move to a on-demand solution built on a new platform is both an exciting opportunity but also a technical challenge. 

The technical focus of the project started with a trip to salesforce.com which gave us an insight into the architecture of Force.com and provided valuable connections to the key figures in their development team. The visit also allowed us to promote the needs of an enterprise level ISV to salesforce.com. 

Read the rest of this entry »

We’ve just finished our first ‘sprint’ using the Scrum methodology that we’ve adopted for the development of CODA 2go. There are significant differences between Scrum and  more traditional development methodologies we also use. In our adoption of Scrum we develop and test in two-week cycles (‘sprints’) and at the end of each sprint have demonstrable functionality. 

One of the main differences with traditional methodologies is that design becomes integrated into the development, rather than being handed from designer to developer. In scrum the designers, developers, testers and documentation guys all sit together and feed off each other’s knowledge and where possible pitch in to get the job done, even if it’s out of the individual’s usual remit. So for example, we have designers and developers working on testing. 

Read the rest of this entry »