Integrated Infrastructure Blog

Poor Customer Service and Snoring Keep Me Awake...

Last night, like many weeknights, I pre-planned my escape by putting my phone in the guest room. As I entered the room and got ready for the one-click alarm set, I noticed that I had a new voice mail so I called in to check it. Here is what it said:

"Hello, This is an automated voice message from Jet Blue Airways for Pamela Gazley with important information about a change to your scheduled flight. Your flight has been canceled. We look forward to serving you. Goodbye."

My first response was "why?"; my second response was "which flight?" My 2nd response was a little silly because of the 4 flights I have scheduled for the next week, only one involved Jet Blue; however, what if there were others? Does Jet Blue Airways know that there are products out there that can improve their processes so that they can deliver better customer experiences? Does Jet Blue have any business analysts that might think, "hey, what if when we send out the automated voice message, we include the flight number, date of travel, and the reason for the cancellation"? I guess not because I was completely annoyed.

Now I don't work for Jet Blue but I'd bet that they have some kind of integrated infrastructure that would allow them to improve business processes. If this "automated message" knows my name (though pronounced wrong), it should know my flight number, the date of travel, and the reason for the cancellation. My advice to Jet Blue: learn more about business transaction assurance,  business process management (BPM), and give us a call because we can help you achieve operational efficiency and improve your customers' experience.

Celebrating the shadow of Punxsutawney Phil

As the week of Punxsutawney Phil’s appearance commences, I must admit I’m one of the few that is happy to hear we have another 6 weeks of winter to look forward to! Why you ask, well that means more skiing and an extended window of time until I have to start worrying. Worrying about when to apply “Step 1” nutrients to my lawn, about how much the voles and moles have destroyed my plants, and about whether or not I warded off the dreaded Dutch Elm disease with the systemic treatment that was applied last fall. Bottom line is I have a 6 week reprieve.

But... what if I could apply technology to my yard, garden and even the infrastructure of my home. What if I could apply some fundamental concepts like automatic discovery, monitoring, management and control, across my household infrastructure? The possibilities are endless. I could set up points of visibility at strategic points in my yard such as the base of my newly planted Double Pink Weeping Cherry and at the perimeter of my bulbs. In the house I’d want visibility at the base of my water heater, sunk pump and egresses. With all this visibility I’d then establish a console where a complete infrastructure map would clearly reveal all activity that transacts in and around each point of visibility and if any issues were detected I could quickly and easily pin-point the root cause. And with points of control I could then dynamically control and avoid potential danger or damage such as voles eating the bark of my young cherry tree or avoid having my basement flood. Ohhhh wouldn’t this make life so much easier and a lot less costly.

Even though technology has not yet met my household needs, I still have hope. Maybe someday the principles and benefits of solutions like Actional for business transaction assurance will apply not only to the needs of enterprises with business critical transaction but to my needs as well. With Actional enterprises gain complete and automatic end-to-end visibility into their heterogeneous environment. Visibility that helps organizations understand the value of each transaction with the ability to dynamically control and optimize outcome. If enterprises can gain this level of business transaction management, I think it only makes sense that our next market should be the household management sector!

Reduce Order Fallout and Improve Your Customers' Experience

A New Video / Flash Presentation

Our audio presentation, Lost in Transactions – A Day in the Life of Application Failure, presents the fictitious story of one company struggling to find the root cause of application performance problems. If your enterprise identifies with their pain, take the next step by learning more about business transaction assurance with Actional.

Visit our website to view the Flash, or visit the Progress Software YouTube channel to watch the video.

Enjoy!

[Note: The voice of Karen is me, and the voice of Chuck is our own David Bressler.]

SOA? What do you call it?

Some of you may have noticed that we renamed our blog from SOA Infrastructure to Integrated Infrastructure. This came about when our product marketing team wanted to create a new “Open Integration” blog – same authors, same topics. Admittedly, I wasn’t a proponent of it because I wanted more blogging activity here, and I wanted to leverage the audience (and SEO truth be told) that we've built up over the past two years. So, I recommended that we re-brand it and we did.

