Integrated Infrastructure Blog

Now That's a Real Forklift Upgrade

I have to admit... I don’t really know how our customers use OpenEdge. I do know there are a ton of customers - over 65,000. And, if that weren’t enough, there are over 1,500 partners too. What's more, many of them are in-production with SaaS offerings.

Damn, that’s a lot.

(If any analysts are reading... just think about the opportunity of selling Actional into that installed base even if we never got another “new logo” sale.)

This week’s press release follows on from several months of a beta period where about 20 or 30 OpenEdge customers tested the newly released Actional integration.

As TVH Forklift Parts realized, knowing what’s happening in their integrated infrastructure, and being able to assure a consistent level of service has tremendous value to a distributed and shared infrastructure.

Why is this important?

It’s about the business context. Without that context, solutions are just technology (we have good technology too… but that’s not enough).

That’s the difference between assurance and management. Assurance implies business-technology coordination to achieve a business result. Management implies your technical components are up and running. Big whoop. Just today I spent 2 hours on the phone with T-Mobile. All the technical components were up, but it still wasn’t working. I know you can relate.

Colleen points out that our partners are being viewed more and more as business partners, not just technology providers. Simply put, our partners need technology to understand the business impact of “events” within their infrastructure.

Understanding the business impact means that we (technology infrastructure providers) need to provide an awareness of the business context when problems occur. The only way to do that is to track business context all the time.

I’ve heard a few times recently of prospects who have a “competitive” solution in place to track business assurance… but when I probe, it seems they don’t run it all the time because (pick one):

1. It impacts performance of my applications. (it doesn’t scale)
2. It collects too much information. (it doesn’t scale)
3. It requires too much CPU on my app servers. (it doesn’t scale)

I don’t understand how people think a solution that doesn’t run all the time can do the job.

Let me rephrase.

If it’s not running all the time and collecting context of your business, how are you using the context of the business to make better run-time decisions?

Simply put, you’re not.

I’m glad to welcome TVH Forklift Parts to the Actional family. And, if you’re reading, thanks for sharing your story.

Holy Cloud! Thousands of Customers & Hundreds of Partners

At parties, I do everything I can to avoid talking about work. But, when forced, people eventually ask where I work. When I tell them Progress Software, it's usually followed by "No, we're actually a big public company that does more than databases."

I bet you didn't know we had thousands of SaaS customers in production using our products... Well we do!

And, by the way, it makes a great opportunity for each of those to use Actional for both cloud governance and inter-mediation for customer-specific policy and really flexible standards-based application layer security. If we never sold a new logo, we could still grow like weeds. Our tiny competitors are struggling to survive the recession after raising tons of money their investors will never see again, and we're in a position to thrive by delighting our existing customer base. Awesome.

And not only do we have thousands of customers, we have hundreds of partners adding vertical value to our software solutions.

That partner thing. It's big here.

Why does it work so well for us? Well, that's a huge thanks to the culture of collaboration here at Progress. Actually, it's more than that. It's like an open source attitude towards collaboration (even when we're creating commercial products). We listen, we adapt, and we learn.

We're a day away from the end of our fiscal year, and things are really crazy as you'd expect as we close our year end business. This has been a real transitional year for Progress and another successful year for Actional:

1. We've absorbed IONA and Mindreef, and rolled out new products around integrating those technologies with Actional.
2. We've received top recognition from Gartner and Forrester analysts, and Forrester even delivered a few use cases demonstrating hard ROI numbers around Actional deployments at our production customers in finance and telco.
3. We've delivered another major release update, demonstrating Actional's capabilities well beyond traditional web-services based SOA by integrating Progress OpenEdge, SAP ABAP, IONA Orbix IIOP, Spring, and Microsoft BizTalk orchestration support.
4. We've weathered a very bad economy, and we're quite well positioned for a very strong 2010 with our top-selling Business Transaction Assurance offering.

SOA Upgrade to British Airways

British Airways (BA) is turning to service-oriented architecture (SOA) and Progress Software to connect over 600 different electronic systems and processes involved in getting BA passengers in the air.

BA has more than 250 key applications distributed over 300 locations around the globe, which explains why they chose Progress. From an integration perspective, Progress® Sonic ESB® excels in those scenarios that require the integration and management of hundreds or even thousands of systems. One Progress customer was able to deploy its integration backbone out to 25 locations a day (and can update them in a fraction of that time).

One can only guess how many of those 250 systems are touched when you travel BA. Everything from choosing your seat assignment to charging your credit card (once only please), to selecting a vegan meal is managed via systems. And let's hope those systems succeed in keeping track of your luggage.

The real-time data synchronization of Progress® DataXtend® Semantic Integrator (SI) allows BA to significantly improves information quality while reducing costs associated with data replication. And Progress® Actional® SOA Management provides BA with the visibility they need to make sure your reservation gets booked and you make it to your destination in a timely manner. Weather permitting, of course. ;)

