Integrated Infrastructure Blog

Adding Leading BPM (Business Process Management) Solution to Our Portfolio

Our integrated infrastructure (or SOA infrastructure) portfolio just got broader and better! On Monday Progress Software announced the acquisition of Savvion, Inc.  Savvion offers a comprehensive, standards-based BPM suite that helps more than 300 of the world’s top-performing companies – including 24 of the ‘Fortune 100’ – automate and continuously improve critical business processes. Dr. John Bates, Progress Software’s CTO and Head of Corporate Development, says, “The Savvion BPM suite is a perfect fit for Progress because it offers leading capabilities for business process modeling and execution. The suite also uniquely includes other integrated key capabilities, including business rules management, document management, an event engine and an analytics engine.”

Progress Software made the announcement during our Global Field Operations Conference in Orlando, FL, which is being held this week. Those lucky enough to attend were able to hear David Bressler deliver a great sales pitch that really communicated the benefit of having the industries best-in-class BPM technology in our briefcase. The combination of our Business Event Processing (BEP), Business Transaction Assurance (BTA) and Integration portfolio, coupled with Savvion's BPM suite, will enable enterprises to achieve the highest levels of operational responsiveness.

To learn more about this announcement, visit our Apama Event Processing blog and read two posts by Dr. John Bates:

• Why businesses must evolve their business processes to be highly responsive, dynamic and predictive – or they will cease to be competitive
  
  
• 10 Reasons Why Progress Chose Savvion

Welcome Savvion to the Progress family, and stay tuned for more details.

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.

CORBA is now Actional-ized!

This is really cool, and I can finally speak about it. Wow, gag orders just don't work very well for me. I mean, I can keep a secret, it's just that the really juicy ones are harder to keep than the others! And, this one's juicy. Ready...

Today we will release Orbix 6.3.4 with support for Actional.

Whoa! I bet at this point a lot of you are like SOA What? (yeah, remember that blog-ism we did here back when SOA was cool?)

Well, let me give you end-to-end visibility into the import of that sentence above.

As with all the other technologies we cover, including the recently announced SAP ABAP integration, Actional integration with Orbix gives customers:

1. End-to-end message flow visibility across an entire CORBA environment, in run-time, without any impact on performance or scalability. That same visibility extends beyond CORBA, and does so consistently to provide a unified view of message flows and business transactions in their environment.
2. The ability to centralize run-time policy creation, allow for distributed enforcement across multiple environments, and to ensure compliance with corporate and regulatory policies across the entire messaging infrastructure.
3. The same tools our current customers have that help them achieve an 80% reduction in time to resolving critical production incidents and a 20% reduction in major production incidents per year by simplifying root-cause analysis and problem resolution.

Now, you might think with all these great benefits, there would be a high cost. Nuh uh!!!

• No additional coding changes to get this up and running. Instrumentation of all CORBA services is automatic.
• No architecture changes, Actional won't impact scalability.
• No extra capacity required, Actional won't impact performance.
• No additional staff are required, dependencies are dynamically discovered and maintained to help keep the cost of ownership low. In fact, case studies independently verified by Forrester Research of our customers who are in production showed a rather quick payback of the investment due, in part, to the low cost of ownership.

Of course, if you follow Actional and Progress at all, awesome technology is old news. Actional has been working on non-SOA distributed applications since early in the development of our product and anytime we add a new technology, protocol, or platform, we've always added the same rich features, while maintaining the enterprise-class performance. Let me say that again, because I've accidentally brought up a very important point.

The single Actional Agent adds all of the functionality, across all of the protocols and platforms, and provides the same outstanding performance you've come to expect from us. In contrast, many other vendors can support all the platforms/protocols, and all the business-transaction-management features, and do so non-intrusively... but THEY CAN'T DO IT ALL AT THE SAME TIME!

Back on track, sorry for the diversion. I'm almost done here, I promise.

There are other equally interesting implications from this release that I'd like to share (in no particular order).

1. This helps to, in part, validate the strategy that lead us to acquire IONA in the first place. There are a lot of cross-product synergies.
2. This continues to prove the applicability of our technology far beyond the common understanding of SOA infrastructure (SOA and HTTP/JMS). We have successfully broken out of the "SOA management" niche, and are providing real value to customers across the entire breadth of business transaction management needs.
3. In this "recovering" economy, Progress can help customers gain more value from their legacy technology investments by upgrading the capabilities in mission critical platforms like Orbix/CORBA. Whether it's from the operational perspective of lowering their operating costs while providing higher-levels of service, or from the business perspective of preventing "revenue leakage", Actional solves real-world problems without impacting the architecture or requiring coding changes to existing applications.

In closing, I wish I could share some of the early adopter customer quotes here. I can't, but the feedback from the (former) IONA field was equally funny. The IONA field is (relatively) new to Progress and hasn't necessarily developed the instant-automatic love for each-and-every Progress product because we all share a logo color scheme. We actually had to prove ourselves to these guys and gals (a very capable team I might add). Once the engineering team was finished, they took the early software and implemented it at some rather large (and equally skeptical) customers. After running it through it's paces, people were actually smiling. When was the last time you saw beta users smiling at performance results? To quote one guy working at a large airline... "it simply worked the way it should."

Beat that!

Now That's What We Mean By Performance!

Was visiting a customer in Switzerland last week and a funny thing happened.

They presented us with where they are in their deployment... they've deployed their first "major" application early last year (Inventory Management), and this year are planning two more applications in the suite to be deployed in 2010 (E-Ticketing & Centralized Checking-in).

They're using a very old version of Actional (v6x), and I was hoping to help them understand why it was important to upgrade to the current release (v8.0). The Inventory Management application contains about 300 applications (including TIBCO BusinessWorks and Oracle/BEA WebLogic Server), and is designed for 400 million messages per month. They're currently doing about half that. (It was really cool to see the Actional console with those sorts of numbers in the dashboards!!!)

Each of the new applications will probably add a similar amount of traffic. 1.2 Billion messages per month. Surely, there's my in.

I started talking about how we've made major improvements to auditing performance, user-interface usability in large scale environments, and CPU and memory utilization, along with general performance improvements you'd expect in two years of development. I was sure this was a certain driver for them to upgrade to a recent version, when the lead architect from Progress leaned over, and whispered in my ear...

The current architecture's not even breathing hard. Even with that traffic growth, we'd probably only be at 30-40% of design capacity.

What can I say? We have a really fantastic engineering team.

And, I'll have to work with the customer on building a business case for upgrading using a different angle.

Patently Confusing!

Well, if you track our "space," you'd have seen that Forum has been awarded a patent on XML security appliances. Apparently, it's patent number 7,516,333.

As it turns out, Actional has a patent in the area of web service security too - Patent 7,480,799.

It seems that Forum's patent focuses on appliance devices (hardware) that incorporates acceleration, though doesn't limit itself to web services.

To help compare the difference between the two patents, you might look at the top level claims.

Forum's states that their patent is...

A method for applying security policies to data in a network, said method comprising the steps of: intercepting data being transferred across the network; determining that a security function to be performed can be offloaded for acceleration; utilizing a JAVA.RTM. Cryptographic Engine (JCE) to transparently offload the data; performing the security function in hardware, said hardware performing the steps of: entering a request in a JCE layer for a cryptographic function to be performed; invoking JAVA.RTM. Native Interface (JNI) hooks in a JNI layer to function as an interface to an operating system specific C programming language interface library; unpacking data from the intercepted data so that the unpacked data can be manipulated in the operating system specific programming language; and marshalling the unpacked data in a cryptographic messaging layer so that the unpacked data can be transformed to a standard format.

Whereas our patent is...

A computer-implemented method of implementing security for Simple Object Access Protocol (SOAP) messages which can be exchanged between client and server programs, the method comprising: receiving a SOAP message; determining whether at least one security rule has been defined for the SOAP message, the at least one security rule being defined based on a security policy for exchanging SOAP messages between at least one client program and at least one server program, wherein the at least one security rule includes at least one decryption rule; and performing at least one security related operation on the SOAP message based on the at least one security rule when the determining determines that at least one security rule is associated with the SOAP message, wherein the performing of the at least one operation comprises: determining whether the SOAP message is encrypted, and decrypting the SOAP message based on one or more decryption keys which are associated with the at least one decryption rule.

Looks like ours deals with how policies are applied to SOAP messages, even when they're encrypted.

I want to congratulate Forum for being second to the patent game here... ours just beat theirs, being approved January 20th, 2009.

Of course, we're not new to the patent game. We've got a few around our unique runtime governance technology as well... it's why our competitors are constantly saying, "you know who you do business with" or "you don't want to have all that information in your display, it's too confusing." The method we use to discover services in a network is unique and they can't do it (while running in production all the time, on any protocol, and not affecting performance).

In case the two summaries above aren't enough to put you to sleep on the spot (I've found myself dozing off as I write this myself), below are links to the others. I believe there are also a patent or two pending on the Actional Team Server / Actional Diagnostic technology too.

Patent 5,732,270 (1998)
Patent 6,349,343 (2002)
Patent 7,330,889 (2008)

This last one is the real interesting stuff relative to Actional. The title is "Network Interaction Analysis Arrangement", and relates to the way we (and our partner Software AG) compete successfully against solutions from HP, SOA Software, and Amberpoint.

The abstract:

In a network through which service providing nodes are interconnected, one or more software elements at each service providing node process the network operations. A client interceptor coupled in an examine node to a selected software element intercepts transmissions from the software element to record transmission flow control information. A server interceptor coupled in the examine mode to the selected software element intercepts transmissions to the software element to record transmission flow control information. An administrative node of the network examines the transmission flow control information from the selected software elements to assess network operation.

And the top-level claim:

A computer network interconnecting a plurality of service providing nodes each including software elements for performing computer network tasks and an administrative node for monitoring the computer network tasks, at least one of the service providing nodes comprising: a plurality of software elements in an application layer of the service providing node for coupling to other software elements in the same application layer and in the application layers of other service providing nodes of the network to process operations of the network; an interceptor unit for each software element of the at least one service providing node, the interceptor unit being coupled to its software element in response to selection of the software element by the administrative node for intercepting transmissions in the application layer from the selected software element to other software elements in the same and different service providing nodes and for intercepting transmissions in the application layer to the selected software element from other software elements in the same and different service providing nodes wherein said interceptor unit further forms a record of information pertaining to the transmissions at the selected software element and each record of transmission pertaining information further comprises a chain correlation identifier to identify an operation of a selected software element in its performance of a network task and an interaction correlation identifier to identify an interaction of a selected software element with another software element; and a transfer unit responsive to a transfer command from the administrative node to the selected software element for transferring the record pertaining to transmission pertaining information from the interceptor unit to the administrative node, in order to monitor operations of network tasks.

Actional for IONA Orbix & DB

I've been on the road since the end of May and I have also moved, so needless to say, I'm behind on my blogging and tweeting responsibilities. I mean, you know you're busy when you don't have time to tweet!

My colleagues have been out there though, doing some great things. We've got some early trials going on with Actional being evaluated at a few IONA Orbix (CORBA) customers. Since the team has tweeted this, I thought I'd blog about it!

As Frank Lynch said, "CORBA users will be mighty pleased to have Actional visibility, an no performance penalty to boot." Yep, couldn't a' said it better myself.