I have no doubt that one of the reasons we wanted to move away from SOA was due to last January’s post by Ann Thomas Manes, SOA Is Dead; Long Live Services. Lots of SOA evangelists commented about the post, including our VP of Products Dan Foody who agreed with Anne’s perspective. Me? I personally think that SOA in itself is just a marketing term for a number of fairly distinct things, including enterprise integration.

With that said, this wouldn’t be a post by me if I didn’t offer or promote something, so I’m going to let you fill in the blanks.

Our new white paper The Foundation of _________ Quality is now available! What does _________ quality really mean? This white paper not only answers that question but it also examines the many facets of _________ quality. Read it and learn how you can ensure that your _________ initiative, such as Web 2.0, cloud computing, and BPM, can deliver the visibility and operational responsiveness that your enterprise demands. Get the white paper.

If you’d like to learn more about how your enterprise can achieve operational responsiveness, visit the Progress Software website.

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.

British Airways Selects Progress SOA to Upgrade the Travel Experience

British Airways announced yesterday that they had selected Progress Software for a revolutionary project that is integrating more than 600 different electronic systems and processes which are involved in getting BA passengers in the air.  This new highly automated infrastructure will bring increased agility to the airline. Rollouts will be easier, and associated cost and time will be reduced.

As is often the case with these kinds of announcements, however, it wasn’t really news to an “insider” like me.  I had visited BA earlier in the year and met with numerous people in the organization from the CTO to Architects and Developers on a number of the projects where they are implementing our technologies.  The thing that was most gratifying to me in those meetings wasn’t the scope of this cutting edge project or even that they were implementing using nearly our entire portfolio of SOA infrastructure products, namely Progress® Sonic® ESB, Progress® Actional® for SOA Management and Progress® DataXtend® Semantic Integrator (SI).  It was that, at every level in the organization, they expressed how pleased they were in the selection of Progress.  

At the senior executive level, they were discussing the partnership that they had developed with Progress and the vision we had provided to address real business challenges, for example, improving customer service by extending the features of BA’s e-commerce website into airports.  At the architecture level, there was a great sense of partnership on how the products we provided could be brought together in a coherent SOA based approach to their infrastructure that increases agility and operational responsiveness.  The developers were just happy that it really was “best of breed” technology that “just works”.  

At a time when most airlines are cutting back, it’s great to see British Airways taking advantage of what SOA has to offer and at every level of the organization they can count on Progress as a trusted partner to help.

Worried About Business Transaction Failure?

Besides costing you money, each failed transaction diminishes customer experience, and can even push your customers to competitors. We just released an Infographic that shows how Progress® Actional’s patented architecture and other key differentiators work to preserve the health of all transactions. It will allow you to see exactly what makes Actional unique, and how transactions are automatically discovered and tracked in a typical process flow. 

With improved business transaction management, you will:

• Enable centralized management and distributed policy enforcement for a cost-effective solution;
• Achieve real time exception management to diagnose and repair transaction problems quickly;
• Get the ability to optimize and create quality services before they are deployed.

WANT TO LEARN MORE? Download the PDF our Business Transaction Assurance Infographic. You can also register to get our E-kit which includes insightful papers and an E-book that will help you ensure that your web services never fail.

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!

Smart Integration Infrastructure for Insurance Industry

Those of us who have been entrenched in middleware and SOA infrastructure technologies over the years know the importance of having a smart integration infrastructure. Well, today we released a press release announcing that West Bend Mutual Insurance, a property and casualty insurance carrier, chose Progress Sonic ESB and Progress Actional as core applications for their service-oriented architecture. West Bend Mutual Insurance will use Sonic ESB and Actional to supplement its existing policy administration system, so its insurance agents can conduct business more easily and effectively via a single integrated portal. The insurance portal will also be a critical tool to help them improve their customer retention and acquisition. The best part is that West Bend Mutual will finally be able to enjoy operational responsiveness by being able to respond to changing conditions and react more quickly to business opportunities.

