The Old Dogs Have Learned Some New Tricks

Many will be surprised by the enhancements that B2B Service Providers (the ones we used to call Van’s) have added to their service portfolios.  Five years ago, a lot of folks thought that the days of the providers of EDI document exchange services were numbered and that they would fade away into the sunset.  But guess what – it didn’t happen. 

The main reason why it didn’t is that these vendors aggressively sought out new ways of providing advanced integration capability and services and bolstered their long term chances of survival in the process.  GXS accomplished this via key technology partnerships with leading providers of advanced integration solutions.  Inovis and Sterling Commerce chose the route of internal development with key acquisitions to bolster internal capabilities.  Either way, the result was the same; vendors capable of providing a wide range of hosted integration features that include not just EDI/B2B, but also BPM, SOA and MFT features as well.

These new hosted solutions allow customers to leverage their existing B2B infrastructure while providing easier integration with back-end systems and business applications.

Another trend is the emergence of smaller B2B Service Providers like Axway, Crossgate, Hubspan, Seeburger, and SPS Commerce that are bringing new B2B solutions to the marketplace that will continue to drive innovation in this key sector.

Everything considered, the B2B Service Provider space has become a lot more dynamic than many thought it would.  What do you think?  Take a second to drop us a line.

 

Check out my latest research: The Forrester WaveTM: B2B Service Providers, Q4 2009

Twitter: integrationman 

Comments from Autodesk’s Manufacturing Analyst Day

This past Tuesday Autodesk conducted its annual Manufacturing Analyst Day event in Lake Oswego, Oregon, and I had the opportunity to catch up with executive leaders across the company’s spectrum of product brands (i.e. Alias for conceptual design, AutoCAD and Inventor for engineering design, and, more recent acquisition additions, MoldFlow and Algor for simulation). Contrary to my original perception that Autodesk offers affordable, no-frills product design tools to lots of smaller, mom-and-pop companies, I learned that their business is significantly shifting to include more direct sales to large, enterprise-level manufacturers like Intel, Nestle, and Parker Hannifin. In fact, approximately a quarter of Autodesk’s manufacturing business now comes from customers with over $2 billion in annual revenues, and it’s their fastest growing segment within this vertical. While some of this shift is undoubtedly a result of Autodesk’s relentless pursuit of acquisitions, I was keen to understand if there was a more systemic reason behind this unexpected find. So, while at the event, I got the chance to interview two Autodesk customers at polar ends of the spectrum – a 50+ employee design shop of food processing equipment, and a $100B+ food and consumer products conglomerate. Despite some expected differences in software needs (e.g. different scalability levels, different interoperability requirements with legacy tools, etc.) both customers impressed me with a common view on Autodesk’s value, specifically citing:

 -          Lower cost of ownership. Autodesk’s explicit philosophy is to offer software which addresses 80% of total capabilities at 20% of the price -- a mindset which reinforces its low-price, high-volume sales strategy, simplifies pricing structure for its army of channel resellers, and prioritizes pervasive user requirements over relatively-rare, “corner case” functionality. The result? Software that is more affordable and “fit-to-purpose”.

 -          Ease of deployment. Both customers I spoke with insisted that, compared with other software installations, Autodesk tools are quite reliable, always ready-to-use OOTB (per Autodesk’s Assurance policy), and simpler in a way that makes it easier for users to pick up new functionality. The net result? Software that has faster “time-to-value”.

 If you’re familiar with Forrester recent Application Development research, you’ll recognize that these are the very same characteristics that typify Lean Software  -- applications and architecture that, by design, cut through suffocating complexity and are slimmed down in a way that allows developers to deliver faster, "just in time" capabilities to the business.  Autodesk’s approach also stands in stark contrast to competitive offerings from mainstay PLM leaders like Dassault, PTC, and Siemens, whose applications have taken on more-and-more weight, complexity, and corresponding deployment challenges as companies pursue a more ambitious, broader agenda for PLM. Though these market leaders largely don’t view Autodesk as a viable competitor, Autodesk CEO Carl Bass is explicit in his view that the PLM market is positioned for low-end disruption where technologies with less product performance (at least in the near term) win over incumbent solutions because they are generally, to quote Prof. Christensen, "cheaper, simpler, smaller, and, frequently, more convenient to use". Sounds an awful lot like lean software again, doesn’t it?

 

