In our “ Technology Enablers for SaaS ” series, we highlighted Sharding in the last digest. This week we will focus on Aspect Oriented Programming (AOP) and Service Oriented Data Architecture (SODA), two more technology concepts that can be used effectively when building a SaaS product.

AOP: Code related to cross-cutting concerns like transaction, security and logging are usually common across a product. If any of these needs to be modified, large parts of the code base are impacted. This increases the complexity of a product and makes product evolution difficult.

Speaking in the context of SaaS, AOP attempts to solve the above problem by allowing cross-cutting concerns to be expressed in terms of stand-alone modules called Aspects. This is hard to do in case of Object Oriented Programming. For example, a security module can include ‘advice’ that performs a security check before accessing a bank account. The point cut defines the instances (join points) when a bank account can be accessed. Using AOP, we can link advices and join-points during runtime, thus giving flexibility to link both dynamically.

SODA entails that the databases are partitioned according to well-defined and logical service boundaries. At a logical level, a database service exposes a well-documented interface to data. This is not a general database interface for reading and writing data, instead it provides very specific functionality. For example, an inventory database service might expose methods for checking inventory levels, reserving inventory, removing products from inventory, etc.

While this may sound similar to stored procedures, what is different is that access to data under the control of one database service is completely isolated from that of a different database service. Moreover, requests to database services are exposed as Web services (instead of a database connection).

We will cover more technologies and tools for enabling SaaS in our upcoming digests.

Read the entire digest contents

“Professional Services originally meant services offered in the services of Medicine, Law and such other fields. Today it has expanded and the breadth of definition has come to include Design and IT too. When we say Professional Services in the IT industry, majority of the people consider it as customization, project management, implementation, consultancy and such kind of things. This is an era where the concept of differentiation for ISVs is very essential, and it becomes imperative for them to differentiate their products. This is where Professional Services can play a key role”.

Starting with this quote from the moderator, the tone for this month’s Producteering teleconference was set, which focused on Professional Services being a potential differentiator for business success.

At the outset of the discussion, one of the participants discussed on how his company started working with one of their customers through a trial version of their product suite. Once the PS team got in, they observed that in their customer’s organization, there were several best-of-breed systems, which did not talk with each other and that was the main cause of their IT problems – not the need for another independent product focused on one particular area. As a result of understanding what was actually the need of the customer, the PS team was able to recommend and implement a solution which solved the customer’s integration problems, while earning much higher revenue for itself and bettering its relationship with the customer.

This interesting example was then highlighted with the fact that the Professional services revenues from this company was almost 60% compared to the revenues from sales. This trend is not something new and all PSOs are aware that they are making a huge difference to the top and bottom-line growth of their organizations – this was further supplemented by a quote from the moderator that 52% of IBM’s revenues come in from Professional Services.

During the discussion, one point that was brought up was whether Professional Services should be done by the organization (ISV) itself or should it be done by partners and resellers.  Salesforce was cited as an example, by one participant, as one company whose partners were able to do many successful product implementations. However, a conflicting opinion to this was that unless your size and geo spread forced you to tie up with several partners, having your own Professional services team doing product implementation was valuable as your thinking and way of doing things can be directly brought to the customer rather than getting diluted by a partner.

Another important aspect of the discussion was of SaaS becoming main stream rather than a buzzword. While there still remains a concern of security in the SaaS model, many small and mid-sized companies, which cannot invest on expensive enterprise products, are now looking at transitioning to SaaS to reduce upfront costs and also shorten the time for product implementation. Integration e.g. integrating a project management suite with a CRM or ERP tool therefore becomes a key service, which ISVs have to provide as an add-on service, to become a differentiator in the marketplace.

The time has come for ISVs who do not want to adopt professional services as a key focus area for growth, to reconsider their decision, as PS has become a backbone of differentiation in the market. What they seem to have ignored for long is the fact that a product, in itself, is a service at a higher level. It targets and caters to the needs of the customers. And under this umbrella, ISVs can go far beyond implementation and integration to solve customer’s daily business problems.

Amidst this mind shift in the way ISVs stand as providers, it was unanimously concluded that professional services can be a potential differentiator for them and it can help them improve their products’ visibility, customer satisfaction, increase their revenues, margins and market share.

Moving to a Software-as-a-Service model isn’t easy, as we highlighted last week. Quite a few design and engineering considerations must be taken into account. Of course, a minimalist approach can be taken while building a SaaS product and that can work very well. For example, Tomcat, MySQL, XML, Struts 2.0, POJO and JSP are all it takes to build a SaaS application/product using Java technology.

However, there are additional techniques and tool-kits that can be made use of when SaaS-enabling a product. While these techniques and tools have not been developed specifically for SaaS and have been around for quite a while, they can come in handy when building enterprise-class SaaS products.

Some of the useful technology concepts to keep in mind, when engineering SaaS applications, are SOA (Service-Oriented Architecture), Web Services, Sharding, SODA (Service Oriented Data Architecture) and AOP (Aspect Oriented Programming).

