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 

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

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
 

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?

Excuses, excuses: The Business Doesn't Know What It Wants

I have grown weary of hearing excuses (for 20 years)  from application development professionals about why they are challenged when it comes to developing and delivering applications that meet the expectations of the business. Excuses such as:

• The business doesn't know what it wants.
• The requirements keep changing.

 

Application development professionals are not served by these lame excuses because no one gets what they want or need. The business is left lacking and application development professionals deserve their reputation. If you have no excuses, then I salute you. If you want to stop the excuses, here's how:

Solution 1: Get Over It

Stop denying reality. The business either doesn't know or can't always articulate what application features they need to make their business more productive, more responsive to customers, and more flexible to market changes. And, they often change their minds because they are just thinking this through themselves and that often results in new needs or missed requirements. This is the nature of the beast. Accept it and stopping beating your head against the wall. It's not good for you.

Solution 2: Understand The Business And Your Users

What's a poor app dev gonna do? You must learn the workings of the business, understand what customers want, what competitors are doing, and what it will take to create a great user experience for users. This will give you a much better context when you speak with the business and you can work together in the requirements, offer new ideas, and head-off many of the gothcha's that come up later. This is your job and you have to start doing it to the n^th degree. Keep being strictly a tech-head if you want, but stop the excuses, please. Learn the business.

Solution 3: Build For Change

Things change constantly. You need to choose technologies, architectures, and processes that enable you to respond to change. This requires getting creative and being open to new combinations. For example, maybe an event processing architecture is a more natural way to respond to what is happening in the business than a service oriented architecture. Or, maybe you can build a more better user experience by using Adobe Flex rather than JSF. Building for change is a lot easier when you know the business because it helps you to anticipate future requirements.

Solution 4: Get Passionate About Your Craft!

The industrialization of software development has been an epic fail. Developing software is not like building a car on an assembly line or bottling beer like Laverne and Shirley at the Shotz brewery. Software development is a creative craft more akin to making a movie where talent, creativity, discipline, and passion result in great creations. For years, app dev pros have been told to keep their heads down - that all you need to do is follow the project plan and write your code. Wrong. Lift your head up, find your passion, understand the business and then use your technical creativity to make beautiful applications that users find useful, usable, and desirable.

What's your excuse?

 Mike Gualtieri, Senior Analyst, Forrester Research

Follow me on Twitter.

Distributed Cache Technologies Are Ready For The Mainstream

The open source project, Memcached, is a common staple for many of the largest Web sites including facebook, twitter, wikipedia, and others. The enterprise software vendors haven entered the market and have added features that are more attractive to enterprise IT - especially to Java shops.

In recent months, we have had a significant uptick in client inquiries about distributed cache technologies and how they can be used to improve performance, scale, and reduce costs of Web and application architectures. We are also encountering distributed cache technology in conjunction with other platform technologies such as CEP. There is also an intriguing potential for distributed cache technology to become a staple of cloud computing environments (some might say amazon S3 has the properties of a distributed cache).

Based upon this increasing level of interest, the maturity of the products, and the potential of distributed caches to radically change they way applications are architected John Rymer and I have initiated a Forrester Wave evaluation of Distributed Cache technologies.Our current list of candidates to evaluate include:

• Alichisoft NCache
• Gemstone
• Gigaspaces
• IBM ExtremeScale
• Memcached (we may also include Gear6 and Schooner since they support memcached)
• Oracle Coherence
• Red Hat
• Terracotta

Are There Any Other Products We Should Include?

These are the products that we have encountered when speaking with both vendors and customers. Are there any others that you think should be on this list? For example, should Amazon S3 make our list or are there any other commercial products that are available?

We Would Love To Hear From Customers Who Are Using Any Of These Products.

If you are a client using any distributed cache technology we would like to speak with you about your experiences with these products and the business and technical requirements that drove you to implement the technology.

Please let us know.

Mike Gualtieri, Senior Analyst

John R. Rymer, Vice President and Principal Analyst