Certainly there are still barriers to address before Autodesk’s lean product development tools become pervasive for large product development organizations, (e.g. evolving their sales strategy to include more direct sales, taming the growing complexity arising from serial acquisitions, resolving thorny data interoperability challenges in multi-CAD environments, etc.) But if you accept the idea that a trend toward lean software has been building for years -- and is, in fact, accelerating in today’s current down economic conditions – then enterprise organizations are only going to view Autodesk as a more viable and competitive provider of product development technologies over time.

Is COBOL The Root Of All (Technical) Evil?

OK, so I used a tongue-in-cheek title to attract your attention, forgive me. A recent blog about the Boomer retirement phenomenon provoked some comments by a colleague with strong opinions about COBOL's useful life. I felt that his comments raised a topic that is substantial enough to warrant its own place in the blogosphere. The comments read, in part:

" I am a boomer myself ... But as a software architect who has to look ahead and figure out what customers and users want I can't wait for the 3270 green screen boomer generation to retire.  It will allow for the acceptance of a new application paradigm. Those stepping up to the plate will not hesite to dump the COBOL garbage and use modern tools to create modern mobile apps that will finally end the drama of IT as today's business disabler. ..."

In an attempt to surface a provocative issue for broad debate, allow me to play devil's advocate for a moment. I agree about 3270 and would broaden it to include all character-based interfaces - VT, 5250, etc. The interfaces they create do not match the business expectations of today's users. But does that really extend to COBOL as well? Should we all be lobbying our business peers to spend whatever it takes to strip COBOL from our application environments? It is certainly feasible if you have a small amount of COBOL remaining, but firms with large amounts may have a much harder time justifying it. Simply put, our business peers do not care what languages we use - they want, what they want, when they want it. Funding technically-driven change is difficult, which is one of many reasons COBOL is still with us.

COBOL is a tool and like any tool it is entirely fit for some uses, and entirely unfit for others. The point being that adjectives such as better / worse, fit / unfit-for-purpose needs a context (purpose) before we can judge it. It is certainly fit for some purposes or its fate would resemble BASIC, ForTran, and other pre-historic languages. But fit/unfit misses the most important point. Even if we accept that COBOL is unfit for all uses, the problems that arise are: the ubiquity of its use, the cost to shed it, and the business benefit the change brings - as compared to other business-benefits those resources could bring if they weren't tied to a technically-oriented mass-change such as shedding COBOL. This line of reasoning falls away in small shops with little COBOL left, and looms large in large shops and big batch-processing environments.

Let's draw an analogy outside of IT. The metric system of measures and weights is undeniably better than the systems we use in the US, Canada, UK and other geographic regions of the world. Predictions of the wholsale adoption of metric measures in the US date back to the 1920s, with no clear adoption in the foreseeable future. The lack of standards causes problems every day in a global economy, (commerce, space programs,etc) so why haven't we all adopted metric? The reasons are similar to COBOL - the ubiquity of our current system, the cost to change and the perceived business benefit.

Turning back to COBOL - if we had all subscribed to the "shed COBOL" mind-set that was prevalent at the dawn of client-server, we would have exchanged all our COBOL for PowerBuilder. Had we done that, we would now be wondering how we could possibly extract ourselves from 20 years of PowerBuilder development and move to a modern programming language. This is where we come back to the link to Boomers - migrating the language is the easy part - what do you do with your people, skills, operating environment, operations procedures, etc? You can certainly replace them all, but in the spirit of devil's advocacy, we should recognize the true scope of the entire effort.