Thanks to SOA, BA is able to extend the features of its e-commerce site right through to its airports, allowing greater self-service functionality and 'plug and play' capability to over 25,000 users.

"Moving this to a highly automated environment is a challenge, but SOA quickly proved itself to be the right approach to achieving our goal of a fully agile environment."

So the next time you take your family to London (or Disney - that's my family's destination of choice at the moment), think about how many transactions went right along the way, automatically.

I love when technology makes a tangible difference. Pretty cool stuff.

Alphameric Beats the Odds with Progress Software

It’s always great when a company is willing to talk publicly about your products and services, even when the public statement incorporates a bad pun. In this case, Alphameric Solutions Ltd., the leading technology provider to the bookmaking marketplace in the UK and Ireland, wasn’t holding their cards close to their chest when they decided to collaborate with us on a press release. Alphameric selected the Progress® Sonic® ESB to revolutionize the way they handle content and messages across their network because they couldn’t roll the dice with unreliable infrastructure. Sonic’s continuous availability architecture made this a sure bet.

With new virtual games such as poker and fantasy football being released every day, Alphameric was struggling to manually keep all the feeds and databases up to date. The new SOA-based approach makes accomplishing those tasks a lead pipe lock. Alphameric can now change data more quickly, easily bring new feeds online, without gambling with the accuracy through automation.

Using Progress, Alphameric is achieving operational responsiveness, increasing revenue and improving customer service to finish in the money. You can’t beat that. I’d add that this decision puts them clearly ahead of the game, but Matt Smith, our Senior Enterprise Architect quoted in the press release, beat me to the finish on that one.

OK, I think I got that out of my system now. Sorry about that...

Business Transaction Management with SAP

If you follow Actional, you may have seen that we announced Actional 8.1 today.  The most interesting part of the release is our new support for SAP.  Yes, we already supported SAP NetWeaver (like most of the other people in our space) so unless you're an SAP aficionado, you probably won't recognize the importance of natively supporting SAP ABAP - which is what we've announced.

SAP supports two main application server environments: one based on Java and one based on ABAP, SAP's own programming language (you might also hear the term "basis" which is another name for the ABAP application server stack).  OK, with me so far?  While SAP support both, almost all of the SAP packaged applications are written using the ABAP stack - Java is primarily used for infrastructure services (things like their portal).

With this new version, we've added the ability to trace business transactions into and through ABAP - so we can detect problems even within the ABAP portion of a business transaction.  This is critical for many SAP customers because - without the ability to do this - SAP packaged application logic is seen as a black box silo.  And, with 100's of millions of lines of code in the SAP packaged applications, that a pretty big area to have a blind spot.

While there are a lot of business transaction management vendors out there that support SAP, they are usually referring to the Java side of SAP. As a result, once a transaction hits ABAP (and almost all of them do) it enters the black box and can't be seen again until it leaves ABAP.

As you might have guessed, we're really excited to extend Actional's patented transaction tracing to SAP's core platform.  If you're an SAP user, and need to ensure the success of business transactions that span SAP and other applications, platforms, and middleware then hopefully you'll get a chance to see whether this unique Actional capability can help you.

Who’s in Charge of the Architecture? You Are.

In Replacing Large Applications – Who’s in Charge?, Kathy Harris at Gartner writes:

"Most of the organizations have no real architectural vision for their system. The result is that they are essentially allowing the vendor to establish their architecture. This may be ok in the long run, but for many organizations, it is a de facto decision rather than an active choice."

While many vendors have the expertise to make the right recommendations for their portion of a solution, things become much more complicated when you start integrating their applications with others. Complexity increases exponentially when you consider the changes being made by other departments, in other locations, and by your partners.

The complete picture can be daunting. Great enterprise architects understand that you don’t need an exact schematic of how infrastructure will evolve over the lifetime of the business. Rather, you need to take proactive steps to incorporate flexibility into your architecture. And the best way to do this is to partner with vendors that adopt Open Integration principles to ensure that your architecture can grow to support the business as it evolves.

If you’re concerned that your vendor is prescribing your architecture for you, consider these three Open Integration requirements:

1. Make sure your vendor supports open standards. This means that they support de facto standards as well as those specific to your industry. More importantly, they should also be involved in defining emerging standards, to ensure future compatibility. If your vendor supports open standards, you have a better chance of adapting to change.
2. Develop an open architecture. Look for solutions that are modular in nature and allow you to mix and match functionality to meet your needs, while only paying for what you use.
3. If possible, leverage open source. By using open source, you reduce your price of admission to mission-critical infrastructure. More importantly, you have direct access to the source code and those who wrote it.

Organizations need to take an active role in defining architecture. All three Open Integration principles allow you to actively choose what’s right for your business, instead of being at the mercy of others and hoping it will all work out in the long run.

Secret No. 2 - The Myth of Five Nines

Lets continue to pull back the covers on highly available integration infrastructure.

Listen now to Part 2 of the Five Dirty Little Secrets of Highly Available Integration Infrastructure podcast series: The Myth of Five Nines.

