One of the areas which has been fuzziest to me in Emergic has been about how we should be creating enterprise software (ESW) components. So far, I had been thinking of building a eBusiness suite integrating ERP, CRM and SCM. Easier said than done! Of course, our approach would be to look at a minimal feature-set which could get us started as we target SMEs. But even there, where do we begin? How will we handle the challenges of customisation that will inevitably come? My solution to that was to build only the components which would do 60-70% of the work, with independent software vendors doing the rest. Basically, build the Lego blocks which make assembly of low-cost enterprise software applications easy.
All this sounded neat in theory. But, implementing would it would be a huge task. Especially, for us, with no experience in the enterprise software space. So, the thinking continued. What should we be looking to do? I did not want to not do anything. When we go to SMEs, we need to go with a whole solution (or at least promise availability in a few months). Server-based Computing (Thin Client-Thick Server) would be the first step which would allow them to build their enterprise IT infrastructure, and have a computer on every desktop. The Digital Dashboard would be the second step, which creates an enterprise knowledge management system based on whats there is peoples heads and not whats sitting in files and databases. The third step had to be with the core business applications.
I have now come up with a different line of thinking on how to tackle this issue. Instead of focusing first at the core, let us look at the edges (the periphery) of business: the interactions between enterprises. In other words, instead of focusing on EAI (Enterprise Application Integration), let us look at B2BAI (Business-to-Business Application Integration).
In EAI, one has to look at legacy data already existing in companies. It would have meant us worrying about their existing applications (if any) and the data that they already had. It would have also meant customising or building adapters for data transformation. We would get into the heart of the company without too many resources. Besides, much of what is done within is very specific to the enterprises.
In B2BAI, the focus shifts from transaction processing to document processing. Businesses are exchanging information between themselves product information, financial information, order details, shipping details, etc. Information is the primary flow. Even for the actual product and money flow, it is the information about them that matters. This is where the last few years have seen the emergence of standards in the form of ebXML, RosettaNet and BizTalk. While Microsofts BizTalk has focused more on information flows, RosettaNet has actually mapped out processes through its PIPs (Partner Interface Processes). RosettaNet provides the model, specifications, format and validation for various processes between enterprises. (There are, perhaps, strengths and weaknesses for each of the standards. This is what we need to take a closer look at: what is good at doing which part best. Can we do value-added aggregation across them?)
So, our focus initially should be building the interfaces between businesses, based on the standards that exist. This is the area where SMEs would be interested in seeing how they can communicate electronically with other SMEs or with their bigger partners. Of course, in the latter case, the partners would set the communication mechanism, but the push is going to be towards standards. Our approach should be to use standards to leapfrog the proprietary communication mechanisms. (Think back to how Oracle used SQL to its advantage in the mid-1970s.)
So, we need to codify various business processes using the process and information exchange standards which are coming into place. What we also should look at doing is seeing how we can build an SME Exchange connecting various SMEs together. This is a good starting point as SMEs do a lot of procurement from each other also. Standardising this using the XML base and Web Services is what is needed.
Another related idea is to target SMEs through the industry associations that they belong to. One idea here is to create a Slashdot-like community weblog ASP. This would allow SMEs to come together and share best practices and learnings. It is also a low-cost way of reaching out to SME Clusters. It has the potential to spread like an epidemic, as SMEs see the benefits of belonging to online community networks. Creating self-organising networks of SMEs can only be done online; if we can play an enabling role here, it would solve one of the biggest problems we face reaching out to SME. .
Over time, this edge strategy gives us the network of SMEs to then start building the Lego blocks for use within the enterprise. Sometimes, it is better, especially for newcomers, to chip away at the edges, than attack the core.
Again, this is the theory. But, I feel that this seems a much better approach than the earlier one which I had been thinking of. Theres a lot more to think through, which I am hoping to now do this month. At least, I now feel the problem is solvable. One small step forward.