The implication that Boomers = COBOL and COBOL = Boomers over-generalizes the programming population. Some recent research completed by my colleague Jeffrey Hammond in conjunction with Dr Dobbs Journal showed that lots of 50-something folks are coding entirely in newer languages. COBOL was a miniscule part of the survey. Although we can stipulate that a survey of a mainframe-oriented publication would show markedly different results, we can't equate all Boomers as aging COBOL hippies - I don't have the hair for it anymore. *;-)  The main point about the survey data is that the world is not so black and white, but myriad shades of grey. Some Boomers are Java-heads, some programming newbies are trying their hands at COBOL via academic initiatives. 

So, I'd like to close this by thanking my colleague for his contributions to these blogs, and hope that by placing his remarks in a devil's advocate context, he'll not take offense, and together we will raise issues that elicit broad participation from a diverse set of folks in the blogosphere and Twitterdom.

What are your opinions about COBOL - is it a useful tool, a technology to tolerate and minimize as time goes on? Is it the root of all evil? Or is it some hybrid of all of these? Voice your opinions and please note your role in IT - it will be interesting to see whether (for example) the opinions of programmers varies from applications directors from those of systems architects and others. 

Boomer Retirement And IT - Are You An Ostrich, Chicken-little, Or an Owl?

The rock-band R.E.M. sang a song about the "end of the world as we know it" and to hear some people talk - the end is near! 

The Chicken-littles of the world would have us believe that retiring Baby Boomers will wreak untold havoc. Half the world's population will suddenly disappear from the workforce - collapsing world markets, straining national pension systems to the breaking point, and burdening younger generations with unmanageable national debt.

Other folks are at the opposite end of the spectrum - they're in denial, like ostriches with their heads deep in the sand - if they don't look at how bad the problem is, it can't hurt them, right? No staffing problems here - look we can still hire people, let's deal with today's problems and not go looking for tomorrow's troubles!

Those of you who were involved in IT during the Year 2000 issue in the late 1990s heard way too much hype from Ostriches and Chicken-littles. Remember, COBOL programmers were predicted to be commanding thousands of dollars an hour, spurring legions of retirees to come back to the workforce? Yeah well, if that REALLY happened, I'd have gone back to COBOL coding and earned enough to retire in Tahiti by now. True, there were some shortages, some public glitches and other glitches that were kept buried for the bad press they would otherwise create - especially in financial services. But net/net, the prudent management of resources got us through January 1st, 2000 with comparatively little pain - the wisdom of the owls won out.

Sensing that we're at the start of another bruhaha, I spent a good deal of last quarter sourcing data for my report on global workforce planning - which was just recently published. While it dispells much of the hype, it also serves as a call to action. I'd love to hear about the issue from the minds in the blogosphere and Twitterati - in your opinion, is this a pressing issue or just another sound-byte for IT? (pun intended)

On a scale of 1 to 5 - with 5 being "Very large" and 1 being "None"  - please answer 3 questions:

1) Do you believe Boomer retirement will impact your IT organization significantly in the coming 5 years?

2) What is the level of activity in your firm to mitigate the impact of Boomer Retirement?

3) Do you believe Boomer retirement will impact your business significantly in the coming 5 years? (impact to non-IT staff and business volume).

Is application consolidation keeping you up at night?

I've written a lot of research around the topic of application portfolio management (APM), and how the tools are slowly maturing from their application mining roots. Although the process of APM applies equally across packaged and custom-appls, the mining tools, until recently anyway, have excluded packaged applications.

Our application development team recently expanded with some new colleagues, and one of the topics a new colleague - George Lawrie - and I intend to take on as a joint effort is application consolidation across custom and packaged applications.

We'd like to know - how important is this topic to you - what are the nuances of it that keep you awake at night, or is it a non-issue? If it is a non-issue, why? Have you done such a good job of staving off redundant and obsolete technology, or is it someone else's responsibility? Please chime in, we'd love to hear about your application environments.

Business Rules Technology Belongs In Your Architecture

Checkmate! You're Toast.

Those are words you don't want to hear when playing chess. Similarly, you don't want to be checkmated in the rough and tumble of the business real world.