Presented by Hub Vandervoort, CTO, and Ken Rugg, VP and General Manager, Integration Infrastructure, Progress Software, this is the second of five new interview-style podcasts that reveal the software industry’s five "dirty little secrets" or misconceptions of a so-called highly available integration infrastructure.

Three minutes of downtime may not seem detrimental now but if that failure occurs during peak transaction times, it will result in lost revenue and poor customer service. In this podcast, Hub and Ken present ideas on how to deliver a highly available enterprise infrastructure.

> Secret No. 2 - The Myth of Five Nines

Tune in next time for Secret No. 3 - Recovery Time.

How to Be Agile Without Falling on Your Face

Eric Knorr of InfoWorld recently wrote an article about how testing was the key to how to be agile without falling on your face.

While I agree that IT organizations are squeezed and that quality is often given short end of the stick, I don't think Eric's solution of "optimize the efficiency of your testing tools, environments, and methodologies" is necessarily the right way to think about the problem.

Most organizations think of quality as a role (the role of the tester) - and as a result most testing tools are just that: specialized tools designed with the needs of the professional tester in mind.  The problem is, with modern applications, quality doesn't start and the tester and doesn't end at the tester.  Quality is a responsibility not a role - a responsibility of everyone involved from development through production.    This is one of the reasons that developers really like our free Actional Diagnostics tool (used to be called Mindreef SOAPscope) - it's designed from the perspective of the needs of developers, but it focuses on improving quality. For example, we found in formal ROI analysis that deploying our products in the hands of developers reduced the number of production issues by 25%.

So, rather than focusing on how to make testers more efficient (which will only get you so far), it's better to focus on tools and SOA infrastructure to help developers and architects avoid defects before they are created.  But these aren't testing tools because developers don't use traditional testing tools.  If you have 10 defects, avoiding just one of these development (something which is eminently doable) is as beneficial as improving testing productivity by 10% (something which is probably a lot harder).

On the other end of the spectrum, with today's interconnected applications the number of defects which will show up in production is significantly higher than traditional applications, and you'd likely have to increase your testing by a factor of 10x to get to the same production-defect-rate as a traditional silo'd application.  Alternately, a 10% reduction in the time-and-cost of resolving issues in production easily pays off as much as a 10% improvement in testing efficiency.  And, achieving a 10% reduction in this is definitely achievable... Now imagine you could reduce the time-and-cost of resolving issues in product by 85%...

Actional Business Process Visibility (Definition)

I haven't been writing much (here) lately but, well, I've been thinking of writing.

The process is weird. Topics come into my head often enough but I talk myself out of sharing. I'm not sure how useful they are or how biased I'd sound.

I'm working on the outline for training materials integrating Sonic and Actional, and I had to explain Actional Business Processes (tracking of)  to some new people.

As I did that, I remembered hearing a prospect earlier this week say "Actional sounds good but really functions more at an IT level, we're interested in monitoring at a business level."

I must admit my bias but Actional not only monitors at a business level, but we tie it back to the IT level, to achieve two great benefits:

1. Business people and IT people can communicate because they are working off the same vocabulary of processes, services, KBI's, Dimensions, etc;
2. Staff can look at the same picture (automatically drawn and updated in real time) and see the business impact of a technology change/failure, and vice versa.

My definition to the training team earlier today went something like...

"Remember how Actional automatically learns flows. Well, Actional business processes are really just named sub-flows. Meaning, without any orchestration or BPM we can take a 'free form sub-flow,' name it, and we have something we call a business process that we can track as a unit. We can track it that way even in a shared environment, so shared components report in only their statistics for that process, when implementing policy or service level agreements. If other processes or services use those shared components, we can separate all the different performance statistics (for policy based management) so that things aren't lost in the average statistics as they are with so many other management systems."

You saw our press release earlier this week about Q1's results. Actional rocked, again.

It's because we do some really unique, creative and relevant stuff, like business process visibility.

Cloud Computing... It Depends on Who You Ask

What exactly is cloud computing? Lately, this is one of the most often repeated question in any discussion about the Cloud. And the answer depends on who you ask! (Personally, I think that if there are not at least three different popular definitions of a new technology, then the technology is not in its "hype" phase of the hype cycle :-) ).

Cloud is often confused to be just one of:

• Utility Computing - The on-demand resources with dynamic provision offered by virtualization platforms such as VMware, EC2 etc.
• Grid computing - Loosely coupled discreet computing nodes, that come together to form a larger computing-grid.
• SaaS - Just the notion of a software abstracted on the web is cloud to some.
• PaaS - To some, cloud is if one were to "build" the solution and then deploy it on a virtualized platform on the web.
• User centric cloud - RIA desktops that provide seamless and integrated access to information and services on the web, while still retaining a "sane" visual front to the user.
• Even Wikipedia defines it as: The majority of cloud computing infrastructure as of 2009 consists of reliable services delivered through data centers and built on servers with different levels of virtualizationtechnologies. The services are accessible anywhere in the world, with The Cloud appearing as a single point of access for all the computing needs of consumers.
• And, I am sure there are more!

