Vendor managers in companies with Oracle applications may have heard a lot of talk about its next-generation applications over the last five years. Well, the news from Oracle’s customer event in San Francisco is that Fusion is almost here. Oracle is extensively demonstrating the product here at the event, early adopter customers are already in the implementation process, and Oracle intends to generally release it in the first quarter of next year.
Oracle hasn’t announced final pricing yet, but Steve Miranda, SVP of Oracle Application Development, confirmed that customers on maintenance will get a 1:1 exchange when they swap the product they own now for the Fusion equivalent. That is good news, although to be fair, my Oracle contacts had indicated this, off the record, all along.
The packaging into SKUs will mimic that of the current product set, to make the swap easier. I.e., the price list for HR will look like the PeopleSoft price list, CRM like Siebel, and so on. That makes some sense, but I wish Oracle had taken the opportunity to simplify the pricing so that there are fewer SKUs. For instance, Siebel's price list is over 20 pages long, and there's no clear link between the the items in the price list and the functionality you want to use. As a result, some customers buy modules by mistake, while others fail to buy ones they really need. Hopefully Fusion will provide a clearer audit trail between functionality and SKU.
As someone who has worked in development teams, I take it for granted that not everyone on the team has the same needs and interests. A twenty-something Java developer, fresh out of college, is interested in questions like, "Which emerging framework might be worth learning?" The architect on the team may be interested in the same frameworks, but for entirely different reasons. Unlike the rank-and-file developer, the architect has decision-making power over which framework to adopt. The architect bears responsibility for the long-term consequences of this decision, while the rank-and-file developer is primarily concerned about delivering components written for whatever framework the team selects. Meanwhile, the development manager has to oversee the work of both the developer and architect, ensuring that, collectively, the developers and architects and testers and everyone else deliver their work product on time, at an acceptable level of quality.
Different roles, different questions -- not a hard principle to understand. When applied to developer support, it means that developer conferences, discussion forums, and other resources must tailor their content to a specific audience. Not surprisingly, the material interesting to developers might not be as interesting for architects, and vice-versa. (And if you're still not convinced that the two roles have different needs, take a look at the chart in this earlier blog post, which shows the sources of information and advice to which developers and architects turn.)