Last week, I introduced the ADF development methodology I’m proposing, “Extreme Reusability,” articulated its goals, and discussed the techniques of “Generalize, Push up, and Customize” and “Think Globally, Deploy Locally” that are critical to the methodology. I didn’t, however, describe the actual…well, methodology, meaning the development cycle prescribed by Extreme Reusability.
Notice I didn’t say the application development lifecycle. That’s because developing under Extreme Reusability, like developing under SOA, isn’t primarily about the creation of standalone applications. You should think of the development cycle for extreme reusability as part of an enterprise-wide effort.
Development under Extreme Reusability involves developing along three separate but interacting (and communicating–communication is absolutely vital under this system) tracks: framework development, service development, and application development. These tracks are assigned to different individuals on the team, in (at a guess–remember this is a proposed methodology) somewhere around a 20-60-20 division for a typical organization’s needs.
As promised, I’m posting of the presentation I’d been hoping to give at the OOW Unconference Methodology Symposium last week, expanded slightly for the more forgiving medium of a blog. As it turns out, it’s expanded substantially more than I thought, so I’m going to divide it into two parts. This week, I’ll talk about the basics of the methodology, its goals, and the two techniques it relies heavily upon. Next week, I’ll talk about the actual development process it specifies.
“Extreme Reusability” (the name is not mine, but rather Chris Muir’s; however, I decided I like it) is an idea for an ADF development methodology for mid-sized teams (generally around 4-20 developers) that I’ve been recently expanding on. Continue reading Extreme Reusability, Part I
Ted Farrell announced this morning that there is a release date for the production version of Oracle 11g: October 1st. The realease won’t have *all* the functionality present in the previews–in particular, WebCenter and full SOA support won’t be present; there’ll be another release at some later date that includes this functionality.
Alas, the most exciting thing I’ve seen so far (even more exciting than this) is something I’m not allowed to talk about in detail. However, I don’t think anyone will get too mad at me if I say this: When SOA Suite 11g is released (I don’t know when exactly, and can’t say when even generally), if it looks anything like the current plans, it’s going to be phenomenal. It’s going to seriously mitigate the disadvantages of SOA, and make it a much more attractive option to a much wider range of development teams. I’m not saying that it will mean everyone should rush to SOA–if you’re part of a, say, two-person development team working exclusively on Java EE apps, I’m still unconvinced it will be worth it for you–but mid-size (as opposed to just huge) development teams, even those that don’t have any of the indications for SOA that I list, will be able to (indeed, well-advised to) seriously consider SOA as an architectural option.
More news as I get it.
October 5th, 2008: So, obviously, the October 1st date did not materialize, and we currently have no date for the initial (AKA “Boxer”) release of JDeveloper 11g except for “really soon.” Ah well.
October 7th, 2008: Woohoo!
If you’re going to Oracle OpenWorld (OOW) next week, I’d love to meet you. As of now, I’m going to be at 3 public (as in, I’ll be there in a capacity where I’ll be accessible, not just as an audience member) events: