New Gmail Look

Literally, 10 minutes ago, I walked away from my laptop and had Gmail loaded in my browser. After returning with my hoagie, Gmail had a weird look. All the sudden - Gmail throws a nice box up at the top of my screen that says "Our look has changed, check out the available themes".

Awesome!

Not the themes, per se (although I do like them), but the fact that Google can roll out a major enhancement like this without an explicit and direct communication to all members. Can you picture how much discussion (and scrutiny) this would go through in corporate America?

Not Google, that's the beauty of their products - they roll it, tell you about it and most importantly - give you the ability to go back to the same old if you desire too. Now that's usability...

Oracle SOA Suite Training: Day 5

Security, policies, securing policies with processes and policies. Information overload at this stage, I gotta leave this one up to the Ops guys to handle.

Again, as I mentioned before - NFRs play a big part in this one.

Oracle SOA Suite Training: Day 4

Day 4 – real-world stuff:

* business rules
* human workflow
* integrating java apps

Great agenda – let’s finally get a look at how this technical solution will work for the business world.

Business Rules are a small component of the SOA Suite. I love the concept – create an abstracted layer for business rules so business users can make changes freely through a nice user interface without the need for a code change. Great – great concept!

Unfortunately, the Oracle solution will only get you half of the way there in my opinion. To say the UI is more unfriendly than the rest of their apps is a safe statement. It looks like a product that they acquired years ago and never really invested anything else into it. Binary files behind the scenes, no web services hooks – pretty ugly. However, it does have an API so at least you can put the lipstick on the pig. (See InRule.com for a more friendly BRE)

Human workflow – awesome stuff. Unfortunately we didn’t get very much into this topic because of an all-day lab exercise. I need to continue to explore the interface to approving or completing tasks within the product. I couldn’t tell if the dashboard I was working through in a lab was a free lab add-on or part of the SOA Suite. I was pretty impressed with the technology’s ability to query a directory for escalation paths – that’s neat stuff, especially when you get into the SLA conversation.

Java integration – it’s doable, right in BPEL. Nice stuff, but not my cup of tea…

Oracle SOA Suite Training: Day 3

Day 3 – on to the bulk of ESB and SOA, specifically:

* adapters
* data transformation services
* exception handling

Now we’re on to the bulk of ESB and SOA. I’m thoroughly impressed with JDeveloper at this stage. While the tool has a few quirks and is not the most defect-free of its time – it is a super powerful tool that does some really neat things.

Today we examined a few of the built-in adapters that Oracle provides out of the box with the SOA Suite. I was impressed, there are a quite a few that I can see being used pretty regularly: file, database and copybook were the ones that jumped out at me. Of course they had a vast amount of adapters for the Oracle Applications suite but we didn’t play with them because of the isolated training environment.

We used JDev to build some quick and nesting data transformation which was pretty cool. I could have used that a few months back. We took the input from some flat files and mapped it to inputs in the process which was used to drive decisions further down the process road. Neat stuff…

As far as exception handling goes, we watched more of a lab demonstration vs. talking about why, where and what to do with them. Not much additional on that topic, wasn’t covered all that well.

The ESB product is pretty cool, you can set up notifications for dropped messages, etc. pretty neat stuff. Plus, its integrated with JDev real well, you can build an ESB projects seamlessly in JDev and build/deploy in no time. Great stuff… Now, if I could just test all of this without using Oracle Application Server I’d be a super happy camper.

Oracle SOA Suite Training: Day 2

Day 2 - BPEL 101 [finally, the reason I'm here] We covered:

* developing a simple process,
* orchestrating a few services with BPEL
* creating parallel process activities.

As we walked through a different synchronous vs. asynchronous process and consuming services offered through a PartnerLink, my initial thought was - man, how important NFRs and services agreements are in this "SOA" world.

Picture this scenario - I order a product online which kicks off the "Submit Order" business process (via BPEL). During "Submit Order" the process makes an external synchronous call to a shipping service and waits for the response. However, the shipping provide is having issues and doesn't generate a response.

"Submit Order" is now holding and waiting - yet not submitting.

Do we have an agreement in place with the shipping provider that states they'll respond in less than 1 minute? Do they guarantee a response?

Did we capture the expectations of the fulfillment team during our elicitation sessions? Do they care that it might take 2 days to actually complete "Submit Order" or do they think it's instantaneous?

It seems to me that NFRs have more importance in the SOA and BPEL worlds.

Oracle SOA Suite Training: Day 1

Oracle DC facility is nice; it is in the heart of a tech-centric area called Reston that’s 15 miles west of DC.

Day 1 consisted of SOA overviews and installing the various pieces of the SOA Suite . Nothing real noteworthy on Day 1 except that everything runs on the Oracle Application Services (read: scary).

We did cover top-down WSDL-driven services vs. bottom-up services – cool stuff, same old Interface-driven development but much, much easier with Web Services. Does any actually create an object from scratch now? I doubt it... JDeveloper (as I'm sure most tools do now a days) allow you to right-click and create your entire Java source from the WSDL. Great stuff.

Wonder if WSDL black belts run the world in the future?

Requirements and Design

I have recently found myself on an engagement where the is no clear line between requirements and design. Both activities tend to bleed together which creates a level of requirements complexity and they quickly become unmanageable.

I have read many books on requirements (including my personal favorite which authored by a good friend of mine Daryl Kulak, Use Cases: Requirements in Context) and have been producing them for the better part of a decade now. In most of my reading, authors typically stand firm on the idea that design is a separate activity and should be isolated from the requirements creation process. I have found that most effective practitioners will also agree with this approach.

And, while I tend to agree with this as well, is this a stance that can be taken in all organizations? More importantly, is this approach feasible when working with a COTS package?

So, while requirements generation and documentation is without a doubt an art (vs. a science), how much "creativity" can be embedded in requirements without bleeding into design?

Home Remodeling and Requirements Elicitation

Two relatively different topics, right? Not so much it turns out… Recently, after a long weekend of remodeling our master bedroom, I was reminded how important the requirements gathering process is, even in everyday life.

After my wife and I painted and rearranged our entire bedroom, my wife decided to “de-clutter” the room (I would like to thank HGTV for this new concept). However, in the process, she didn’t ask which items in the room were important for me to have quick and easy access to. So early Monday morning when it came time to leave on a business trip, I couldn’t find my watch, or my passport.

Me: “Honey… where is my watch?”
Wife: “In the nightstand!” (she responded in a frustrated tone)

Nightstand? For my watch? Hmmm… Of course, I thought… (insert sarcasm here)

I quickly figured out that my wife made a mistake that IT team have traditionally made. She assumed that she could hide all of my personal belonging in the effort of de-cluttering our room. However, she never asked which of the items were important to me to have easy access to. So was this an ill-willed effort to make my life more complicated? Of course not – she just simply never gathered requirements from me (the end user).

So, before you attempt to bury that application functionality deep in a menu to make the screen look cleaner, make sure you talk to the folks that are using the system to see which functionality they need quick and easy access to.

And honey - the room looks great...