AmberPoint has had a unique perspective of application governance over the years. As the industry’s leading provider of management solutions for composite applications, we’ve seen our enterprise customers struggle with implementing application governance time and again.
What’s gotten in their way? Well, the biggest problem is often the governance solutions themselves. Existing application governance solutions are typically heavy and inflexible, which means an organization must revamp processes and replace infrastructure to accommodate it. And they require way too much manual effort to be practical. IT staff and managers reject these time-consuming solutions, which seem to be more trouble than they’re worth. On that subject, these solutions call for an unreasonable upfront investment – to the tune of hundreds of thousands of dollars.
As a result, few organizations get what they expect from such application governance solutions.
At AmberPoint, we set out to fix this problem. The result of our efforts is AmberPoint Governance System, which we formally announced just recently. AmberPoint Governance System goes about things quite differently:
• It automates many governance tasks to minimize the manual effort of cataloging and policy enforcement
• It’s lightweight and flexibly accommodates the processes and infrastructure you already have in place.
• It minimizes resistance and promotes coordinated application development and deployment.
• It features an incremental deployment model that enables you to start with just the governance you need, and then add more to accommodate new projects or more users.
You’ll hear more from us about AmberPoint Governance System in the weeks and months ahead. In the meantime, here’s what one of our customers had to say:
"AmberPoint has thought about this the right way. By automating many of the more arduous governance tasks, AmberPoint is making it much easier for us to keep tabs on our application environment. Its automated policy enforcement will give us much better compliance across our complex system. They’ve changed application governance from a chore to a true benefit for our IT staff."
~ Kevin Forbes, Enterprise Architect at Healthways
Tuesday, December 15, 2009
Tuesday, November 3, 2009
Who’s Responsible for Sorting Out Failed Transactions?
During our webcast last week on Business Transaction Management, we polled our audience of Architects, Project Managers, IT Executives, Application Developers and Business Managers to see who’s responsible in their organizations for fixing things when transactions start to fail.
We asked them:
When Transactions Fail, Which Group is Responsible for Sorting Things Out?
We got a variety of answers, as you’d expect. Not every organization handles failed transactions the same way. However, by far the most common answer was Application Support Groups. Operations was a distant second, followed closely by Business Units. Here are the results of our poll.
1) Application Support Group - 68%
2) Operations - 13%
3) Business Units - 12%
4) We just muddle thru - 7%
For companies that don’t have Business Transaction Management, it’s typically the Business Units who first hear about the issue—often from irate customers whose transactions did not complete properly. The Business Units then notify Operations and App Support (please note that I’m using the word “notify” here as a very gentle euphemism for the way they actually tell them about the problem). And these unfortunate Application Support and Operations teams are left with the complicated and time-consuming task of sorting out where in their complex application flows the failure took place.
The biggest issue, of course, isn’t necessarily who fixes the issue but how soon they are able to fix it. Unless you’re tracking all the transactions flowing across your distributed applications, you probably won’t hear about failed transactions until they’ve impacted your bottom line.
We asked them:
When Transactions Fail, Which Group is Responsible for Sorting Things Out?
We got a variety of answers, as you’d expect. Not every organization handles failed transactions the same way. However, by far the most common answer was Application Support Groups. Operations was a distant second, followed closely by Business Units. Here are the results of our poll.
1) Application Support Group - 68%
2) Operations - 13%
3) Business Units - 12%
4) We just muddle thru - 7%
For companies that don’t have Business Transaction Management, it’s typically the Business Units who first hear about the issue—often from irate customers whose transactions did not complete properly. The Business Units then notify Operations and App Support (please note that I’m using the word “notify” here as a very gentle euphemism for the way they actually tell them about the problem). And these unfortunate Application Support and Operations teams are left with the complicated and time-consuming task of sorting out where in their complex application flows the failure took place.
The biggest issue, of course, isn’t necessarily who fixes the issue but how soon they are able to fix it. Unless you’re tracking all the transactions flowing across your distributed applications, you probably won’t hear about failed transactions until they’ve impacted your bottom line.
Friday, August 7, 2009
The Thing about Going Green…
Going green is the new mantra for both business and IT. In this economic climate, one might wonder why now’s the right time for businesses to up their investments in the environment, rather than squirreling away their money. Truth be told, being green ultimately boils down to reducing IT costs. Remember, corporate data centers require massive amounts of power to upkeep and maintain.
It takes careful planning to shave excesses, however. That means you need good data on which to base your decisions. So datacenters need insight into the actual resource requirements for their applications, not just estimates. More often than not, datacenters over-provision the application environment to ensure they can meet peak loads. Of course, application loads don’t remain at their peak for the better part of a 24 hour operation. The solution lies in provisioning capacity on-demand.
Dynamically scaling capacity to meet application needs remains a holy grail in the world of IT management. Virtualization and cloud computing both promise solutions to this challenge. However, these technologies bring only the mechanics for on-demand provisioning, not the control system for allocating or removing capacity. Building intelligent procedures for dynamic provisioning requires close monitoring of the quality of service your systems are delivering to your customers. Should performance breach your service level objectives, on-demand measures should kick-in.
The better your grasp of service quality, the better optimized your control system will be. What’s the best way to measure quality of service, you ask? Well, we think its best measured by monitoring the transaction performance, service usage and fault rates experienced by your end users, not the CPU and memory consumption of your servers.
It takes careful planning to shave excesses, however. That means you need good data on which to base your decisions. So datacenters need insight into the actual resource requirements for their applications, not just estimates. More often than not, datacenters over-provision the application environment to ensure they can meet peak loads. Of course, application loads don’t remain at their peak for the better part of a 24 hour operation. The solution lies in provisioning capacity on-demand.
Dynamically scaling capacity to meet application needs remains a holy grail in the world of IT management. Virtualization and cloud computing both promise solutions to this challenge. However, these technologies bring only the mechanics for on-demand provisioning, not the control system for allocating or removing capacity. Building intelligent procedures for dynamic provisioning requires close monitoring of the quality of service your systems are delivering to your customers. Should performance breach your service level objectives, on-demand measures should kick-in.
The better your grasp of service quality, the better optimized your control system will be. What’s the best way to measure quality of service, you ask? Well, we think its best measured by monitoring the transaction performance, service usage and fault rates experienced by your end users, not the CPU and memory consumption of your servers.
Tuesday, July 14, 2009
Services in the Cloud, Security in the House
Reading through the Cloud Security Alliance (CSA), I was struck by a basic theme that addresses some architectural reservations that have emerged elsewhere. As we pointed out in an earlier post, the cloud fear factor is ramping up significantly. A recent blogger has even claimed that cloud "mega-hubs" will be a favorable terrorist target, and may result in a digital 9/11. Cloud mega-hubs are nothing new. Consider the DNS system -- repository of domain names and network mappings, available over the network as a utility. This mega-hub risk has existed for some time, and thus mega-hubs, in themselves, may not necessarily represent a new risk.
In any case, a relevant theme emerges through the CSA's Guidance. A few choice quotes that illustrate this theme:
"Unencrypted data existent in the cloud may be considered 'lost' by the customer."
"Segregate the key management from the cloud provider hosting the data, creating a chain of separation."
"The key critical success factor to managing identities at cloud providers is to have a robust federated identity management architecture and strategy internal to the organization."
As you can see, the theme is that security starts in the home. So, while the security risks of the Cloud may actually be overhyped, the best solution is draw a distinction between the cloud business service functions, and the governance activities that surround your organization's consumption of those services. Be sure you encrypt your own data before it is sent to the Cloud.Manage your own users internally before you begin federating, and ensure that you have native capabilities in house (for example, your own standalone SAML authorities) before you begin looking outward. Use Cloud services for their business benefits. Keep your hands on the reins when it comes security and governance.
In any case, a relevant theme emerges through the CSA's Guidance. A few choice quotes that illustrate this theme:
"Unencrypted data existent in the cloud may be considered 'lost' by the customer."
"Segregate the key management from the cloud provider hosting the data, creating a chain of separation."
"The key critical success factor to managing identities at cloud providers is to have a robust federated identity management architecture and strategy internal to the organization."
As you can see, the theme is that security starts in the home. So, while the security risks of the Cloud may actually be overhyped, the best solution is draw a distinction between the cloud business service functions, and the governance activities that surround your organization's consumption of those services. Be sure you encrypt your own data before it is sent to the Cloud.Manage your own users internally before you begin federating, and ensure that you have native capabilities in house (for example, your own standalone SAML authorities) before you begin looking outward. Use Cloud services for their business benefits. Keep your hands on the reins when it comes security and governance.
Thursday, July 9, 2009
Cloud Computing... Meet Mafiaboy
Today, security in the SOA/Web services arena is usually more about risk and compliance than it is about crime prevention--although thwarting criminal activity is certainly a major aim of governance, risk and compliance (GRC) in the first place.
Enter Mafiaboy.
What better quote generator can you find than "a reformed black-hat hacker better known as the 15-year-old 'mafiaboy' who, in 2000, took down Websites CNN, Yahoo, E*Trade, Dell, Amazon, and eBay"?
And what's Mafiaboy back to tell us?
"[Cloud computing] will be the fall of the Internet as we know it.... You're basically putting everything in one little sandbox...it's going to be a lot more easy to access." Mafiaboy concluded that "cloud computing will be extremely dangerous."
One may quibble with Mafiaboy's basic assertion, or question his motives for making such newsworthy sound bites. However, it may be time to pause and realize that, even if cloud computing will not be the 'fall of the Internet as we know it,' there are millions of Mafiaboys out there who will attack cloud services. They may fire up a botnet to instigate a denial of service/extortion scheme. Or they may poke around your Cloud APIs and find a WSDL or two laying around that let them start 'playing' with your services.
All the more reason to evaluate governance solutions very early in any initiative that includes the Cloud.
Enter Mafiaboy.
What better quote generator can you find than "a reformed black-hat hacker better known as the 15-year-old 'mafiaboy' who, in 2000, took down Websites CNN, Yahoo, E*Trade, Dell, Amazon, and eBay"?
And what's Mafiaboy back to tell us?
"[Cloud computing] will be the fall of the Internet as we know it.... You're basically putting everything in one little sandbox...it's going to be a lot more easy to access." Mafiaboy concluded that "cloud computing will be extremely dangerous."
One may quibble with Mafiaboy's basic assertion, or question his motives for making such newsworthy sound bites. However, it may be time to pause and realize that, even if cloud computing will not be the 'fall of the Internet as we know it,' there are millions of Mafiaboys out there who will attack cloud services. They may fire up a botnet to instigate a denial of service/extortion scheme. Or they may poke around your Cloud APIs and find a WSDL or two laying around that let them start 'playing' with your services.
All the more reason to evaluate governance solutions very early in any initiative that includes the Cloud.
Monday, June 15, 2009
When Lightning Strikes
Wed June 10th, 6:30 PM PST: A lightning strike damages Power Distribution Units serving a set of racks hosting Amazon’s EC2 service.
6:30:05 PM PST: Your business transactions start failing.
7 PM PST: Your iPhone rings.
You thought that since your engineering teams were moving to "THE CLOUD," Your systems were finally going to be more reliable, more trustworthy. Finally, the much needed relief in your already over-extended workday!
But the reality is that no matter where you run your business systems, what underlying technology you use or what controls you put in place to ensure reliable business, there will always be incidents and unforeseen events that are out of your control.
Moving pieces of your application and infrastructure to a third-party hosting environment or leveraging third-party services directly within your business applications will mean even less control. A quick glance at http://status.aws.amazon.com tells you that even the best Cloud providers are only human. Service disruptions remain commonplace, no matter if they result from freak weather conditions or good old-fashioned configuration errors.
As your application evolves and as your data center turns into an amorphous cloud (no pun intended), you need to be prepared for damage control.
From a transactions standpoint, you need watch every single transaction and make sure that your iPhone rings within seconds of a disruption, not minutes or hours. In the real-time economy, every second lost equates to lost revenue.
You’ve got to be able to immediately identify which transactions failed, how many transactions failed, which consumers were affected and more, so that corrective procedures can be put into action. It will no longer suffice to simply let the business know that their transactions were disrupted!
Finally, it would help your case to negotiate strict SLAs with your service provider and establish a strategy for monitoring and documenting real-time compliance. In the event of a disruption--even if it’s too minor to be counted as a disruption by your provider--be prepared to furnish evidence and hold them accountable for the losses your business incurs.
6:30:05 PM PST: Your business transactions start failing.
7 PM PST: Your iPhone rings.
You thought that since your engineering teams were moving to "THE CLOUD," Your systems were finally going to be more reliable, more trustworthy. Finally, the much needed relief in your already over-extended workday!
But the reality is that no matter where you run your business systems, what underlying technology you use or what controls you put in place to ensure reliable business, there will always be incidents and unforeseen events that are out of your control.
Moving pieces of your application and infrastructure to a third-party hosting environment or leveraging third-party services directly within your business applications will mean even less control. A quick glance at http://status.aws.amazon.com tells you that even the best Cloud providers are only human. Service disruptions remain commonplace, no matter if they result from freak weather conditions or good old-fashioned configuration errors.
As your application evolves and as your data center turns into an amorphous cloud (no pun intended), you need to be prepared for damage control.
From a transactions standpoint, you need watch every single transaction and make sure that your iPhone rings within seconds of a disruption, not minutes or hours. In the real-time economy, every second lost equates to lost revenue.
You’ve got to be able to immediately identify which transactions failed, how many transactions failed, which consumers were affected and more, so that corrective procedures can be put into action. It will no longer suffice to simply let the business know that their transactions were disrupted!
Finally, it would help your case to negotiate strict SLAs with your service provider and establish a strategy for monitoring and documenting real-time compliance. In the event of a disruption--even if it’s too minor to be counted as a disruption by your provider--be prepared to furnish evidence and hold them accountable for the losses your business incurs.
Thursday, June 11, 2009
Plugging Gaps Instead of Creating New Ones
Joe McKendrick cites interesting observations in his latest post. Ovum reports that enterprises may be creating governance silos within their organizations – silos that handle SOA as a special case rather than managing the overarching software development lifecycle.
Most organizations already have well established SDLC processes. Instead of expanding and tweaking existing processes to encompass the development and delivery of the new breed of services-based applications (SOA, Cloud, BPM, whatever), they sometimes buy into the vendor hype and purchase a "SOA Governance" technology just because they think they need it to be successful.
True, new technologies may be useful in expanding existing processes, but governance-in-a-box seldom works. If the tools you buy don’t play nice with the established behavior of your IT staff, all you will get is resistance. Everyone is way too busy to adapt and change. They can adopt however, if the cost of adoption is small and rewards are large. Before buying yet another governance tool, try thinking about Application governance, not just SOA governance.
You’d expect application lifecycle management vendors to broaden their suites to encompass the requirements in SOA governance. However, most of their efforts so far appear to be marketing and rebranding excercises instead of true product expansions.
If you believe in governance, you already have a bit of it – your software engineering lifecycle is fully capable of handling the new needs for distributed computing. Of course, there are gaps to be plugged. So let’s focus on the plugging those instead of creating a whole new gap!
Most organizations already have well established SDLC processes. Instead of expanding and tweaking existing processes to encompass the development and delivery of the new breed of services-based applications (SOA, Cloud, BPM, whatever), they sometimes buy into the vendor hype and purchase a "SOA Governance" technology just because they think they need it to be successful.
True, new technologies may be useful in expanding existing processes, but governance-in-a-box seldom works. If the tools you buy don’t play nice with the established behavior of your IT staff, all you will get is resistance. Everyone is way too busy to adapt and change. They can adopt however, if the cost of adoption is small and rewards are large. Before buying yet another governance tool, try thinking about Application governance, not just SOA governance.
You’d expect application lifecycle management vendors to broaden their suites to encompass the requirements in SOA governance. However, most of their efforts so far appear to be marketing and rebranding excercises instead of true product expansions.
If you believe in governance, you already have a bit of it – your software engineering lifecycle is fully capable of handling the new needs for distributed computing. Of course, there are gaps to be plugged. So let’s focus on the plugging those instead of creating a whole new gap!
Thursday, May 7, 2009
Governance – Where is the Carrot?
Our folks are just back from the IBM Impact conference. And clearly, IBM thinks SOA is alive and kicking, as Joe McKendrick reports in his blog.
Well, so do we. Businesses have been services oriented for a long time. They divide their core strengths into a variety of services they offer to consumers. However, do you ever see an insurance company with two different divisions selling you the same type of service? Not really. There is one of each and different services build upon each other.
Service orientation in IT follows the same principle. The technologies available today make this an even easier task.
The ease of creating services naturally leads to the issue of governance. How do you prevent developers from re-inventing the wheel each time? How do you ensure that services conform to your operational standards and best practices? How do you prevent unauthorized access to services? The list goes on.
I recently finished discussing governance (the broader topic) with a customer, a large Telco. They suggested that governance is increasingly difficult to implement, not withstanding all the other governance software designed to help. Apparently, developers simply tire of the additional work involved with governance. They ask – what’s in it for me? Any effort that requires a non-zero investment of time and energy, without an incentive, could easily flounder.
Whether you use commercial governance products or not, how do you provide a “carrot” to promote governance adoption amongst the IT teams? Some customers have explored the idea of tying developer bonuses to governance adoption. Some, on the other hand, have considered firing developers that don’t participate. Talk about principles of capitalism and communism applied to governance!
Well, so do we. Businesses have been services oriented for a long time. They divide their core strengths into a variety of services they offer to consumers. However, do you ever see an insurance company with two different divisions selling you the same type of service? Not really. There is one of each and different services build upon each other.
Service orientation in IT follows the same principle. The technologies available today make this an even easier task.
The ease of creating services naturally leads to the issue of governance. How do you prevent developers from re-inventing the wheel each time? How do you ensure that services conform to your operational standards and best practices? How do you prevent unauthorized access to services? The list goes on.
I recently finished discussing governance (the broader topic) with a customer, a large Telco. They suggested that governance is increasingly difficult to implement, not withstanding all the other governance software designed to help. Apparently, developers simply tire of the additional work involved with governance. They ask – what’s in it for me? Any effort that requires a non-zero investment of time and energy, without an incentive, could easily flounder.
Whether you use commercial governance products or not, how do you provide a “carrot” to promote governance adoption amongst the IT teams? Some customers have explored the idea of tying developer bonuses to governance adoption. Some, on the other hand, have considered firing developers that don’t participate. Talk about principles of capitalism and communism applied to governance!
Friday, April 24, 2009
Twitter & BTM
Twitter is all the rage these days, so we're jumping on the bandwagon. You can follow our official line at twitter.com/edhorst_ap. We plan to use Twitter to update all those interested in getting the latest from AmberPoint.
Of course, we're still novices with Twitter. Others seem to have taken the medium quite a bit further. We're not surprised to see our competitors following our Twitter feed, but it is a bit alarming to see them practically stalking anyone's tweets that mention "AmberPoint". And we've seen a few proactively reach out to our existing and prospective customers with fictitious information (much like my observation in a recent post on shopping for a new car).
We can't tell how Twitter will evolve. Is it reasonable to stalk and spam users in Twitterland with unwanted messages and posts? Email provides spam filters -- what does Twitter offer?
At AmberPoint, we'd like to establish a policy to not abuse social chatter. If you wish to follow us, we'd love it. If you wish to interact with us, we'd be happy to respond. However, we plan to avoid spam-like "@joe buy amberpoint" sales pitches to the denizens of Twitter. Perhaps that might be good etiquette for Twitter to proliferate. Imagine being bombarded by salesmen from the another telephone company just because you happened to mention you were using Comcast!
A "Do-Not-Tweet" list, anyone?
Back to management topics. Twitter does remind us of the principles underlying Business Transaction Management. With BTM, you follow the trace of a transaction in real-time, as it flows across a distributed application environment. A transaction can update you on its status along the way, letting you know if there was a problem mid-flight. Of course, that remains the holy grail for BTM. Not all systems are built to provide updates. In fact, most don't. That’s where AmberPoint gets creative. Our technology generates these transaction tweets for you. All you need to do is to follow!
Of course, we're still novices with Twitter. Others seem to have taken the medium quite a bit further. We're not surprised to see our competitors following our Twitter feed, but it is a bit alarming to see them practically stalking anyone's tweets that mention "AmberPoint". And we've seen a few proactively reach out to our existing and prospective customers with fictitious information (much like my observation in a recent post on shopping for a new car).
We can't tell how Twitter will evolve. Is it reasonable to stalk and spam users in Twitterland with unwanted messages and posts? Email provides spam filters -- what does Twitter offer?
At AmberPoint, we'd like to establish a policy to not abuse social chatter. If you wish to follow us, we'd love it. If you wish to interact with us, we'd be happy to respond. However, we plan to avoid spam-like "@joe buy amberpoint" sales pitches to the denizens of Twitter. Perhaps that might be good etiquette for Twitter to proliferate. Imagine being bombarded by salesmen from the another telephone company just because you happened to mention you were using Comcast!
A "Do-Not-Tweet" list, anyone?
Back to management topics. Twitter does remind us of the principles underlying Business Transaction Management. With BTM, you follow the trace of a transaction in real-time, as it flows across a distributed application environment. A transaction can update you on its status along the way, letting you know if there was a problem mid-flight. Of course, that remains the holy grail for BTM. Not all systems are built to provide updates. In fact, most don't. That’s where AmberPoint gets creative. Our technology generates these transaction tweets for you. All you need to do is to follow!
Wednesday, April 22, 2009
Recommended Reading
I should get to blogging more often, but I don’t. So I’d like this opportunity to comment on two successive posts our friend David Linthicum recently made on the InfoWorld site.
David comments on the growth of SOA in a recent post, "SOA is growing...and nobody is surprised". The title alone was interesting. In addition to its increasing adoption, "SOA" seems to be maturing as an architecture and technology stack. Organizations are a lot more cognizant of their business goals for SOA projects and know the tools they need to be successful with those projects. More importantly, they realize the importance of succeeding with their initial projects. Initial success bootstraps adoption, not to mention funding for more projects and a gold star for the project champion! SOA survives as services, as BPM, as Cloud, as Web 2.0, as APIs and more. Services are services. Use them for integration. Use them for reaching out to your business partners. Use them to quickly roll-out new business applications. Use them to create a more agile business environment. As long as the business needs justify the use of this technology, give it your favorite name, go forth and use it!
A more recent post, "Cloud computing needs governance to be successful", comments on the need to extend governance to Cloud computing. In my opinion, and I hope David would agree, Cloud is just another paradigm that layers on top of service orientation. How do you access the Cloud? Via services. How do you Cloud-enable your system? Via services. How do you leverage Cloud infrastructure? By decomposing your application into services that can independently leverage the Cloud platform to scale and adapt based on demand. Ultimately, we’re looking at a massive shift to distributed application development. As VMWare puts it, virtualization and Cloud are the new mainframe. We think it’s a distributed mainframe. So, Cloud services need governance and the issues are even more acute when you now have the choice of running a service on both an on-premise and off-premise Cloud. Imagine a transaction that kicks off in your private data center, hops onto Amazon’s Cloud, makes a few trips to SalesForce.com, and then bounces back into your enterprise. Consider the security implications for such a transaction. More importantly, how do you follow such a transaction, and ensure that it actually delivered business? Governance matters...
Thank you David – might I propose renaming "Real World SOA" to "Real World Applications"? I really don’t know of applications out there that don’t leverage services in one way, shape or form.
David comments on the growth of SOA in a recent post, "SOA is growing...and nobody is surprised". The title alone was interesting. In addition to its increasing adoption, "SOA" seems to be maturing as an architecture and technology stack. Organizations are a lot more cognizant of their business goals for SOA projects and know the tools they need to be successful with those projects. More importantly, they realize the importance of succeeding with their initial projects. Initial success bootstraps adoption, not to mention funding for more projects and a gold star for the project champion! SOA survives as services, as BPM, as Cloud, as Web 2.0, as APIs and more. Services are services. Use them for integration. Use them for reaching out to your business partners. Use them to quickly roll-out new business applications. Use them to create a more agile business environment. As long as the business needs justify the use of this technology, give it your favorite name, go forth and use it!
A more recent post, "Cloud computing needs governance to be successful", comments on the need to extend governance to Cloud computing. In my opinion, and I hope David would agree, Cloud is just another paradigm that layers on top of service orientation. How do you access the Cloud? Via services. How do you Cloud-enable your system? Via services. How do you leverage Cloud infrastructure? By decomposing your application into services that can independently leverage the Cloud platform to scale and adapt based on demand. Ultimately, we’re looking at a massive shift to distributed application development. As VMWare puts it, virtualization and Cloud are the new mainframe. We think it’s a distributed mainframe. So, Cloud services need governance and the issues are even more acute when you now have the choice of running a service on both an on-premise and off-premise Cloud. Imagine a transaction that kicks off in your private data center, hops onto Amazon’s Cloud, makes a few trips to SalesForce.com, and then bounces back into your enterprise. Consider the security implications for such a transaction. More importantly, how do you follow such a transaction, and ensure that it actually delivered business? Governance matters...
Thank you David – might I propose renaming "Real World SOA" to "Real World Applications"? I really don’t know of applications out there that don’t leverage services in one way, shape or form.
Friday, April 10, 2009
Security Isn't Just "Security" Anymore
Companies deploying composite applications often think of security as a complex and daunting aspect of their initiatives, ivolving PKI, Identity and Access Management solutions and so on. But security is often just a matter of knowing what's going on. At AmberPoint, we've been talking about how "Situational Awareness" is critical for the security of composite applications. And that means you not only need to watch your service-enabled apps. You also need to be able to look in on your EJBs and JDBC connections to see what's going on.
I recently spoke with an AmberPoint customer, a large mobile phone retailer, who confirmed this. Their business goal is to integrate as many partners as possible to enable cell phone activation. They're starting with around 500 services, and for Phase I AmberPoint monitoring meets their security requirements!
How is that? Well, they need to get a handle on what's out there. That’ll help prevent rogue services. Rogue services are usually not malicious--they're just orphaned services, test apps that (somehow) slipped out into production, or an "unofficial" integration point that made a developer's life easier at some point in the past. Preventing all this is the first step on the road to trustworthy composite applications. And you need to keep in mind that an intermediary or broker approach won't let you rest as easily as the broad coverage you get from a BTM solution like AmberPoint.
I recently spoke with an AmberPoint customer, a large mobile phone retailer, who confirmed this. Their business goal is to integrate as many partners as possible to enable cell phone activation. They're starting with around 500 services, and for Phase I AmberPoint monitoring meets their security requirements!
How is that? Well, they need to get a handle on what's out there. That’ll help prevent rogue services. Rogue services are usually not malicious--they're just orphaned services, test apps that (somehow) slipped out into production, or an "unofficial" integration point that made a developer's life easier at some point in the past. Preventing all this is the first step on the road to trustworthy composite applications. And you need to keep in mind that an intermediary or broker approach won't let you rest as easily as the broad coverage you get from a BTM solution like AmberPoint.
Tuesday, April 7, 2009
Vendors & Rants
I recently found myself in the market for a new car. Given the buyer's market, I decided to look at a larger pool of candidates—which is probably a good idea no matter what product you’re looking for these days. There were several good options in my chosen price range. There’s the Prius, the Jetta, the new Mazda, and the new Insight, among others.
As I visited each dealer, it was interesting to hear them compare and contrast their cars against the others. The VW folks, who were touting their Diesel cars, said the Prius is all hype and that its fuel savings is overshadowed by its battery issues. The Toyota folks were of the opinion that the Prius is the best selling car in the market, period, and that that anyone who drives anything else is silly to do so. The Mazda folks didn't dare venture into the mileage debate. They positioned around the performance and fun aspect. And so on.
Ultimately, my selection was based on my needs, not the car salesmen’s commentary or any brand positioning. More importantly, my choice took into account the entire sales experience including internet-based price quotes, visits to the dealerships, test-drives and the individuals I dealt with. Too negative a commentary or too pushy an approach puts me on high alert! I like to know that I can trust the person I'm interacting with.
No matter the product, you will always run into salespeople and evangelists who try to vilify their competition. However, it’s good to keep in mind that baseless comments, speculation and obsession with denigrating competitors ultimately say more about their companies and products than it does about the competition they're bashing.
We face these same issues in our market. We have competitors who watch every change on our website, critique it, then turn around and copy the same graphic, marketing message or product terminology they just finished bashing. Tolerating this kind of behavior is one of the costs of leadership. At AmberPoint, we have focused on building an experience that our customers rave about. My customers always have feedback for the product, both positive and negative. However, there is nothing but praise for our field and customer support staff. Kudos to those teams!
It would behoove you to search the blogosphere (and now twitto-sphere) for your own competitors. Rest assured, you’ll find interesting comments from them aplenty. How you respond to them defines you and your company.
This week we are announcing some truly unique capabilities in the area of Business Transaction Management. Having announced SLA Management and Exception Management for business transactions in the past, we ran into many customer scenarios where proactive detection of problems was next to impossible. Software systems always find a way to surprise you!
That’s why we’re rolling out an end-to-end Transaction Saftey Net™, a rich set of capabilities that help organizations manage the risk of their business transactions. Have a read here.
As I visited each dealer, it was interesting to hear them compare and contrast their cars against the others. The VW folks, who were touting their Diesel cars, said the Prius is all hype and that its fuel savings is overshadowed by its battery issues. The Toyota folks were of the opinion that the Prius is the best selling car in the market, period, and that that anyone who drives anything else is silly to do so. The Mazda folks didn't dare venture into the mileage debate. They positioned around the performance and fun aspect. And so on.
Ultimately, my selection was based on my needs, not the car salesmen’s commentary or any brand positioning. More importantly, my choice took into account the entire sales experience including internet-based price quotes, visits to the dealerships, test-drives and the individuals I dealt with. Too negative a commentary or too pushy an approach puts me on high alert! I like to know that I can trust the person I'm interacting with.
No matter the product, you will always run into salespeople and evangelists who try to vilify their competition. However, it’s good to keep in mind that baseless comments, speculation and obsession with denigrating competitors ultimately say more about their companies and products than it does about the competition they're bashing.
We face these same issues in our market. We have competitors who watch every change on our website, critique it, then turn around and copy the same graphic, marketing message or product terminology they just finished bashing. Tolerating this kind of behavior is one of the costs of leadership. At AmberPoint, we have focused on building an experience that our customers rave about. My customers always have feedback for the product, both positive and negative. However, there is nothing but praise for our field and customer support staff. Kudos to those teams!
It would behoove you to search the blogosphere (and now twitto-sphere) for your own competitors. Rest assured, you’ll find interesting comments from them aplenty. How you respond to them defines you and your company.
This week we are announcing some truly unique capabilities in the area of Business Transaction Management. Having announced SLA Management and Exception Management for business transactions in the past, we ran into many customer scenarios where proactive detection of problems was next to impossible. Software systems always find a way to surprise you!
That’s why we’re rolling out an end-to-end Transaction Saftey Net™, a rich set of capabilities that help organizations manage the risk of their business transactions. Have a read here.
Monday, March 23, 2009
Mind Your Transactions When Times are Tight
These days, it’s more important than ever to ensure your business systems work like they’re supposed to. For starters, customers are harder to come by. They’re pickier, too, since they’ve got a wide range of bargain-basement options. The slightest glitch in your system and your competitor gets the business, not you. Simply put, you can’t afford to have unreliable systems.
It’s pretty clear how transaction failures affect your bottom line. Shopping carts lose their contents, accounts fail to be provisioned, orders are lost and packages become untraceable. Not good. And remember, it doesn’t matter one bit to your customers why, how or where the error occurred. All they know is they weren’t served well.
Modern application architectures are becoming increasingly brittle. With interconnected, multi-tier applications running in virtualized environments, isolated failures, errors or slowdowns can have a dramatic impact on the overall system. It’s tedious and expensive to locate and repair these issues. Your teams waste countless hours searching through log files or looking at multiple consoles in order to piece together the problem and its root cause.
One of our customers met this issue head on. A Fortune 100 financial services company that’s one of the largest, most complex transaction-oriented organizations in the world. A single business unit within the bank processes 780,000 transactions per day, spread over 3,500 distributed nodes. The Senior Development Manager had this to say:
“The risk for our application is enormous. In our business, with the nervousness of the market, perception is key. Even with 30 minutes of downtime costing 100,000 Euros, our face to the street is much, much more important than transactional dollars.”
This customer was facing a huge challenge in pinpointing application problems because processes and transactions were dispersed across thousands of blade servers throughout the data center.
Business Transaction Management addresses these pain points. Done the right way, it provides visibility into every transaction flowing from start to finish across the environment. It detects slowdowns and failures and notifies you immediately of the problem. And it pinpoints the source of the transaction failure so you can quickly remedy the situation.
For more on this topic, have a look at our analyst report on Business Transaction Management. It gives more information on the Fortune 100 company I described here.
It’s pretty clear how transaction failures affect your bottom line. Shopping carts lose their contents, accounts fail to be provisioned, orders are lost and packages become untraceable. Not good. And remember, it doesn’t matter one bit to your customers why, how or where the error occurred. All they know is they weren’t served well.
Modern application architectures are becoming increasingly brittle. With interconnected, multi-tier applications running in virtualized environments, isolated failures, errors or slowdowns can have a dramatic impact on the overall system. It’s tedious and expensive to locate and repair these issues. Your teams waste countless hours searching through log files or looking at multiple consoles in order to piece together the problem and its root cause.
One of our customers met this issue head on. A Fortune 100 financial services company that’s one of the largest, most complex transaction-oriented organizations in the world. A single business unit within the bank processes 780,000 transactions per day, spread over 3,500 distributed nodes. The Senior Development Manager had this to say:
“The risk for our application is enormous. In our business, with the nervousness of the market, perception is key. Even with 30 minutes of downtime costing 100,000 Euros, our face to the street is much, much more important than transactional dollars.”
This customer was facing a huge challenge in pinpointing application problems because processes and transactions were dispersed across thousands of blade servers throughout the data center.
Business Transaction Management addresses these pain points. Done the right way, it provides visibility into every transaction flowing from start to finish across the environment. It detects slowdowns and failures and notifies you immediately of the problem. And it pinpoints the source of the transaction failure so you can quickly remedy the situation.
For more on this topic, have a look at our analyst report on Business Transaction Management. It gives more information on the Fortune 100 company I described here.
Thursday, March 19, 2009
What's in a Name?
We’ve seen a lot of name changes for distributed applications. First it was Web services-based applications and then SOA-based applications. Now there are some question marks associated with the term SOA itself. From our vantage point, services are not only surviving but thriving. As customers modernize their applications, services are used in one form or another. Many use terms like “composite applications,” “connected systems” or even “compositions.”
Does it matter what term we use to call these distributed systems? Perhaps it would suffice to simply call them “applications” and know that in today’s enterprise landscape the de facto application is cobbled together from services developed in-house, or exposed by commercial off the shelf applications, SaaS, legacy systems and so on. Different services may support different lingua franca to enable a conversation. They may use different platforms and programming models for development. However, they are all examples of enterprise services. Furthermore, while most organizations encourage service reuse, some simply do not! With application modernization projects continuing unabated—even in these budget-conscious times—silo’ed applications are increasingly becoming the exception.
Of course, your management solution shouldn’t care what you call the application. Nor should it care what comprises the system. To succeed with loosely-coupled systems, you need visibility and control of the whole enchilada – at the application level. You need to track the transactions end-to-end, no matter the platform, the infrastructure or the transport protocols involved. But I digress.
I’d like to hear from you on the subject of naming. What do you call YOUR distributed systems and new project initiatives? Are you still saying “SOA?” Do you use another term instead? Or is it simply your “claims processing system” or your “procurement application” with no mention of the underlying architecture?
Your comments, please.
Does it matter what term we use to call these distributed systems? Perhaps it would suffice to simply call them “applications” and know that in today’s enterprise landscape the de facto application is cobbled together from services developed in-house, or exposed by commercial off the shelf applications, SaaS, legacy systems and so on. Different services may support different lingua franca to enable a conversation. They may use different platforms and programming models for development. However, they are all examples of enterprise services. Furthermore, while most organizations encourage service reuse, some simply do not! With application modernization projects continuing unabated—even in these budget-conscious times—silo’ed applications are increasingly becoming the exception.
Of course, your management solution shouldn’t care what you call the application. Nor should it care what comprises the system. To succeed with loosely-coupled systems, you need visibility and control of the whole enchilada – at the application level. You need to track the transactions end-to-end, no matter the platform, the infrastructure or the transport protocols involved. But I digress.
I’d like to hear from you on the subject of naming. What do you call YOUR distributed systems and new project initiatives? Are you still saying “SOA?” Do you use another term instead? Or is it simply your “claims processing system” or your “procurement application” with no mention of the underlying architecture?
Your comments, please.
Subscribe to:
Posts (Atom)
Posts
