Business Making Progress

Consulting our crystal ball: IT Predictions for 2012

With the New Year just around the corner, many are busy thinking up unattainable diet and fitness resolutions, but we here at Progress have instead spent our time collaborating on more realistic forecasts for the coming year.

The team here at Progress put our heads together to produce our top predictions on how the role of IT within the business will change in 2012. An increased emphasis on cloud development, data security and social integration are all issues we expect organizations to prioritize over the next twelve months, but the list doesn’t stop there. Here’s a quick look at where we see business IT going in the coming year:

1. Cloud on the move. Organizations will increase deployment of the public cloud, escalating demand for cloud-enabled systems and applications.
2. Cost control evolves to efficiency. While cost was the main driver of cloud adoption in the past, the focus will now expand to include system efficiencies and time to market.
3. Data security starts with secure access. Who will have access to the data? How will it be encrypted? Who is the core owner? A strong driver that runs on a stable and tested data interface like ODBC is the best line of defense as application stacks continue to grow.
4. RIP: Non web-based applications. Approximately 80% of business apps will be web-based, and they need to be business process enabled, web-based and cloud-deployed.
5. IT border control. More than half of all content and functionality will be out of your organization’s control … in the hands of outsourcers, supply chain partners and external community databases. How will it be protected is the question du jour.
6. What’s in the fire hose? While we may see companies promoting fancy strategies for managing “fire hose data,” only those focused on responsive analytics will make meaning from the massive deluge.  
7. Limitations of freeware. This year, we will see greater support for ODBC and investment in data connectivity as companies look for dependable, robust ODBC drivers to handle financial transactions securely and quickly.
8. All hail the social enterprise. Social collaboration apps will dominate as employees look for ways to more effectively share and innovate across regions and lines of business; in fact, users will begin to expect these capabilities to be offered as standard, embedded features in business applications. 

And there they are: Progress’ IT predictions for 2012… how do they stack up to what you have in mind? We welcome comments below or on Twitter at @DrJohnBates or @ProgressSW

Forrester Recognizes Progress Sonic As A Leader in the ESB Market

Did you know that Progress® Sonic® was the industry's first Enterprise Service Bus (ESB)? It was, however, introduced in 2002 by Sonic Software which was an independent operating company of Progress Software Corporation.

In April independent research firm Forrester Research, Inc. named Progress Software as a leader in “The Forrester Wave™: Enterprise Service Bus, Q2 2011” report. In this detailed review of Enterprise Service Bus (ESB) providers, Progress Sonic ESB was recognized with particularly high scores for its ESB architecture, orchestration as well as change and control capabilities. The report also gave Sonic ESB high scores for product strategy and strategic alliances, while also scoring the product highly for its large customer install base.

Strategic businesses worldwide have made Sonic ESB a core component to their service-oriented architecture (SOA). A few of these companies include British Airways, Royal Dirkzwager, AutoTrader, and most recently UK-based PD Ports. Why did they choose Progress? Because Sonic ESB delivers the best overall combination of architecture, orchestration, mediation, connection as well as change and control features. It helps them achieve the business and operational responsiveness they need to be successful.

Cruise past your competition and make sure your integrated infrastructure is powered by the 1st and best ESB... Sonic ESB. If you are interested in the report, click here. It will be available FREE FROM REGISTRATION for the next five business days only. What a deal! ;-)

Feel free to also share your ESB integration and deployment experiences here.

SOA. It’s back… but it’s got more sparkle.

I’ve been working in high-tech marketing roles for over 20 years now and every time some new marketing collateral comes across my desk and “I get it”, I get excited. As a matter of fact, my first job in a high tech company was as a marketing assistant to an R&D group at BBN Systems and Technologies. They were introducing a very innovative product called BBN Slate which was a multi-media editor for Unix. Because my previous jobs involved word processing (Wang), spreadsheet analysis (Lotus), and creating pretty charts (DEC/VMS – yes, really), “I got it” and I was committed to championing it. I loved every minute of it. Well, in 2007 I was tasked to optimize the Progress Software website for SOA. We already had great traction for the enterprise service bus (ESB), but not specifically for service-oriented architecture (SOA). Well, “I got it”, got going and started optimizing for SOA Infrastructure – a popular long tail term at the time - less than two months later. As a matter of fact, this blog was once the SOA Infrastructure blog.

