One of the things that most intrigued me was how their methodology compared to what I came up with for Extreme Reusability. It’s not the same, and for good reason–Extreme Reusability is aimed at much smaller teams (5-20 developers) and doesn’t use true SOA, whereas the Oracle Applications team is gigantic and does use SOA. But the goals, and some of the techniques it uses to accomplish them, are really very similar. And in general, Duncan’s methodology strikes me as a great methodology for large (say, 50+) teams of developers, which is a level that Extreme Reusability really can’t handle.
Oracle Fusion Applications uses a custom framework extension of ADF, the Oracle Applications Framework (OAF), plus custom components, templates, and skins that are used enterprise wide. They have teams devoted to each of these. In Extreme Reusability, I bundled all of these things together in one track, the Framework development track, because mid-sized teams don’t generally have the resources to divide up their teams so finely. But Duncan and I agree on the big advantages of pulling out framework work into (at least one) separate team: It maximizes reuse of code and components, and it limits the need for Java programming to a small subset of the overall team. As Duncan said, most Fusion Application developers write very little Java, and many of them don’t even know the language! The vast majority of Java coding (beyond what ADF provides out-of-the-box) is handled in the framework, and the rest is largely written by “SWAT teams,” roving bands of expert developers that help when individual application teams run into trouble (the “SWAT team” is the last port-of-call for issues before they’re passed to the ADF product managers).
Duncan’s SWAT teams (and, in fact, the teams for individual applications) are actually divided into three subgroups: business service developers, UI developers, and SOA integration experts. A much smaller team (like the 5-20 developer teams Extreme Reusability is targeted towards) probably can’t afford even one SWAT team, but members of the Framework development team can moonlight as troubleshooters, ready to swoop in and handle specific issues the rest of the team can’t, as they arise.
In addition, the Fusion Applications team is very serious about the creation and reuse of what I call “reusable applications,” bounded task flows and associated components that can be developed separately and reused from application to application. Unlike in Extreme Reusability (where this isn’t feasible due to smaller team size), there are specialized teams developing the business services and UI (plus a separate SOA orchestration team) for each application, but Oracle implements a specific policy (Duncan didn’t go into the details) for reuse and uptake of task flows between application teams as well.
One thing that I didn’t cover as well as I’d like in Extreme Reusability (although I do a slightly better job in the revised version, which I will post soon, than I did in the original) was release management. Oracle Applications does have an established methodology for this–a team, built of members of other teams (with each product team contributing at least one member), which coordinates builds and releases, manages policies for task flow reuse, keeps track of inter-team schedule dependencies, and so on. Again, this is something that doesn’t directly translate well to a merely mid-sized application development team, but even if you don’t have enough developers to justify a special team for this sort of thing, at the least, you should have regular meetings at which representatives of the various tracks can discuss dependencies and release management.
Another aspect of Duncan’s talk wasn’t directly tied to reusability, but rather to the creation of UI prototypes. On the Oracle Applications team, the usability experts and designers who put together the prototypes of pages don’t use Dreamweaver or another typical design tools; they use JDeveloper, making ADF Faces pages that run against placeholder data controls, which hold static, prototype-appropriate data. I have to admit I’m a little skeptical of this one as a general policy–making functional ADF Faces RC pages and fragments, even ones not bound to real data, isn’t entirely trivial, and it’s going to introduce an additional learning curve for your designers (and one that some designers, who may have primarily artistic backgrounds, won’t be thrilled about). But Duncan was right that it has one big advantage–by becoming familiar with the capabilities of ADF Faces RC, your designers will gain an understanding of what’s easy, what’s difficult, and what’s completely infeasible for you to do in the final application.
Duncan also mentioned a good resource, which I recommend checking out. It’s Oracle’s (still modest, but useful) collection of functional patterns for ADF/Fusion development. I think there’s a lot more to be said about ADF design patterns, and I don’t even agree 100% that all of these patterns are always the very best way to do the things they describe (the Enable/Disable a UI Component pattern, for example, uses PPR, but I think that many–perhaps most–cases of this can ideally be done without even a partial server roundtrip), but they’re a good starter set. Duncan also pointed out that most organizations will find that they have particular tasks that come up again and again (either in ways that aren’t solvable by code reuse and configuration, or ways where the configuration itself is fairly complicated) for which they can establish and document their own in-house design patterns, and this strikes me as an excellent idea.