Syscon attempted to reconcile the definitions by getting no less than twenty one (!!) industry experts to define cloud. Their definitions had wide ranging defining attributes: elastic, virtualized, services over the web, multi-tenanted, pay-as-you-use, massively scalable technology enabled services, SaaS is the consumer-face of cloud computing, distributed utility grid (wow!), on-demand resources with APIs, and more!

What I see missing though is the end enterprise view. It is this view that brings all of the above (and more) together. As I see it, this is "cloud computing". A fairly abstract IT enterprise landscape. Where the biz requirement is real—with its solution made available over the web, with simple web based user access, with guaranteed SLAs on service availability and performance, with seamless integration to other information sources/services over the landscape. The exact location, platform, configuration, size and such are all abstracted from the enterprise by the solution provider. Further, the solution provider also takes care of maintaining the application (enhancements/bug fixes), managing the production environment, and managing any backend integration requirements that the client-enterprise may have - offering a complete "managed service". The enterprise needs to focus just on the biz at hand, and in defining the IT solution that is needed. The solution-service providers takes care of the rest. All of them coming together to form the enterprise "cloud" - accessed over the web, managed over the web and probably even orchestrated over the web.

The enterprise Cloud will also evolve over time. When there is just one ISV making a solution available in the above managed model, that is SaaS. If the same ISV also "builds" it on the web before making it available on the web, then that is PaaS. If the ISV just uses storage on the web, then that is cloud storage. If the same solution is deployed within the enterprise network on a virtualized platform such as VMware, then that is virtualization. If the solution is distributed across discreet computing "nodes" on the web, then that will be the computing grids. Now fast-forward a few years... If the IT landscape in an enterprise architecture is a combination of all of the above types of solution environments, then there is an opportunity for a loose "biz grid" that can bring all of these together, which in many ways is already prevalent today - the SOA infrastructure! SOA is all about discreet services that are location agnostic, with standards based description and easy access. Today's SOA environments are very very vendor dependent (that is assuming the emphasis is on the reliability and performance). Soon we may see this a reality. A vendor neutral SOA environment that will bring together all the disparate IT solutions in the enterprise, both within and on the cloud. Likewise, Web 2.0 will define the user experience that brings all of the same solutions in a seamless integrated and very-functional UI.

Below is a visual of what I'm thinking... use Comments to let me know what you think.

Rumors of My Death Have Been Greatly Exaggerated

There was a time when I was diving intensively and I'd call my boss at the end of vacation to let him know I was still alive and would be back in the office as planned. I even left my passwords and his information with my brother so my bro could send him my laptop if a fatal event occurred. Have you ever written a "here's what to do if I die" letter to anyone before? I highly recommend it. It's good for the soul.

But, I digress... We're not here to talk about my death but the death of service-oriented architecture (SOA). It's all the rage since Anne's post the other day.

A good summary of the chatter it's stirred up can be found on Twitter, so I won't head there. But, I will point out that the second comment on Anne's post was mine - and I think my one line summarizes most people's feelings - whether they believe SOA is dead or not:

"SOA must die, so we can move on with, well... SOA"

From our perspective here at Actional, the death of SOA from a marketing perspective (but not from a technical one!) has been going on for some time. So, I wanted to give some insight (I'm usually not punny but couldn't resist - go ahead, click on the "insight link" to see what I mean) into our messaging and positioning of the Actional platform in advance of some releases you'll see later this month.

Clearly, we're defocusing our SOA message. There's been a bit of disillusionment with SOA, and associating with it doesn't seem to be in vogue. Now, we're not the only ones to do this. One of our competitors has decided there are many "hot topics" to grab onto and has a flash animation scrolling through them all to make sure people realize their solution is as good for cloud, SaaS, Web 2.0, and composite apps, as it is for SOA.

Our perspective is different. From our perspective, a SOA message is limiting. Fundamentally, we're about managing/controlling services, and anything built upon services, regardless of whether a SOA architecture is used or not. We (and I) believe that by messaging around SOA, organizations that are disillusioned will "throw the baby out with the bathwater" when, in fact, huge ROI* can be achieved with Actional.

The Buyers' Guide I wrote recently mentions SOA only once, and talks more about composite applications and business processes (both based upon services) and the benefits of a performant solution like Actional providing visibility and control. (Email me directly if you want a copy without registering.)

For the record, I believe fully in SOA, SOA principles and the use of SOA to drive business and IT alignment. Done properly, SOA infrastructure adds agility, accountability, and makes IT's contribution more visible to executives from a business perspective. I'll be very happy when the SOA paparazzi move onto a younger celebrity and let us get on with our SOA lives.

* Later this quarter - frankly, I'm just not sure of the date - we will be releasing some independent third party ROI analysis and case studies of some of our production customers. The idea being that these customers have adopted Actional for some time. What did they achieve? What was their ROI? What is their future expected ROI? And, how can you use this information (discounted for risk) to justify a decision on Actional? Stay tuned.

