Take the BriefingsDirect middleware/ESB survey now.
Forgive my harping on this, but I keep hearing about how powerful social media is for gathering insights from the IT communities and users. Yet I rarely see actual market research conducted via the social media milieu.
So now's the time to fully test the process. I'm hoping that you users and specifiers of enterprise software middleware, SOA infrastructure, integration middleware, and enterprise service buses (ESBs) will take 5 minutes and fill out my BriefingsDirect survey. We'll share the results via this blog in a few weeks.
We're seeking to uncover the latest trends in actual usage and perceptions around these technologies -- both open source and commercial.
How middleware products -- like ESBs -- are used is not supposed to change rapidly. Enterprises typically choose and deploy integration software infrastructure slowly and deliberately, and they don't often change course without good reason.
But the last few years have proven an exception. Middleware products and brands have shifted more rapidly than ever before. Vendors have consolidated, product lines have merged. Users have had to grapple with new and dynamic requirements.
Open source offerings have swiftly matured, and in many cases advanced capabilities beyond the commercial space. Interest in SOA is now shared with anticipation of cloud computing approaches and needs.
So how do enterprise IT leaders and planners view the middleware and SOA landscape after a period of adjustment -- including the roughest global recession in more than 60 years?
This brief survey, distributed by BriefingsDirect for Interarbor Solutions, is designed to gauge the latest perceptions and patterns of use and updated requirements for middleware products and capabilities. Please take a few moments and share your preferences on enterprise middleware software. Thank you.
Take the BriefingsDirect middleware/ESB survey now.
Tuesday, August 18, 2009
Monday, August 17, 2009
Open Group forms Cloud Work Group to spur enterprise cloud adoption and security via open standards
This guest blog comes courtesy of Dave Lounsbury, vice president of government programs and managing director of research and technology at The Open Group, where he leads activities related to government research, adaptive and real-time system software, and cloud computing. He can be reached here.
Take the BriefingsDirect middleware/ESB survey now.
By Dave Lounsbury
Like so many others, The Open Group has been busy for the past year figuring out our place in
the cloud. With the great work already being done by industry groups like the Cloud Computing Interoperability Forum, CloudCamp and the Cloud Security Alliance, we have given great thought and consideration to how we can best add value to this evolving area. [Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]
The growth in cloud computing has resulted in a diverse array of technical capabilities, and companies of all sizes are trying to understand how to take advantage of them in their business operations. We saw this as an opportunity to bring both vendors and end-users together with an eye toward providing guidance for adopting and implementing cloud computing in a way that helps ensure that organizations get the business benefits promised by these new capabilities.
Over the past year, The Open Group’s members have engaged in focused work to identify end-user requirements for cloud computing, identifying needs in security and identity, standards to prevent lock-in, skills in management of cloud outsourcing, and the need for enterprise architecture models for cloud. As a culmination of this, I am pleased to announce that we have officially formed our own Cloud Work Group.
We have taken what we’ve learned from our London and Toronto conferences to create a group
The Cloud Work Group is in a unique position to develop a common understanding between buyers and suppliers of how companies can use cloud products and services in a flexible and secure way to realize its full potential. By focusing on customer input and drawing on the diverse views of our global members, we intend to bring a somewhat understated perspective to the discussion – that of the end-user.
Our first deliverable will be to publish a Business Scenario for Enterprise Cloud Computing, based on end-user requirements discussed at The Open Group’s latest Enterprise Architecture Conference in Toronto. During a business scenario workshop, led by MITRE’s Terry Blevins, we brainstormed and discussed the cloud’s most critical business requirements, as well as “pain points”. As Sandy Kemsley summarizes in her blog post, The Enterprise Cloud Business Scenario will help companies identify and understand business needs relative to cloud computing and thereby derive the requirements that the architecture development must address.
This is an exciting time for us as we collaborate with some of the industry’s leading cloud providers and end-user organizations to ensure both sides are in sync and able to reap the rewards as a result. The direction of the group is determined by Open Group members, but participation is welcomed from all organizations that wish to understand or contribute to the development of best practices for enterprise use of cloud computing.
To get involved or for more information, please visit: https://www.opengroup.org/cloudcomputing/. We hope you will join us!
Take the BriefingsDirect middleware/ESB survey now.
This guest blog is courtesy of Dave Lounsbury, vice president of government programs and managing director of research and technology at The Open Group, where he leads activities related to government research, adaptive and real-time system software, and cloud computing. He can be reached here.
Take the BriefingsDirect middleware/ESB survey now.
By Dave Lounsbury
Like so many others, The Open Group has been busy for the past year figuring out our place in
the cloud. With the great work already being done by industry groups like the Cloud Computing Interoperability Forum, CloudCamp and the Cloud Security Alliance, we have given great thought and consideration to how we can best add value to this evolving area. [Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]The growth in cloud computing has resulted in a diverse array of technical capabilities, and companies of all sizes are trying to understand how to take advantage of them in their business operations. We saw this as an opportunity to bring both vendors and end-users together with an eye toward providing guidance for adopting and implementing cloud computing in a way that helps ensure that organizations get the business benefits promised by these new capabilities.
Over the past year, The Open Group’s members have engaged in focused work to identify end-user requirements for cloud computing, identifying needs in security and identity, standards to prevent lock-in, skills in management of cloud outsourcing, and the need for enterprise architecture models for cloud. As a culmination of this, I am pleased to announce that we have officially formed our own Cloud Work Group.
We have taken what we’ve learned from our London and Toronto conferences to create a group
The Cloud Work Group is in a unique position to develop a common understanding between buyers and suppliers of how companies can use cloud products and services in a flexible and secure way to realize its full potential.
that we believe truly reflects the importance of cloud computing to The Open Group members and industry at large. Our main goal is to ensure the effective and secure use of cloud computing in enterprise architectures, given The Open Group’s experience driving vendor-neutral standards and certification programs in and around enterprise architecture.The Cloud Work Group is in a unique position to develop a common understanding between buyers and suppliers of how companies can use cloud products and services in a flexible and secure way to realize its full potential. By focusing on customer input and drawing on the diverse views of our global members, we intend to bring a somewhat understated perspective to the discussion – that of the end-user.
Our first deliverable will be to publish a Business Scenario for Enterprise Cloud Computing, based on end-user requirements discussed at The Open Group’s latest Enterprise Architecture Conference in Toronto. During a business scenario workshop, led by MITRE’s Terry Blevins, we brainstormed and discussed the cloud’s most critical business requirements, as well as “pain points”. As Sandy Kemsley summarizes in her blog post, The Enterprise Cloud Business Scenario will help companies identify and understand business needs relative to cloud computing and thereby derive the requirements that the architecture development must address.
This is an exciting time for us as we collaborate with some of the industry’s leading cloud providers and end-user organizations to ensure both sides are in sync and able to reap the rewards as a result. The direction of the group is determined by Open Group members, but participation is welcomed from all organizations that wish to understand or contribute to the development of best practices for enterprise use of cloud computing.
To get involved or for more information, please visit: https://www.opengroup.org/cloudcomputing/. We hope you will join us!
Take the BriefingsDirect middleware/ESB survey now.
This guest blog is courtesy of Dave Lounsbury, vice president of government programs and managing director of research and technology at The Open Group, where he leads activities related to government research, adaptive and real-time system software, and cloud computing. He can be reached here.
Understanding the value of reference architectures in the SOA story
This guest post comes courtesy of ZapThink. Ron Schmelzer is a senior analyst at ZapThink. You can reach him here.
Take the BriefingsDirect middleware/ESB survey now.
By Ron Schmelzer
There's nothing more that architects love to do than argue about definitions. If you ever find yourself with idle
time in a room of architects, try asking for a definition of "service" or "architecture" and see what sort of creative melee you can start.
That being said, definitions are indeed very important so that we can have a common language to communicate the intent and benefit of the very things we are trying to convince business to invest in. From that perspective, a number of concepts have emerged in the past decade or so that have become top of mind for self-styled enterprise architects: architecture frameworks and reference architectures.
In previous ZapFlashes, we discussed architecture frameworks, which leaves the topic of reference architectures left untouched by ZapThink. Since we can't leave a good argument behind, we're going to use this ZapFlash to explore what reference architectures are all about and what value they have to add to the Service-Oriented Architecture (SOA) story.
What is a reference architecture?
One commonly accepted definition for reference architecture is that it provides a methodology and/or set of practices and templates that are based on the generalization of a set of successful solutions for a particular category of solutions. Reference architectures provide guidance on how to apply specific patterns and/or practices to solve particular classes of problems. In this way, it serves as a "reference" for the specific architectures that companies will implement to solve their own problems. It is never intended that a reference architecture would be implemented as-is, but rather used either as a point of comparison or as a starting point for individual companies' architectural efforts.
Others refine the definition of reference architecture as a description of how to build a class of artifacts. These artifacts can be embodied in many forms including design patterns, methodologies, standards, metadata, and documents of all sorts. Long story short, if you need guidance on how to develop a specific architecture based on best practices or authoritative sets of potential artifacts, you should look to a reference architecture that covers the scope of the architecture that you're looking to build.
One of the most popular examples of reference architectures in IT is the Java Platform Enterprise Edition (Java EE) architecture, which provides a layered reference architecture and templates addressing a range of technology and business issues that have guided many Java-based enterprise systems.
Reference architectures vs. architecture frameworks
While the above definition(s) may seem fairly cut and dried, there is a lot in common between the concepts of reference architectures and architecture frameworks. For some, this is where things get dicey and definitions get blurry. Architecture frameworks, such as the Zachman Framework, the Open Group Architecture Framework (TOGAF), and Department of Defense Architecture Framework (DoDAF) provide approaches to describe and identify necessary inputs to a particular architecture as well as means to describe that architecture. [Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]
If a particular architecture is a cookbook that provides guidance on how to go about solving a particular set of problems with a particular approach, an architecture framework is a book about how to write cookbooks. So, architecture frameworks give enterprise architects the tools they need to adequately describe and collect requirements, without mandating any specific architecture type. More specifically, architecture frameworks describe an example taxonomy of the kinds of architectural "views" that an architect might consider developing, and why, and provides guidelines for making the choice for developing particular views.
This differs from the above concept of a reference architecture in that a reference architecture
Furthermore, most reference architectures emphasize the "template" part of the definition of a reference architecture. Both frameworks and RAs provide best practices, and while it might be argued that RAs provide more of a methodology than a framework does, RAs are still not really characterized by their methodology component. Most can be characterized by their template component, however. From this perspective, patterns are instances of templates in this context. In fact, multiple reference architectures for the same domain are allowable and quite useful. Reference architectures can be complementary providing guidance for a single architecture, such as SOA, from multiple viewpoints.
The value of a SOA reference architecture
In many ways, SOA projects are in desperate need of well-thought out reference architectures. ZapThink sees a high degree of variability in SOA projects. Some flourish and succeed while others flounder and fail. Many times the reason for failure can be traced to bad architectural practices, premature infrastructure purchasing, and inadequate governance and management. Other times the failure is primarily organizational. However, what is common in most successes is well-documented and/or communicated architectural practices and a systematic method for learning from one's mistakes and having a low cost of failure.
Furthermore, we find that many architects spend a significant amount of their time researching, investigating, (re-)defining, contemplating, and arguing architectural decisions. In many cases, these architects are reinventing the wheel as their peers in other companies, or even the same company, have already spent that time and effort defining their own architectural practices. This extra effort is not only inefficient, but also prevents the company from learning from its own experiences and applying that knowledge for increased effectiveness.
From this perspective, SOA reference architectures can provide some help to those struggling
Indeed, in order to gain the promised SOA benefits of reuse, reduced redundancy, reduced cost of integration, and increased visibility and governance, companies need to apply their SOA efforts in a consistent manner. This means more than buying and establishing some vendor's infrastructure as a corporate standard or adhering to the latest WS-* standards stack. SOA reference architectures can serve as the basis for disparate SOA efforts throughout the organization, even if they use different tools and technologies. Good SOA reference architectures provide SOA best practices and approaches in a vendor-, technology-, and standards-independent way. Therefore, don't go hunting for one from your favorite vendor of choice. In fact, if you got your SOA reference architecture from that vendor, you might want to consider dropping it in lieu of something more vendor-neutral.
In particular, OASIS offers a SOA Reference Architecture (RA) that "models the abstract architectural elements for a SOA independent of the technologies, protocols, and products that are used to implement a SOA. Some sections of the RA will use common abstracted elements derived from several standards." Their approach uses the concept of "patterns" to identify different methods and approaches for implementing different parts of the architectural picture. While the OASIS SOA Reference Architecture is certainly not the only valid one on the block, it certainly makes a good starting point for those looking for a vendor-neutral SOA reference architecture on which to base their own architectural efforts.
The ZapThink take
Enterprise architects needs all the help they can get to make sure that they deliver reliable, agile, resilient, vendor-neutral architectures to their organization that meet the continuously changing requirements of the business. While certainly the art and practice of enterprise architecture continues to mature, companies should look to borrow as much best practices as they can and learn from others who have already gone down the EA and SOA path. If you plan to learn SOA, or any form of EA for that matter, as you go along, or even worse, from a vendor, then you risk the entire success of your SOA efforts. Rather, leverage (for free) SOA reference architectures so that you can advance at a faster pace and lower risk.
Bernard of Chartres put it best in the well-known saying: "We are like dwarfs on the shoulders of giants, so that we can see more than they, and things at a greater distance, not by virtue of any sharpness of sight on our part, or any physical distinction, but because we are carried high and raised up by their giant size." Stand on the shoulders of other enterprise architecture giants and let them increase your vision and success.
This guest post comes courtesy of ZapThink. Ron Schmelzer, a senior analyst at ZapThink, can be reached here.
Take the BriefingsDirect middleware/ESB survey now.
and Networking Events
In need of vendor-neutral, architect-level SOA and EA training? ZapThink's Licensed ZapThink Architect (LZA) SOA Boot Camps provide four days of intense, hands-on architect-level SOA training and certification.
Advanced SOA architects might want to enroll in ZapThink's SOA Governance and Security training and certification courses. Or, are you just looking to network with your peers, interact with experts and pundits, and schmooze on SOA after hours? Join us at an upcoming ZapForum event. Find out more and register for these events at http://www.zapthink.com/eventreg.html.
Take the BriefingsDirect middleware/ESB survey now.
By Ron Schmelzer
There's nothing more that architects love to do than argue about definitions. If you ever find yourself with idle
time in a room of architects, try asking for a definition of "service" or "architecture" and see what sort of creative melee you can start.That being said, definitions are indeed very important so that we can have a common language to communicate the intent and benefit of the very things we are trying to convince business to invest in. From that perspective, a number of concepts have emerged in the past decade or so that have become top of mind for self-styled enterprise architects: architecture frameworks and reference architectures.
In previous ZapFlashes, we discussed architecture frameworks, which leaves the topic of reference architectures left untouched by ZapThink. Since we can't leave a good argument behind, we're going to use this ZapFlash to explore what reference architectures are all about and what value they have to add to the Service-Oriented Architecture (SOA) story.
What is a reference architecture?
One commonly accepted definition for reference architecture is that it provides a methodology and/or set of practices and templates that are based on the generalization of a set of successful solutions for a particular category of solutions. Reference architectures provide guidance on how to apply specific patterns and/or practices to solve particular classes of problems. In this way, it serves as a "reference" for the specific architectures that companies will implement to solve their own problems. It is never intended that a reference architecture would be implemented as-is, but rather used either as a point of comparison or as a starting point for individual companies' architectural efforts.
Others refine the definition of reference architecture as a description of how to build a class of artifacts. These artifacts can be embodied in many forms including design patterns, methodologies, standards, metadata, and documents of all sorts. Long story short, if you need guidance on how to develop a specific architecture based on best practices or authoritative sets of potential artifacts, you should look to a reference architecture that covers the scope of the architecture that you're looking to build.
One of the most popular examples of reference architectures in IT is the Java Platform Enterprise Edition (Java EE) architecture, which provides a layered reference architecture and templates addressing a range of technology and business issues that have guided many Java-based enterprise systems.
Reference architectures vs. architecture frameworks
While the above definition(s) may seem fairly cut and dried, there is a lot in common between the concepts of reference architectures and architecture frameworks. For some, this is where things get dicey and definitions get blurry. Architecture frameworks, such as the Zachman Framework, the Open Group Architecture Framework (TOGAF), and Department of Defense Architecture Framework (DoDAF) provide approaches to describe and identify necessary inputs to a particular architecture as well as means to describe that architecture. [Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]
If a particular architecture is a cookbook that provides guidance on how to go about solving a particular set of problems with a particular approach, an architecture framework is a book about how to write cookbooks. So, architecture frameworks give enterprise architects the tools they need to adequately describe and collect requirements, without mandating any specific architecture type. More specifically, architecture frameworks describe an example taxonomy of the kinds of architectural "views" that an architect might consider developing, and why, and provides guidelines for making the choice for developing particular views.
This differs from the above concept of a reference architecture in that a reference architecture
Both frameworks and RAs provide best practices, and while it might be argued that RAs provide more of a methodology than a framework does, RAs are still not really characterized by their methodology component
goes one step further by accelerating the process for a particular architecture type, helping to identify which architectural approaches will satisfy particular requirements, and figuring out what a minimally acceptable set of architectural artifacts are needed to meet the "best practices" requirements for a particular architecture. To continue our analogy with cookbooks, if an architecture framework is a book on how to write cookbooks, then a reference architecture is a book that provides guidance and best practices on how to write cookbooks focused on weight loss, for example. This would then mean that the particular architecture you develop for your organization would be a specific cookbook that provides weight-loss recipes targeted to your organization. Indeed, if you get puzzled with the definitions, replacing the term "architecture" with "cookbook" is helpful: cookbook frameworks, reference cookbooks, and your particular cookbook.Furthermore, most reference architectures emphasize the "template" part of the definition of a reference architecture. Both frameworks and RAs provide best practices, and while it might be argued that RAs provide more of a methodology than a framework does, RAs are still not really characterized by their methodology component. Most can be characterized by their template component, however. From this perspective, patterns are instances of templates in this context. In fact, multiple reference architectures for the same domain are allowable and quite useful. Reference architectures can be complementary providing guidance for a single architecture, such as SOA, from multiple viewpoints.
The value of a SOA reference architecture
In many ways, SOA projects are in desperate need of well-thought out reference architectures. ZapThink sees a high degree of variability in SOA projects. Some flourish and succeed while others flounder and fail. Many times the reason for failure can be traced to bad architectural practices, premature infrastructure purchasing, and inadequate governance and management. Other times the failure is primarily organizational. However, what is common in most successes is well-documented and/or communicated architectural practices and a systematic method for learning from one's mistakes and having a low cost of failure.
Furthermore, we find that many architects spend a significant amount of their time researching, investigating, (re-)defining, contemplating, and arguing architectural decisions. In many cases, these architects are reinventing the wheel as their peers in other companies, or even the same company, have already spent that time and effort defining their own architectural practices. This extra effort is not only inefficient, but also prevents the company from learning from its own experiences and applying that knowledge for increased effectiveness.
From this perspective, SOA reference architectures can provide some help to those struggling
While the OASIS SOA Reference Architecture is certainly not the only valid one on the block, it certainly makes a good starting point for those looking for a vendor-neutral SOA reference architecture on which to base their own architectural efforts.
with their SOA efforts or thinking about launching a new one. SOA reference architectures allow organizations to learn from other architects' successes and failures and inherit proven best practices. Reference architectures can provide missing architectural information that can be provided in advance to project team members to enable consistent architectural best practices. In this way, the SOA reference architecture provides a base of assets that SOA efforts can draw from throughout the project lifecycle.Indeed, in order to gain the promised SOA benefits of reuse, reduced redundancy, reduced cost of integration, and increased visibility and governance, companies need to apply their SOA efforts in a consistent manner. This means more than buying and establishing some vendor's infrastructure as a corporate standard or adhering to the latest WS-* standards stack. SOA reference architectures can serve as the basis for disparate SOA efforts throughout the organization, even if they use different tools and technologies. Good SOA reference architectures provide SOA best practices and approaches in a vendor-, technology-, and standards-independent way. Therefore, don't go hunting for one from your favorite vendor of choice. In fact, if you got your SOA reference architecture from that vendor, you might want to consider dropping it in lieu of something more vendor-neutral.
In particular, OASIS offers a SOA Reference Architecture (RA) that "models the abstract architectural elements for a SOA independent of the technologies, protocols, and products that are used to implement a SOA. Some sections of the RA will use common abstracted elements derived from several standards." Their approach uses the concept of "patterns" to identify different methods and approaches for implementing different parts of the architectural picture. While the OASIS SOA Reference Architecture is certainly not the only valid one on the block, it certainly makes a good starting point for those looking for a vendor-neutral SOA reference architecture on which to base their own architectural efforts.
The ZapThink take
Enterprise architects needs all the help they can get to make sure that they deliver reliable, agile, resilient, vendor-neutral architectures to their organization that meet the continuously changing requirements of the business. While certainly the art and practice of enterprise architecture continues to mature, companies should look to borrow as much best practices as they can and learn from others who have already gone down the EA and SOA path. If you plan to learn SOA, or any form of EA for that matter, as you go along, or even worse, from a vendor, then you risk the entire success of your SOA efforts. Rather, leverage (for free) SOA reference architectures so that you can advance at a faster pace and lower risk.
Bernard of Chartres put it best in the well-known saying: "We are like dwarfs on the shoulders of giants, so that we can see more than they, and things at a greater distance, not by virtue of any sharpness of sight on our part, or any physical distinction, but because we are carried high and raised up by their giant size." Stand on the shoulders of other enterprise architecture giants and let them increase your vision and success.
This guest post comes courtesy of ZapThink. Ron Schmelzer, a senior analyst at ZapThink, can be reached here.
Take the BriefingsDirect middleware/ESB survey now.
SPECIAL PARTNER OFFER
SOA and EA Training, Certification,
and Networking Events
In need of vendor-neutral, architect-level SOA and EA training? ZapThink's Licensed ZapThink Architect (LZA) SOA Boot Camps provide four days of intense, hands-on architect-level SOA training and certification.
Advanced SOA architects might want to enroll in ZapThink's SOA Governance and Security training and certification courses. Or, are you just looking to network with your peers, interact with experts and pundits, and schmooze on SOA after hours? Join us at an upcoming ZapForum event. Find out more and register for these events at http://www.zapthink.com/eventreg.html.
Friday, August 14, 2009
HP partners with iTKO on LISA services testing suite for SOA, BPM
Take the BriefingsDirect middleware/ESB survey now.
When HP inks a deal to resell your testing software, you know you must be doing something right.
HP is reselling iTKO’s LISA Virtualize product, a suite of test, validation and virtualization solutions optimized for distributed, multi-tier applications that leverage SOA, BPM, cloud computing, integration suites and ESBs. HP’s aim is to help customers reduce testing costs and speed the time to market for modern applications. [Disclosure: HP and iTKO are sponsors of BriefingsDirect podcasts.]
How does LISA help HP’s Quality and Performance Management solutions suite? By eliminating common system infrastructure dependencies during application testing. The idea is to trim both the cost and risk of modern Quality Assurance – a major issue for today’s enterprise.
Here’s how it works: LISA Virtualize does away with system dependency constraints by simulating the dynamic behavior and performance conditions of downstream system dependencies. In other words, you can see how systems react and respond as if they were running live – but they aren’t running live. That saves time and money.
Jonathan Rende, vice president and general manager of the Business Technology Optimization Applications, Software and Solutions group at HP, said: "Customers can reduce costs and speed up their ability to respond to business needs by modernizing their applications.”
By bringing together HP Quality Center and HP Performance Center solutions with iTKO's LISA Virtualize software, Rende said customers can remove delay-causing system dependencies during testing processes. The result: saving time and lowering the cost of delivering complex applications.
To be sure, putting quality top of mind earlier in the development process is a key to reducing defects and speeding time to market. And Shridhar Mittal, iTKO's CEO, claims the company’s virtualization capabilities lower test lab costs by up to 65 percent and shortening software release cycles by up to 38 percent.
If those claims hold true, it’s easy to see why HP is partnering with this young company. The running theme with this announcement is saving time and money – both critical selling points in a down economy.
Take the BriefingsDirect middleware/ESB survey now.
BriefingsDirect contributor Jennifer LeClaire provided editorial assistance and research on this post. She can be reached here and here.
When HP inks a deal to resell your testing software, you know you must be doing something right.
HP is reselling iTKO’s LISA Virtualize product, a suite of test, validation and virtualization solutions optimized for distributed, multi-tier applications that leverage SOA, BPM, cloud computing, integration suites and ESBs. HP’s aim is to help customers reduce testing costs and speed the time to market for modern applications. [Disclosure: HP and iTKO are sponsors of BriefingsDirect podcasts.]
How does LISA help HP’s Quality and Performance Management solutions suite? By eliminating common system infrastructure dependencies during application testing. The idea is to trim both the cost and risk of modern Quality Assurance – a major issue for today’s enterprise.
Here’s how it works: LISA Virtualize does away with system dependency constraints by simulating the dynamic behavior and performance conditions of downstream system dependencies. In other words, you can see how systems react and respond as if they were running live – but they aren’t running live. That saves time and money.
Jonathan Rende, vice president and general manager of the Business Technology Optimization Applications, Software and Solutions group at HP, said: "Customers can reduce costs and speed up their ability to respond to business needs by modernizing their applications.”
By bringing together HP Quality Center and HP Performance Center solutions with iTKO's LISA Virtualize software, Rende said customers can remove delay-causing system dependencies during testing processes. The result: saving time and lowering the cost of delivering complex applications.
To be sure, putting quality top of mind earlier in the development process is a key to reducing defects and speeding time to market. And Shridhar Mittal, iTKO's CEO, claims the company’s virtualization capabilities lower test lab costs by up to 65 percent and shortening software release cycles by up to 38 percent.
If those claims hold true, it’s easy to see why HP is partnering with this young company. The running theme with this announcement is saving time and money – both critical selling points in a down economy.
Take the BriefingsDirect middleware/ESB survey now.
BriefingsDirect contributor Jennifer LeClaire provided editorial assistance and research on this post. She can be reached here and here.
Thursday, August 13, 2009
Got middleware? Got ESBs? Take this survey, please.
Take the brief online survey.
I keep hearing about how powerful social media is for gathering insights from the IT communities and users. Yet I rarely see actual market research conducted via the social media milieu.
So now's the time to fully test the process. I'm hoping that you users and specifiers of enterprise software middleware, SOA infrastructure, integration middleware, and enterprise service buses (ESBs) will take 5 minutes and fill out my BriefingsDirect survey. We'll share the results via this blog in a few weeks.
We're seeking to uncover the latest trends in actual usage and perceptions around these technologies -- both open source and commercial.
How middleware products -- like ESBs -- are used is not supposed to change rapidly. Enterprises typically choose and deploy integration software infrastructure slowly and deliberately, and they don't often change course without good reason.
But the last few years have proven an exception. Middleware products and brands have shifted more rapidly than ever before. Vendors have consolidated, product lines have merged. Users have had to grapple with new and dynamic requirements.
Open source offerings have swiftly matured, and in many cases advanced capabilities beyond the commercial space. Interest in SOA is now shared with anticipation of cloud computing approaches and needs.
So how do enterprise IT leaders and planners view the middleware and SOA landscape after a period of adjustment -- including the roughest global recession in more than 60 years?
This brief survey, distributed by BriefingsDirect for Interarbor Solutions, is designed to gauge the latest perceptions and patterns of use and updated requirements for middleware products and capabilities. Please take a few moments and share your preferences on enterprise middleware software. Thank you.
Take the brief online survey.
I keep hearing about how powerful social media is for gathering insights from the IT communities and users. Yet I rarely see actual market research conducted via the social media milieu.
So now's the time to fully test the process. I'm hoping that you users and specifiers of enterprise software middleware, SOA infrastructure, integration middleware, and enterprise service buses (ESBs) will take 5 minutes and fill out my BriefingsDirect survey. We'll share the results via this blog in a few weeks.
We're seeking to uncover the latest trends in actual usage and perceptions around these technologies -- both open source and commercial.
How middleware products -- like ESBs -- are used is not supposed to change rapidly. Enterprises typically choose and deploy integration software infrastructure slowly and deliberately, and they don't often change course without good reason.
But the last few years have proven an exception. Middleware products and brands have shifted more rapidly than ever before. Vendors have consolidated, product lines have merged. Users have had to grapple with new and dynamic requirements.
Open source offerings have swiftly matured, and in many cases advanced capabilities beyond the commercial space. Interest in SOA is now shared with anticipation of cloud computing approaches and needs.
So how do enterprise IT leaders and planners view the middleware and SOA landscape after a period of adjustment -- including the roughest global recession in more than 60 years?
This brief survey, distributed by BriefingsDirect for Interarbor Solutions, is designed to gauge the latest perceptions and patterns of use and updated requirements for middleware products and capabilities. Please take a few moments and share your preferences on enterprise middleware software. Thank you.
Take the brief online survey.
Subscribe to:
Posts (Atom)