Why is Actional/Orbix integration important?

1. It demonstrates a key differentiator between Actional and all other solutions out there... we're not designed specifically for web services. Never were. Extending Actional beyond web services started in late 2003, and continues with the work we're doing with the Orbix team.
   
2. CORBA customers are "interesting" in that they are typical enterprise class deployments. They have high message rates, are deployed in critical infrastructure, and are sophisticated deployments due to their maturity. Right in Actional's sweet spot.
   
3. In this down economy, Progress has a key advantage over our smaller competitors, so much so that it's hard to actually view these customers as competitors. Where these small guys have to go and develop new customer relationships, we can continue to delight our existing customer base (in over 100 countries) with innovative integrations between the products in the Progress portfolio. This continued innovation enables us to drive market adoption while delivering products that meet real enterprise customer needs.

On that last point, I've got a bit of a new role here. Or, better said, my role is being further formalized as Actional Product Evangelist. I'm very pleased to have the responsibility for socially-marketing some of the new integrations we are delivering to market. In particular, those integrations between products in the Progress portfolio and Actional, and between Actional and some partners. I'm hoping I can have a real impact with this formalization to my role, as well as some fun introducing Actional to some new technologies.

That said, my initial focus is going to be on IONA's Orbix, Progress OpenEdge, and Sun Glassfish. Glassfish support has been released, and both IONA and OpenEdge are in early trials (pre-beta). As I get organized around communicating these solutions, feel free to drop me a line with questions if you are interested in seeing what we've got!

Any existing Orbix customers interested in the Actional integration should contact your sales rep... or me. You're required to have Orbix 6 or later for Java (for now... we're working on the C++ and Java/C++ for Orbix 3, but they're not ready to trial yet).

PS Why not follow Maneesh Sahu (Sr. Solution Architect, Partners), Dion Picco (Engineering) , Frank Lynch (Sr. Solution Architect, East), or Marcelo Jabali (Sr. Solution Architect, West)?

Follow Up to Cloud Computing Panel Discussion

I made a comment the other day on the EBizQ Cloud Camp panel that was off-the-cuff (meaning, I hadn’t prepared to say something like this, in fact, it kinda just rolled out of my brain on the spot).

It had to do with the difference between SOA infrastructure and the Cloud. I mentioned that cloud computing offers benefits of agility and time-to-market, and was called-out on the fact that that’s what vendors said the benefits were to SOA. What’s the difference? Why is Cloud going to be different?

My answer was that Cloud is going to force a lot of issues because as an external service provider, there can’t be any informal handshake agreements as their would be within an enterprise. Being formalized, cloud providers will have to figure out a way to do the governance... only the solutions they deliver to market are going to have to reflect the true cost. That is, the cost of the service plus the governance of the service.

@KevinJervis asked me to followup with what I meant. How will cloud force these issues?

In short, cloud companies need a valid business plan... reflecting the costs of the service they provide, and governance of the service. Innovative features are critical - easy versioning, rapid root-cause analysis, flexible and customizable security contracts, and personalized SLA’s. Critical for differentiation and for creating satisfied customers. These features come at a price... and their business plans need to reflect the costs of the “whole product.”

I’ve seen the following situation happen over-and-over. A customer plans a project. That project includes a “grand vision” of what they’d “like to accomplish.” Reality sets in and they find ways to do without. Perhaps they cut back on redundancy or they share servers with another project. They cut out “management” (gosh I hate that word) figuring that at first, they won’t have many users of the service, therefore “management” can come later. This happens “intrinsically” as well... shortcuts are taken in the development of the service just to “get it out the door.”

The problem is that these short cuts are often not really explicitly declared. Or, they are declared and conveniently forgotten.

These short cuts save costs and reduce functionality... yet when functionality is expected, the costs are not remembered. I hope I don’t sound bitter but I am frustrated. This technology stuff is hard, and we forget that because the baseline is so low to get started. But, to elevate it to an art-form... takes a seemingly-disproportionate amount of work.

So, what happens? A service oriented project is planned. As part of the planning, a “full” governance solution is designed. However, for the sake of time-to-market and cost, the governance stuff is left out until a later phase. Service levels are delivered through one-off agreements and over-capacitization (putting in a heck of a lot of capacity for not so much use - after all, you can’t buy 1/2 a server, right?). And, governance is forgotten. Service levels are met, until they’re not. Often, “cost-free” arrangements get project teams part way there. To some extent, you can use existing management systems, with manual configuration to get some of this stuff done. And, after all, why put in the capacity for versioning easily when you’ve not even deployed your first version?

I admit that this approach within the enterprise is normal - natural even considering business reality. It might even work for a year or two, or at least until, as with so many applications, the cost of ownership goes up. Services are shared much more than they were initially and manual procedures don’t work. So many things have been moved into and out of production, that you can’t trust anything but log files... and we all know how hard it is to troubleshoot a distributed application checking log-files across hundreds of machines.

Cloud providers can’t do this. Just to stay in business they’ll have many users very quickly. And, they’ll probably have custom service level agreement requirements from the beginning, they’ll need to decouple these customers from each other by default. They can’t have “informal handshake agreements” between teams to “do their best” to make this all work.

Even if they don’t have a “full blown solution” up front, they do need to make sure the right costs are built into their business model. And, that’s where it differs from within the enterprise. There is less rigor within the enterprise for building a proper business model. Many may disagree but I believe this to be true. (Not unreasonably so... it’s very difficult to account for everything that goes into a project, some costs are just assumed... but an assumed cost to a business unit directly hits a cloud provider in their bottom line).

Let me leave with an analogy this time.

We’ve all heard the idea of behaving in a way that wouldn’t leave us embarrassed if it ended up on the front page of a newspaper. Truth is, in the past much of our behavior would have no chance of getting that much air time.

Social technology changes that. We’ve all see videos of people throwing tantrums in airports, listened to recordings of obnoxious people on the phone, and even seen emails that executives presumed would stay within their company.

I believe this is one of the chief benefits of social technology. We will all be accustomed to always being on our best behavior because you never know when someone with a camera phone is watching.

It’s the same thing in enterprise technology. As soon as someone breaks a piece of something out of the enterprise, and offers it as a service, all the costs, implicit and explicit need to be reflected in the business model. These costs become exposed just like people’s worst behavior. Sometimes this exposure is OK because a specialist can perhaps do things cheaper than a company for which the activity is not their core business. However... in this case, we’ve been fooling ourselves into thinking we have been truly governing our services, when in fact, that is anything but the case. Cloud providers have no choice, and their business models will have to reflect that.

I know this is a long post, and I hope I’ve answered Kevin’s question well. As always, you can find me at @djbressler for followup questions and conversation on this topic.

Webinar Link: Controlled Velocity

Recently, Didier Mamma, our Director of EMEA Strategy, presented at a SOA Event in Paris (I thought the link might be helpful for my American readers) called Sustainable IT Architecture. In it he talks about how to achieve "controllable velocity". Velocity is critical, controlling it ensures speed is achieved with the least amount of cost and waste possible. It's a powerful presentation he gives... though I've heard it in English, this one is in French.

Enjoy!

Astounding Statistics Regarding Order Fallout & Revenue Leakage

Sometimes it’s really nice working for a profitable and established public company. With the launch of Actional 8, we’ve put some discipline on our focus around Business Transaction Assurance (BTA). We’ve rolled out lots of internal materials to train our field to understand the “problem” from a customer perspective, so that they can engage in conversations around the problem, rather than “pitch products.”

In any case, I’m reading through some research around order fallout (revenue leakage) Progress just sponsored that was completed by Vanson Bourne. Vanson Bourne carried out over 200 company interviews (these, to my knowledge, were not all Progress customers). The companies are in the USA, Europe, and Asia/Pacific and all had a minimum revenue of $200M. The study was not limited to the Telecommunications industry, but does call out specifics about both the Telecommunications and Hospitality industries because of their heavy reliance on consumer transactions.

Even realizing that we sponsored the research and so it is perhaps somewhat suspect, I can’t help but be amazed at the raw statistics the report showed. Some examples:

• 86% of telecommunications companies believe that order fallout causes delayed or lost revenues; 64% believe it causes customer churn also
• 98% Say that order fallout “definitely” or “probably” causes increased operational costs
• 75% say that having to deal with increased order failures increases demand on resources (warning: circular reference here... increased demand on resources causes order fallout to worsen, and so on...)
• Transaction volumes increased in 2008 by 16% on average, yet transaction failures increased 35% on average over the same period of time
• 86% of companies reporting high levels of IT complexity admitted to an increase of transaction failures; those with the most complex environments had their transaction failures increase by almost half in 2008
• On average, these companies have 11 full-time employees manually finding/fixing transactions, and it takes approximately 2 hours on average to fix them; Telcos have teams of 18 people, on average.

There are phenomenal implications to these numbers. The inefficiency is outstanding. And, there is plenty more where that came from!

I’m a student of life, and in particular of software companies. I’m always amazed when companies spend huge efforts to win new business, only to discard the relationship once the deal is won. Sure, no one does this purposely, but... through compensation and other more subtle motivations, there aren’t too many people in companies whose job it is to deal with happy customers without problems to keep them happy. I find this curious, because “relationship revenue” has a much lower cost of sale than “RFP revenue” and puts much less burden on every aspect of the company.

I digress a little, only to make the point that the companies in this survey are LOSING MONEY THEY HAVE ALREADY EARNED. Therefore, these lost transactions represent the most profitable ones they process! It’s like there’s a queue for service, with someone at the head saying “I’ll take yours, I’ll take yours, I’ll take yours, Nope - you, drop that on the floor, but don’t worry, keep our service.”

The report goes on to talk about some of the interesting “management” facts that usually are part of press releases about “new software versions” but often don’t actually make it into the software release (hasn't anyone developed a compiler that can compile press releases yet... it's a product some companies really need). It seems like there are a lot of difficulties with the software meant to solve these problems. Such as:

• The performance of the apps being monitored is negatively impacted (>60% companies reported this to be the case)
• The management system requires additional servers (~48%)
• Management systems need additional people to run them  (~47%)
• Can’t run all the management/monitoring features in production due to their resource requirements (~42%)
• They use up too many CPUs (~38%)
• 44% of companies don’t manage the end-to-end order process because of the above reasons!

All that said, I still have a personal favorite...

When asked “How often do you lose orders even though these systems say everything is OK?”, fully 35% of companies admit this happens “often” or “frequently.” The number soars to 56% of the very large companies (revenue >$2B) and 69% in companies that have the highest IT complexity scores. (78% of companies self-classify themselves into the highest complexity ratings)

It goes without saying that I believe Actional solves the problems in the first list, without introducing the ones in the second.

Who cares what I think though when you have Forrester studying two of our IN PRODUCTION customers, and finding the same results:

• Staff required to fix root-cause messaging problems was reduced by 85%
• Service quality reports are available in near real time, and created automatically; in the past they were difficult to prepare and were not readily available
• Of the two companies studies (admittedly, not a large sample!), one had a payback of <12 months, the other around 20 months

I’ve blogged before about the importance of the scalability and performance of the management system, without which features don’t really matter. This report validates my earlier post, and calls out specifically that many management features can’t be used in production because of the impact on performance. I wonder if the vendors of these management systems didn’t oversell their products... I wish they had asked that question in the survey! (And, when looking for that link, I found another post that was also mentioned in the report... the importance of actually knowing you have a problem.)