To win at chess and in business to you have to make smart decisions constantly and consistently - decisions that are guided by a carefully crafted strategy designed to checkmate your opponent or, at a minimum, to stay in the game. Deciding what moves to make in chess is hard enough even though it is just you and your opponent. The decisions businesses have to make everyday can be much more complicated and the stakes are much higher.

Where Is Your Decision Logic Implemented?

Most firms embedd them deep within its application code far from the businesspeople who understand the business rules best. That might be OK for business rules that do not change frequently. But, for business rules that change frequently or need that need to change quickly, there is a better way. Forrester has identified business rules technology as one of the Top 15 Technology Trends Enterprise Architects Should Watch and one of the 5 key changes app dev shops should make in 2010 (attend or replay the free Webinar Live: Tuesday, October 20, 2009, at 11:00 a.m. Eastern time).

Avoid Checkmate. Include Business Rules Technology In Your Architecture

Business rules platforms (often called decision management) allow decision logic to be authored and executed external to you application. The result is better management and faster change of your business rules because:

• The business rules are not embedded deep in application code such as Cobol, .NET, or Java code that only a programmer can change.
• Business rules are executed consistently across all applications that need them because they are implemented once and shared for all applications that need the.
• Businesspeople who understand the business rules can author and maintain the rules directly instead of explaining the rules to programmers who then have to code them in a programming language.

The result for your business: faster change and consistent decisions.

Research For Application Development And Enterprise Architecture Professionals

John Rymer and I consistently published research on business rules platforms, best practices, case studies, and technical architecture. If you are interested in learning more about business rules technology please feel free to schedule an inquiry with John and me and check out the research documents below.

The Forrester Wave™: Business Rules Platforms, Q2 2008

The Truth About Business Rules Algorithms

Best Practices In Implementing Business Rules

Case Study: California Association Of Realtors Innovates With Business Rules

Case Study: Hypo Real Estate Enables Credit Risk Professionals With Business Rules

Must You Choose Between Business Rules And Complex Event Processing Platforms?

Case Study: The Doctors Company Innovates While Rebuilding Its Core Systems

Deputize End-User Developers To Deliver Business Agility And Reduce Costs

Mike Gualtieri, Senior Analyst

email: mgualtieri@forrester.com

twitter: mgualtieri
 

Are you creating a Canonical (or “Common”) Information Model?

 

 

Hi!

It’s been almost two years since I last wrote about this topic, but since then this trend has continued to accelerate. I have not had an opportunity to do another survey myself, but have seen:

• Anecdotally among many clients doing SOA, more than half are also creating and managing one or more canonical information models for their SOA and/or information management strategies. These are all focused on “data in motion,” not “data at rest.”
• Surveys from other sources have shown 50-60% of those doing SOA are creating a canonical information model (increased from the 39% rate our 2007 survey found). Last week I saw data shared informally by a major vendor of SOA suites, from a survey of hundreds of their customers (all of whom are doing SOA), showing more than 60% are creating a canonical model.

So what’s behind this growing trend? The forces we identified in our original research piece are all still in operation, but to give a quick view, stories I’ve heard typically go like this:

• “We have thousands of XML Schemas (XSDs) about the place, rapidly proliferating out of control – with each representing the information model as the local team sees it for their application interchanges or service interfaces.
• From the point of view of an individual developer or small team, it’s not a big deal, but the lack of a canonical/common model is a huge obstacle to any integration or interoperability we require across multiple applications.
• Our issues with schema governance are exacerbated by the rapid evolution of the industry schema standards with which we must comply.
• The lack of interoperability is especially painful when:
  • We’re integrating with one of our ecosystems of B2B partners.
  • We’re integrating/automating a cross-functional business process, like order-to-cash, or order-to-provision.”

When these folks try to establish a canonical model, results vary:

• If the work happens in a context where industry standards like SID, Acord, or FPML can provide a starting point, the effort tends to succeed. This is true even when those standards have not previously been adopted by that enterprise.
• Where such industry standards don’t exist, it’s often much harder to get enough agreement among the interested parties to get the effort off the ground.
• And since two years ago I’ve seen one other interesting dimension to the problems of establishing a model: the need for a federated approach. In very large organizations with multiple business domains, it sometimes turns out that it’s not possible to establish one canonical model. Instead, multiple domain models are necessary, interlinked with one another and with an enterprise-level canonical model. These domains may reflect different external ecosystems, such as securities trading participants, as opposed to customers of a wholesale bank, or international banking exchange operation.

