Business Making Progress

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.

 

When it comes to Integration, Contracts Make all the Difference.

It may seem odd to talk about contracts and SOA in the same sentence, but without them experienced enterprise architects and integration developers understand the negative consequences that will ripple through the business.

A service-oriented architecture (SOA) requires establishing contracts between its participants. The first or most basic SOA contract provision concerns what formats and protocols are used. When two service participants, a provider and a consumer, establish a contract, it must start out with some protocol and format artifact (or transport and data-level semantic), such as an XSD and the associated WSDL describing the interface between that consumer and producer. These decisions establish the beginnings of interoperability, specifically how the first-level pin-outs get wired together.

Beyond this basic level, IT professionals tend to think about contracts in two broad areas: the service-level agreement (SLA) and security. For IT, an SLA usually specifies scale, response time, and availability: for example, handling 10,000 requests per second with a response time of less than 500 milliseconds, and availability to four 9s, or 99.99 percent uptime. From a security standpoint, a contract covers four or five areas.

In installment #7 of the Enterprise Integration Whiteboard Series, Hub Vandervoort delves into the sixth point of mediation - Quality of Service (QoS) and Quality of Privacy/Protection. But rather than providing a comprehensive account of the idea of QoS and QoP, the video podcast and technical paper offer a high-level overview of some capabilities within Sonic ESB by itself and in association with Actional, which is largely built into the ESB infrastructure, and how those come together to create the foundation of QoS\QoP—trust and commitment —required for effective contracts.

---

Check out all of the Enterprise Integration Whiteboard Series white papers and videos here!

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.

Celebrating the shadow of Punxsutawney Phil

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

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

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

SOA? What do you call it?

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

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

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

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

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

Now That's a Real Forklift Upgrade

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

Damn, that’s a lot.

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

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

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

Why is this important?

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

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

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

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

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

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

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

Let me rephrase.

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

Simply put, you’re not.

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

Holy Cloud! Thousands of Customers & Hundreds of Partners

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

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

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

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

That partner thing. It's big here.

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

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

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

CORBA is now Actional-ized!

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

Today we will release Orbix 6.3.4 with support for Actional.

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

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

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

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

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

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

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

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

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

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

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

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

Beat that!

Actional for IONA Orbix & DB

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

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

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

Why is Actional/Orbix integration important?

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

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

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

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

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

Follow Up to Cloud Computing Panel Discussion

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

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

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

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

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

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

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

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

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

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

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

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

Let me leave with an analogy this time.

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

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

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

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

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

How to Be Agile Without Falling on Your Face

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

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

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

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

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

SOA Infrastructure - Back to Future, No. 1

The New SOA Maturity Model

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

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

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

Enjoy!

White Paper: The New SOA Maturity Model >

Quick Reference: The New SOA Maturity Model >

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

Astounding Statistics Regarding Order Fallout & Revenue Leakage

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Welcoming Scottish Widows to the Family

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

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

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

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

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

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

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

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

Boy, Did This Guy Understand Actional!

I love talking to people who get it.

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

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

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

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

"Wait, you can track dependencies?"

"Yep."

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

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

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

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

Actional Business Process Visibility (Definition)

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

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

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

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

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

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

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

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

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

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

SOA Next- Just a New Skin for the Same Problems

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

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

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

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

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

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

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

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

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

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

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

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

Rumors of My Death Have Been Greatly Exaggerated

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

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

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

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

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

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

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

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

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

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

The problem with good governance

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

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

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

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

Business Transactions, Exciting Stuff!

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

My note was simply:

"Process Mashup = Business Transaction"

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

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

I think an important generalization can be made...

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

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

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

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

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

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

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

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

Goldilocks Governance

An article in the Wall Street Journal today on approaches to IT Outsourcing (The Goldilocks Strategy) has definite parallels to what I've seen with SOA Governance.

The article talks about an organization which first moves to outsourcing with a very loose contract, and ends up failing (poor service, mistrust, etc.).  Then, they move to an airtight contract that lays out every last detail.  But as their business changes, the rigid contract creates issues that result in... you guessed it: poor service and mistrust.  So, they finally switch their approach to one that's much more hand's on to build trust between their organization and the outsourcer, allowing them to more easily adapt to changing business climate... and they end up with a very successful IT outsourcing strategy.

The same parallel hold true for most SOA Governance initiatives.  Either there's none, or it's too overbearing (automated, rigid, and inflexible) - creating the exact problems that governance is intended to fix.  Moving from web services to REST?  "Sorry, our governance approach doesn't allow for that."

The right solution is often one that has little to do with tools, technologies, contracts, or mandates but instead is heavily based on the enterprise architecture team building a strong personal relationship with the rest of the organization.

Meaningful Measurements

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

Six cents. Huh?

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

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

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

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

Where was the discrepancy?

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

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

Sometimes It's Just Too Late

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

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

I couldn't find the car.

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

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

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

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

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

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

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

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

• Scalable
• Performant
• Resilient

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

Architecture deficiencies are mortal. Feature omissions are easily corrected.

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

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

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

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.

Welcome Back!

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

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

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

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

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

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

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.

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

Interesting thing happened on my way back from lunch yesterday.

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

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

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

SOA What does this have to do with anything?

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

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

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

Actional @ Codecentric.de

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

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

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

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

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

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

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

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

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

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

Let me explain.

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

It’s always the first one there.

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

David Bressler’s Birthday (’67)

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

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

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

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

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

SOA is like a financial market part II

Glen Daniels added a good comment on one of my last posts.  Glen's point was that in a financial market everyone tries to achieve their own goals, but it's different in an enterprise - an enterprise is more like a sports team, with everyone working towards a common goal.

