Evaluating analytic appliances

With the amount of data in the world increasing asymmetrically if not hyperbolically, the market for big, purpose-built machines for high-speed data analytics is now being contested by some major players.

The first company to bring out an analytical appliance (hardware and software, highly tuned and bundled together to provide something that will run out the box ) back in the 1990s was Teradata, and they had the market for such appliances for a number of years. Later came Netezza, now part of IBM. But neither of these seem to have generated the amount of press that two recent entries have done – SAP with HANA, and Oracle with Exadata.

It was during the mid-1990s when I worked in Silicon Valley with Redbrick, the data warehouse product and company started by Ralph Kimball, that I first experienced the database competition ‘war’ – then it was mainly against Oracle and Informix.

So I was interested to read a comparison of HANA and Exadata, and I see that the the same competitive arguments are still much the same as they were 15 years ago; the claims and counter-claims sound strangely familiar as well.

As I see it, the challenge of anyone trying to evaluate an appliance is to cut through the hot air and hype generated by SAP and Oracle and find the real information they need to make a selection. So the article about HANA and Exadata should help to clear up some points.

Not every company is going to go for an analytic appliance, certainly not the average mid-size company that I am mostly familiar with. The price tags of HANA and Exadata are in the millions, and require a level of IT sophistication and support that only very large organisations, and governments, can achieve.

I think it would be interesting to see a comparison of the appliances from the four vendors I mentioned, not just two. If anyone has seen it, please let me know

BI’s continuing problems

I recently attended a Microsoft seminar on BI (business intelligence) and who should I meet there but a former colleague, who worked with me in the field of what was then called decision support (in the days before the term BI was coined by Howard Dresner).

The first interesting point made was that, over 20 years since I started in BI, one of the continuing challenges is that the ability to access data is limited. That may be explained by the next point. An interesting diagram was shown during the session which highlighted some of the issues facing BI (I have adapted it here):

My era was very much that of Traditional IT, whose prime concern was control. Data was extracted from the source (usually operational systems), massaged and finally provided in a different form to the user. This ensured that the data came from the right sources, followed the approved definitions, and used the right formulas. If you follow this approach, access to data is going to be limited.

The problem with the traditional approach is that it creates other challenges, which again were issues we faced 20 years ago, namely:

• IT expends a lot of effort in providing information that is often used by one person, once;
• information requirements change too fast for the technology and approach to keep up.

The solution from the Microsoft perspective is to encourage self-service BI, with the emphasis on agility. It helps to understand that Microsoft advocate their PowerPivot product as the route to enable self-service BI. One unquestionable fact is that the goal of the universal BI front-end tool has been reached – and that tool is Microsoft Excel.

The problem with self-service BI is that the issue of proper understanding of the source data is not managed. It actually gets us back to the days of fourth-generation languages, such as SAS and FOCUS, when users with some technical understanding could pull data from mainframe databases without asking for the help of a programmer. This led to situations in which two people could produce information in a meeting, using the same source, but with differing results. That created the demand for a ‘single source of the truth’, something which the data warehouse was supposed to address, which brought the control of data back into the realm of IT.

So it seems that BI’s problems continue today in much the same way as they have done in the past. How can we solve these ongoing problems? If you have a suggestion, please let me know.

Notes from the UK version of the BI seminar can be found here.

Cross-context product marketing

One of my roles in product marketing is to generate product-based messaging to highlight the value proposition of our enterprise software, and to enable sales to position, articulate and sell the product. In doing so, something that has become clearer to me over the last few months, as I have absorbed experiences from a number of product announcements and launches, is how differently English-language speakers and readers use the language. (Note: this article is limited to English, I don’t have experience in translating).

In my previous roles in enterprise software marketing and sales, I was the person at the end of chain, delivering the message. Most of that time I was working for US-based companies, and there were many occasions when I was frustrated by the lack of understanding by corporate marketing of how things worked where I was. Now, I am at the other end, near the start of the chain, which means that I have to be aware of global implications of what we produce.