Fortunately, since I last wrote, the state of the art has moved on, with more tools coming on the market, as well as evolution of the tools I mentioned in the earlier piece. These included (from those mentioned in the 2007 document):

• Enterprise architecture tools. Casewise, IDS Scheer, MEGA International, Proforma, and Telelogic led the EA tools market (IDS Scheer has since been acquired by Software AG, and Telelogic by IBM). But some folks are relying for their information modeling needs on vendors like Embarcadero that made the transition from data modeling tools to EA tools more recently.
• Tools embedded in ESB, Information-as-a-Service, or BPM suites. Major vendors of ESB, IaaS, and BPM suites often include information modeling tools as part of their solution. For example, TIBCO ActiveMatrix, Composite Software Composite Studio, Red Hat MetaMatrix Enterprise, and IBM Information Server (which includes semantic technology from the acquisition of Unicorn Systems) can be good options if you're using those suites for multiple other parts of your SOA or IaaS strategy.
• Independent specialist vendor tools. For the most advanced modelers, especially when semantic technology is required, tools from specialists like Contivo, Metatomix, or Revelytix are a good solution. Other independent tools include Progress Software's DataXtend Semantic Integrator.

Since then I’ve also heard of others, like TopQuadrant’s TopBraid Suite. Oh, and my colleague Dave West has written a great report on the ways that semantic technology is being used by application developers nowadays. Dave and I are doing more new research in this area, about both canonical modeling and semantic technology. So please help us with our research:

Are you creating a canonical model? What tools and techniques are you using to drive your success (whether based on XSDs, or semantic technology, or both)? What issues have you encountered along the way? Can we interview you for our research?

Please comment here if possible, or Tweet with hashcode #ForrCanon, or email me (if you must retain confidentiality) at mgilpin@forrester.com.

Leaving User Experience To Chance Hurts Companies

Have you ever driven in Boston?  If you have, then you know that the streets are very difficult to navigate. Why? In colonial Boston someone built a house. And then someone else built a house. Then they built a path between the two houses. And so on and so forth. As a result, Boston’s layout was accidental and the result is a convoluted set of streets that frustrates both residents and visitors.

Similarly, application development shops achieve poor results when they design without a plan, leaving user experience to chance. They:

• Hurt conversion rates. A well-designed site can have up to a 200% higher visit-to-order conversion rate than a poorly designed site. And visit-to-lead conversion rates can be more than 400% higher on sites with a superior user experience.
• Alienate customers. Retained customers become an annuity to your business and are ambassadors of your value and brand. Well-designed sites have page abandonment rates up to 41% lower than their inferior cousins.
• Run up development costs. Upfront user experience design can greatly reduce the need for extensive redesign and redevelopment that may be necessary to fix a poor user experience.

Wow! App dev shops who are not doing user experience design have a great opportunity to substantially increase their value to the business. Our latest research on user experience (UX) design shows application development professionals how.

Mike Gualtieri

Senior Analyst, Forrester Research

Put off making strategic decisions about mobile development until 2010

In the first three quarters of 2009, I’ve had an increasing number of discussions with Forrester clients about the state of mobile development and what technologies they should be evaluating. These conversations usually start with the statement “mobility is a mess…” What I mean by that statement is that we’re in the midst of a sea change in the technology options that IT shops have at their disposal when it comes to building custom mobile applications. The frenetic pace of evolution makes mobile development one of the Top 15 Technology Trends and it warrants careful attention on the part of enterprise architects and application development professionals.  By the end of 2010, you’ll have at least five distinct mobile applications architectures to choose from, including:

