Brownian Code

Icon

Just another WordPress.com site

CRM Underway

At the company I am currently contracted to, we have finally kicked off the CRM project.  CRM is generally identified with sales automation and order entry, a la salesforce.com.  But the acronym CRM stands for customer relationship management.  So, CRM is really quite a broad concept.  How many types of relationships does a customer have with an organization.  When an organization does nothing more than sell widgets, then having sales info, shipping info, and order status everything is great.  But what if you provide widgets and services.  Do you know the service status of your customer?  More than that do you know the business process for the service you are providing to your customer?  How do you express to your service clients the value of the services that you provide to them?

This is the situation and the questions that I find with the current customer.  This is  a large company with more that 10 billion in sales yet they manage sales contacts with spread sheets.  This may seem incredible, but the company has a very “just get it done” attitude and most everyone is just getting it done.  The company maintains a large portfolio of products so order placement and tracking is important but this company distinguishes themselves in their marketplace by providing product related services and analysis.  Contacting a potential customer is the first step in a long and involved relationship with a customer.

So, in implementing a CRM system, we want the flexibility to address the range of relationship needs from lead tracking to product performance on behalf of the customer.  I call this the continuum of CRM.  At each point on the continuum there is another axis of depth, or how effective is the tool that is employed.  How good is the lead tracking or customer analysis.  As the system is implemented, we want to smooth out the relationship continuum and deepen the effectiveness of the tool.  We want movement along these axes to be incremental and regular, so we will use agile techniques along with a base system that provides a modular structure.

This project will be implemented with Apache’s Open for Business for a couple of reasons.  The first, and most important, is that OfBiz is already in place for inventory, billing, party management, etc.  The second is that OpenTaps, which is an offshoot of OfBiz, has a CRM module that we can merge back into the OfBiz implementation.  This project should be quite illustrative of what can be accomplished merging powerful open source tools with a major enterprise.

Filed under: Uncategorized

Turtles, All the Way Down