Today, we’ll elaborate on Sharding, which is basically Entity partitioning. From a SaaS viewpoint, sharding can allow you to have parts of the data stored in different databases, spread across multiple servers. For example, user ids 1-100,000 live on one instance while the next 100,000 is stored in another instance. Tenants A and C can be stored on one server, while data for Tenant B is on another server.

Though sharding is regarded as partitioning, it is not just that. It is more than that. One can also split tables among different and smaller databases on different servers. Though sharding is not perfect, it offers high availability and faster queries of data. This also ensures more bandwidth, which is very essential for SaaS products, as the number of users at any point of time will be huge.

We will continue to highlight the different technologies and tools that can be made use of to develop SaaS products in the coming weeks.

Read the entire digest contents

Everyone’s heard the buzz about SaaS or On-demand, as it is popularly known, for quite a while now. Thankfully, SaaS has gone beyond being just a buzzword, and its benefits are perceived as real now. Although SaaS may not be for every Independent Software Vendor, an ISV can afford to ignore the SaaS model of delivery only at its own peril.

Before considering transitioning to SaaS however, ISVs should accept the fact that making the move to on-demand will have a profound impact on every aspect of the business: including pricing, delivery, sales channels, product architecture, support and infrastructure.

The architectural changes involved in getting your product SaaS-ready can be quite complex, hence the engineering aspects of building a SaaS product should not be overlooked. On-demand products need to have user customization designed-in and remote development capabilities. Also, as SaaS allows for instant upgrades to be done across the customer base, it would typically follow agile or iterative methodologies.

Adopting agile or iterative methodologies in turn ensures that your product will not be over-engineered and will have just enough features for you to go live with just enough technology. The most important aspect of any SaaS architecture will be allowing for reusability, extensibility, availability, and a service oriented approach.

One limitation of on-demand software is that it is configurable by end-users for their individual needs, but there is a single code base for all customers (or tenants) which is not customizable for any one customer. Because of this, competitive advantage or differentiation based on the software itself becomes negligible.

However, SaaS vendors have woken up to this and have developed platforms that can accommodate customizations. This rich customization allows SaaS vendors to serve larger corporations, in addition to their typical customer base of small and mid-sized companies. All of this and a few other things promise to change the SaaS landscape soon – the next wave of SaaS is coming!

Read the entire digest contents

Enterprise mashups aren’t as happening as consumer mashups, as we’ve discussed here once before. This is primarily because enterprise mashups aren’t as easy to create compared to their consumer counterparts.

One reason is that the most popular mashups today are browser-based. This means that querying different data sources, filtering and combining of data and rendering it in a proper format is all done within the confines of the browser. However, this cannot be the case in an enterprise, where data is quite heterogeneous - it resides in different formats, in different places, with different access limits. This is where server-based mashups come into the picture.

Mashup servers can deal with disparate data sources and even allow users to mashup sources without understanding the differences between the various data formats. A mashup server can also provide a visual drag-and-drop interface for easy creation of mashups and allow users to share mashups through pre-built, server managed interfaces via everyday tools like spreadsheets, email and portals.

Most importantly, a mashup server can safely store authentication and authorization information and be connected to an enterprise’s own authentication and monitoring toolsets. However, setting up the mashup server, feeding it with formal services and connecting it to security, governance and connection tools calls for the involvement of IT personnel, without which the enterprise mashup space cannot make much progress.

Faster and better access to external and internal data sources, reuse of existing resources and newer ways to use information are some of the advantages of mashups without costly investments and middlemen. Another big advantage that mashups can bring about is to complement SOA, if it is being implemented across an enterprise and to very quickly and visually represent the ROI of SOA to end-users.

Read the entire digest contents

Declining budgets for software development and IT in general has been a trend for the past few years now. And, in today’s fast-paced world, everything is needed yesterday!

Independent Software Vendors (at least the smaller and mid-sized players) have to constantly weigh these two factors – reduction of development costs (or resources) Vs. bringing products to market quickly – and compromise on one for the sake of the other. This pressure on an ISV’s internal engineering team can ultimately result in lower quality software products being released to the market.

In this kind of situation, ISVs must attempt to control the third element that has an impact on any development effort – namely the scope or the feature list of the product being developed. By prioritizing features that will go with a first version release, second version and so on, vendors have a better chance of bringing their products to market at a rapid pace while keeping costs in control.

Infact, many start-ups benefit from testing their product early with beta users and some of them get users into the feedback loop much earlier – even before a beta launch. This results in many software teams adopting iterative and incremental practices in order to keep up with such frequent release cycles.

A software project can be looked at as a problem that is being solved through the use of technology. The software product developed is one of the outputs of the project – in other words, it is the solution to the problem defined. Other outputs of the project can be reusable components, the knowledge gained by the team and so on.