The Semantic Dialogues Have Begun!

Are you thinking about OSS/BSS Integration?

The Semantic Dialogues tells the story of how National Networks, a fictional telecommunications service provider, pursued and achieved data interoperability within their SOA infrastructure. When the VP of Systems Architecture, Eric Golden, welcomed Mick Dundon, his new director of Data Architecture, he didn't pull any punches. "The top priority for your new team is solving our data problem. National Networks is under pressure from competition and regulators and needs to become more efficient. We can't afford another round of failures in our attempt to control OSS/BSS sprawl." And with those instructions ringing in his ears, Mick built the team that could make it happen.

How does this dialogue evolve? Who's involved and what decisions are being made? Are they the right ones? Does the story sound familiar? Read the prologue and first chapter of The Semantic Dialogues today. Then revisit every two weeks when we post the next chapter. Follow The Semantic Dialogues... they have begun.

Can You Unpeel a Banana?

Maybe, but the banana won't ever be the same. If we extend this really poor analogy, we'll have a more flexible and scalable banana. (Sorry, I couldn't help myself.)

Glanced at twitter and saw @windley tweet "The trend to disaggregation gives users more choice, but necessitates other tools for threading the experience together.”

I couldn’t agree more. In fact, I liked the way he said it so much, I kept re-reading his tweet. There was something in my head that wanted to come out.

As a public representative of Progress Actional, I’m quite widely available online in various communities, blogs, and such. As my mind skitters over all sorts of news and information, I leave comments here and there, I tweet on various ideas, and blog on more comprehensive thoughts.

But being the scatterbrain that I am, I lose sometimes track. Was my comment approved? If not, I may turn it into a post of my own. I just signed up to the SOA Interest Group on LinkedIn, but did they approve my request? Has that forum been quiet, or did something happen to my subscription? How do I keep track of the services I’m using, my interactions with them, and turn that to a stream of consciousness to achieve my goals? How do I analyze the progress I’ve made, the themes that resonate, and capitalize on the effort?

Damn good questions, but SOA what?

Well, reread the last paragraph there, but think services in the context of composite application development and SOA, not sites and communities.

All you services and SOA experts out there, how do you keep track? How do you track users of services? Dependencies between services? How can you keep track of which services use which protocol, regardless of whether they are part of your SOA infrastructure, or just part of your integration backbone? How do you track from the earliest part of the lifecycle when the entire system is contained on a single laptop, through to production when it’s fully deployed and distributed? Worse yet, what if you’re using shared services in development, and your development project depends upon resources outside of your team and your control? It's worse because then you have a versioning problem even before you release a single line of code to production.

Now that we’ve disaggregated, we need to re-aggregate. That is, we need to unpeel the banana. But, we can make improvements (I have the theme song to The Six Million Dollar Man in my head). Re-aggregate automatically, only loosely, and do it using a layer of meta data around the business. One user may want a view by product, another by business process, and a third by customer type, or product class. Well, I hope you get my point that the whole idea is that it doesn't matter what your meta data layer is, only that it maps scalably and flexibly to address your current and future business needs.

That's where Actional comes in. Once services are used to disaggregate an integration project, Actional is the tool to thread the experience together at a meta, or logical, layer based upon the business. And, that's how technology can help a company use service-orientation to address business needs more rapidly than ever before.

Impact of Cloud Computing on Enterprise Architecture

What impact will Cloud Computing have on your enterprise architecture? Why should you care?

In this podcast David Bressler, SOA Evangelist at Progress Software, presents his thoughts on how Cloud Computing will make it easier for you to get business-critical information to your consumers. As applications become more distributed, the data can often become muddled. During this podcast, David allows you to imagine what the impact would be if you could easily bring information from multiple data sources into the cloud, present it contextually, and then use it in the best way possible.

For more SOA podcasts, subscribe to our iTunes channel.

Question: How Do You Manage Your Policies?

Answer: Hopefully better than the NYC Department of Traffic.

Before you laugh at them, think very carefully about your model of SOA Governance.

Gartner analyst Frank Kenny uses a slide that shows SOA Governance containing four key governable elements:

1. Service Governance
2. Process Governance
3. Policy Governance
4. Profile Governance

I agree with Frank's model and think that it's really important to be able to fully decouple policies from the SOA infrastructure so that they can be properly governed. Proper governance enables policies to have have their own lifecycle, and even to be owned by a team separate from the service owner.

SOA What? Why is this important? Well, governance drives policies. Governance doesn't dictate "on your next release, you must..." Rather, governance demands compliance by a certain date or in a certain time period. These policies therefore have a life of their own - a life that needs to be managed. Also, often the "policy expertise" (think security or corporate governance) is often not in the development team. In fact, distributing "policy expertise" to the development often leads to problems of interpretation... developers are left to do their best interpreting policies as they implement their services. Again, security is a good example. Not all developers are security experts. And, it's easier (and cheaper!) to have security trained staff write a good policy, than train every developer on security policy interpretation.

Fully decoupling policy has other advantages as well if the product that implements the policy has the right abstractions built in to enable dynamic policy-service coupling. For example, a policy can be written for all "external customers" -- and automatically inherited by any new external customer as they are discovered (configuration implies a prior knowledge of the customer... don't get me started on how little we actually know about what our systems are really doing). Another great example, is Actional's ability to evaluate policy once, closest to the customer, as a way of: (1) optimizing policy calculation and overhead, and (2) driving policy to relate directly to meaningful customer/business experience, rather than "arbitrary" technical statistics like CPU load or response time.

Now that you've had time to think about the policies that govern your mission critical applications, I bet you can relate a little bit more to those guys at the NYC Department of Traffic. Scary, huh?

Actional @ Codecentric.de

Our very own Eric Schaumlöffel presented the latest on Actional and DataXtend SI at Codecentric's Friday meeting. They've written up a short blog-post which I'd like to comment upon briefly.

Actional doesn't actually "mark the messages with a unique tracer" as they say in the post. We do have a unique (and patented) way of tracking message dependencies across nodes, discovering consumers and producers that can't be replicated (or hasn't been yet) by vendors who do port sniffing or who have "agents" that are really intermediaries. The important thing is that we do not affect the message, nor do we depend upon the message being in the clear. Why is this important? Well, for starters customers don't like having their messages messed with. But, from a technical perspective, it means that: (1) you don't need to have Actional everywhere in order to get value (we don't have to be on both sides of the communication), and (2) you can remove Actional without affecting your application or requiring any recoding. Yeah, it's like magic... only it's real.

Another thing. The key difference, and the basis for many other differences in our product from what is expected of a solution, is that Actional tracks dependencies BETWEEN nodes, whereas most products, like Dynatrace care about what happens inside nodes. Sometimes products can do "one-hop dependency tracking" (meaning, they can see which nodes communicate with each other, but they cannot trace the communication across multiple hops, like from a consumer, to a portal, to a web service to a database, and then identify unique cluster members for each message for every message in real-time/run-time) whereas Actional can track end-to-end flows, without affecting performance or scalability. And we do it on across a list of platforms and protocols that's quite long (Ouch. Note to self, update website with latest platforms/protocols!). Yeah, again, it's magic. Magic in GA! Shipping. Really.

Finally, they mention that it's weird to do security in a management tool. This is where language fails us. A topic that's close to my heart (here and here). Actional has three offerings (products?), all based upon the same technology so that it is easy for customers to move between them and so that all integrate seamlessly (single UI, single policy expressions, single server to manage 1000+ nodes, etc.). The three are:

1. Actional for SOA Operations, our "monitoring" tool that provides automatic visibility, policy management, and root-cause analysis,
2. Actional for Active Policy Enforcement, our "security" tool, that includes all Actional for SOA Operations functionality, and
3. Actional for Continuous Service Optimization, our "business optimization" tool, that includes all security and monitoring capabilities of the other offerings.

The reason for this variety of offering is because customers value capabilities differently from each other. Some customers drive their "governance" efforts around security, whereas some just want to address the "visibility gap" while others perhaps are not ready for "business optimization."

I'd like to personally thank Codecentric for the opportunity to speak at their meeting, and I'm confident that they found Eric knowledgeable and informative.

Never the twain shall meet, eh?

IONA CTO, Eric Newcomer, and I had to laugh when we recalled the panels we've sat on together and (somewhat pedantically) debated the merits of IONA Artix and Progress' Sonic. We shared the religion of distributed systems, alright, but we argued about them like we belonged to different sects. That's because a matter of principle—architectural principle—was at stake. In the highly-distributed SOA environment, what's the preferred approach: smart end-points or smart networks? Like all religious arguments, this one had a lot to do with up-bringing—and the particular tool we were both holding in our hand at the time.

Eric, coming from a CORBA heritage, had a natural affinity for the smart end-point approach, which IONA had successfully commercialized. On the other hand, I saw the problem through the prism of an enterprise messaging background and argued for smart networks—the solution Sonic had chosen to build. The schism, however, proved to be as nonsensical as the RPC vs. MOM religious wars of the early 90's. In our hearts I think we both felt that the argument was a bit contrived. We always knew that both models were valid—like a hammer and a screwdriver they are tools that address different needs. Neither replaces the other and they are rarely interchangeable. When you need the flexibility to put intelligence in the network (and can't or don’t want to change your endpoints), then the smart network approach is great. And, the converse is true too: when the network (or networks, for that matter) is a given, and I'm looking to service-enable a variety of endpoints, then the smart endpoint approach is perfect. The fly in the ointment all along was the decision we baked into our respective architectures at design-time.

Like a tattoo, you had better be sure you liked it—as CTOs, our mission was to defend it at all cost. But that's all changing now that new standards like Spring and OSGi give us the flexibility we need to defer those decisions to deployment time, where they always belonged. And thus a doorway is opened—a doorway to the best of both worlds!

SOA What? Bringing IONA and Progress together means that we can dispense with the pedantic debates and truly offer our customers the best of both approaches. It's a great time to be working in this industry, and fantastic to be joining forces with IONA. But, now what will Eric and I argue over? Well, there’s always emacs vs. vi!

By the way, if you haven't had a chance to hear what Eric Newcomer, CTO of IONA, has to say about the Progress acquisition of IONA,

A Note On Policy Portability

Today, I write like my colleagues. No humor. No funny title. No family stories. Just boring technology evangelizing.

I apologize.

But, I have something to say, and it can't wait until I think of a funny, but related personal story.

People often ask about policy portability. In particular, something along the lines of:

"Is there a way to create an XML representation of the policies configured/applied to services so that we can store them in the registry and share them with other policy enforcement points?"

Policy would only be truly portable if there were a standard that defined how policy should (could) be written. It would have to define a lot of things that we take for granted, like how to define semantics of policy constructs (defining something as simple as response time can vary greatly from vendor-to-vendor today). That in itself would be difficult, but perhaps not impossible.

The larger challenge becomes the "value added features" that vendors enable in their products that differentiate them from one another. From Progress® Actional's perspective, these value added features include Service Stabilizers, Dimensions, and Message Fields - all aspects of our product that add to the flexibility, scalability, and overall power of the platform. These are powerful features that provide detailed insight into service usage and control in a shared environment.

Realize, that this might sound like I'm trying to defend my product's value-add, but in fact, this is one of the real differentiations - how powerful can a governance solution write policy? How flexible can the policy be? How can it be applied creatively, to make sure everything is managed, even services you don't know exist? (Yeah-  you got that. We can write policy, and have it be inherited by services we don't even know exist. And, the policy automatically kicks in, when appropriate, without having to restart services, app server, or management platform).