Thank you for reading this far. Email me if you like a copy of the Vanson Bourne report and the Forrester case studies. (These case studies are anonymous, but all research was completed by and validated by Forrester Research).

Welcoming Scottish Widows to the Family

For the record, I think I've had three hours of horizontal sleep in the last 48 hours or so, and that was on a hard wood floor - though I did have a pillow and blanket.

That said, the title of this post makes perfect sense to me... See, we've just announced (this past Tuesday) a new customer relationship for Progress - Scottish Widows. Scottish Widows is a part of Lloyds TSB Group, and is a well known provider in the life, pensions and investment industry in the UK.

The press release is typical - you can read it - but it essentially says:

Scottish Widows performed a 20 month selection of an integration platform and selected Progress' offerings because they perform better than other offerings. Scottish Widows hope to

1. launch new products faster
2. integrate easier (probably why they hope to launch new products faster)
3. lower their IT costs overall

In fact, it's this last point that's very interesting. I was only involved with the deal on the periphery but from the beginning the deployment team of both Scottish Widows and Progress are integrating metrics into determining the success of the deployment. Among other things, they will be measuring their cost savings by using Progress Software. From an Actional perspective, this means diagnosing issues faster and reducing support costs, as well as improving customer (and end-user) satisfaction.

We've done a similar case study with a Financial Services institution, validated by Forrester Research. Email me if you'd like a copy of the case study or watch the on-demand webinar with Forrester that explains the results (as a special perk to readers... you don't have to register). The case study provides real numbers about the Total Economic Impact (TEI) and measurable results achieved by this institution.

The press release also mentions that Sonic ESB and DataDirect Shadow (mainframe integration) were also selected. Congratulations to those teams, they're great products. We're starting to see some really interesting dynamics driven by customers selecting multiple products from the Progress SOA infrastructure portfolio, but more on that after I've gotten some more sleep.

Boy, Did This Guy Understand Actional!

I love talking to people who get it.

I was talking with a guy from Cornell today about AppZero's server virtualization technology and he mentioned that they have a consultant talking to them about ITIL, and the challenge that all the information being put into their ITIL compliant CMDB would be out of date the second it was entered. Sorry Greg, but the conversation turned from AppZero to Actional's end-to-end visibility in less time than it took me to shift so I was standing between this guy and the door.

I commiserated and mentioned that it's one of the really interesting things about Actional - that we track that message flows automatically and therefore provide two key benefits:

1. Accuracy
2. Low cost of ownership (due to non-manual discovery)

We started talking about one of our oldest customers, University of Phoenix. They're the largest online university and they use our products to track the flow of messages as they flow through the network. Our conversation was a breath of fresh air. Not that many people get it so quickly:

"Wait, you can track dependencies?"

"Yep."

"Boy, could I have used you recently. We were taking down an old system and we emailed everyone, we checked log files, and we sniffed the network. But, what it came down to was simply disconnecting the machine and going to see where the screams came from."

I laughed, because that's one of the oldest case studies I talk about. An early customer of ours had a similar problem and it would cost them two weeks every time they decommissioned a system. It was nice to hear someone else pitching my story to me.

Here was a guy who understood the difficulties of the anonymous consumer, as well as the futility of manual discovery when his own internal processes were not robust enough to keep up with the changes in his environment.

I'm sure I'll be talking to him again soon.

Cloud Computing Impact on Enterprise Integration Recap

Well, that was fun. Spoke at 7PM this evening, at the end of a long day of presentations at the Cloud Computing Expo. I was a little afraid of a 7PM speaking slot because I thought people would rather be at the bar rather than listen to me talk. Boy, was I wrong. Apparently, people were standing in the hallway. Had I noticed, I certainly would have rearranged furniture to get more people in - even if it meant more people sitting on the floor!

First, as promised, here are the presentation materials:

• Download Presentation (please view this in presentation mode for best effect)
• Download Cloud Computing Impact on Enterprise Integration Paper

The presentation was targeted at the Enterprise Architect and hopefully left people in the room with thoughts about how to approach (and explain) cloud computing, and how to get started in the enterprise with a few best practices. Based on the nodding-heads in the audience, I think I touched a few key points.

Summarizing in my own words:

• Cloud computing is about turning a commodity into a utility.
• Integration is way too hard, non-technical people don't understand, so discount the efforts.
• Moving what we can to a utility model, will let us focus on what's important and elevate our game.
• Integration, the easy stuff is way too hard, so we never get to do the cool stuff; just do it. Mistakes with cloud computing are much less expensive and irrevocable than they are with typical enterprise software purchases/deployments.

And as for the best practices... well, just download the paper or the presentation.

For a full "live blog" summary, check out Brenda Michelson's post.

Great feedback that I heard afterwards was that I was the "first presenter of the day who knew how to present." That was the best feedback of all.

Thanks to all my friends, real and virtual, who a ttended. It was great to see so much support.

Download ExpoPreso

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.

NYC Cloud Computing Expo Preparation Almost Done

Well, we're just a few days away and preparation is winding down. We've got an article written and ready to go, and I've got my presentation mostly complete and just need to work on layout, notes and review. Sounds like I'm almost done... just hope I don't get sidetracked by some fire drill.

The media alert went out today and it got me thinking that it might be interesting to share the creative process.

Personally, I don't get nervous with public speaking. It doesn't mean I always do well, its just that I quite enjoy the opportunity to get in front of a crowd of strangers full of adoration for the gems spewing from my mouth. In fact, I tend to not "rehearse" for presentations as much as "immerse" myself in the content and visualize how it will go, the thoughts I'd have, the questions that might come up, and feed that back into the presentation in a way that makes it more robust.

This presentation started with work on a white paper I began working on about two months ago. It was a bit of a free form set of ideas I have about cloud computing. I had only the guideline of my submission - The Impact of Cloud Computing on Enterprise Architecture - and I ended up with content in four areas:

1. The difficulties of enterprise integration
2. The corporate challenges of enterprise software
3. A definition of cloud computing
4. Some best practices

The level that I speak at is relatively high, and I worry that it's not enough detail for people. I guess we'll see on Monday.

It took me a week of writing, with some interruptions I'm sure, to get down about 3,000 words on paper. That's about 3 1/12 pages of writing, and it was handed over the PR team for editing.

It may be totally behind the scenes but the people that have edited my stuff in the past, this time included, do wonderful work. It's always important to double check the content and the meaning, and to make sure that the important points stayed, but they really tighten it up and focus it down.

They turned my 3,000 words into 1,120. The final piece has just 20 additional words, though I had to do about a day of editing to bring some of the meaning back, and highlight some points that were lost originally. It'll be posted on Monday so keep an eye out for it. As always, let me know what you think.

I had been thinking about this cloud stuff for some time, and tweeting ideas to see how people would respond. I've also been vigorously reading the tweets and blogs of others to get a sense for where the conversation is. Hopefully, my presentation on Monday adds something to the conversation, in a way that constructively builds on what others are saying.

The difficulty with creating the presentation, of course, is that I didn't just want to put the paper in presentation form.

That would be boring. (Boring is bad.)

I came across a presentation titled "Charts are Cheap" by Major Dan Ward (who unfortunately, didn't include a link to his blog in his presentation, so I can't link you to him!). The idea was 1/2 - 1 idea per slide/chart. Simplify and people will understand more.

So, I'm trying something new with my presentation. It's really lightweight and a lot of what I'll say is not written on the slides. It is, mostly, written in the paper. And, what's not, would be great to discuss online after the event.

Part of the reason to do something different is my "middle of the night" speaking slot. And, I believe I'm also last for the day, so anyone that does come, and stays awake, has me between them and the bar. Not an enviable position.

Though, if they need a drink after my presentation, I believe Mike is organizing a Tweetup at ESPN Zone in Times Square after. Hope to see you there.

This Should Make It Obvious to Anyone

Looking at things from the perspective of how software is evaluated and brought into the enterprise, it's no wonder cloud computing is dramatically changing the landscape. Combine that with the trend of software vendors looking to compliance to shore up revenues, and customers pushing back to reduce their software maintenance costs, and I think we're in for some interesting changes in selling software over the next couple of years*.

In any case, I thought it would be interesting to put together a quick list of how software is piloted in a "traditional" purchase cycle, and how it might be piloted if "purchased" from a cloud.

So, assume a thorough selection process has been completed on a product and its alternatives (I don't think we do that well today either... I think it's too feature-focused and we're not nearly evaluating the "right" things), and we're talking about getting the first small set of people up and running on the selected solution.

Traditional Software Purchase

1. Software is purchased.
2. Hardware is purchased.
3. Space is found in data centers for the production kit.
4. A plan is created for moving into production, often a lengthy process inserted around specific rules/restrictions for changing production systems.
5. Development and test environments are setup.
6. Computer room space is found for the permanent location of the development and test kit.
7. Any databases required to support the application are purchased and configured, including hardware if necessary.
8. Administrative and security staff support is required to configure all this new equipment to company standards, backup procedures, and security policies.

Cloudly Purchased Software

1. Get a login.

Even people who don't know anything about software should be able to figure out which is easier. And, while I shouldn't need to ask, but, how much longer do you think the first process takes than the second from the time a decision is made?

If you want to follow the doings of a new startup taking advantage of just this difference, follow Mike on Twitter. He's starting a new company and taking full advantage of open source and clouds to have some incredible infrastructure and development cost metrics - actually showing through his own experience what can be achieved.

Want to hear more? Remember, I'm speaking at the NY Cloud Computing Expo later this month.

* "Ray" Wang has been tweeting and blogging about this topic quite a bit. I find it very interesting to follow.

There's a Dilbert Cartoon in Here Somewhere...

I'm reviewing a customer case study, and there was a comment from a sales guy that I'd like to share. It brought up a funny visual for me. Did I mention, this came from a sales guy?

What about the benefit of knowing you have a problem at all? I think this is a big benefit. Finding out you have a problem from your users is embarrassing and not error proof. They will start reporting everything as your problem. [...rambling deleted...] having evidence to avoid the root cause effort altogether seems meaningful. It is also a point I have heard from other customers. It is rewarding to be in a position to say, "Mr. End User, the systems are performing just fine. Are you sure you actually hit the 'submit' button?"

I know, sounds like utopia. Just wait 'til you see the case study. Huge returns and cost improvements, all validated by a third party, and currently in production by the reference customer.

And, did I mention, it was a sales guy who pointed this out? A really smart one got through, call in the hounds. ;-)

If you are interested in seeing the case study once it's ready for distribution, email me and I'll email it to you.

Progress, A Technology Company's Company

Last Thursday was analyst day at Progress Software, and while I wasn't there, I followed some of the activity on Twitter. I'd like to share a bit about what it's like to be at a product company, and some of the challenges we face getting our message(s) out - instead my usual rant about SOA.

WRT the conference, the tweet of the day was @rwang0's tidbit: "Did you know that Epicor, QAD, Infor, Consona, Sage, and others are using Progress technology in the back end?"

@neilwd's answer was: "@djbressler re: your @rwang0 RT - no I didn't know that - and that's part of the problem, perhaps?"

Perhaps? Neil's apparently an understated kind of guy.

I'll add a little nugget of my own. Can you guess how many SaaS customers we have? A few thousand. (Sorry I can't find the exact number but I think my point is made.)

