I was very, very surprised to find that CIO.com, the flagship website for "Business Technology Leadership" (that's from their site), didn't automatically detect my iPod Touch and re-skin accordingly. Now, CNN, ESPN and most other "mainstream" sites do this automatically so I don't have to be inconvenienced with constant strolling, but not CIO.
Reread their tagline - it's interesting (and ironic).
Monday, January 19, 2009
Tuesday, January 13, 2009
Great Analysts Do Solution
“Just tell us what you want and we’ll tell you how” - the old adage of “what” vs. “how” in the IT mantra.
Today I was reminded that effective (great) solution analysts do both.
[I think the architects just threw something at my head from down the hall]
Let me clarify a bit…
I don’t think that solutions analysts need to know the extreme interworkings of a solution but they had better understand the conceptual aspect of the solution, and, most importantly, know what it can and cannot do. You must be cognizant!
Take for example a custom-development system vs. one that is available off the shelf (SaaS more specifically). When eliciting requirements it is critically important not to lead stakeholders down a path that will be impossible to fulfill with the defined solution. (read: you’re solutioning with the team) So, if the winner ends up being a pre-built package then it’s important to know the boundaries as you’re dance with the stakeholders. Otherwise, there’s a solid chance that you’ll never be able to fulfill requirements that you pulled out of the stakeholders.
[I think the PM just threw something at me – we wasted time and irritated the stakeholders because we’ll never be able to deliver this functionality]
So, in summary, understand the capabilities and constraints of a solution early in the game – even in the requirements phase.
Today I was reminded that effective (great) solution analysts do both.
[I think the architects just threw something at my head from down the hall]
Let me clarify a bit…
I don’t think that solutions analysts need to know the extreme interworkings of a solution but they had better understand the conceptual aspect of the solution, and, most importantly, know what it can and cannot do. You must be cognizant!
Take for example a custom-development system vs. one that is available off the shelf (SaaS more specifically). When eliciting requirements it is critically important not to lead stakeholders down a path that will be impossible to fulfill with the defined solution. (read: you’re solutioning with the team) So, if the winner ends up being a pre-built package then it’s important to know the boundaries as you’re dance with the stakeholders. Otherwise, there’s a solid chance that you’ll never be able to fulfill requirements that you pulled out of the stakeholders.
[I think the PM just threw something at me – we wasted time and irritated the stakeholders because we’ll never be able to deliver this functionality]
So, in summary, understand the capabilities and constraints of a solution early in the game – even in the requirements phase.
Thursday, November 20, 2008
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...
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...
Friday, November 7, 2008
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.
Again, as I mentioned before - NFRs play a big part in this one.
Thursday, November 6, 2008
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…
* 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…
Wednesday, November 5, 2008
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.
* 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.
Tuesday, November 4, 2008
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.
* 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.
Subscribe to:
Posts (Atom)