So you have a SOA Management dashboard. How do you drive it?

Lately we've done a lot of research and publishing on how Dev & QA teams can ensure better quality throughout the software development and release lifecycle. But what about the IT Operations guys? It seems we are encountering a disconnect between the Enterprise Architecture and Integration disciplines that are moving to SOA, and the people who need to monitor and maintain these systems in deployment. There are a lot of companies starting to focus on better SOA Governance, which includes the management of business processes and workflows, and the services and applications behind that. Great stuff happening on that side of the IT shop. However, often the actual running applications are still in the purview of IT Operations teams. Don't get me wrong, it is a great thing that we have a team that is manning Mission Control -- hopefully providing an impartial report and monitoring function that is crucial, when you have live customers depending upon these apps in deployment. And there are mature tools out there that provide this kind of live "dashboard" of how the implemented apps are performing, like TIBCO Hawk, HP OpenView, IBM Tivoli, CA/Wily, etc. So why would these IT Operations teams be interested in SOA testing and validation? Well, it's really about "causing the cause" of performance and latency issues in these systems. If you are trying to prove that live SOA infrastructures are ready to roll, it's not enough to sit and watch the dashboard for that "Check Engine" warning light when a condition is caused by too many customers using those apps. The point I'm making is to use automated Test Execution as a way to drive expected and unexpected behaviors into your SOA Monitoring dashboards. This can be done both at integration time in staging, and against live applications, if you can provide a test window of time to make this process happen. For instance, we recently worked with a large energy industry customer who wanted to prove that their live implementation was able to handle a realistic profile of varied transactions in their system. So instead of waiting for a rush, they manufactured one -- by executing automated test transactions into the system, and monitoring the performance results within their Operations dashboards. Then they could feed the same data out to their SOA Testing platforms to tell the tests if they performed according to service levels. We recently put out a little news on this kind of integration - it's a pretty exciting way to apply Test & Validation to the Monitoring applications that have been around and evolving for some time: http://www.itko.com/site/company/news_65.jsp To me, that is a better machine - and it takes away a lot of that disconnect between Development and Integration teams, and the Operations people who are ultimately answerable for customer service levels.

Oracle buys BEA - Nice time to get a check-up

The biggest news in software may have already hit this year, but it's not like we didn't hear it coming for the past few months. Oracle finally makes good on its intent to buy BEA at $8.5B: http://online.wsj.com/article/SB120048691486294361.html To us, this is good news -- like when SoftwareAG and webMethods merged - it combines a strong integration firm with a global presence, with a technology leader in the SOA space. It's also a good move for Larry. Aside from increasing their customer base, it really moves Oracle more into the SOA mainstream - almost every customer we know has some Oracle apps, databases and integration inside their enterprise, but adding some leading AquaLogic ESB and Governance aspects of BEA will make a huge difference in advancing Oracle FUSION as an SOA platform. Oracle getting JRockit from BEA also bodes well for performance, as now they can optimize that for the Oracle application stack. For BEA customers, at least the anticipation is over, and they can continue to move forward with their plans with this reality in mind. I'm quite sure the best of BEA's stack will still be going on in the FUSION platform. Plus, for quality and reuse, consolidation of a SOAP stacks is a good thing. Both BEA and Oracle were operating their own SOAP stacks, and combining those particular efforts will create better interoperability for a whole lot of customers. Is this too much consolidation? There are still several choices for how you provision SOA - you can go TIBCO, SoftwareAG/webMethods, IBM or HP, now Oracle/BEA, maybe Microsoft, or even open source, and there are best of breed tools out there that still perform unique functions in the SOA ecosystem. See, SOA is still something you DO, not something you buy. The business requirements should still lead the technology decision in every case -- and that doesn't usually jibe with the "one vendor fits all" strategy. Where's the risk to BEA and Oracle customers? As a vendor charged with testing and validating platforms from both BEA and Oracle, this will create many new opportunities to help companies integrate and ensure business continuity as the story of consolidation continues to evolve. We recommend that whatever your preferred tools are, that you follow best practices of creating a set of baseline component and system-wide tests of your "as-is" environment, so that as these two platforms are merged and upgraded, you will be able to test and maintain Business Continuity throughout the process. This is equally important if you decide to move to another vendor as well. While we do believe that the combined new company will certainly make a commitment to customers, if you are in IT there is no shortcut to quality. Your best strategy is to establish a line of defense against unforeseen consequences -- with a thorough, and thoroughly managed suite of tests.