Now, one of the approaches suggested back in the mid-90s, by James Bach, and which still holds good today is to apply an evolutionary strategy to software development. This approach is developed from the fact that as you work on a problem – it evolves and your understanding of it and your capability to solve that problem also changes or evolves. This leads to the product that is being created, evolving over time, and product knowledge also evolving.

When applied to the project level, the evolutionary strategy means ongoing process education, experimentation and adjustment, rather than clinging to a notion of one particular way of developing software. On the product level, it means planning and building the product in layers, which allows concurrent design, coding, and testing. This also provides opportunities to respond to changing requirements or unforeseen problems. On the problem level, it means keeping track of history, and learning about failure and success over time.

Some of the elements of using the evolutionary approach are:

* Don’t even try to plan everything up front.
* Converge on good enough in successive, self-contained stages.
* Integrate early and often.
* Encourage disciplined evolution of feature set and schedule over the course of the project.
* Salvage, reuse, or purchase components where feasible.
* Record and review your experience.

This approach has now become common-place, especially in relation to Rapid Application Development, but what you really need to do is to take an evolutionary view of your people, processes, and resources as well. This can lead to better software development in the long-run!

Read the entire digest contents

Software product companies who say, “We are an entrepreneurial company. We cannot be afraid of risk” may have to rethink that statement. This is due to the fact that every software development project comes with a sizeable amount of risk and this risk has to be minimized to the level where a project becomes successful and the product can be released without any major disaster.

Risk is the key to many tough decisions, for example: What is the best lifecycle model to use? How much requirements work is enough? How much design work is enough? Can junior staff be used instead of senior staff and where? How much schedule buffer is needed?

A risk management plan can help minimize unforeseen developments. Risk management is a set of practices which aids in analyzing many software development issues viz. assessing overall project risk and identifying, prioritizing, and managing specific risks.

Some examples of in-built risk management are active project tracking, UI prototyping, end-user involvement, incremental delivery and upstream technical reviews. This cyclic order has to be maintained for a software product being developed to be a success.

While every risk cannot be controlled, it can be identified, and solutions for the ones with the maximum impact can thus be developed. Good software development therefore calls for an effective Risk Management Plan.

Read the entire digest contents

During the Producteering Breakfast series held at the SD Forum in  California last month, the majority of participants (from the ISV community) held the view that a flawless and high quality product need not be the goal when attempting to build a successful product. Instead, a product that fulfilled customer expectations and which was better than competing products had more potential to be a ‘great product’.

So, instead of zero-defect software, what most users want is software that is cheap enough, fast enough, feature-rich enough, and available soon enough — that is, “Good enough”. Zero-defect software is often at the expense of time, functionality or cost – or all three. In fact, zero-defect software never guarantees that a product is ready or good enough to ship.

That leaves us with the question that’s been asked many times before: when is non-life critical software ready to ship? Is it when a certain date arrives, certain functionality built or some quality metric achieved? None of these criteria can actually result in software that is good enough to deliver. One aspect of an approach promoted by James Bach is to adopt a utilitarian method to deliver good enough software that is based on risk analysis. That is:

* Software is good enough when the potential positive consequences of creating or applying it outweigh the potential negatives
* Structured risk management needs to be applied to weigh the consequences and identify factors that make the risk more or less likely to occur
* Assessment of short and long-term consequences if the risk occurs
* Knowing the difference between important and unimportant, necessary and unnecessary

Many successful software products ship with dozens, if not hundreds or thousands of bugs, including most Windows and Mac product versions. However, it isn’t the number of bugs that matters; it’s the effect of each bug. In other words, knowing the risks of deploying software with known (and unknown) defects allows one to release software that is good enough, even to be the best!

Read the entire digest contents

Aspire launched its “Producteering Breakfast Series” revolving around building great software products, at the SDForum in San Jose, CA this month. The breakfast series drew an enthusiastic response from several ISVs in the Bay Area and elsewhere.

Participants debated the very definition of a “great product”. The majority of them believed that building a flawless and high quality product need not necessarily be the goal of a “great product”. Rather, a product that can meet customer expectations (immediate and in the near future) and one that is better than current products in the market is really a “Great Product”. 

There was also emphasis that product engineers need to have the ability to communicate well with business users and this was defined as a critical element for building a successful product.  There were suggestions on exposing product engineers to sales tradeshows, meeting with end users and having them interact directly with customers as some of the possibilities for getting better business exposure. 
 
Successful products need to be built iteratively with constant market feedback, and implementation of that feedback was one recommendation.  The Google Vs Apple
product development model was also critiqued during this discussion and the consensus among the Producteering breakfast series participants was that Google had a better product delivery model because suggestions are implemented within a 2 week cycle rather than the longer, better version releases in months or years time in case of Apple kind of products.
 
The availability and need for collaborative tools/platform that interfaces with different product development/management systems and the ability to track progress was also discussed briefly.
 
Overall, everybody felt the discussions were very useful and the idea of a Producteering forum exclusively for ISVs was well appreciated. We plan to have more breakfast series in different cities on a periodic basis.