1.       Native, on-device applications. With smart phone use growing, we’re seeing the evolution of distinct mobile operating systems like the iPhone OS, Windows Mobile (WinMo) 6.5, Symbian, Android, and BlackBerry OS. Unfortunately, each mobile OS has its own programming model, so while building native apps gets the most out of each device, it takes a lot of effort to execute a native app strategy.

2.       Java ME. Java runs on many mobile platforms, including many feature phones. While there’s less work involved in targeting many different devices, it’s not as simple as you might expect. Inconsistent implementations of specifications and APIs by different devices have led to a fractured landscape, giving rise to a “write-once, port everywhere” reality.

3.       Mobile middleware. Companies like Sybase, Antenna Software, Vaultus and Pyxis Mobile solve the porting challenge by providing a consistent set of APIs and design tools that generate on-device applications. These companies are extending their products to support the mobile OSes listed above, and their tools are a good option for shops that need to get started immediately. But be warned: the tools aren’t cheap, and you’ll need specialized development skills to get the most out of them.

4.       Web development.  Emerging mobile OSes provide full support for Internet standards like HTML and de-facto standards like Ajax. Development frameworks like Appcelerator Titanium, PhoneGap and Rhomobile Rhodes allow Web developers to build apps with technologies they know, and then deploy them on mobile devices.

5.       Mobile RIA plug-ins. Forrester has documented the rise of rich Internet applications (RIAs) on desktop OSes, but now plug-ins like Adobe Flash, Microsoft Silverlight, and Sun JavaFX are getting slimmed down and ready for action on the next revs of high-end mobile devices. Mobile RIA is not a realistic option yet, but it will be by the end of 2010.   

If possible, you should focus on tactical per-project implementations for the remainder of 2009 and the first half of 2010 while the technologies at your disposal continue to mature. All you need to do is look at the announcements in the mobile space over the last few weeks to see how fluid the situation is. Here’s a sampling from just the past week:

• RIM and Google joined the Open Screen Project (10/5/09). The Open Screen Project is an effort led by Adobe to port the Flash player to multiple devices, including Mobile phones and set-top boxes. Adobe also announced the intention to release Flash on Windows Mobile, and Palm’s Web OS as well as "ahead of time" compilation of  Flash applications to iPhone OS. Expect betas of full Flash on mobile devices to start toward the end of 2009 and continue through 2010
• RIM Announced the Widget SDK for the BlackBerry Platform (10/6/09). The BlackBerry Widget Software Development Kit (SDK) lets developers build apps for BlackBerry OS 5.0 using common web technologies like HTML, CSS, and JavaScript.
• Verizon joined the Android camp (10/6/09). At this year’s CTIA show Verizon announced that it will launch a range of Android-powered devices over the next few weeks. As more and more Android devices surface and more carriers adopt them, they become a more tempting target for developers, which could create the first significant challenge to Apple’s iPhone as the developer platform of choice.
• PhoneGap got back into Apple’s good graces (10/7/09). PhoneGap was an attractive early option for developers that wanted to build apps for both Android and iPhone OS, but Apple began rejecting PhoneGap apps from the app store with the release of the 3.0 update to its operating system. It now appears that Apple’s concerns with PhoneGap have been resolved.  

These four events illustrate the reality of the mobile space: shifting alliances, and investment by ISVs, device manufacturers and carriers in multiple technology options as each establish themselves as players tries to emerge as a winner in a hyper-competitive market. But there’s an upside for shops that keep their options open: lower prices, better-looking apps, and mobile development platforms that are easier to use.

Jeffrey

Follow me on twitter.

The Dream Stack For Developing And Deploying Web Applications

I want to develop a Web application - a really good Web app. The kind of Web app that will make me so rich that I can buy an $9.4 million co-op over looking Central Park, a Yacht registered in Monaco, and hire an architect to build my dream-house west of Boston that is a combo of Buckminster Fuller, FLW, and MTV cribs. Throw in a vintage sweet ride like Don Draper's Cadillac and lifetime membership to the Boston Sports Club. I'm set.

The problem: What technology am I going to use to develop and and deploy a pwn-some Web app that will scale forever and never go down. (I need a great idea too!)