I'm not sure I think these things could never be standardized. But, perhaps it might happen. And, we'd be all for it for those of us who work on and with Actional products. But in an emerging market, in many ways, the market is still trying to figure out what works and what doesn't. That's why many of the WS-* standards efforts (including WSDM, which I think in some ways might have indirectly led to policy standardization) have faltered. I think the standards got a bit ahead of the market and actual implementations.

Back to my point. It's very useful to visualize, in a way that scales to the enterprise, performance by customer, business process, or whatever arbitrary business characteristic a business manager wants. It's powerful to see this information without any a priori knowledge of the set of information to view things by (e.g. you don't need to pre-configure the list of customers, we can discover them live, and as the list changes, dynamically adapt and instantly start collecting new customer stats). None of that would be possible if policy were delivered as the lowest common denominator across vendors. Delivered as a standard, we'd all have to agree on how to define these things first... and in my opinion, that's too much to ask of a standards organization at this point in the maturity of SOA Governance.

SOA What? From another point of view, it seems to be a growing need. That is, for a policy written in one place to be stored centrally and then pushed to various (policy) enforcement points.

Of course, that's expressed as a feature, not as a benefit. The benefit is to be able to govern policy better, and have consistent policy deployment across the SOA.

One way to solve this problem is to only deploy solutions that embed Actional agents! Then, you can use our policies everywhere. Policies can be attached to the WSDL and stored in registries using WS-Policy standard (we do this today). Before you discount this as a "sale pitch," take a look at the breadth of platforms supported.

Actional Agents are available for a broad range of platforms, including:

1. BEA
2. Microsoft
3. IBM
4. Oracle
5. Sonic ESB & SonicMQ (Progress Software)
6. Tomcat
7. IBM DataPower
8. TIBCO BusinessWorks
9. JBoss
10. Lombardi Teamworks (see my recent webinar on this topic)
11. Cisco ACE XML Gateway (formerly known as Reactivity)

And, there are platforms that we support that have not yet been announced (and probably some I've overlooked) so ask your account manager for the complete list.

Why have these partners chosen to embed the Actional technology? Simple. We perform and scale orders of magnitude beyond any other solution out there. And, the Stabilizers, Message Fields, and Dimensions mentioned above add an abstraction layer that makes cost of ownership really low through a really flexible policy implementation.

In other words, our Agents can be embedded in places where performance and scalability are critical. Places where other technologies simply couldn't live because of their footprint or intrusiveness. Imagine how the very powerful XML accelerators that embed our technology would behave if each time an XML payload needed to be processed, the management solution had to send the message back to the central management server?

But, I digress into hitting my competitors for poor enterprise scalability. We've just been removing so much of their stuff lately...

The downside of putting Actional everywhere would be the perception of our policies being proprietary and being locked into Actional. Well, I tell you what... any solution you choose, that'll be the case. The advantage to Actional is that if you choose one platform, say BEA, and all of a sudden, they get acquired by another vendor, say Oracle, you can easily migrate to the new platform without having to redo your policies. You can easily plug-replace, or amend, you infrastructure with an instrumented platform, and not have to re-design your policy infrastructure. At that point, you need to decide three things to choose the right policy infrastructure (Actional!):

1. Does the solutions scale to my needs?
2. Is the policy authoring power sufficiently robust?
3. How many partners consistently support the policy infrastructure?

In fact, the argument against us being proprietary is to look at the alternatives (considering that any solution today is really proprietary)... one alternative is to have weak policy authoring (through a lowest common denominator policy language) or, point-to-point vendor integration to work around the lack of standards. Point-to-point integration has the weakness that usually each integration is done differently, and not all features are available everywhere.

I think a single vendor solution that doesn't compromise policy flexibility or power, or solution scalability or performance, while enabling a broad selection of policy enforcement points (and for that matter, policy repositories via WS-Policy) and technologies/protocols, is a desirable, and in fact, preferred alternative.

The "genius award" goes to...

The guy who made airline-seat TV screens into touch screens.

Yep, there I was as asleep as I could get on my red-eye between JFK and SCL, and all of a sudden I feel someone poking the back of my head. Poke, poke, poke.

As I was counting to ten, in a sleep befuddled daze I played back the experiences of the flight in my head, and sure enough realized what was going on. I don't use those tiny screens. In fact, they annoy me to no end. Flashing lights and colors just inches from my face when the person in front of me reclines. But, I remembered touch screen controls.

More evidence that airlines are purposely doing everything they can to make flying miserable. I can't wait until mobile phone use on airplanes is widespread. Though, admittedly, I made a Skype call from my laptop once on a Lufthansa flight. Why? Well, because I could.

Well, SOA what?

Let's pretend for a minute that my seat is a service in an SOA. As a passenger, there are several processes that passengers undertake that include my seat... sleeping and entertaining. Each of these processes use the same seat service, and clearly in my case, those processes interfered with each other when they both used the same instance of the service!

Both processes use the seat service as it was intended. Perhaps the service designers didn't take into account how it would be implemented. There isn't enough support in the chair design to protect the sleeping beauty from the poker.

The analogy falls apart a bit, but if we measured satisfaction with the service, I might have been unhappy, but the guy behind me was quite happy. On average, it was OK! Yet, that didn't make me feel any better rested when I arrived.

If I really pulled my soapbox out and ranted... I'd mention those people who use the service not as it's been designed - as an arm rest. Walking past and shaking me awake without any consideration for the beauty rest I so needed.

All of this really happens. Services used, as designed, by different (business) processes interfere with the quality each process receives, and that's further complicated by innovators using services in ways they weren't designed to be used. And, for those of you who think having a reg/rep will solve this problem, good luck!

It's important to have discrete visibility and policy-based management from the perspective of all processes (and personas and applications) using a service. And, it's important to know for sure how each service is being used... not just how the developer designed it to be used.

Fortunately, I didn't trust my service provider, and arrived two days early for my IDC presentation. That's quite a lot of overhead. Not everyone in a shared service world is going to have that luxury. That makes Actional a necessity for anyone serious about satisfying their customers by delivering meaningful SLA's without keeping you awake at night.

Distributed vs Federated

In a previous post, Distributed SOA, I have got a couple of comments about how technologies, such as SAML etc., fit in.  I would like to say that the title was Distributed Not Federated SOA, but Distributed and Federated mean two different things - although in many deployments, both are used.

Distributed SOA is where a deployment is performed over a geographical area. A good example is in Retail. In the case of Retail, there maybe 1000+ stores that are 100s of miles away from the head office.  All of these stores will typically be in the same organizational unit.  Requirements of a distributed SOA include (but are not limited to) the ability to manage, deploy and upgrade any location with no organizational overhead, i.e. there should be no extra IT resources required at the deployment site.  Within the SOA infrastructure the following may also required:

• The ability to go through firewalls using standard and accepted practices.
• The ability to provide high availability without the need for expensive IT infrastructure such as shared disks.
• The ability to define processes that will essentially travel the network and perform the processing on the network where it makes sense.
• The ability to deploy services on machines, either owned by the same or another organizational unit's data center again, without any extra manpower requirements. Note: This is common in state and local government use-cases.

A Federated deployment is very different because the idea is that different organizations will work together and as such some technologies, such as identity management, are key concerns.  A federated deployment does not necessarily need to be distributed. For instance, there are manufacturers that have different divisions that operate in the same building.  A federated environment allows the different organizational units to work together through a defined contract that allows the ability to invoke and share public services.  However, each organizational unit still will want to keep many things private.  Agreed upon security, SLAs, and other contractual definitions are required to make this infrastructure work.

Then there are Federated and Distributed deployments, such as large global manufacturers that have manufacturing plants in many countries and many lines of products managed by different organizational units.

SOA What? Before jumping in the technology toy box and trying to make sure that you have all possible TLAs in the solution, make sure you listen to what is being asked and bring the appropriate technology and no more; only then will you really be in tune with what your customer wants.