I've been attending sessions at conferences, talking to folks inside and outside of Oracle, piecing together parts of the puzzle, working with Fusion Apps when possible, and flat-out speculating for several years now. And I've got fat notebooks with notes on all of it. After Collab, I went back through those notebooks and started some rough architectural sketching. Guess what? I think I've got a pretty good guess about a conceptual architecture for the apps stack. So I thought I'd share and see what ya'all think.
A few of the typical caveats:
- If you're a member of the press, please know that this is total and utter speculation on my part. No inside scoop, no top-secret tips, notta. If you're going to republish, please note that this is Floyd's speculative architecture: no Oracle stamp of approval or confirmation anywhere.
- If you're a customer, the same warning applies to you as it does to the press. Rely on this at your own risk.
- I've assumed that customers running Fusion Apps will be involved with some kind of a grid. Whether you see it (local premise installation) or not (hosted, SaaS, etc.), you'll run Fusion Apps on a distributed platform of some sort.
- I didn't get it all, especially in regards to the middleware components. I've likely listed a few that aren't there, and I'm sure that I've missed several. But I'll willing to bet at least a nickel or two that I'm in the ballpark.
- If you're from Oracle's legal department, there's no point in suing me if I've actually come up with something really close to the mark - as I've said repeatedly, I've got nothing worth taking. So give me a break, OK?
Again, could be that I've nailed it or it could be that I'm all wet. Maybe all those notes have paid off or maybe I've just wasted my time (well, I'm pretty sure the apps list is correct, but everything else is in play). We won't really know for a bit yet. But I'd like to hear what you think. The comments are waiting for you...
1 comment:
Cool!
My thoughts (based on doing many similar diagrams in the past):
Applications layer--I'm wondering if the level of detail here is enough, is the high level grouping right to ensure completeness. Also, in a few places, there is the question of what is an application, what is a service, what is middleware, e. g. where does DOO fit? where to put MDM and PLM/PDQ? OTM and other (optionally) hosted components?
Does there need to be a service layer, given the architecture of fusion? DOO and MDM probably would sit in that layer, as would Tax/Landed cost
Does there need to be a concept of "Core" (what everyone implements or must implement) vs "optional"
What about bought-in components e. g. Taxware/Vertex, EDI, Payment engines--there is still a need for these for many practical implementations
Middleware--you have a question about BPM, Yes, I would split that out as separate middleware. Also, what about PIPs to link in commonly used fusion optional components and pre-fusion/transitional components? Is there a separate layer for these?
Miles
Post a Comment