For industries like insurance that need to constantly offer new products and services to remain competitive, creating an infrastructure that is agile and scalable, and one that delivers end-to-end visibility of back-end systems, is essential. SOA is a great fit. Read the complete release.

Business Transaction Management with SAP

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

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

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

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

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

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.

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)?

How to Be Agile Without Falling on Your Face

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

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

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

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

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

SOA Infrastructure - Back to Future, No. 1

The New SOA Maturity Model

Originally introduced in 2005, the SOA Maturity Model white paper and the Quick Reference diagram were co-authored by business partners Systinet, Amberpoint, BearingPoint and Sonic Software. During a 2005 live webinar an audience poll noted that 40% of the webinar participants were “currently developing a SOA project,” and 37% noted that they would “begin a SOA project within the year”. That same year, Gartner, Inc. predicted that by 2008, "SOA will provide the basis for 80 percent of new development projects." (1) But over the past few years, there has been much skepticism about the ROI and business value of SOA. That doesn't mean that SOA is dead or that companies should abandon their SOA initiatives, it means that it might be worth stepping back to review your original goals and best practices, and move forward to seek the right solutions that will help streamline and cut costs.

The players have changed—Systinet was acquired by HP, Sonic Software was brought back under the Progress Software umbrella, and Progress Software acquired Actional whose product offerings align with Amberpoint—but the goals of any SOA technology provider or practitioner are the same; software reuse, agility and the improved alignment of business and IT. (I like Miko Matsumura’s 2005 post, The Rise of the Software Architect in an SOA World.)

With that, I’d like share the New SOA Maturity Model white paper and quick reference diagram which were updated in 2007. The tone may have changed slightly but it still provides a framework for discussion between IT and business users about the applicability and benefits of SOA in an organization across five levels of SOA maturity, including: Functionality, Cost Effectiveness, Responsiveness of Business and Collaborative Services, Transformation, and Optimization. The benefit of these resources also remains the same… to not only to provide a means for organizations to benchmark current implementations, but to offer a source of inspiration as IT leaders successfully advance the value of SOA within their organizations.

Enjoy!

White Paper: The New SOA Maturity Model >

Quick Reference: The New SOA Maturity Model >

1 Hayward, S. "Positions 2005: Service-Oriented Architecture Adds Flexibility to Business Processes," Gartner, Inc. Feb. 2005.

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.

SOA Governance in SMEs == Cart Before the Horses

I have always held that SOA governance is premature yet. While we are struggling to just get SOA adoption in the right spirit, governance is the least of our problems. If we cannot identify a mechanism to first re-engineer "service orientation" into IT solutions and have the IT teams in an organization be "SOA aware" ground up and not just deliver the POCs that the CIO or CTO demands, where is the need for operational processes and governance? In this context I found this article that professes a SOA governance approach for SMEs to be quite out of touch with reality.

While the thoughts proposed, such as agile approach to governance and the business users defining the need and IT groups quickly implementing the same, a managed governance process is not necessarily bad. It's just that we are dealing with more fundamental issues right now. Issues that are preventing the widely touted gains of SOA. That led to the drastic predictions of SOAs death!

In the present stage of SOA adoption, where we have just crossed the hype-curve's chasm, and are just now pondering over the serious practical use cases with a full grip on reality (of issues with SOA adoption), all that is immediately needed is anything but SOA Governance. Good tools and utilities to help quickly create services, test services, deploy and manage the same in production. The need for complete SOA lifecycle governance is still a few years away. At least, and surely not for SMEs, their SOA problems will be much more fundamental. SOA Management is what they will need now.

 

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.

SOA Next- Just a New Skin for the Same Problems

After the recent (and dramatic) proclamation that SOA is dead, is it a question of time until we see the rising of the proverbial Phoenix? Seems to be starting... at least going by the interview with Miko Matsumura in Information Week. Referring to the Gartner hype Cycle, he says, "I think we're on the 'Slope of Enlightenment' before we reach the 'Plateau of Productivity'. Anne Thomas Manes' pronouncement about the death of SOA was made in the depths of the 'Trough of Disillusionment'." I particularly liked the reference to "coarse grained cost-cutting", where he says when a whole division is rendered obsolete, what happens to the systems that the division was responsible for; that may still remain operational? SOA infrastructure is supposed to solve this!