For those who don’t know the story of “the turtles,” it is well worth reading the wikipedia entry (http://en.wikipedia.org/wiki/Turtles_all_the_way_down).  In general, the problem is one of infinite regression.  To recap, here is a quote from Stephen Hawking: A well-known scientist (some say it was Bertrand Russell) once gave a public lecture on astronomy. He described how the earth orbits around the sun and how the sun, in turn, orbits around the center of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: “What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise.” The scientist gave a superior smile before replying, “What is the tortoise standing on?” “You’re very clever, young man, very clever”, said the old lady. “But it’s turtles all the way down!”

The meta-physics of infinite regression aside, there are many practical situations in and around programming that feel like a stack of turtles.  Three stupefying examples come to mind from my work history.  The first was a project at MCI (if I stopped there, it would be a punch line) in the mid-nineties where they were moving to a new client-server based billing system.  The lead contractor was selling MCI on the idea of an object oriented database, which was a holy-grail of the day.  The problem then, which had yet to be addressed by great products like Hibernate today, was how to do the object-relational mapping for the system.

Experimental development was proceeding with the database for performance and understanding.  Meanwhile, others were using sample datasets to develop reports.  All in all it was chaos.  When we talked to the chief architect from the lead contractor about these issues he always wanted to talk about the object model.  When we said,”yeah, we get that, but how are we going to store this stuff?” the answer was “that’s just an implementation detail.”  Read: there is a turtle holding all of this stuff up, so don’t talk to me about celestial mechanics.  It is truly amazing how intelligent and educated people can rest their everyday assumptions on the back of a turtle.

The most important point to realize is that we all use turtles in some part of our lives.  It is the nature of being human.  We don’t like gaps, and when we find them we fill them with often poorly thought through assumptions.  We generally spend more time questioning the assumptions of others than our own, yet we can actually evaluate and control our own assumptions.  When was the last time you questioned your own assumptions, when was the last time you discovered, on your own, that you were wrong?  Challenging your assumptions is for you mind what challenging your body is for your health.

Filed under: Uncategorized

OSGi and Modular Development

In the Java world OSGi is gaining popularity steam and will surely be coming to an enterprise near you if it hasn’t already.  OSGi originally stood for Open Source Gateway Initiative and refers to a service specification that provides a dynamic component model.  The best known OSGi application is undoubtedly Eclipse.  Eclipse is the well known Java IDE built upon the Equinox OSGi framework.  The great thing about OSGi is it’s support for dynamically loadable modules with the ability to enforce strict interfaces.  This leads to flexible and modular development.  Is this the way towards programming Nirvana?

First, it’s important to remember Croft’s First Law of Development:  good tools never overcome bad programming.  Given that, it is always a waste of time to talk about the things that can go wrong with a technology because it is always possible for things to go wrong; the focus should be on what can be done to help things go right.  From this perspective, OSGi can be very helpful.  The ability to break a system into dynamically loadable, but developmentally isolated modules should not be under valued.  So let’s look at these two qualities independently and define more carefully what is meant by each.

By developmentally isolated, I mean that ongoing development for one part of the application is not compile time bound to development of another part of the system.  Normally, programmers view libraries like this.  There is a library to use say log4j and you plug it in and go.  You generally don’t worry about the ongoing development of the library interfering with your own development.  In the form of a library, you have a distinct package and a well defined, and hopefully well documented, API.  If the library development continues, it is not a problem for you to continue your development because you have your package and it works.  You continue on your merry way.   Later if you decide to upgrade the library, it’s generally not a big deal.  Increment changes tend to be backward compatible and the defined API’s make for easier testing and integration.  We all know this, so let’s move on to dynamically loadable.

By dynamically loadable, I mean that a module of code can be dynamically replaced at runtime.  Being able to select a given block of code for replacement without having to recompile and cycle a whole system has to be a good thing.  To be sure, there are issues with testing to confront when replacing any part of  a production system, but knowing the exact dependency graph and being able to analyze the behavior of one node in the graph has got to be a step in the right direction.  Ideally, you have test coverage to support thorough testing of  a module in isolation, and then you could pop one module out and put one back in at any time.  Hot fixes become simpler, life becomes better.  Over the next series of articles we will explore the benefits of the OSGi development model.

Filed under: Uncategorized

Life During Wartime, or Coding in the War Room

There are many good aspects to agile development, but I am not sure that writing code in a war room is one of them.  The advantages of the war room environment are supposed to be that people are there, together, to collaborate, to fix problems on the spot, and generally to feel productive.  It is supposed to build the team and make everyone feel entrepreneurial.  But entrepreneurial should really mean: cramped in a room that is too small, too loud, and too hot.  Rooms that are 150 square feet are not designed to have 15 people with associated office equipment in them.  Having spent time in some, I can’t say that it is all it’s cracked up to be.

So why do people do it?    This is a common mistake made in many areas of life and management:  some idea seems to work, but for natural reasons the failure of the idea isn’t seen.  Let’s expand on that with a related example.  Suppose you have a startup without much money or resources.  So they rent a very small room some place and pile in, maybe three or four people initially.  They are all together batting around ideas, they are excited just to have their own office, and they get a lot accomplished.  They grow, they bring in 3 or 4 more people and are really cramped, but even more importantly they are cash flow positive and everyone is really excited.  Soon it’s time to hire again, and now they have to move.

Now, let’s consider a similar situation:  suppose you have a startup without much money or resources.  So they rent a very small room some place and pile in, maybe three or four people initially.  They are all together batting around ideas, they are excited just to have their own office, and they get nothing done.  Their ideas don’t gel, one guy eats with his mouth open, two guys think a third is too autocratic.  A fourth thinks they are all idiots.  In truth they all have some ideas they everyone would respect, but sharing ideas is dropping off because there is already enough tension and everyone has to work together.  Nevertheless, they manage to put an OK concept together, sell it to a company, and get some money in.  They get two more people in to help with the big project.  Stress is higher now that there is money to manage.  A couple of heated arguments take place, people skip coming in because the environment is impossible, the project fails and the business goes away.

It’s important when managing to distinguish effective tactics from random results.  War rooming is given credibility because people talk positively about the successes and don’t mention the failures.  Given business failure rates, it has to be likely that war rooms fail more often than they succeed.  What is far more import with teams is a common vision, belief in the goals, and trust.  All of these things can create cohesiveness, which, when coupled with proximity, is very likely to result in productivity and success.  But proximity alone will not create cohesiveness and can exacerbate tensions.  The next time a project starts, if you have vision, goals, and trust, the rest will take care of itself.

Filed under: Uncategorized

Pages

Archives

Follow

Get every new post delivered to your Inbox.