Sorry, Glen.  I can't agree. The majority of people care most about closest to them (i.e. their health and welfare, etc.).  And, sometimes this aligns with their organization (or team) - just ask any Red Sox fan whether Manny Ramirez was always acting in the best interest of the team and you'll see this is true.

Here's a business example that's more relevant: SOA goals are often long term goals.  And these can often conflict with short-term goals of getting a project delivered quickly.  It might be in the best interest of the organization to follow the "SOA route" and delay project delivery - but the IT team would risk being fired if they did that.  So the majority of IT teams focus on the short term goals.

The way I look at it, your assumption out of the door should be that no one is aligned with your SOA goals (just like in a financial market you're acting like the market regulator).  Yes, this is the paranoid approach: they are out to get you.  Even if only 20% of them are out to get you (and the other 80% are with you) the problem is you usually don't know which 20% to worry about!

So, what does this mean?  You should always focus on ensuring the goals of your SOA are never in conflict with other goals that people might have (e.g. short term project delivery deadlines).

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.

Roles and Responsibilities in SOA

Stephan Lahanas posted on the top-10 reasons SOA projects fail.  I think many of his points are very valid (especially the one about how it's the business that matters, not the standards or the hype).

But, I think one of his points is a bit off the mark:

"Design drives development not the other way around, we wouldn't want the drywall guy designing a skyscraper, yet that happens in SOA implementations (figuratively speaking)...You can't really do 'Agile SOA'..."

Well, I certainly wouldn't want the architect of a skyscraper putting up my drywall.

But seriously, creating a SOA infrastructure isn't like creating a skyscraper. Creating a SOA is not an orderly progression of activities that lead to a defined end result.  It's more like a financial market: anyone can do whatever they want to make themselves wealthier, as long as they don't violate the rules (i.e. the law).  There is no defined end-result for a financial market: everyone is free to try and achieve their own optimal end result.  And many financial markets are extremely agile.

So, can you do "Agile SOA?" Absolutely.  As long as you've optimized the rules - your SOA governance - to allow for agility (which many people get horribly wrong, of course).  Provided the rules are not cumbersome, if someone else has built the services you can very quickly create consumers for those services without any muss-or-fuss.  No waterfall model of software development needed; no systems engineers needed.

If, on the other hand, you think of your organization's SOA as one big project, then almost certainly there is no way to be agile.  But, if you're thinking about it this way, you've already lost anyways. Central planning never has been (nor ever will be) agile.

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.

Less Governance is Good Governance

Todd Biske wrote a good post the other day that focused on how governance doesn't mean command and control.

Let me add a few important things to the discussion though: no amount of "management by consensus" will make everyone happy.  There will always be someone that's unhappy with something.  The real issue is that different people will be unhappy about different things - so you'll end up with everyone unhappy in one way or another anyways.

What this means for SOA governance is actually pretty simple: less governance is good governance.  It sounds pretty simplistic but the fewer policies you put in place, the fewer things there are for people to be unhappy about - and therefore the easier it will be to come to consensus, and the more people will be happy being governed.

As much governance as is absolutely necessary, but no more.

Supporting SOA Governance Monday

Whew. What a rough weekend.

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

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

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

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

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

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

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

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

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

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

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

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

All Hail the SaaS Revolution!

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

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

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

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

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

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

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

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

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

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

Providers have the following concerns:

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

Consumers have similar, but different requirements beyond the obvious:

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

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

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

When Design-time Becomes Redesign-time

I continue to be surprised by the number of enterprise architects I talk to that think that the way to implement design-time governance is to have a checkpoint, before a service goes into production, to validate the service meets the requirements and rules.

The key problem with this approach is that it's already too late.  By the time a service is ready to be deployed, it's well past "design-time" (technically, it's actually "deployment time").  So, one of two things happen: The service meets the requirements so it can go ahead, or it doesn't. If it doesn't, it's back to the drawing board for a redesign (or the project gets deployed anyways because it's more important than following the rules set by the enterprise architect).

While it's definitely valuable to have deployment-time validation "checkpoint," you shouldn't confuse this with design-time.  Real design-time SOA governance happens when the service is being designed (surprise!), so that you avoid problems before they are baked in and expensive to change.

If your design-time governance approach consists only of checkpoints at deployment-time, you should really call it what it is: "redesign-time governance".

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.

The secret is out: We acquired Mindreef

Well, my intrepid investigative reporter friend, Jeff Schneider, broke the news.  We've acquired Mindreef.  You can never time these things perfectly, and we didn't want to have news of Mindreef get lost in all the noise around some of the other acquisition stories.  So, we had been planning to announce it a bit later.  Of course Jeff, never one to let go of a breaking story, couldn't hold off :-)

On the Actional side, we first started partnering with Mindreef back in 2003 or so (long before Actional was acquired by Progress).  One of the first things that attracted us to work with Mindreef was the way their products make working with XML and web services easy.  As Mindreef expanded their product line they added the ability for a team of SOA stakeholders to collaborate, working together to ensuring that services are delivered successfully - something that still separates Mindreef from any other SOA quality or validation product.

In the SOA space, there's often been a clear dividing line between products that focused on design time concerns and those that focused on runtime concerns. But, SOA isn't so clear cut.  When I've built a service that's in production, and you want to design a consumer for that service, is this design time or runtime?  What if I've built a consumer that's in production and you want to change your service, is this design time or runtime? Well, it's both really.  So why then do we have such a divide between design time and runtime SOA governance products?

By bringing together Mindreef and Actional we're doing what's only natural - removing the artificial dividing line between design time and runtime, addressing the complete SOA lifecycle with technologies that are leaders in both.