In January of 2009, Anne Thomas Manes of the Burton group published the blog post SOA is Dead; Long Live Services. The industry had a lot of fun with that. Now, I don’t know if it was a coincidence, but suddenly Progress stopped talking about SOA and they asked me to change the name of this blog. I was sad, I admit it.

This responsive business integration diagram was taken from a presentation by Hub Vandervoort, CTO, Enterprise Infrastructure. Listen to the archive.

Well yesterday I saw some sparkle. We announced our new Responsive Business Integration (RBI) suite. Truth be told, I’ve known about it for a few months because I had to post the content and work on my SEO plan. I know it’s not nice to play favorites, but I was delighted to see my favorite Progress technology/products back in the game – Actional, DataXtend SI and Sonic. And, I’ve concluded that the RBI suite is SOA pimped up! It’s taking the existing service and application foundation most enterprises already have (or are building) and it’s enhancing it with semantics, policy management and mediation. The Progress RBI suite is going to allow businesses to decouple systems which will give them improved visibility, agility and the ability to change.

Read more about Progress Responsive Business Integration. And check out a great presentation by Progress customer Southern Union Company. They built their enterprise integration strategy around RBI and didn't even know it.

For the lack of a better term, do you think RBI it is our next-generation SOA? Give us your comments!

Multi-tenant Distributed Process Environment

As part of the Internals of a Middleware Systems course (one of the two courses I teach at IIIT-Hyderabad), I wanted to dabble in multi-tenant service oriented architecture (SOA) as a course project. About two months back when I first thought of this as the project, I assumed it was going to be an academic exercise where the class would build some interesting multi-tenant SOA platform (building on Camel, CXF on JMS, with a home-grown approach to partitioning the tenant domains for same set of services & processes (camel routes) available in the environment). But as I started getting more into it, I began to realize that there is probably more to it than an academic angle!

We actually started looking at business processes as being a more integral part of an application infrastructure, and not necessarily just part of the integration layer. Our thought process even brought us above and beyond our recently introduced OpenEdge BPM solution that enables our Application Partners to have key parts of their business logic defined as BPM processes, thereby allowing easier customizations for unique business flows and requirements. (Many years back had proposed embedded buziness preocesses (in Java applications) as a theoretical possibility in application architectures. At that time didnt realise there will actually be a simple platforms that brings both BPM & application logic together as well as our OE-BPM now does). With BPM and application logic now part of an integrated platform, it is only question of time before this architecture extends to a more distributed deployments with application logic composed as distributed services that is then orchestrated in the BPM layer to enable first level business capabilities and flows. Thus bringing in SOA also into the mix. And the moment this solution goes on the cloud in a SaaS model, the whole platform- Application logic, SOA & BPM- will now need to be multi-tenant capable.