To understand how to approach cross-cultural communication, the concept of “high and low context” can be helpful (I am indebted to my brother-in-law for telling me about it; he has had to deal with the issuing working in mines around the world). “High context” societies don’t require verbally explicit communication, and have a more internalised understanding of the message. “Low context” societies require everything to be spelt out explicitly in the communication, there is very little implicit understanding. The other side of high and low context is that people tend to mistrust or look down on those in a different context society.

I have struggled to find sources about high and low context in a product marketing situation. There are a number of good sites – Hutch Carpenter’s , also here and here – but none seem to have discussed the issue any time recently.

What I have learnt is that messaging works best if we send draft material to various people in offices around the world for their comments before we finalise our collateral. By the way, I never saw this happen at either JD Edwards or Microsoft Dynamics – I they have a similar process I was not aware of it.

If you have had experience developing product collateral for high and low context societies, I would be interested in your comments.

Implementing ERP more effectively

Part 2 of a series on enterprise information systems

Building a house on a solid foundation

This blog has been cross-posted on the SYSPRO corporate blog.

You can hardly miss it these days: questions about why Enterprise Resource Planning (ERP) projects hit problems, or worse fail, are appearing on many websites. I have seen many ERP implementations and thought I had some answers, but it was only after I had been involved in building a house that I could see the similarities between building projects and ERP implementations, and why we don’t see buildings collapsing in the same ways some ERP projects fail.

Eric Kimberling’s Panorama Group identified this similarity at the same time I was building the house. The critical requirement for construction is the blueprint; the drawings of what the house will look like, what its parts will be and how it will be constructed.

The problem with projects, especially complex ones (like a house or an ERP project), is how to communicate the varied components, interactions, hierarchies and responsibilities to all parties concerned. You need a representation that will capture all these elements in a way that is clear and easy to understand, even if you are not a professional in the field. This will ensure that the various parties involved can achieve alignment in terms of common understanding of business needs and technology capabilities.

You also need a way for the plans to develop as your ideas and perspectives evolve. When you start planning a house you don’t go straight into the details. You may have some thoughts (even a vision), but you need guidance from an architect on what is possible, feasible and within budget. So you start with drawings that help you decide on the appearance of the house, then move into the technical and architectural details, and finally the construction and engineering specifications.

Until recently there was no easy way for ‘ERP novices’ to see the business in terms of how it would look after an ERP implementation. But now, with the integration of business process modeling (BPM) and ERP, those visual representations (the drawings) can be done. For an ERP implementation, the functional requirements and business processes are like the rooms and materials of a house, and a business process model is the equivalent of an architect’s drawings. The Business Process Modeling tool can be used in the same way that you start a house with some initial sketches. It allows you to view the business from a high level to make sure executives agree with the ‘look’ before going into more detail.

This graphical way of representing an ERP project can replace the mountains of design documents that were the staple of past ERP projects. This pile of paper used to be the main documentation a business had to describe its strategy, plans and processes. The sad fact was that only a few people ever probably read them, and even fewer understood them.

It’s about time that “the big freakin’ requirements document must die”. What is needed is one tool which can capture scope at different levels in one place, which provides traceability between business requirements and IT capabilities, and which uses better means of communication to illustrate than the common legal-style text of many project documents.

If you are an ERP implementer, how did you experience communicating via traditional project management tools? If you’ve experienced an ERP project as a business user in the past, what did you think of the project documents that you had to use?

At SYSPRO, we now provide a tool that can replace the big project document, which is graphical and shows how integrated BPM and ERP functions: SYSPRO Process Modeling (SPM). Analyst Brian Sommer described the combination as “A Key Mid-Market Need”. With SPM we believe that our customers will get more value, and have a far lower risk of problems in their ERP implementation projects.

In the next part of this series: changing the system as business realities change.

Best API for web services?

If you are programming for web services, which API do you use – SOAP or REST? According to some stats, REST is becoming far more popular than SOAP.

The question however seems to be whether these stats have taken into account all the enterprise apps that still use SOAP.

There is a good comparison of the two APIs here.

Does anyone remember previous discussions along the seem theme over the the years: is X dead, where X =

• COBOL
• Java
• … add more languages here