Interestingly, @neilwd was right on the ball earlier when Judith said, "progress software - no differentiation" and he responded "jhurwitz v interesting Progress comment - I think Progress is a bit like Unilever - top-level brand is vanilla, sub-brands have chops".

We'd love for the Progress brand to have some chops, and we're trying but it's not trivial. To illustrate this point, and the challenge we face bringing all our brands together, here's a little visual riddle:



How many times do you see Progress on this screen shot? (Answer below)

Coincidentally to analyst day, I was doing some research in preparation for my upcoming presentation at the Cloud Computing Expo in NYC. When I saw this page I just had to email it to our new CMO, Gary Conway, to illustrate the problem we have.

No one knows who or what Progress is. And in part, it's our fault, but only in part.

You see, Progress is mentioned four times on that page but you'd never know it. Granted, there's one double-mention but still four times on one page, you'd think people would of heard of us.

I'll pat myself on the back for a second. Last year we had some moderated management meetings to tease out what we all thought Progress' core strengths were. My belief is that Progress is a technology company's company - that our core competency is creating software that, as Neil pointed out on Twitter after analyst day, others embed in solutions of their own. Our established network of partners is more valuable than gold, and having traveled the world talking to them, they really like us. Oh, and they're committed to our technology across the board. The exciting thing is that we're starting to realize that core competency in the Actional team here with our relationship with Software AG and their release of WebMethods Insight. It's amazing how when you do what you do well, it works well!

I'll say one last thing before giving you the answer to the riddle, since I suspect there are some important people at my company who might read this.

I'm a bit disappointed that we could have an analyst day without a social presence. Not a blog post about it, not a tweet, not a single conversation. Granted a lot of what was said is confidential but we've gotta be part of the conversation and we missed a good opportunity to do so.

Answer: The four places we're mentioned on the screen shot...