Miko's solution is that if the services are well defined - with dependencies clearly modeled and governance practices in place - then it is easy for the organization to deal with such extreme situations as a whole division not existing anymore! This seems like Utopia. Really!

To me, the scenario is more the promise of SOA. The issue though (leading to the proclamation of SOAs death) is the reality, which is far from the promise. None of the anticipated flexibility and value is realized beyond the POCs and pilots! Not much mainstream gains yet. But, like I mentioned in an earlier post, the issue is more about the adoption approaches rather than any inherent deficiencies in the SOA design approaches or the platforms/technologies selected.

So even if we were to invent a "new SOA" or "SOA Next" or "SOA Whatever", the problem will remain because it never was about the technology, per se. It is more about the practical difficulties in getting an organization (its management, architects and developers) to understand and appreciate the SOA principles even half as much as they yap about the next minor revision to a WS* standard as the necessary consideration in their present SOA projects.

At the end of a successful SOA initiative, it's not just about the individual IT groups/teams understanding the need for defining a services layer, it's also about their well defined UI and DB layer which have to be ready for enabling coarse-grained services based on sufficient cross-functional business analysis of the organization. What's more these should be XML-aware layers, beyond just the fringes ("wrappers"). Now, all of these need to be in a single solution, regardless of who needs it now, and what SOA platform is in place. In this bottom-up approach to SOA adoption, the principles are adopted and ingrained first, and then comes the platforms, services, orchestration and governance.

Simply put, successful "service orientation" is the single most significant key to successful SOA in any organization!

Progress Software Introduces Actional Diagnostics

Presented by Dan Foody, VP of Products for Actional at Progress Software

With Actional Diagnostics, you can accelerate Web service development, testing and validation with tools to improve service quality, performance, and compliance, and simplify time consuming XML-oriented tasks. Listen to this podcast and hear Dan talk talk about the features and benefits of introducing a service quality and validation tool into your SOA infrastructure initiative. Register to be alerted when the FREE download is available.

For more SOA podcasts, subscribe to our iTunes channel.

Rumors of My Death Have Been Greatly Exaggerated

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

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

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

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

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

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

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

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

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

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

The problem with good governance

I saw an interesting story in the news two days ago.  It's about a company that has received multiple "good governance" awards.  Well, it turns out that their "good governance" has led to the chairman having to admit that their finances were falsified.  Know who I'm talking about?  Satyam.  Yes, that good governance award winner - the one that turned out to have over $1B of "falsified" cash on their balance sheet.

Sure, this is corporate governance, not IT governance - but it raises an interesting question for IT and SOA governance: How do you know your governance is not being bypassed? Because this is exactly what happened in the Satyam case.

The thing that likely got Satyam into the problem was likely one key thing: Their governance checks were manual, not automated.  This meant that they could be easily bypassed or avoided.  They were people processes, not automated processes.

SOA What? The moral of the story is that governance that's not automated (with the checks in the right, unavoidable, places) is governance that doesn't work.

Goodbye SOA, we hardly knew you.

Anne Thomas Manes of Burton Group posted how SOA is Dead; Long Live Services.  This one is too juicy not to comment on!

Firstly, I totally agree with Anne.  I think "SOA" is definitely dead in 2009.  And I also agree that the need for services will grow.  But, we still wrap too many things into the same terms.

At a simple level, I'll break it into four points, I'd like to talk about where I think things are going:

Service-oriented applications.  BPM, cloud computing, SaaS, PaaS, composites, mashups. All of these are doing well and will continue to do well even in the 2009 economy.  Why?  1) They can be leveraged as needed; 2) They can be done fast; and 3) Using them typically provides measurable benefit from day one (if it doesn't, then you should do something else shouldn't you!).  It's precisely the laser focus solution aspect of these that is their greatest strength.  Get in and get out while solving a problem that someone really cares about.

