Like many others, I went to the July meeting of the SDForum Business Intelligence SIG expecting to hear about Salesforce.com and its new AppExchange. In practice we heard about a lot more. The speaker, Darren Cunningham, had just left Salesforce.com and joined LucidEra, a new start up that specializes in Business Intelligence as Software as a Service (SaaS). Darren also brought along Ken Rudin, the CEO of LucidEra who had some interesting things of his own to say. There are several write ups of the meeting on the web that capture the big picture. I want to note a couple of the smaller moments from the meeting.
Firstly, both Ken and Darren described building your own business intelligence system as being similar to a business building and running its own Nuclear Reactor. What they mean is that while a full blown data warehouse can be very powerful, it also requires a lot of maintenance and attention to detail to keep it running. In practice many businesses do not have the resources and energy to keep their business intelligence system running in the kind of peak condition that is required to get value from it.
Secondly, someone asked about LucidEra's pricing and business model. Darren explained that they are taking the same approach as Salesforce.com. That is, start with an offering for small and medium businesses and then build up to the larger businesses. After 8 years in business Salesforce.com is just now starting to sign up large businesses like major brokerage houses.
Ken had some interesting things to say about pricing. Unlike sales, a typical business has a few business analysts who would be the major users of their system, so pricing on a per seat model is difficult. Also they do not want a tax on reports, so the pricing model should allow a business to run as many reports as they want. Therefore LudcidEra uses a flat rate per application per customer. Currently they are using a single flat rate of $2900 for their starter application.
In my opinion, a flat rate encourages the customer to use as much of the service as they can which is a good thing, however it is optimal for a particular size of business. Smaller customers are shut out by a cost that is too high for them. Large customers could overwhelm the service without fully covering their costs. One way to expand the model is to provide tiered pricing based on the size of the customer. Tiers could be based on either customer total revenue or number of employees.
At the moment LucidEra is just starting to build their portfolio of customers and applications. They will have to suffer growing pains before their pricing model is put to its full test.
Monday, July 23, 2007
Wednesday, July 04, 2007
Design Patterns in Python
Alex Martelli is a leading light of the Python programming language community. He is a leader in the development of the language, author of Python in a Nutshell and has written extensively on Python in other books and articles. Last week he spoke to the SDForum Software Architecture and Modeling SIG on "Design Patterns in Python". Alex has posted the presentation slides here.
Design patterns are a useful concept in programming. A programming language consists of a set of basic constructs that are used in various ways to build a program. Design patterns capture higher level constructs that commonly appear in programs. As Alex explained, an important part of each design pattern is its name. Having a good and well known name for each pattern makes it easy to explain a program and discuss how it works at a higher level than the programming language constructs.
Although design patterns are supposed to be programming language agnostic, many of the books on design patterns are based on statically typed languages such as C++ and Java. There are some classic design patterns that do not translate well into dynamically types languages like Python. One example is the Singleton design pattern. This uses strong typing to ensures that there can be only one instance of a particular type of object.
Python is a dynamically typed language, and in these languages the type system is used to make sure that the right thing happens at run time rather than to do any enforcement. The consequence is that you cannot really do a singleton in Python or any other dynamically typed language. If I were in the dynamic language camp, I would argue that if you only want one instance of an object, make sure that you only create one instance of the object. This is clearly in the spirit of dynamic typing.
However Alex is clearly concerned by the absence of these design patterns from Python. First he claimed that these design patterns do not exist in Python because it is a higher level language and that the design patterns are somehow subsumed by the language system. Then he went on to show us his Python answer to the singleton design pattern, which he called the Borg. In the Borg, all instances of the class share the same state, and so they all appear to be the same instance.
While the Borg pattern works in Python, I do not see it a either necessary or interesting. Alex told us, Guido van Rossum, the father of Python, does not like it either.
Design patterns are a useful concept in programming. A programming language consists of a set of basic constructs that are used in various ways to build a program. Design patterns capture higher level constructs that commonly appear in programs. As Alex explained, an important part of each design pattern is its name. Having a good and well known name for each pattern makes it easy to explain a program and discuss how it works at a higher level than the programming language constructs.
Although design patterns are supposed to be programming language agnostic, many of the books on design patterns are based on statically typed languages such as C++ and Java. There are some classic design patterns that do not translate well into dynamically types languages like Python. One example is the Singleton design pattern. This uses strong typing to ensures that there can be only one instance of a particular type of object.
Python is a dynamically typed language, and in these languages the type system is used to make sure that the right thing happens at run time rather than to do any enforcement. The consequence is that you cannot really do a singleton in Python or any other dynamically typed language. If I were in the dynamic language camp, I would argue that if you only want one instance of an object, make sure that you only create one instance of the object. This is clearly in the spirit of dynamic typing.
However Alex is clearly concerned by the absence of these design patterns from Python. First he claimed that these design patterns do not exist in Python because it is a higher level language and that the design patterns are somehow subsumed by the language system. Then he went on to show us his Python answer to the singleton design pattern, which he called the Borg. In the Borg, all instances of the class share the same state, and so they all appear to be the same instance.
While the Borg pattern works in Python, I do not see it a either necessary or interesting. Alex told us, Guido van Rossum, the father of Python, does not like it either.
Subscribe to:
Posts (Atom)
