Making Sense of SOA Blog : SOA Quality

Short and sweet -- one place to find a majority of our web information on SOA

kellyemo — Wed, 19 Aug 2009 20:21:00 GMT

I'm pleased to introduce our new SOA Resource Library on www.hp.com. This is not a fancy web page with embedded graphics, amazing diagrams, post-modern navigation, it's just a simple list. But that said, it's a one-stop shopping list of links to the latest white papers, videos, demos, podcasts and the like on HP and SOA. Yes, you can find these assets elsewhere, scattered through our products and solutions pages, but I find it helpful to know if I'm not sure where to look, I just go the resource library and find it in the master list.

Keep this page bookmarked as we plan to update it frequently with our latest SOA content

http://tinyurl.com/nutfbn

Remember SOA is a journey... and any journey requires commitment, dedication and the occasional navigational checks and adjustments to stay on the desired path...where are you on your SOA Journey?

A Toast to Service Virtualization

kellyemo — Mon, 17 Aug 2009 22:37:00 GMT

"So a performance tester and a functional tester walk into a bar and the bartender says... why the long schedule?"

So you want to build out composite applications, deliver against business requests by assembling sets of pre-built services rather than build from scratch or orchestrate dynamic business processes from shared SOA and REST services driven by events? Does this sound like the nirvana of modern applications?

Architects get excited about realizing the promise of SOA, shared services and interoperable, loosely coupled application modules with standard interfaces driven by well-accepted policies. Developers get excited about building things using the latest and greatest standards. But, what about testing teams?

Functional testers need to test the functionality of their applications or conduct regression tests when the application under test isn't completely in their control or even in their domain of expertise. Now, they must test something that makes a call to or relies on a response from a dependent service or system that is virtually impossible to get access to. What if the dependent service is actually a mainframe application in production or a SAP system running a production business process, or even not built yet by another development team building out a shared service?

To date, the answer has been wait. Wait for your small time slice of the mainframe, wait until operations gives you a 2:00 am window, next Monday, (a business holiday) to access SAP, or until the other development team gets a stable enough build of their service for you to test against.

Performance testers need to test against a goal SLA that the business expects but their SLA is the aggregate of the performance of their composite application and all the downstream services that are part of the composition. How do they do that? What if they cannot even get enough cycles of a downstream system to prove performance? (let's say the downstream system is a third party SaaS application and each transaction costs the testing team major bank? It would be way too costly to run a major load test against the SaaS back-end). So, once again the answer is wait, or worst-case, take a SWAG (and we know what SWAG stands for..)

It's time to think about adding capability for testing teams to virtualize their constraints and dependencies so they can continue testing throughout the application lifecycle. And it's time to stop expecting testers to become experts in challenging back-end systems such as mainframe protocols, integration systems such as MQSeries or JMS, or proprietary programming models. Enter the role for Service Virtualization.

In case you missed it during summer vacation, iTKO announced that HP will be reselling iTKO LISA Virtualize. The waiting is over. Service Virtualization will help testing teams keep forward progress in the face of an array of constraints....

Now that's worth raising a glass!

more on the basics -- how to walk the talk on being service oriented

kellyemo — Mon, 02 Feb 2009 18:52:00 GMT

I just recently had a simple article published in the digital edition of SOAWorld magazine titled "Navigating the SOA journey from project to productivity". It's another back-to-basics piece. With all the hooplah lately about whether the term SOA is dead or alive, we lose sight of the fact that regardless of terms, IT needs to embrace service orientation to transition from the silo'd applications state to a state of agile compositions... and service orientation is not just a technology dicussion. It encompasses architecture, applications, organizations and best practices.

In the article, I describe the move to service orientation as a three-stage journey from getting started, to crossing the shared service divide to scaling to the enterprise. I believe these tenents hold true whether the architecture is SOA or service oriented using web-oriented principles, mash-ups, cloud services or something else...

The article can be found here.

Here's a snippet:

Remember, a journey of a thousand miles begins with a single step and so does a SOA. The best way to get started is to assess your organizational readiness for SOA, empower a team to own SOA adoption, identify a project with substantial business support, and start to implement services under the guidance of a governance program.

Recent SOA best practice gems from HP SOA Customers – or more than lost wages comes from attending HP Software Universe in Las Vegas

kellyemo — Mon, 30 Jun 2008 21:34:00 GMT

I drew the lucky straw to be a track manager at HP Software Universe. This meant I was tagged to organize all the sessions at HP Software Universe for our SOA track . The positive side of the administrivia was that in the process, I had the opportunity to review and hear some great presentations from our SOA customers who are making the journey towards effective SOA transformation. Here are some of the quips and gems that stood out for me: 1. One customer mentioned how for their organization, SOA is a tool within an Enterprise Architecture: The key message here is that you never do SOA for “SOA’s sake”. It’s a tool to help you achieve an architectural objective: agility, re-use, efficiency.

If you want to dig into this topic more, there is some interesting writing about SOA and EA here

2. One needs clear SOA transformation metrics to measure success: What is your SOA measured against? For one key customer, the clear metrics are 1) standards conformance and 2) business agility. Business agility is defined as the ability to see new business intentions, realize business changes and make improvements quickly.

To hear more about measureable benefits of SOA check out Tim Hall’s podcast

3. Don’t be surprised that one of the largest adoption hurdles is that SOA is fraught with “charge back challenges” -- In order for a group to adopt SOA it must be cheaper for the potential service consumer than to do it themselves. (This should be obvious) 4. How to manage versions effectively in a SOA? A best practice is to establish a time-based contract between service consumer and provider – allows the service provider to get consumers onto new versions, otherwise they will never move. 5. My favorite -- How to entice project teams to adopt SOA? Show them how SOA will grow their kingdom and make them a bigger king – appeal to ego, create a buzz – the more groups that use the service, the more successful the service provider, or the bigger the "kingdom". 6. Sometimes silos are not a dirty word. One customer started building out SOA in silos and is now connecting them when the organization has matured enough to handle it – the goal, build initial focused success, gain people buy-in, then expand scope 7. And since there are two sides to every story, that said, some silos must be broken from the get-go. For example, to have success in attaining SOA quality testing that works—you must have collaboration between development and QA – services change continuously during design, requirements definition, development and testing and dev and QA must have a dynamic feedback loop to get a positive result. 8. Finally a good quote ”you need SOA governance but it can’t be bureaucratic” Governance should make SOA easier not put up roadblocks. As the cliché goes..for many of these customers the carrot is proving more effective than the stick.