The solution: Enlist your illustrious help to come up with the perfect Dream Stack to help make all my dreams come true.

Dream Stack: What Are The Requirements?

The Dream Stack is a perfect combination of tools, technologies, and platforms that meet both development and deployment requirements. But, deciding what combinations of technologies to use is no simple task because there are choices and combinations galore. Here are my requirements for the Dream Stack:

Development

• Low-cost tools (because this is a startup).
• Maximize developer productivity.
• Faster development and faster change.
• Can develop great user experiences.
• Availability of talented developers (we plan to grow fast).
• Will support a scale-out deployment architecture of both data and computing.

Deployment

• Low-cost, linear-cost deployment  (because this is a startup).
• Support scale-out architecture of both data and computing.
• Architected to never go down.
• Employs security features
• Easy to manage and monitor

Your Thoughts? What Is The Dream Stack?

Your Dream Stack should consist of tools, technologies, and platforms that are currently available either as open source, commercialy available products or a combination of both. Your stack will probably, but not necessarily, include programming languages, databases, app servers and/or cloud, IDEs, libraries, and other platform technologies. Any combination is fine as long as it meets the requirements of the Dream Stack.

1. What other requirements should the Dream Stack have?

2. What is your recommended Dream Stack?

Mike Gualtieri, Senior Analyst, Forrester Research

Follow me on Twitter

Cross-posted at Dr. Dobbs Code Talk

How Do You Define A "Legacy" Application?

 

I had an interesting inquiry with a client that began with this question - "What is the defniition of a legacy application?"  Yikes, I thought - this will be one of those long-ranging, rhetorical discussions that - at the end of the day - lacks the kind of decisive answer clients typically seek during inquiries. The client actually had a good reason for wanting an externally published, formal definition - an external entity was attempting to measure the company's risk by quantifying its exposure to "legacy."

Why repeat the question here? It's not that I don't have published opinion on the matter - I've written a number of pieces on modernization options and defined the term for those purposes, and I get tons of inquiry around "legacy skills" and the how, whether and when to "modernize" legacy applications. Those conversations follow a familiar path, and tend to end up at these points of agreement:

• The app was written some time ago, its original authors moved on taking knowledge with them (lost knowledge).
• Subsequent authors changed the application based on insufficient / lost knowledge, introducing bugs and de-stabilizing it.
• The app is now brittle, and people are reluctant to change it for fear of breaking it.

In the above context, note that the underlying technology that people usually use to define legacy (mainframe COBOL, iSeries AS400, VB 6.0) has little or nothing to do with the symptoms. In fact the the symptoms could describe 5 year old Java, C# or .Net applications just as well as a 30 year old COBOL application.

Past experiences have taught me why focusing wholly on technology as being the cause of "obsolete" can be problematic. In this case, I'd advised in a Webinar that PowerBuilder was a legacy language from which folks should move ahead. No offense to PowerBuilder - I could have cited many other languages as obsolete. In the Q&A section of the Webinar, one attendee asked - "But all of my applications are written in PowerBuilder."  Ooops, scratch that generic advice.

Clearly, my proclamation of "obsolete" required the context of this client's situation as a litmus test. Therefore, I submit that we can't rely (solely) on technology as an indicator. But we can't ignore technology either, because it can contribute to the desire to shed an application if:

• App can't be extended due to the lack of / waning 3rd party vendor support - perhaps APL, PL/I, VB 6.0 are examples.
• App won't scale based on deficiency in original technology choice - app written as a throw-together temporary app, now needs to scale to meet public-Internet traffic volumes and security protocols
• Long-standing poor coding techniques, "patching it fast" rather than "doing it right" over a long period of years for example

A succinct definition of a "legacy application" is more difficult than it seems, but perhaps that's the point - this isn't a simple matter. Deciding the fate of an application needs more than over-simplified terms like "legacy."   Perhaps we should take more of a potfolio view, and replace the entire question with a more appropriate test such as "When is an application no longer suitable for the business?"

Now that I've presented my opinion above, I'd really like to hear from you folks in the blogosphere and the Twitterati - How do you define a legacy app?