SAP’s technical strategy
I just posted an extensive discussion of SAP’s technical strategy over on the DBMS2 blog. Key takeaways include:
1. SAP is serious about SOAs and, in most regards, openness.
2. SAP’s strategy does not gladden the hearts of top-tier DBMS vendors.
I also dinged them for being clueless about how to succeed in text search, but hey — nobody’s perfect, and there’s still time for them to fix the problem.
One interesting aspect of their strategy that did not fit into the above-mentioned server-oriented post is their take on UI. They said again and again and again that it is important to provide a high degree of UI freedom in accessing the same underlying application services. (Except that they usually referred to the services as — no surprise here — “business processes.”) This is a reversal from their prior belief that a transactional screen — or a portal page — was sufficient for everybody.
In general, the enterprise software industry is getting a lot more sophisticated about and competitive in it’s work on UI. I should post about that soon. (The point has come up repeatedly in my work on BI, with SAP, Business Objects, and others.)
Comments
2 Responses to “SAP’s technical strategy”
Leave a Reply
[…] So once the objects are found – then what? Well, if you find a person or invoice or whatever, there are only so many application functions that can be performed on them. Thus, SAP aspires to present these functions to you. (Analogy: The SAP/Microsoft Duet product line.) Which ones will be presented first – i.e., which will be the most “relevant results?” Uh, that’s not so clear. There are a range of possibilities, ranging from hard-coding* to a simple voting mechanism based on earlier users’ choices in similar situations. Fortunately, SAP doesn’t have to find the single best fit; with good portal technology, it’s realistic to present a number of top functionality choices more or less at once. This fits in well with the flexible access to business objects that SAP has been talking about for quite some time. […]
[…] My two-part take on SAP’s excellent architectural vision. (December, 2005) […]