Service-oriented architecture (SOA).  This is where you look from a higher level above all your service-oriented applications to create a cohesive architecture that all of these follow.  Dead in 2009.  Why?  Because approaching this from an architectural perspective will always fail.  Is it a noble goal?  Sure.  But without other changes in your organization (see below), it just can't be successful.  Said another way, before you can start on a successful SOA infrastructure initiative you must finish the items below.

Service Delivery.  By service I don't mean what you're probably thinking (a thing you create).  I mean service in the most pure sense: as in "what value do you deliver to others" (with the follow up of "how do I continue to improve the value I deliver to others").  This requires a transformation for most IT organizations... and most haven't even started yet. To be fair, there are organizations that have figured this out (take S&P for example: their whole business is service delivery, so of course they understand it) - but the vast majority don't fit into this category - and if you do not pass go, you can't collect your $200: So this is the next step for most IT organizations that want to transform.  Think: "How do I create my first true service?" Here's a hint: you can't do it by creating a project, task force or cross-functional team (more on this in a subsequent post since this is a richer topic than I can cover here).

Service-oriented IT.  Once you've mastered service delivery on a small scale, then you can tackle it on a larger scale: turning IT from being project and application oriented to being service oriented.  Warning: this is a major transformation that can't be done without the CIO leading the charge.  Sorry, but no enterprise architect can make this happen.  And it can't happen until you've figured out service delivery.  This is not a 2009 project for most organizations.  It is a 2010+ transformation.

Most organizations that went down the SOA route tried to do SOA without first figuring out what it means to deliver a service, and without realizing they needed to get this right (and begin the service-oriented IT transformation) before they could never be successful at service-oriented architecture.

Service-oriented architecture is a technical and architectural transformation.  But it can't exist without first focusing on the organizational and cultural transformation of service delivery and service-oriented IT.

This is why SOA is dead in 2009 and why services will live on. But who knows... maybe once an organization figures out service-oriented IT, SOA will be resurrected - but don't wait up.

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.

What does that web service mean to you?

Do you have the right SOA infrastructure tools in place that will help you achieve better business visibility?

SOA management tools that aid in runtime governance and service quality will help. Listen as Dan Foody describes how a popular industry automobile website had some troubles because users were learning how to "game" their system.

Interested in more? Visit and subscribe to our iTunes podcast 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?

SOA Management. Do you really need it?

What the cost is for not having it.

Did you forget to think about SOA management when you developed your SOA infrastructure deployment plan? If you haven't already, listen to this podcast presented by Dan Foody, VP of Products for Actional at Progress Software, and hear an example of a company that did just that and regretted it. Make your SOA more agile by making sure that the right SOA management tools are in place before you deloy your SOA infrastructure.

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.

Actional's Strategic Partnership with Software AG

Today, Software AG announced the strategic OEM partnership between our two companies.  What makes this especially noteworthy is that, up until now, if someone wanted to buy full-lifecycle SOA governance, they only had two choices:

• Buy all the pieces, design and runtime, from one vendor (knowing that one or the other was weak - since no vendor had even a half decent offering on both sides of the fence).
• Buy market leading components - but have to buy them from different vendors

This partnership will allow customers to buy full-lifecycle SOA governance from one vendor, without having to compromise.

One other important note is that Actional's direct competitors have tried to create FUD in the market by claiming that Actional is tightly tied with Sonic.  Of course we do work well with Sonic, but a very large percentage of Actional customers use us with platforms such as BEA, TIBCO, IBM, Microsoft, JBoss, and others - no Sonic in sight. Our competitors certainly liked to paint a picture that Actional was "Sonic centric" even though this was far from the truth.

To have a successful SOA management and runtime governance offering:

• Your products need to be vendor neutral - working equally well with the SOA infrastructure of many vendors.
• As many more organizations are scaling up their SOA initiatives - building mission critical applications that are service oriented - SOA management can't cause your applications to slow down, or cause you to lose transactions.  It needs to be scalable and reliable.

These were two important factors in Software AG's selection, and this partnership clearly demonstrates Actional's leadership in these areas.

"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.

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?

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.