Most of multi-tenant SOA seemed common sense.Still, when I was trying to find some academic basis, I came across this comprehensive overview in an IEEE article, Multi-tenant SOA Middleware for Cloud Computing. This article summarizes the various aspects of multi-tenancies - from the well known models for database centric solutions to enabling multi-tenancies (one DB per tenant, one schema per tenant or the more advanced tenants across multiple schema's (each shared)), to the more complex problem of actual application multi-tenancy. The application multi-tenancy also had a sound approach presented in this paper - Architecture Strategies for Catching the Long Tail - where they present a few levels, from the basic custom instance per tenant, to the next level where it is still one instance per tenant but the application is architected for easy configurabation. This paper further presents the next level where there is a shared instance that can service multiple tenants, to the most advanced level that it is a shared instance across tenants that can also be clustered & made highly-available. All great stuff. But what does this mean for SOA and BPM environments?

The more fundamental question that begs to be answered is what is the play for SOA in the cloud? Is there a SaaS play at all involving SOA? In the past few years that I've been dabbling in cloud  computing and talking about cloud environments at seminars here in India,  I never really thought SOA had a major angle. But surely in today's enterprise IT landscape, any enterprise integration solution will need to also access solutions in the cloud either by running a SaaS platform, custom built on a PaaS platform, or in a cloud-based virtual infrastructure platform. As SOA adoption matures, the other aspect that is rapidly emerging is a new class of business applications that use business process management (BPM) and service abstractions as a more integral part of solutions. All the simplicity, rapid development, composability and maintainability value that SOA offered for enterprise integration (in terms of atomic coarse grained business functions and processes that are composed off of these services, and that are easy to define and modify), now makes sense even for individual applications. Who would say NO to applications that are easy to build and maintain?

Given this, the use cases emerging for BPM solutions are now very different. And once BPM and SOA get into the application architecture, the need for (and value from) the cloud and multi-tenancy is immediate. We've seen the SaaS model get serious traction from ISV's because it delivers flexibility as well as a low-cost & ease of ownership. Once we go the full hog, then why just business processes? The applications can also have first level business services (aka SOA services) that can be composed into next level business processes and business workflows. A full-fledged SOA platform now forming the basis for applications.

So, in order to multi-tenant enable these BPM + SOA solutions, what are the challenges? ...Stay tuned.

Belgacom and the Case for Business-oriented integration in Communications Providers

It is no secret that the telecommunications industry has been exploring various ways to tackle issues such as declining ARPU (average revenue per user) and increasing customer churn over the last five years. The keys to proactively addressing these issues are agility and responsiveness. For example, responsiveness around customer service – to make customers feel they have a personalized valuable service – which reduces churn; and agility -- around launching new and compelling services rapidly – to increase ARPU.

Despite this quest for the Holy Grail, many communications providers have failed to lay sufficient foundations. While there may be some useful technologies deployed in an attempt to provide an agile and responsive integration platform – these technologies have often failed to deliver what is needed by the business. SOA is a prime case in point. While SOA technology has been successful in many ways, it has also led to a lot of disappointments. Often the business was sold on the promise that SOA would make operations more agile and responsive.  However, what resulted was technology for technologists that looked like plumbing and was daunting and too generic to the business.

Business people want solutions that can deliver visibility to problems and opportunities – such as key business events (e.g., an opportunity to sell a new service, based on context or location) or process failures (e.g. persistent dropped calls for an important customer) – so that problems can be responded to quickly and opportunities taken. The business also wants solutions that can enforce business-level policies and service-level agreements, as well as solutions that can interconnect services at a “semantic level” – not just plumb data together. In other words – the business wants to deal in business-level concepts, and be assured that the underlying complexity will be managed by the system.

Today’s announcement that Belgium operator Belgacom is transforming its business and IT integration programme (more information here) represents a huge step forward for the telecommunications industry. Belgacom is clearly focused around being more responsive to the needs of their customers in order to tackle issues such as churn through improved integration. By selecting the right business integration foundation to support their IT strategy, Belgacom has taken a critical step forward in a long-term strategy to become more operationally responsive to their customers.

Due to the nature of the economic times we live in, it is vital that the telecommunications industry as a whole ensures that they have the best possible integration technology in place. Only then will operators be able to enhance their customer experience management offerings to attract and retain their business customers, differentiate their offerings, and lower their service costs.

 

Actional 8.2 Released

It’s a great time to be in New England. Bright fall colors frame every road as the trees that provide refreshing shade during the blistering summer days now provide a canvas of brilliant color. Nestled among the trees that line Route 3 north you’ll see corporate headquarters for Progress Software, a leader in Business Transaction Management software with Progress Actional.

Actional 8.2 was just released and continues to show significant advancements in supporting enterprises that need to ensure the success of every single important business transaction. As the heterogeneity of IT infrastructures increases, Actional can help organizations achieve this level of assurance by extending visibility into transactions that traverse environments that include Apache CXF and JBoss ESB. And if improving the customer experience and the performance of mission-critical applications is on your radar, be sure to visit the Actional website for details on expanded alerting—and other enhancements. This release is targeted for organizations that are looking to work more intelligently and with a laser-focus on quality and efficiency.

So does the release of Actional 8.2 trump New England’s fall foliage? With a true Bostonian accent I’ll just say, “When driving one’s cahr through Hahrvahd yahrd, one can rest assured that transactions are running smoothly, application perfahrmance is optimized and the customah experience is at an all time high!”

Are you a sitting duck or one that will respond immediately to threats?

While many organisations are being ‘cautiously optimistic’ about what the future holds, the realities of today’s tough business environment could leave them as sitting ducks, according to Rick Reidy, CEO at Progress Software. They might take consolation that they’re in the same pond, but when interest rates in Japan hit near-zero, banks continue to fail and mistakes can lead to a ‘flash crash’, the pond is not a safe place to be. Businesses may have money, but fear and uncertainty is holding back decision-making – we await further regulation and want to know the consequences of recent government changes.

 
Listening to Rick’s keynote at our UK business summit (#progresswsummit, if you want to follow on twitter), in the impressive surrounding of Chelsea Football Club’s ground, London, it seems most of the audience agrees – it’s not good enough to sit around and wait to see if growth returns, and you cannot grow simply by cutting costs. You have to take control of your own ‘growth agenda’, as Rick put it. Businesses that want to survive the next five years need better visibility, through putting processes in place that enable them to react quickly to meet customer demands, adapt to market changes and take advantage of new opportunities. As Rick has advised, businesses need to act on up to the minute information so that leaders can make decisions based on foresight, not hindsight.
 
If you’re a regular reader of this blog you’ll already know that we call this ‘operational responsiveness’: the ability to sense and respond to customer and market changes so that organisations can move quickly to meet challenges and take advantage of new opportunities. 
 
Rick has talked about what this means in the airline industry: the notion of irregular operations has become a weekly reality as companies face intense market pressure, striking staff and disruption from natural phenomenon. ‘Swivel chair’ communication between operational areas is no longer good enough. To react quickly enough, they need responsive processes in place that can help them maintain services and inform customers, almost as-it-happens. If they don’t, they will face massive fines, lost custom and damaged reputation – risks no company can afford at present.
 
We’ll be hearing more from Gordon Penfold, CTO at British Airways, about their approach to becoming operationally responsive to meet the challenges of today and tomorrow. Watch this space for my take on his talk…

 

Stamford Bridge, here we come

Tomorrow sees Progress Software taking over Stamford Bridge, home ground to the world-famous Chelsea Football Club. We’re not just there to check out the players’ dressing rooms – we are being joined by James Caan, of Dragons' Den fame, as well as the great and the good of the UK business community, to discuss how businesses can start to make decisions based on foresight, not hindsight, in their operations.

Gordon Penfold, Chief Technology Officer at British Airways, will be sharing his insight on ‘operational foresight’, revealing how the organization has set itself up to better deal with the irregular operations that have become a fact of life in the last year. And Mike Gualtieri, senior analyst at Forrester Research, will be sharing his views on where the next wave of truly responsive business management is coming from, and which trends to watch for. And Progress' own Chief Executive Officer, Rick Reidy, will be giving a keynote too.

I'll be there, speaking in one session but also blogging and tweeting from the event. So watch this space for the latest updates.

For those of you attending, I look forward to seeing you there.

www.progresssoftwaresummit.com

 

Know Your ABC's: Business Transaction Management with Progress OpenEdge in the Cloud

This is the title of a session being presented at Exchange Online 2010 by Gary Cink on September 15th at 9:45 am. In this presentation, Gary will demonstrate how some of the complimentary Progress' products enhance the OpenEdge experience for business transaction management (BTM). BTM is a critical component in the new IT/Business relationship. Progress® Actional®, Progress's first class BTM product, translates data relating to an underlying IT estate into information that is relevant to various business stakeholders including operations staff, application development, quality assurance, and security & compliance personnel. With this knowledge the various stakeholders can make informed decisions, often proactively, to ensure the success of every critical business transaction necessary for the day-to-day running of a business. Actional also offers the capabilities of automating operational Service Level Agreements (SLA) against this estate, thus preventing issues or alerting appropriate staff to problems before they have even happened.

Learn more about Gary and this technical session on our View From The Edge blog.

You can also read the white paper SLAS: Lost in the Cloud? Service-level agreements (SLAs) are crucial any time a business service provider (BSP) provides an application or service to a client via the cloud. In the results of this survey, 76% of respondents report that SLAs are critical to winning new business. Yet, 84% are unable always to meet their SLAs.

Integration and the Responsive Enterprise

Over the last year you’ve heard a lot about Operational Responsiveness from Progress and what it means to and for your business - the ability to:

• Respond to changing business conditions as they occur;
• Capitalize on more opportunities, to drive greater efficiencies;
• Make real-time course corrections;
• Reduce risk.

Every business and enterprise wants to be operationally responsive, but getting there is the challenge. Certainly, our recently announced Progress® Responsive Process Management (RPM) suite makes this challenge easier by enabling business users to gain visibility into critical processes, immediately respond to events, and continuously improve business performance without disrupting existing infrastructure. But what about that infrastructure? What role does that play in responsive process management and Operational Responsiveness?

We believe it plays a foundational role and that is why we’ve created a completely new set of educational and informative videos, whiteboard sessions, podcasts and technical papers that services and application platform architectures in the context of Operational Responsiveness.

Beginning with four podcasts and technical papers on messaging, the Enterprise Integration Whiteboard Series will explore services integration, data connectivity, transformation and life cycles, legacy modernization, and management as core, interdependent components of every modern enterprise application integration infrastructure. In total the series will consist of 10 topics with a new topic posted every two weeks through September 2010.

The first brief and whiteboard video, Messaging Architecture, examines the four basic components of the Progress® Sonic messaging system --brokers, acceptors, clusters, and the underlying protocols—to show how they provide not only robust integration, but business and IT benefits as well.

Read the paper and watch the video and let us know what you think by commenting to this post. Share your enterprise integration experiences.

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

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

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

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

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

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

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.

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.

Alphameric Beats the Odds with Progress Software

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

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

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

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

The great cloud crash of 2009

I've been following the recent story of how Microsoft's Danger division and the T-Mobile Sidekick.  If you don't know much about Danger, it's basically a cloud service tied to a hardware device (the Sidekick).  All the data is stored in the cloud (email, contacts, etc.) and cached on the device so that when the device resets, it starts up empty and reloads its data from the cloud.  Unfortunately, many customers found out recently that when they reset their device, all their data was gone.  Poof.  No more contacts, no more calendar entries, no more emails.  It turned out they didn't have any real backups and their data redundancy was foiled by human error.  Whoops.  While they have recovered most of people's data now, there are some important lessons to be learned from it.

One of the articles I read on this was titled Don't Blame Cloud Computing for the T-Mobile Mess.  While the author's heart is in the right place (he really likes cloud computing), I can't agree: Cloud computing is absolutely to blame for this fiasco.

Let me explain by starting with an analogy.  Recently we had a little event that some people call the "great market crash of 2008".  The root cause of this is pretty well known now:  A lack of transparency into different financial instruments (e.g. CDOs) made it impossible to accurately assess risk.  And, in the absence of an accurate risk assessment, people assume things will be ok and focus on their short term gain.

It seems to me that we have the exact same situation with cloud computing.  There's essentially no transparency into any cloud provider's integration infrastructure, processes, or planning.   As a result no user can accurately assess the risk of using one cloud provider over another.  Do you think that if sidekick users had know "Danger doesn't do backups" they would have trusted the service with their data?  Of course not, most users assumed everything was OK.  They assume their cloud provider is doing the right thing.  It was only a matter of time before a crash would happen (and this won't be the last one).  In the immortal words of Otter from Animal House, "You f*cked up - you trusted us".

Cloud providers, unfortunately, think that it's not in their best interest to be transparent because, frankly, customers are conditioned to just assume everything is OK so why rock the boat.  When was the last time you walked into a grocery store to buy apples and said, "Can you cut this one open so I can see whether it's OK on the inside?"  No, you probably look at the shiny skin of the apple and assume everything is OK with the inside.

Before cloud computing can become mainstream, users of cloud services must have the ability to accurately assess risk for themselves.  In order to do this, cloud providers must provide transparency. if not users must demand it by speaking with their wallets.  Don't let the cool, shiny UI fool you into assuming everything is OK under the skin.

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 Progress Software 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.

Is the Travel Industry Out of Touch with Our Changing Business Climate?

Did you knw that the travel industry loses $11.5 million per year through failed transactions?

Last week Progress Software released the results of a survey commissioned with an independent specialist technology market research company, Vanson Bourne Research. The researchers surveyed 149 global travel businesses and found that 67% of respondents have noticed their transaction failures soar by almost a third – even though their transactions have only increased by 12%.

Dan Foody, VP of Products at Progress Software, sites: “This research clearly highlights the far-reaching effects of transaction failures within the travel industry. The trend of increasing IT complexity is further compounding revenue loss through increased lost transactions, customer churn and inefficient use of IT resources with 97% of respondents concluding that transaction failures were increasing operational costs."

 “Companies should consider introducing a more streamlined approach to monitoring transaction flows across their IT environments, delivering the ability to respond to changing conditions and customer interactions as they occur. This will enable business leaders to capitalize on opportunities, drive efficiencies and reduce the risk of impacting customer experience. The more responsive approach will provide visibility and increase understanding of the impact IT failures have on their own IT services and their customers,”

Get your copy of the report! The report IT Impact on Travel & Leisure Industry Reservation Management, examines the causes and consequences of this situation. Read this report and learn about some of the underlying causes for the increase in transaction failures, what the consequences are, and the limitations of most traditional monitoring and management systems.

Share your experiences and thoughts by posting a Comment to this entry.

Simple SOA. Not-so-simple SOA.

Open Source SOA has arrived! On a single day we have one platform announce that they have simplified basic SOA, and another has announced that SOA is never simple - and if it is simple, just use web services. The question is... is there really a simple SOA and a not-so-simple SOA?

As I look at it, there is a very fine line between simple SOA and the more complex ones that require an enterprise service bus (ESB). Lines are blurred today. Now, ESB itself can be in a single container or more massively distributed ESBs with a strong messaging backbone (like Sonic ESB). But messaging backbone or not is more about the underlying integration infrastructure. So, what does it mean for the application itself? Is the model/paradigm different for the two cases? This is what gets lost out in the melee - the application models and the underlying infrastructure are quite decoupled. From an application standpoint many of the ESB mediation requirements may always be needed functionally. Can one access services without getting the data in the right format? To get it in the right format, won't we need data transformation? And security is a given in all cases. Sometimes one can look at business rules based routing to services. All of these regardless of whether it is a simple SOA or not-so-simple (more distributed multi-data-center) SOA. 

This (common treatment of all SOA use cases regardless of complexity) is very evident with the way our open source platform, FUSE, works because it has an embeddable transport layer. One could use the containers with or without Active MQ. But with or without distribution, the same functionality is available. Simple SOA? Or not?

REST maybe part of the answer

In the last few weeks/months I have got more immersed in the world of REST and what it means to build and have a REST application.  While at first glance it may seem that REST is a lighter weight version of a web-service implementation, it is by no means the complete answer and I do not believe REST is simply a replacement of Web Services because of how they operate is different.

When developing Object applications, in whatever language, you hit a reality that if your application is successful, then it will grow beyond the confines of the machine/JMV that it runs on, and as such you have to refer to objects that are beyond a single instance of the application's memory space.  This can be done using a number of different technologies such as object databases that can map the same object into different application instances, but the locks are maintained by the central server so consistency of the objects are maintained, even if the object is distributed in 100s of applications at a time.

Now technologies such as IIOP (Corba), RMI, DCOM and Web Services have been used to access objects and invoke operations on the instances to retrieve data.  This essentially solves the long-wire problem of accessing an object and then returning an instance of the object, the issue here being is that typically a representation of the object that you want is returned, i.e. using Java serialization or XML and the reference to the actual instance is lost, unless you have a known object identity that you are working with.

REST adds the concept of the pointer to the SOA infrastructure in a way that any business object can be referenced by a URL and thus referenced anywhere within the internet/cloud or a single program space. This is something that is not readily available in Web Services and now makes any RESTful resource available to anyone (given the correct permissions).  Now this sparks a whole debate on to how to identity a particular object and to detect duplicates etc, this is beyond the scope of this blog but will have the same techniques that are used in the object-oriented world, but now working at the cloud scale.

So now that REST gives us some new capabilities, how does this change the current implementations that you are working on?  Interestingly, I think many of the challenges existing in the Web Services world still need to be addressed in the REST world, I just believe that REST is probably better able to address some of the immediate ones and in fact just like every Progress customer has another application to connect to Web Services will always be required.

The other cool thing about REST is that I can typically use the services directly from an HTML page on a browser, something that was impossible for Web Services because HTML and WSDL are not compatible.  However, there is still the need to mediate REST in the same way that applied to Web-Services, for instance to be able to turn a switch to expose the same business entity as REST and Web-Service and in fact any possible protocol.  Allowing external access to your business objects will require caching and a level of indirection to provide for maintenance, performance, etc., and the virtualization of the underlying technology to ensure that an object is not a manifestation of the technology that stores it, i.e. database tables and rows are not part of the object serialization.  Security, Quality of Service (QoS) and Quality of Protection (QoP) are observed along with SLA commitments and the ability to monetize the object and charge accordingly.  This last point maybe very interesting as it would allow organizations to potentially charge for access to their data for different reasons and allow IT to start to become a profit-center rather than just a cost-center - something that I think people will look at as they invest in the cloud.

Now I think that the promise of REST is very interesting, in more ways than Web Services was, but whether the ideal is purely based around REST or a hybrid of many technologies is going to depend on the goal of what is to be achieved. In any event, it is very exciting.

SaaS, PaaS... why not SOAaaS (SOA as a Service)?

A busy day in the rapidly converging SOA and Cloud worlds. Oracle talks about plans for the cloud, retracting from the skepticism expressed some months back. Intuit announces a PaaS platform. Another SOA infrastructure vendor dabbles with SOA on the cloud - striking dichotomy here. On one hand we are still trying to figure out how exactly to make SOA projects successful. And on the other, we are talking about SOA in the Cloud and PaaS platforms for SOA. Even so, I find it a natural progression.

PaaS, and therefrom the SOA impact, follows the success of SaaS. Which itself was the best thing to happen to ISVs in recent times. A combination of emerging application models, web based software UI approaches, new cloud platforms, and a very wide acceptance of externally hosted software solutions - less of technology and more of mindset. Now it is only a logical extension of the SaaS paradigm that now one will expect to build custom solutions on the web (PaaS). Or host solutions directly on the web based infrastructure (Cloud). And the moment there are applications, SOA cannot be far behind. The nature of the cloud beast is also such that the significance of SOA and distributed management/governance becomes even more critical given the rather loosely coupled and a less-controlled computing environment.

So while enterprises may be OK with having solutions hosted externally on the web/cloud, they may still want the integrated enterprise where these external solutions are seamlessly available in the enterprise integration platform (SOA) and also in the enterprise distributed management and governance platform. We can probably extend these to bring the external apps into the prevailing GRC and BAM framework in the enterprise, so it is only natural that SOA becomes a first class consideration when SaaS/PaaS/Cloud are in the picture.

Not far will be the support for SOA as a primary attribute of cloud platforms. Right off the bat one will have the ability to build and host applications over the web, with the default web based UI models and a very integration ready platform - both for consuming/orchestrating services over the web, and also to expose new services (off this application) over the web.

Now... taking this a bit further, one could look at explicit platforms just FOR integration and SOA!  Even now there are BPM vendors like Cordys that are providing a web based orchestration platforms (PaaS). These can easily be extended to offer a complete services and integration-application platform on the cloud. Only, we need to figure out the use cases where one needs integration off the cloud. Needing SOA as a Service (SOAaaS).

Patently Confusing!

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

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

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

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

Forum's states that their patent is...

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

Whereas our patent is...

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

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

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

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

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

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

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

The abstract:

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

And the top-level claim:

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

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.

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

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.

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.

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.

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.

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.

When do you need SOA governance?

I was at Software AG's SOA Governance Summit last week and got a chance to see Gartner analyst Frank Kenney give a presentation - on SOA Governance of course.  As always, Frank did a great job - but there is one area that I feel he got wrong.

Frank said that you don't need governance products until you have more than 10-12 services (up to that point Excel will do fine to track things).  Now, Frank was partly doing this because he wanted to show he was independent of the vendor sponsoring the event - so whether he believes this or not, I don't know.

But, here's an example to show why this isn't true: Let's say you have just one service but that service has 1000 different applications consuming it.  Do you think can get by with Excel?  Do you think Excel will help ensure you meet the service levels of each of your 1000 consumers?  Of course not.

In the end, the number of services is irrelevant to whether you need SOA governance or not.  What really matters is the number of relationships.  Having 1 service consumed 1000 times is just as complex as having 1000 services each consumed once.  But, it's definitely a different kind of complexity and so how you govern these two scenarios is very different (with 1000 services you need design time governance first but with 1000 consumers you need runtime governance first).

If you're with me so far, let's bring this to the next level...

I Don't Know Jack...

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

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

Thanks Jack!

Question: How Do You Manage Your Policies?

Answer: Hopefully better than the NYC Department of Traffic.

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

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

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

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

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

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

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

Armadillo Governance

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

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

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

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

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

Let me share a couple of real-world examples.

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

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

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

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

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

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

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

Conversation or Rant? LMK

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

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

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

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.

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.

WOA governance

Joe McKendrick wrote an interesting post on WOA winning the personality contest versus SOA.

That got me to thinking: If we need governance for SOA, do we need it for WOA also?

Some  would argue that it's the complexity of SOA itself (driven by the enterprise top-down focus) that creates the need for a formalized SOA governance initiative.  Without formal SOA governance you can't hope to succeed with SOA because it's too easy to get it wrong.

But WOA removes or bypasses many of the complexities of SOA (no need for complex tools, no need for WS-splat and all the arcane requirements that go along with that). So do you still need governance for it?

The answer is probably yes (if you're an enterprise architect, you can stop holding your breath now).  But, I think the approach to "WOA governance" is going to be fundamentally different than that of SOA governance (OK, time for the EA's to hold their breath again).

In traditional SOA governance, enterprise architects set rules for the providers and consumers of services to follow - they set the rules that govern both sides of the interaction.  This works fine in an enterprise where everyone ends up reporting to one common person when you look far enough up the chain.

But, let's look at a WOA example: Progress Software consumers services published by Salesforce.com.  If we were to apply a traditional SOA governance approach to this, we'd first appoint an "Enterprise Architect for the Internet" who would set all the policies that both Progress and Salesforce.com would have to follow.  Simple really.  Except the part about "appointing an EA for the Internet".  That might be a bit tricky. So, you can see, the top-down approach of SOA governance totally falls down when you look at WOA.

But, if a top-down approach doesn't work, what does?  Do we not have to solve some fundamental "governance" problems still?  Problems like:

• How can a provider make it easier to on-board customers and keep them happy (all while changing the service frequently)?
• How can a consumer establish and build trust in their service provider (that's trust as in "trust but verify")?

WOA absolutely has to address these challenges.  So, for WOA we need to achieve many of the same goals that SOA governance hopes to achieve - but we'll have to achieve them in a fundamentally different way.

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.

On Roadmaps and Future Product Features...

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

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

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

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

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

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

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

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

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

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

Talk therapy.

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

I suggest the following sorts of questions:

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

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

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

If One is Good, Five Must Be Great!

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

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

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

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

Actional currently supports registry/repository integration with:

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

Each of these is currently supported and available.

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

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

Oracle Makes the Right Choice for their Customers

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

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

Oracle drops Amberpoint for SOA Management.

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

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

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

And, there are many others, large and small.

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

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