1. "Progress Software to Present at Cloud Conference" (top center bullet #2)
2. "FUSE on Demand: Webinars on Open Source Integration" (sponsored bullet top center)
3. "SOA Presentation, SOA, WOA, and Cloud Computing: The Frontier for Data Services" (top right)
4. "FUSE on Demand: Webinars on Open Source Integration" (bottom left)

DataDirect is what some would say is the core of Progress, FUSE is our open source ESB acquired with IONA. And, as mentioned above, I'll be presenting at Cloud Computing Expo in NYC. I'd love to meet you and have a conversation. Of course, you don't have to wait until then.

2 April 2009, @NeilWD has blogged his response/feelings about this topic. It makes for a good read. - db

You Can Look, But You Better Not Touch

Actually, touching would be great, but be warned... it costs extra! Did I ever tell you about that time in South Africa where I presented at a conference during one of their open sessions? Afterward, a guy actually came up and hugged me for my performance. True, I swear.

Come see yours truly at Sys-Con's Cloud Computing Expo in NYC March 31st and April 1st. I'll be talking about the impact of cloud computing on enterprise application architecture. I'm excited that they accepted my abstract, but now I need to flesh it out.

For a preview on my thoughts on the topic, check out the podcast I did recently about the impact of cloud computing on enterprise architecture.

Let me know what you think, but I'm on the fence about wearing shoes while I present.

I'm looking forward to seeing you there!

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.

Business Transactions, Exciting Stuff!

Last week, I had an opportunity to listen to some of our top solution spokespeople here at Progress Software present, watch the audience respond, and then drink with the sales people who are tasked to sell our solutions in what could be the worst economy in recent history. I made a note to myself about a topic to blog on and am really excited that Jason Bloombergat Zapthink beat me to it!!

My note was simply:

"Process Mashup = Business Transaction"

In the Zapthink post, they talk about "data mashups" solving the "swivel-chair integration problem." They make a whole lot of talk about SOBA this and SOBA that, but at the very end, say something pretty interesting:

"From a business perspective processes always involve information, and there's no way to get value out of information without doing something with it, and when the business does something, that activity constitutes a business process." (Run on sentence is theirs, not mine.)

I think an important generalization can be made...

From a business perspective, there's no value in infrastructure unless it directly relates to what the business is doing. And, measuring the value requires the ability to directly relate it to the business.

Earlier this week, I mentioneda customer of ours who had 98% up-time but their largest customer was without data for over 3 weeks. Another example is a customer of ours - a large cable company. They have business owners of their "products" -- including cable, Internet phone, cable-Internet.

They use Actional to monitor the provisioning process for these services, and then share it with the appropriate business owners through browser-based dashboards. The first thing these managers do in the morning is bring up our console and look at how their business process is doing.

The important thing is that even though there is a mesh of underlying support systems for each of these products, as well as the famed "triple-play", they don't care about the infrastructure. They care about the results to their business.

Underlying this all is a Process Mashup which, is just a fancy way of saying "multi-product, multi-vendor integration to implement a solution." They've taken the component processes (provisioning, ordering, credit-checking) and made it into a single Process Mashup that helps them understand and deliver an outstanding customer experience. Importantly, the person responsible for the process doesn't really care about how it happens, as long as it does. But from an IT perspective, it's important to know when it's not happening and why.

For example, take FedEx (not a customer). They ship me a package and it arrives on time. I get an email and all is good. If it doesn't arrive on time, I call for help, and someone drills into the step-by-step tracking of where it's been to figure out where it is. At that point, they see which distribution center it shipped from, how it got routed, what the weather conditions are, and so on. Of course, ideally, they'd tell me (rather than have me call them) there's a problem, but... the important thing is that there are many steps in the process. We can police the end-result and use policies to warn us (ahead of time or after the fact) when things don't go as planned. We can also get all the detail we need to assure those important business processes (or Process Mashups as Jason and I like to think of them) keep the business optimized.

SOA What? Well, I find this exciting because we can start to really talk directly to the business in a way that shows hat we (as IT people) understand what's happening. We can talk about results the business cares about (the customer can watch cable tv in two hours from the time they sign up) and speak to results no one cares about, except when they have to ("There it is, the request to provision them got stuck in the queue. Yeah, that happens sometimes. Why were you waiting for it to finish?").

I'm very aware, that in addition to being a brilliant technologist, I'm also the check-out guy at Home Depot (where I always choose to self check-out), I'm a travel agent (book online, don't call the airline, they charge you more), and even a bank teller (using an ATM - just today I found out I don't need to fill out a slip to make a withdrawal from a teller... it's been that long since I've spoken to one!). In all those cases, it's quite easy for me to switch providers and completely opaque to companies as to why I would. And, I will switch if service is promised and not delivered. If a service provider doesn't communicate in terms customers can relate to, and then assure those processes using the benchmark the customers understand, customers will go to service providers who do.

Meaningful Measurements

At our annual sales kickoff in Miami last week, I heard a story about one of the Regional Sales Managers that put a smile on my face, and it made me like Progress a little more. When asked by the CFO how he did last year, the regional sales manager responded "six cents".

Six cents. Huh?

Well, apparently there is a culture here at Progress that you look at regional profitability, and then each sales manager knows how their deals affect the company's bottom line. Being a numbers geek, and one who likes to measure things properly, I think it's cool.

SOA What? Well, I also heard a story about a new Actional customer who had over 98% up-time for their IT systems last year - a number they were proud to report. (Realizing, of course, that each industry has its own benchmark for up-time.)

They were proud to report it but it was meaningless to do so...

Why? Because as it turned out, while they had this brilliant up-time of their underlying infrastructure, something was preventing their largest customer from receiving any information for over three weeks. Do the math, 52 weeks in a year - down for 3, that's almost 6% downtime.

Where was the discrepancy?

The IT team was not tied into the business and was assuring system up time but NOT assuring their business transactions. So now, in order to gain credibility with the business and to make more insightful technology decisions in support of the business, the team chose Progress Actional as the management solution for their SOA and distributed applications (links to good article on what this is about by Anne Thomas Manes). Hopefully, they'll do better next year.

Have you ever had a situation, even in your personal life, dealing with a company's technology where they say all the systems are up but still, it's not working? Create a comment here and share your stories...

Sometimes It's Just Too Late

Down in Florida for Progress' annual sales kickoff meeting and using the opportunity to visit my grandparents. Needing a car to get around, I rented a low-end model from Dollar/Thrifty, an Actional customer. Normally, the car is full featured but this time, I got a car without power locks. No big deal, right?

Saturday morning, I went to the mall, parked, had breakfast, sat in Starbucks and caught up on email. When it was time to go, I realized the problem with not having electronic locks.

I couldn't find the car.

You see, I didn't really pay attention to where I left it. I figured I could walk around, punch the alarm, and move towards the beep. I ended up having to walk the aisles looking for a red Dodge.

This weakness in my plan would never have occurred to me until I experienced it... at which point it was too late to do anything about.

SOA what? You've got similar challenges with SOA management tools. You don't really know what you need until you need it and it's not there. Unfortunately, once you've put the SOA infrastructure in place, it's too late to compensate and you must do without (or find a work-around).

It's important to think things through carefully, but realize that you're going to miss something. This assumption makes your decisions about architecture way more critical than individual features when it comes to product selection. Features can be changed (quite easily in fact) but they are limited by the capabilities, performance and scalability of the underlying architecture of the solution.

Evaluating software for managing your distributed applications? Then this is a must read.

At least, I think it is. Just because I'm the author of the recently released Software Buyer's Guide, doesn't mean my opinion on its relevance is biased, really. If you follow me on Twitter, you've already been notified of the Buyer's Guide. And, as I said before, if you join the conversation and direct message me on Twitter, I'll send you a copy without requiring you to register.

Personally, I get quite frustrated by the vendor-initiated confusion around the problem that Progress® Actional® solves. It's not really a management problem. I mean, you can say a pilot uses his instrument console to manage his airplane, but what he's really doing is flying the beast. Well, Actional and other competitive solutions are the equivalent to the pilot's instrument console. And, the pilot is... Well, I think the pilot is anyone who drives business and the technology on which it runs. But, the right persona is a bit more organization-structure dependent and a bit less obvious than the "pilot" analogy.

While this guide talks explicitly about managing distributed/composite applications in a mission critical environment, it was written in a way that starts by proposing a framework for evaluating enterprise class software. I define enterprise class applications as being:

• Scalable
• Performant
• Resilient

Software that does not have the right enterprise architecture, should be disqualified before a feature-by-feature evaluation begins. I realize that's a strong statement, but I believe:

Architecture deficiencies are mortal. Feature omissions are easily corrected.

I think this simple rule is often overlooked by the whiz-bang of a pretty UI, or the easy sale-ability of a specific feature that touches the purchaser's hot button.

The guide goes on to discuss a few areas that are often part of "managing" a distributed application and tests for each that can be used in a POC. I've said it before, and I'll say it again... DO A PROOF OF CONCEPT BEFORE BUYING SOFTWARE. I've worked in the enterprise "plumbing" business since 1995 and the only consistency is that vendors try to avoid POCs. If we're trying to avoid them, you should be trying to do them. And, when you do them, take the time to do them properly. Little upsets me more than doing something so you can check it off a list somewhere. </rant>

We've also put out a brief teaser release highlighting the buyers guide. You can see it on our site, or over at SOA World Magazine (thanks to BusinessWire).

EDS AirlineSOA Goes Public

I'm a bad blogger. I've been very quiet lately. It's that time of year, after our fiscal year ends, but before we announce our results, and so I've obviously been busy with customers (remember them?) but can't really share the excitement.

I was trying to find the recording from last month's online eBizQ conference and ran across a blog entry by Joe McKendrick (one of my "must-read" industry analysts) talking about EDS' AirlineSOA initiative, and in particular the Lufthansa Airlines project.

SOA What?

Well, which SOA management vendor do you think underlies AirlineSOA?

I'd also point you to a recent post by Anne Thomas Manes that highlights the single most important "new product" that should be budgeted for in SOA implementations... that of a management solution.

It's interesting that both Anne and Joe blog about the same thing... Anne in the abstract, and Joe in the specific. I know AirlineSOA and Lufthansa in particular, use a host of different technologies from various vendors including TIBCO BusinessWorks. But, the only "fashionable" product used differently from the past (when it was just "airline" not "airlineSOA") is Actional.

What do you think of that? (I think it's pretty cool; but clearly I'm biased.)

And, there's more. Why do you think EDS selected Actional?

Performance.

For those of you reading this evaluating your own solutions, I'll share that EDS put a big effort on behalf of Lufthansa to make sure the performance was what they needed. This wasn't a simple "show us what you got, we're going to dump on the vendor" POC. They knew their environment and they invested the time in understanding our architecture, how it mapped to their environment, and how to optimize it all together. If you're serious about evaluating an enterprise tool, you need to make a serious investment in understanding it.

Of course, I still haven't found that recording (in part because I wrote this post). EbizQ has a new face on their site, and it's a big improvement, but old recordings are still hard to find (or, I'm just an idiot).

Now, Even More People Can Enjoy Me!

That's right, another podcast!

Get answers to the SOA questions that keep you up at night:

• Why SOA is like dieting? Many shortcuts but no discipline = no results.
• What do those pesky users want now? More change? Why can't they just let us finish something and move on?
• What's the difference between me and a billboard? Hopefully, I have better hair. Otherwise, not much.
• Why is there so much job security in IT/Software? Change is hard and complicated. SOA makes for a lot more moving part, making change significantly more difficult.

And, yes, I love the phrase 'a priori' -- it reminds me of statistics class in college. I had a funny professor... come to think of it, I was the only one who laughed.

This podcast is a lead into next week's SOA in Action Virtual Conference hosted by eBizQ. It'll be fun, and it's virtual, so you don't really have to pay attention.

Register for the eBizQ event >

Interested in more? You can also listen to the podcast, Impact of Cloud Computing on Enterprise Architecture , which is part of our iTunes SOA Infrastructure podcast channel.

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.

Welcome Back!

As a huge fan of Calvin and Hobbes, one of my favorites was when he'd answer the phone by giving someone his pizza order, as if he had called them. In that vein, all I can say is "welcome back, where've you been?"

Actually, it's been quite busy over here at Actional, putting our push on for the end of fiscal '08 (Progress closes our fiscal year at the end of November), preparing for our next release (oooh, it's cool), and meeting all these new people at Progress who came over from IONA (welcome, and welcome back in at least two cases).

Though I've been quiet on the blog front, October was a busy month. In addition to two weeks off (I feel relaxed, thank you), I've been out there talking about governance of all sorts (SOA, Cloud Computing, and Data Governance). Some might think that with all this governance talk, we're all about governance, but in fact, Actional is just one component of an overall governance solution. Which is why you won't often hear us talk about governance -- except this past October.

So, please accept my apologies for the quiet blog and check out the following October events that recap '08 quite nicely, and give you a sense of where my head is as we turn to '09.

1. eBizQ Panel on Selling SOA Governance to a Skeptical Audience, check out Joe McKendrick's post on the event. Joe moderated the panel and there was some very emotional discussion by the very experienced panel members. If you really are having trouble "getting started" this Monday, you can read the full transcript. And, if that wasn't enough, make sure to register for the next event, Avoiding SOA Disillusionment.
2. Impact of Cloud Computing on Enterprise Architecture. Check out my first podcast. Hopefully there'll be more. Turns out, this is a subject I'm quite passionate about because I see awesome potential if we can just unlock data across the enterprise without breaking the connection to the data owners.
3. DM Radio and Data Governance, the Mission Critical Mandate. An interesting perspective on governance, data governance. If you think governing a SOA is hard, listen to us talk about the challenges of governing the data. I think that's where it starts to get exciting.

And, stay tuned. I've just finished my copy of Todd Biske's book, "SOA Governance; The Key to Successful SOA Adoption in Your Organization". It's a good book, I've even used the material in a couple of meetings. I'll be reviewing it shortly.

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.

I Don't Know Jack...

But, he's said something nice about Progress Actional. He's sharing his perspective on use of intermediaries and monitoring services. He's got a good perspective, because he's talking about his real experience, and NOT his vendor-bias.

I wanted to make sure I shared it here, since he's in Europe, and has a relatively small blog.

Thanks Jack!

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?

Armadillo Governance

Ran across this article on data center security today, and noticed some parallels between the way they’re thinking about physical security, and I think about SOA security (and governance).

A key SOA governance challenge is making sure that things in runtime are compliant with all CURRENT governance policies and procedures.

Why is that such a trick? Well... because most companies implement “armadillo governance.” (I copied this phrase from Mitch in the comments of the post referenced above.)

That is, most companies have governance that is hard on the outside and soft on the inside. Mitch says, “The most carefully maintained $100,000 firewall does no good if someone can simply move a ceiling tile and gain complete and unfettered access...” Amen.

Well, the most carefully implemented developer time governance pre-production testing does nothing to ensure compliance in run-time.

Let me share a couple of real-world examples.

I was working with a semiconductor company on a pilot governance project. They had strict tests for their applications before moving them into production. The tests passed... the application was moved to production but development systems were still able to access this “in production” application.

The problem was, the company tested at the border (they had a hard outside), but once inside production they had no idea what was really happening (they had a soft inside).

In that example, it turned out there were holes in a firewall that shouldn’t have been. So, the failure wasn't at the application level. But... how about this one? An application was successfully in production and the governance rules changed. All new applications tested fine before they were moved into production,and the customer thought they were OK in all the existing production applications. Unfortunately, that wasn’t the case. As it turns out, there was an old server being used by some customers and everything was chugging along OK because it never broke, so no one ever complained. In time, developers moved to other projects, and the application was lost in the shuffle.

Now, before you say “we don't lose stuff here”... early in my career, while working at Box Hill Systems and going in to replace a failed hard drive at a big financial firm, I had to wait on-site about 4 hours for them to find the machine that failed. They knew it failed because they couldn’t access it, but they didn't know where the machine was. They lost a server, the hard drive and all. Now, we're talking about services, software, bits in the ether. Much easier to lose... and there are a lot more of them than there are servers!

1. Do you know where all your services are? Where all the consumers of those services are? How each of those consumers use your services?
2. What about policies. Do you know what policies apply everywhere? Do you have a way to control the policy lifecycle independent of the service lifecycle?
3. Do you have good border security, but let services run amok once they pass security at the border?

Border security is important but please don't design your SOA like an Armadillo. It's a design that works for Armadillo’s but not so much for SOA infrastructure or for data centers.

Interestingly, Dan's discussed why "checkpoint governance isn't good for design time" either. So it seems that like lemmings, deployment managers can't help but heed the call of their profession, though it is of limited value (on it's own -- I think it has value when part of a bigger governance plan) when deploying services as part of an SOA for either developers or operators.

Conversation or Rant? LMK

As Dan mentioned earlier, Software AG have decided to OEM Progress Actional. This is good news for us, and we're quite happy that Software AG made the decision the way they have. I personally look forward to working closely with Software AG and helping to make the relationship a success.

Neil Macehiter @ MWD Advisors wrote a very thoughtful post on his take of Software AG's decision. Rather than rehash his post, and my thoughts, I'd just like to reference his blog, and let you know it's there. My comments and thoughts, somewhat impassioned (what else?), follow his post in the comments section.

Post a comment and give me constructive criticism if you've think I've gone over the line in talking about a competitor.

"Ugly Betty" the Sequel... "Stupid Dave"

Interesting thing happened on my way back from lunch yesterday.

They're filming "Ugly Betty" downstairs and as I walked by the trailer, I noticed a door that said "Please Knock." So, I walked up the stairs and knocked. The door opened and the conversation was weird for both of us...

DB: "Hi"
Guy: "What do you want?"
DB: "Nothing. I was just knocking."
Guy with confused look: "Huh?"
DB: "Yeah, the sign said to knock, so I knocked."

You'd have to know me to believe this story. Enough to say that when the mood strikes (and when doesn't it?!?!), I'm a cat and the world is my rubber mouse.

SOA What does this have to do with anything?

Well, there was a policy posted to "please knock." Obviously, there was some context assumed by the policy creator. Perhaps they assumed I wanted to come in, or even that I belonged there, and if so, I should knock on the door. But, the policy only said "please knock." And, so I did.

This is a really important problem in SOA Policy Management. Without the right context, without tying "intent" to policy, we could end up with some strange behaviors. Imagine if everyone that walked by that trailer knocked on that door? Fortunately for us, while there may be many Ugly Betty's, there's only one "stupid Dave."

I think with Software AG's announcement, OEM-ing Progress Actional to tie together development-time and run-time governance, perhaps some of this confusion will be avoided in the future. Let's hope so.

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.

I Try To Be A Nice Guy, But Bad Things Lurk on the Horizon

A funny thing happened to me last night. Why do funny things always happen when I have time to think?

I was manually copying over birthdays from my Exchange calendar to a Google calendar. Pretty brainless work so my mind was wandering. And, I realized... if I were a little less careful and made this public, I’d put 100 or so identities at risk.

Let me explain.

I’m a fanatic about birthdays. Not sure how it evolved but I actually receive a thank you note at the end of the year from Mr. Hallmark (kidding, of course, but I should!). I figure life goes by so quickly without keeping in touch with people, so the least I can do is catch up once a year on people’s birthdays. And in conversation, if someone’s birthday comes up or if someone mentions the birth of a child, I jot it down and put it in my calendar. I put it in with a 7 day alert which reminds me to get and mail a card.

It’s always the first one there.

So as I was entering birthday’s last night, I would enter something like:

David Bressler’s Birthday (’67)

And if I made this a public calendar, everyone could easily find my birthday. Why is this a problem?

Well, I still don’t know Dan’s -- it’s a mystery. Even his Facebook page has the wrong one! Why? Because he’s worried about identity theft. OK, but what if I did know his birthday and published it? Well, years worth of data security implemented by Dan would be tossed out because one idiot (me) accidentally hit “public” instead of “private” on a Google calendar.

SOA What? Think about it for a second. Companies spend all sorts of effort on keeping data secure, yet it’s really about people and process as well. Just like developer time governance.

Even more importantly, however, is the idea of what’s at stake. Application level security was relatively easy (IMO) - compared to service-level security. I mean, you install an application and you usually know. However, services are a different story. Services are often there as API’s to applications; though the application installers aren’t usually considering them. Worse, any developer can create and expose a web service and an admin would hardly know it’s there. This has the potential to expose data to anyone patient enough to try the default endpoints for packaged services. And, before you disagree... how many Sales Engineers are successful “breaking into” customer systems with default passwords? More than anyone would care to admit! Besides, a lot of security problems are from within an organization, so when administrators don’t know what’s there, they can’t possibly manage the risk.

My point? I admit, I’m rambling a bit... still trying to break through some writer's block. My point is that you’d better know what’s going on, not think you know. To do that, automatic discovery is a critical requirement to any runtime SOA governance evaluation with your SOA infrastructure.

What Does Marketing Do Anyways?

There are different types of marketing... but product marketing, in part, "figures out what to call that thing."

You see, we have a lot of really smart engineers who are doing new things and are very creative about solving problems. But, then they go give it a name that reflects what it does, which is great... until it starts doing more. And, then what? You've got a branding/messaging problem, or worse.

I was in a meeting earlier in the week, talking about product stuff and Julianna asked "well, what category is that?" A question that just sobers me right up, even in a product planning discussion.

You see, if there's no category, no one will understand what it is (and there is no magic quadrant for it!). It's something technology companies seem to face a lot, and with my experience in start-ups, we faced it all the time. There are three options:

1. Glom onto an existing category and hope to convince people you're different (Does this sound familiar? "Why isn't anyone listening to me, I said 'discovery' not 'discovery'?!?!")
2. Create a new category (That's the sound of marketing budget being flushed down the toilet!)
3. Ignore it and do your own thing (At least I'd have alignment between my personal and professional life.)

There is this weird dynamic... if you call it something fancy/different, a lot of technical people (our buyers?) don't trust you. They think "marketing" has just come up with a different way of saying the thing you are trying to differentiate yourself from. It can actually work to reinforce competitive messaging, or at best, simply reduce the trust you are trying to build with the prospect.

Interestingly, Lori posted on a similar subject this morning, differentiating application delivery controllers from load balancers. Her situation is different, as an ADC is a "more advanced" load balancer (don't shoot me if I'm muddying the waters further!). Whereas in Actional's case, we're not something else plus X. We're just X, and when most people are trying to solve the same problem, we solve using something else (wholly ineffectively I might add!).

But, if you look at the three choices above, there really aren't three choices. Or rather, the choices are already made by company culture. Take Progress Software for example: We're not "marketing trend-setters." Meaning, we don't invest in creating new categories. And yet, we're big enough that we don't just "do our own thing" because that requires a different sort of discipline than the one we employ. Don't get me wrong, I like and respect our discipline, it's just different than what's needed for a "do your own thing" approach.

So, we're left shouting into the wind. Perhaps that gives a windbag like me good career prospects? I'm not sure.

SOA What makes us really different in our category but unable to create a new category around easily?

1. We track every single message, consumer, producer, and the relationship between them all, in development or production, without affecting application performance.
2. We do it easily and automagically, meaning we get the full benefit without blowing TCO through the roof.
3. We know exactly who's doing what to whom, and how often, which allows SOA owners, operators, and business analysts to make better decisions about the distributed applications running on their SOA infrastructure. Whether it's about SOA operations, security, or business alignment, there's no more guessing (praying?) about what's happening.

Supporting SOA Governance Monday

Whew. What a rough weekend.

I was listening to Condi talk on Friday with a sense of relief. The Russians had invaded Georgia and she brokered a cease-fire. I was worried about friends I have there, though, when I spoke to them they didn't seem concerned. I guess it wasn't as bad as they were showing on TV. That happens a lot.

I was glad my friends were OK, but more glad for the ceasefire. I think had the Russians cut off Jeb's retreat from Florida to Texas, George would have been forced to act to save his brother. A third front on this war on terror, and this one in our own backyard! I mean, it's bad enough we can't get a good cigar because of the Russians in Cuba, but if peaches became scarce because of the Russians in Georgia, I'd volunteer for the draft. I like peaches.

I was really getting stressed, until someone at Edward's told me the Russians attacked the other Georgia.

That's pretty scary, such a simple mistake. Good thing I wasn't the guy with my finger on the missiles. And, before you say that there's no way a commander with such important responsibility would make such a dumb mistake, think very carefully about how this country is run*.

Truth is, I knew which Georgia they were talking about. But, the whole weekend, I kept thinking how funny it would be to blog as if I didn't. There are only two Georgia's... or at least there are only two I know of, but I'm sure there are more. Driving to Vermont this weekend, I drove through Cairo, Malta, and Hague... yeah, we reuse words a lot. My favorite ambiguity though was the sign that said "New York 165 miles." You see, I was in NY when I saw that sign. I knew it meant NYC, because I had the right context (and a brain). But... it would be totally understandable if someone looked at that sign and cursed the idiot that put it there.

SOA What? Here's another word with too much ambiguity around it... Governance. If you think keeping track of two Georgia's is hard, imagine trying to keep track of all the meanings behind [SOA] Governance!

Last week, Dave Linthicum expressed his frustration with vendors that start by asking, "what do you mean by governance?" Well, what else can we do? It's such a morass right now. Frankly, I think most people hear governance and think registry / repository... but I'm not going down that rat-hole right now.

In my opinion, the word Governance is devoid of meaning due to overuse (as it relates to SOA). Dave, founder of Governance Monday, has a long standing belief that it's about People and Process as much as technology. I agree but... still believe that as software companies, when we talk about governance, it's a good bet we're talking about the software bit.

Another aspect of governance was blogged about by Lori MacVittie over at F5. She points to an interesting InformationWeek article about service mediation. (That article's a good read but I'll have to save my thoughts for another post! This one's already too long.) I believe intermediaries are an important part of a SOA infrastructure as Lori says... I think intermediaries belong at the border of the cloud, where a SOA is really a set of clouds-within-a-cloud. [Discovering how those clouds relate to each other and are used in real-time is the core Actional benefit. Email me if you want a copy of our Concepts Guide that describes this.] I probably differ in opinion from Lori though in believing that the intermediary design of a SOA can incorporate BOTH hardware and software intermediaries, without any sacrifice of performance and reliability. (We here at Progress don't sell/develop a hardware based intermediary solution but I do believe they are an important part of the "right" SOA architecture. Just because we don't sell one, doesn't mean they're not important.)

Dave also tweeted that Design Time Governance is dying (I don't know if it is or not but I sure wish it would so we could focus on what's important!), though Todd Biske thinks otherwise. Todd tweeted something very important. Todd's a big Design Time Governance proponent, but says "it depends upon your goals." That's a phrase we should all live by! Todd posted his latest governance post before Governance Monday, but it's still worth reading. Actually, I'm a big metaphor fan (I learn better and express myself better through metaphors) so I really like his post.

Wow, that's a lot of referential reading! Monday's a good day for that, there are generally lots of "status meetings" on Mondays during which we can multitask. But if you want "in" on the conversation, follow me on Twitter, and check out Dave, Lori, and Todd as well.

* I feel the need to clarify. My "jokes" actually not only don't reflect the political views of Progress, but they don't necessarily reflect my own either. I'm just trying to bring some humor to an otherwise dry topic.

All Hail the SaaS Revolution!

Been thinking a lot about Software-as-a-Service (or SaaS) this week, and as it turns out, so have a few others!

Dave Linthicum posted recently that for the "last year we've been in a silent revolution around the use of APIs/services," while Mel Greer (Lockheed Martin's Chief SOA Architect) says the SaaS model is still an "impending challenge." Past or present aside...

Mel outlines the challenges companies will face by "as a service models" and includes:

• the need for SLA's,
• real time monitoring,
• end-to-end testing,
• new pricing models, and
• a rethink on "service usability."

Mel, if you're reading, when do we not have these problems?!

Though the word is way overused, Mel is really suggesting that we'll need a way to govern the "as-a-service" business model. In fact, it's a popular topic this week. A blogger over at Patni had a long post with a gem in the middle... a governance outline (that I don't fully agree with) for SaaS. I presume this governance model would need a way to measure and police the following five elements of the SaaS scenario:

1. Strategic Alignment
2. Risk Management
3. Performance Management
4. Resource Management
5. Value Delivery

SOA What? Let's think together for a second. Dave's right. There're are a ton of services out there. The Amazon web services are really cool, and people are being really creative with solutions being brought to market around them. Mel's right too. SaaS models are in their infancy, and if they're to really grow and achieve their potential, there are a lot of challenges ahead of us. Why not think about a SaaS governance model that could be used to make SaaS deployment more successful?

Does SaaS impart any requirements that differ from other "services" models? How would you approach figuring out your requirements and evaluating solutions that depend upon SaaS offerings? Do you think that SaaS adds a separate flavor to governance, or is it just same-old with how you operate your services and work with your providers today?

I believe SaaS does add separate requirements. Though, I'd look at the SaaS space from two different perspectives; that of the SaaS provider, and that of the SaaS consumer.

Providers have the following concerns:

• Security: Consumers will have security requirements, but providers will have the more complicated requirement of meeting the security demands particular to each customer, without code changes each time.
• Knowledge: Providers need to know what's happening when a customer calls with a problem so that they can be specific and inspire confidence. Without specifics, vendors are just perceived as finger-pointing even when they're right! (This is one of my favorite customers stories to talk about.)
• Use the SLA as a competitive differentiator: If providers can accommodate their customers' business model better than a competitor, and can accommodate change/expanding models, they'll be a step ahead of the game.

Consumers have similar, but different requirements beyond the obvious:

• SLA's that matter; Availability, for example, is important. Uptime, not really. SLA's should be based upon metrics that matter (and are measurable!).
• Agility, (it's why they're using SaaS); As new features are deployed, it's important for SaaS consumers to be able to on-ramp their applications easily/quickly to take advantage of new features. Conversely, consumers need to be protected from change forced upon them by their service providers.
• Low switching costs; Should a consumer need to change vendors it shouldn't break everything. At the same time, this feature can actually be extended to transparently combining SaaS vendors in the infrastructure so that applications don't know/care which provider is used, and decisions can be made that best serve the business, not the developer.

I'm curious to know what you all think about these requirements, and if these are among the things that are top of mind. I'm curious to know what real-world experiences people have with SaaS from a corporate perspective. I'll tell you, mine are limited to salesforce.com, and they're not very good. Rephrase - they're not what I would want were I a CIO delivering solutions to my users.

Here's a quick SaaS factoid: Did you know that Progress Software has 150 SaaS application providers delivering over 500 SaaS based products to the market today?

Inspired by the Uninspired

Overly complicating things is not an accomplishment, no matter how hard it appears someone's worked to complicate the simplest things.

Take grocery shopping. Simple, right? Pick food, get in line, pay at register. Doesn't get much easier.

Except at Whole Foods.

At Whole Foods you have to pick one of several lines, each color coded. Then, register numbers appear on a screen with three colored vertical lines and you have to match the color in your line (which is only displayed where you enter the line, not where you stand on line) to the color on the screen. If the register number displays on the color of your line, you get to pay for your groceries.

I swear, at my Whole Foods the colors of the lines don't match the colors on the screens. Is the product manager color blind? Were there two different unions involved? Didn't they check before they installed it? When I asked a worker in the store, he laughed and said "Yeah, I know. But, look, it's not one of the other two colors, so it must be the color of your line." For real.

So, the simple process (get in line, pay) involves six lines, seven if you count the express line (don't ask me how that works), two TV screens, three colors repeated each twice, and 24 registers (numbered, but not color coded). To heck with queuing theory, we have colors!

I want to meet the guy (or gal) that designed this system! I would pat him on the back and with admiration in my eye be like "you are one creative dude."

And I bet if I took him out for a drink, he'd explain each and every feature of the checkout line and each corner case it was designed for. I'm sure he'd apologize for the mismatched colors, but... hey things happen. In checkout line 2.0, the colors'll match.

SOA What? Well, I think this guy got too wrapped up in the art of checkout lines and got a little (OK, A LOT!) carried away. But, we all do that. Humans are a creative and proud lot... even the dumb ones.

What does this mean to your SOA infrastructure? Well, take a step back and look at your infrastructure (SOA or otherwise). Ask your users where it's too complicated - they'll be happy to tell you. And if you're lucky, like checkout line guy, they may even buy you a drink while they do.

What does it mean to me? Well, I have to be satisfied that my adventure in queuing-theory-less shopping was much more exciting than Giles' adventure in boardroom statistics.

Now, That's the Way to Approach Your SOA Infrastructure Investment!

A short post today... There's so much good stuff happening but I want to try to blog more regularly. I wonder if shorter posts with less flourish will generate more conversation?

In any case, last night I was reading through Seeking Alpha's transcript of Duke Energy's (DUK) earnings call, and came across the following paragraph that struck me:

"We proposed a $100 million plan to install solar panels at up to 850 sites, including homes, schools, stores and factories. To implement this Solar Distributed Generation Program, we are asking for approval to install, to own, operate and dispatch the solar panels. This initiative will help us meet the state's renewable and energy efficiency portfolio standard. Also it will enable us to evaluate the role of distributed generation on our system, and gain additional experience in owning and operating renewable energy resources."

Let's put this in software terms... they're doing a $100M pilot project, involving 850 sites, to gain experience with a technology that they know is in their future. They have set a few clear objectives, though perhaps I'm reading between the lines. Let me share with you how I read these objectives:

1. They'll learn what it takes to get approval for this sort of thing.
2. They'll learn how to negotiate "right of way" for all these different environments (schools, homes, stores, factories).
3. They'll get real-world experience at what it takes to meet their state's renewable and energy efficiency standards - this means they'll be able to participate with the state as a knowledgeable partner, rather than a defensive infrastructure owner! (I know, no defensive infrastructure owners in your SOA. Right.)
4. They'll get real experience about the impact on their current infrastructure.
5. And, they'll gain first hand experience about the costs of owning and operating this new infrastructure.

SOA What? Face it, SOA is in the future of every technology infrastructure. Do you expect your organization to wake up one morning and just have the required experience? Do you think you'll get it right the first time, without ever trying it first? Do you think you can put every objective for SOA out there, and have a grand plan and just go? That reminds me of a customer I worked with where their RFP read something like... "Your product should support [insert summary of every WS standard], and allow us to [insert every marketing tag line from registry, infrastructure and SOA management company]." That sort of plan doesn't show any insight because it's not based upon experience. Just the opposite, it made me wary because I immediately knew there was a lack of experience.

Well, Duke's objectives sound like good ones for any pilot SOA project. In fact, with some minor rewording, you can use the list above on your own project.

Though, I'm not foolish enough to think anyone will invest $100M in a pilot SOA infrastructure, clearly some pilot investment is justifiable considering the valuable knowledge gained in the process and the long term impact SOA will have on IT infrastructures in every organization.

Say What?!? How Would You Select a SOA Management Tool?

Admittedly I have a bit of ADD and get distracted easily. I love to read, but can't read poetry, or even classics, where I have to pay attention and remember the beginning of the sentence when I get to the end. It's why I studied math... I got to learn by doing, not by reading (pretty ironic, considering I don't actually do anything here at Progress!).

That said, can someone please read and translate Animesh's post for me?

He's got a great topic (even discounting the poor grammar), but I'm not sure what he's saying. So, I'm going to glam onto his topic selection with some of my own advice on tool selection. Here it is, ready???

To select the right SOA Management tool, figure out what you need the tool to accomplish, then DO A PROOF OF CONCEPT in your environment.

That's right. You heard me. I work for a vendor and I'm advocating a POC. Why would I do that? Two reasons...

1. I no longer am responsible for doing POC's. Let's face it, they're hard work.
2. I started my software career in 1995 at TIBCO, and in all this time, never once experienced what I experience here at Progress Actional. We finish POC's on-time, and things just work.

Let's really get under the covers. Why are POC's hard? Well, there is a lot of pressure because everyone's watching, and there are a lot of unknowns. I can't tell you how many times customers drew their environment on the board, but when we installed we found something different.

In fact, a funny one was at a company I can't name (but which carries the same name as an outspoken mayor of a large city that I know well), when they were using JBOSS and swore to us they were using the JBOSS SOAP stack. We go in, install Actional, can see traffic coming into JBOSS, but not out. We lost a day troubleshooting, looked at some log files, and sure enough, they were using the JBOSS stack only on the way in... they were using the AXIS SOAP stack on the way out. Hadn't configured it because they said they weren't using it! This is pretty typical, and in fact, one of the easy ones to track down.

SOA What?

In any case, long story short... it's much easier to sell without doing a POC, but it's not in your best interest to buy without doing one! Besides, without a POC, how are you going to validate a vendor's claims to functionality, performance, and scalability? How are you going to figure out if you're "missing anything" from your evaluation?

If you're interested, drop me a line or, better yet, leave a comment, and perhaps I'll write about some interesting things to add to your POC evaluation criteria.

On Roadmaps and Future Product Features...

As some of you know, I'm more than just a pretty face. In fact, more years ago than I care to think about, I got my MBA because I was more interested in how and why technology got used in the enterprise way more than how it was implemented or what technology it was.

Of course, as with everything in life, the parts that I got out of the experience had nothing to do with what I expected. I've learned to keep an open mind (stop laughing and let me finish), and let things happen - when I do that - I usually have a much richer experience that I could have imagined.

At Progress Software, we're a technology company but, like any other public company, we are also a business. A business subject to rules... some obvious, others not so obvious. Assuming that the readers of our blog are made up of primarily, (1) customers, and (2) Progress employees, I'd like to point out one of those "less than obvious" rules we have to deal with. You see, we're pretty fiscally disciplined here at Progress; disciplined and conservative.

I've become a bit of an Apple fanboy and was reading an analyst article, when I came across the following paragraph discussing the iPhone:

Apple's management cautioned in its Q2 conference call that it will not be recognizing the revenue for any iPhones sold between March 6 and July 11 until after iPhone 2.0 is released. Peter Oppenheimer, Apple's CFO, notes in Apple's Q2 Conference Call, "Because we announced the specific new features to be included in the iPhone 2.0 release and plan to provide them to iPhone customers as a free upgrade in late June, we will delay the start of revenue recognition for all iPhones sold on or after our March 6th announcement date until the iPhone 2.0 software is delivered."

I recognized that necessity. You see, we have the same restrictions with regards to revenue recognition. If we tell you about a product future and you buy the product to use the future feature, we can't recognize the revenue. And, as a conservative company, we are very careful about our financials. Our investors appreciate that but I know first hand that our field staff doesn't, and our prospects question our direction when they feel we are being evasive.

SOA What? What does this have to do with SOA infrastructure? Well, if you're buying our SOA technology, you need to know where we're going - but, we can't always give you specifics AS MUCH AS WE MIGHT WANT TO! You need a feature and you wonder why we can't just commit to a date and get over with it. This is why. It's about revenue recognition, and rules that are placed on us to protect customers and investors alike.

Instead, why not use a different approach? Knowing that these are the restrictions that vendors with integrity are under, how can you get what you need without compromising the integrity of the process?

Let me ask you another question - before I answer that to get you thinking about how successful the current approach is - regardless of the legal restrictions we're under. How many times have you worked with a vendor who successfully delivered a POC with some custom feature (often integration with some other product I would bet), gone and purchased the product only to find that the feature delivered during the POC wasn't quite up to enterprise class? And further, what has your experience been trying to get the vendor to add the feature to the roadmap in a way that addresses your concerns?

So, how do you get what you need without compromising the integrity of those involved?

Talk therapy.

One interesting thing about our space is that we're deep in infrastructure, and purchases of our product, both large and small, tend to be strategic in nature. We're going to be together for a while. Why not get to know us?

I suggest the following sorts of questions:

1. What is the product direction and strategy? What problems does it solve and what does it do best? What won't it do?
2. What use cases do partner integrations satisfy, and where do those use cases fall in the product adoption life cycle? Why not get multiple vendors in a room together and have a mini-summit? A four hour brain dump? I find those informative for all involved.
3. What references can be shared by customers who needed features and worked with product management to get them appropriately prioritized and delivered?
4. What is the vendor's product delivery strategy? How many releases annually? What is the delivery/release strategy? For example, if you look at our minor-releases, they are often driven by customer enhancements. We use the rapid cycle of minor-releases to quickly address customer concerns as they start their implementations rather than forcing them to wait six months or longer for a major release. As part of our process, these minor releases are fully supported and part of the product in a disciplined manner.
5. How flexible is the product architecture to allow for enhancements? What is a typical timeframe for an integration of type X?

I know, talking about strategy is high-level, but... isn't it better to learn how we make decisions rather than to get an answer to the questions you have now? I think so. Remember, we're going to treat you really nicely when we're dating. What you really want to know is how we'll treat you once we're married.

That said, you know Dan and I from this blog. We spend more of our time talking to prospects than customers. There are two people on the team who are the reverse - though they talk to prospects, they spend more of their time working with customers. They are Vasco Kollokian, our Product Manager, and Julianna Cammarano, our Product Marketing Manager. I've learned tons by working with them. Why don't you try some of the questions above on the four of us, and see what happens?

If One is Good, Five Must Be Great!

Rob Hailstone, an analyst over at The Butler Group, just wrote an article talking about our IONA acquisition. It's one of the better articles I've read, and it shows that he knows quite a bit about IONA's products and the overall market.

He makes two points in relation to Progress® Actional® which I'd like to address. He suggests that IONA partners with Amberpoint which will have a conflict with our Actional products. Then he goes on to say:

"Progress partners with the HP Systinet registry/repository for service and metadata management, but Iona has its own registry/repository within the Artix suite."

Well, the Amberpoint issue has been addressed below both by Dan and myself. But, I'd like to clarify the Actional registry/repository positioning for Rob's audience, since I couldn't comment directly on Rob's post.

Actional currently supports registry/repository integration with:

1. Standard UDDI registries
2. HP Systinet (and the Governance Interoperability Framework)
3. Software AG
4. Fujitsu
5. BEA AquaLogic Registry Repository

Each of these is currently supported and available.

SOA What? This actually speaks quite well to the Progress SOA "portfolio" concept (in contrast to "stack" vendor solutions). The idea behind our SOA portfolio is that customers are free to choose bits and pieces that work for them, and be assured that the bits they choose work well with the rest of their enterprise infrastructure choices. Actional supports Sonic ESB and SonicMQ, as well as IONA Artix and other ESB solutions. Customers have a choice, and our partner organization works very hard to make sure that we have the relationships to back-up product integrations we deliver to the market.

SOA How? Actional is sold with an optional module called the "Governance Integration Module." For integration beyond standard UDDI integration, the Governance Integration Module is required. This module abstracts out the various repositories so that we can publish all sorts of cool things beyond service endpoints, like real-time service statistics, dependencies, and policy information. It also make is architecturally-easy to add new registries as circumstances demand. As for integration with IONA's registry... for that, you'll have to wait until we announce and further discuss roadmaps. I can't talk about roadmaps, but I hope I've addressed Rob's concern about partner ecosystem implications.

Oracle Makes the Right Choice for their Customers

As I write this, I wonder if Joe will wonder why one of his (very loyal, and loved by many) employees (me) would promote Oracle on the company blog! Hear me out Joe... this is good news, for us, and for Oracle (and BEA) customers.

Just back from vacation (I know, y'all missed me), and adjusting to the market's reaction to our acquisitions of IONA and Mindreef, and I came across this bit...

Oracle drops Amberpoint for SOA Management.

I mean, it's on the Internet, so it must be true, right?

I can't say this is a surprise, except that I am surprised that they are correcting their mistaken relationship in the first place. I mean, look at the history of Amberpoint's partners once they make the time to find out about Progress® Actional®:

1. Microsoft. Amberpoint's got a great relationship with them, and certainly much better than we do since the Progress acquisition. But... Microsoft has always viewed them as a tool vendor, shipping Amberpoint Express with Visual Studio. A testing tool for developers that doesn't integrate seamlessly with their enterprise offerings. And, we continue to enhance our support for .NET SOA infrastructure, including more protocol support for Microsoft protocols (like ADO.NET and WCF) than any other SOA management vendor.
2. Progress. Progress originally had a "best practice" offering with Amberpoint, until Hub met Dan. Hub, one of Progress' technical gods, got it immediately, and not only did they drop Amberpoint, they acquired us!
3. IONA. Our Actional customers won't talk in public but not only have we been partnering with IONA (with an Actional Agent for Artix ESB), but we've been replacing Amberpoint in several accounts because of the impact they have on production performance and scalability. Oh, and it turns out that Amberpoint modifies one telco's messages in order to track them end-to-end... a big no-no.
4. Software AG. A relationship growing quite well, combining Software AG's registry and repository solution with Actional's SOA management and security offerings. Like chocolate ice cream and whipped cream - it's ecstasy.

And, there are many others, large and small.

By the way, with respect to Oracle/BEA, we support Oracle Application Server and WebLogic Server, and BEA Aqualogic Enterprise Repository, and have for some time.

SOA What? I know the above is a bit sales-y but it's an important part of who we are. And, when customers make a decision to work with a vendor like Progress Actional, they want to know they're in good company and that we'll work with the rest of the enterprise tools already in place. We are, we will, and we'll do it in a way that easy, fast, and scalable. I promise.

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.

What Makes a Good Policy?

Anyone ever see David Letterman's stupid pet tricks? I think we should have a tech show called stupid IT tricks. I recently heard that one CIO's strategy for meeting user requirements was to forbid users to submit feature requests. Software would be installed, and the way it works out of the box is what the users get. His policy of "no more user requirements" ensures a 100% success rate of meeting his IT policy. I applaud his brilliance.

As silly as that sounds, check these two policies out...

• Please don't ride the subway if you have a cold. These signs are posted throughout the NYC subway system.
• Don't drink and drive.

These sound like pretty good policies, right? The former benefits everyone by preventing sick people from getting others sick. The latter, well, it saves lives.

But let's take a closer look... This first policy is totally unenforceable and really doesn't reflect user's realities. Whoever thought of this "marketing campaign" did nothing but waste tax-payer dollars. Most people would love to not come into work when they're sick, but that's just not a reality. If we wanted that policy to work, we'd have to make a realistic alternative for sick people. After all, what's their motivation for following a policy if it's not enforceable, especically when they may not have any direct benefit from following the policy?

On the subject of enforcement, let's look at the second policy. Clearly, this is an enforceable policy. Why then do people continue to drink and drive? There are realistic alternatives to drinking an driving, and would-be drunk drivers benefit directly. A sick person is already sick so not riding the subway doesn't help them, but a drunk who doesn't get behind the wheel is stopped from hurting themselves, or worse, others.

Unfortunately, as Mayor Rudy used to say, "common sense is, unfortunately, not all that common." I think, in part, it's because enforcement is subject to "user interpretation."

But apparently, people are more worried about being embarrassed by having their names/photos published if they are caught drunk driving, than they are about hurting someone, losing their license, or jail time. A new policy started on Memorial Day in Long Island that stated that people arrested with blood alcohol levels over the limit will have their names and photos published on Monday mornings. It's an effective enforcement procedure but has been called "controversial" - probably because it's a government program that works.

SOA What? I commend the person at the MTA who is trying to instill manners on subway riders (though I still think that they should be fired for wasting money/time). But it's a noble cause doomed to fail. And, for those officials on LI willing to risk controversy and continue to publish drunk's names and photos, you set a good example for those of us trying to police our SOA infrastructure.

What can we learn here? Again, it's about the carrot and the stick. Both need to be in place organizationally in order to make policing the SOA practical. You've heard it before, SOA (and SOA Governance) is as much about people and process as it is about technology.

1. Carrot. Enforcement depends upon user behaviors. You can threaten to cut off access to a service if an application doesn't follow policies, but... if that application is mission critical, you probably won't be able to do that. What you'll have to do is adjust your governance policies! It may not be obvious, but there are probably low cost ways to encourage user behaviors without making them political battles. How about posting a list of insecure applications? You may not be able to cut them off, but perhaps users will think twice before depending upon the application. Put the onus back on the developer rather than being the bad guy yourself.
2. Stick. Policies need to be enforceable. And that simply means watching what's happening. Let's compare our SOA to the subway... When we create a list of policies stored in a registry and then test our application against those policies once, when it comes time to place the application into production, it's like making sure we only sell metrocards* to healthy people. Once you have a metrocard (once you're app is in production), you can get sick and ride the subway (you can violate your governance policies), but we have no way to tell because you have no visibility into your run-time environment. If you laughed when you read the policy above, and do this in your SOA, I suggest you rethink your approach to SOA governance.

Have You Ever Been Beat Up By A Tiny Older Woman?

I have.

And, more recently than you might think. She had experience that I didn't and she knew how to use it. I didn't stand a chance.

Some of you know that my role on the Progress Actional product line is both external and internal. I spend a good amount of time evangelizing Actional and Service Management, but also trying to understand how to leverage community technologies to make the evangelizing easier and more permanent.

I'm trying to institutionalize the tribal knowledge Actional "elders" have learned so that the whole company benefits.

I came across an interesting article, "Now Everything Is Fragmented," just the other day on this topic. It really expressed the frustration here in the Progress Tribe, and in part the "old-school" vs. "new-school" thinking on the subject. You see, everyone wants best-practices, canned RFI answers, and even a single ROI model we can use to measure how much money Actional will save our prospects.

What they ask is easy, but, in my experience, marginally useful. Though, as I thought about this article, and my problem, I realize that I could look at two different personas - one for which this information is very helpful, and one for which it is not. People with experience, who can think, need stories. They take these stories, explore new situations and find they have what they need.

SOA What? Yeah - it's that time. And, to be honest. SOA not much! I haven't written in some time, and the article above really stuck with me. I let it run through my head on last night's swim, and this is what I got. I hope you find it interesting enough not to hate me.

But, there are a couple of generally useful take-aways, that I'd like to point out:

1. Personas matter greatly, but only in the context of your goals. In my case, I listened to my users, applied my experience, and realized that two personas would greatly simplify my model. Looking at the world that way, I'm able to prioritize my objectives and address one persona or the other (or both), and be able to explain why I'm doing so. This helps me communicate throughout the organization way more effectively.
2. Communities are about conversations. Sometimes the conversation is around content - like a best practice or ROI model - but sometimes it's about the story (experience). By nature, we're story tellers, and we need a way to capture those stories institutionally and need to train (and hire) people who can use them.

And, a final piece of advice...  This tribal knowledge, this experience, needs to be kept in the company. And, it needs to be nurtured. The people with the stories, these living databases, without them, the community not only falls apart, it simply ceases to exist. Students of knowledge, which I like to think of myself as one, know the value of experience and move mountains to get close to it.

Marrying Best-of-Breed Tools for SOA Governance

1+1=3: Marrying Best-of-Breed Tools for Business Process Governance
Tuesday, April 29, 2008 at 11:00 am EST
Register to participate >

Communication is the basis of any successful relationship, including the communications between business people and technologists. Bringing together BPM and SOA Governance enables business drivers to be translated quickly to SOA implementation, with full accountability, lower cost of ownership, and business-level SOA optimization.

Join David Bressler, Actional Product Evangelist, and Marc Smith, Director of Product Marketing, Lombardi Software, tomorrow, April 29th, for a live webinar entitled, 1+1=3: Marrying Best-of-Breed Tools for Business Process Governance .  Listen to what David and Marc believe are SOA best practices for company's looking to ensure consistent enforcement of policies across all teams building SOA applications.

Other upcoming SOA infrastructure webinars you may be interested in, include:

• Visibility and Tracking for Critical Applications – Optimize Application Performance and Increase Revenue
  Tuesday, May 6, 2008 at 11:00 am EST
  Presented by: Julianna Cammarano, Sr. Product Marketing Manager, Progress Software

Extreme Volatility

Based on the title, this post can be about either:

1. The stock market
2. My personality

Obviously, there are two different audiences that might be addressed here. What's needed is more context around the description above to decide whether this post is actionable or not.

More context is needed. Where have I heard that before? (SOA What?)

Well, if you were in Europe in 2006 just after the acquisition, you probably heard me talk about capturing context of the messages flowing across your SOA infrastructure. It's one of my favorite topics because the benefit is so powerful.

Imagine having a system that pushes contextual information along with alerts, so that the root cause and business impact can be immediately known? This information drives action, improving user experience, and overall system performance. Cool, right?

Here's the message in my head:

1. Actional is different because we track EVERY SINGLE MESSAGE flowing through the SOA.
2. We do it across multiple protocols and platforms, giving people who care, an end-to-end view.
3. We track every single message, all the time, WITHOUT AFFECTING PERFORMANCE (it's magic).

What does this mean?

1. We have every message, and know the relationships automatically - so we can build flows that help us know where to look when a problem occurs, and where the dependencies are (even if we don't have prior knowledge of those flows ahead of time).
2. Because we're tracking every single message, there's no "inference" involved, no guessing - just the facts.
3. We can gather data about the flows and relate it to the flows to add business meaning to what we observe.

Why is this important?

1. No more urgently responding to alert messages that don't impact the business.
2. Preventative alerts let people know what's going on - improving the user experience.
3. The context provides the ability to act on events, in ways to preserve what's important and prevent further service deterioration - important customers, important orders, important channels of business can be prioritized above those less important.

And, most importantly, no more reading blog posts about SOA when you hope to read something about this crazy stock market.

Oh, yeah. I've got a webinar coming up on April29th entitled 1+1=3: Marrying Best-of-Breed Tools for Business Process Governance, during which I'll be using some customer examples of our partnership with Lombardi. If you remember, we shipped integrated SOA Governance with Teamworks, the Business Process Management platform from Lombardi, when we shipped Actional v7.1. Join us for the live event and hear about our success.