Boston is a great city of revolutionary ideas and rich history. This is the inspiration for the conference we have put together for you. Our goal is simple: Provide a fantastic two-day event for application development pros to:

Hear from leaders who have successfully transformed app development to deliver more customer value more quickly.

Learn from expert analysts about the latest best practices and technologies to speed transformation.

Share new ideas with peers.

Become more valuable to their organization.

Help their organization become world class at application development and delivery.

Most Java applications don’t need a fancy container that has umpteen features. Do you want to pay for a car that has windshield wipers on the headlights? (I wish I could afford it.) Most Java applications do not need these luxuriant features or can be designed not to need them. Many firms do, in fact, deploy enterprise-class Java web applications on Apache Tomcat. It works. It is cheap. It can save tons of dough.

Expensive Java Application Servers Sometimes Add Value

There is a need for luxury. But, you probably don’t need it to provide reliable, performant, and scalable Java web applications. Application server vendors will argue that:

You need an application container that supports EJBs. EJB3 fixed the original EJB debacle, but why bother? Use Spring, and you don’t need an EJB-compliant container. Many applications don’t even need Spring. EJBs are not needed to create scalable or reliable applications.

Categories:

With Microsoft's plan to acquire Skype for $8.5 billion, Steve Ballmer is doing a Jason Voorhees in Crystal Lake. Let me explain. Microsoft failed miserably at mobile. While the boys and girls in Redmond were contemplating how to put the "Start" menu on a phone, Steve Jobs was cleaning mobile clocks with the iPhone. But, like all great competitors, Microsoft knew they lost it. So they started from scratch. The result: Windows Phone 7. In my opinion, an awesome mobile platform on a par with iPhone, albeit with a lot less cultural cachet. The problem: The momentum favors iPhone and Android. Microsoft needs an ace card. Ballmer, potentially, found an ace card in Skype.

With 633 Million Users, Skype Is A Communication Juggernaut

Skype is not a phone. It's a way to see your three-year-old granddaughter, connect with your adult children, or make sure your family is safe 4,000 miles away. And, it's mostly free. Of the 633 million users, fewer than 8 million are paying users. No matter. What is important is that many of these users would love to make free calls on a mobile phone.

Do you keep every single light on in your house even though you are fast asleep in your bedroom?

Of course you don't. That would be an abject waste. Then why do most firms deploy peak capacity infrastructure resources that run around the clock even though their applications have distinct usage patterns? Sometimes the applications are sleeping (low usage). At other times, they are huffing and puffing under the stampede of glorious customers. The answer is because they have no choice. Application developers and infrastructure operations pros collaborate (call it DevOps if you want) to determine the infrastucture that will be needed to meet peak demand.

Categories:

Traditional application servers such as WebSphere, WebLogic, and JBoss are dinosaurs tiptoeing through a meteor storm. Sure, IBM, Oracle, and Red Hat still have growing revenue in these brands, but the smart money should look for better ways to develop, deploy, and manage apps. The reason: cloud computing.

The availability of elastic cloud infrastructure means that you can conserve capital by avoiding huge hardware investments, deploy applications faster, and pay for only those infrastructure resources you need at a given time. Sound good? Yes. Of course there are myriad problems such as security and availability concerns (especially with the recent Amazon mishap) and others. The problem I want to discuss is that of application elasticity. Forrester defines application elasticity as:

The ability of an application to automatically adjust the infrastructure resources it uses to accommodate varied workloads and priorities while maintaining availability and performance.

I am not talking about The Donald here, thankfully. I am talking about how fervently impatient users are when it comes to website and mobile app response time. You can design a brilliant, luxurious, and intuitively interactive user experience, but if it doesn't perform well — as in response time — then the users will hate it. They don't want to wait. Why should they? They will just go somewhere else. Your job is to design and implement user experiences that are lovable and that performance spectacularly.

Application Performance Management Starts During UX Design

Forrester defines performance as:

The speed with which an application performs a function that meets business requirements and user expectations.

They say "content is king." But, "context is kingier" when it comes to designing great smartphone and tablet mobile apps. Don't make the mistake of thinking that mobile app design is just about a smaller screen size or choosing the right development technology. Content and context are both important to designing great user experiences, but mobile amplifies context on five critical dimensions: location, locomotion, immediacy, intimacy, and device. Understand each dimension of Forrester's mobile context to design mobile apps that will make your users say "I love this app!"

Location. People use apps in an unlimited number of locations. And not all places are the same. A user may be in a quiet movie theater, at home in the kitchen, on a train, or in the White Mountain National Forest. Contrast this with desktop computers, stuck in places such as an office cubicle, home office, or kitchen. Laptops provide some mobility but are larger and less able to provide the immediate access of instant-on mobile devices such as smartphones, eReaders, and tablets. Location is a key dimension of context, driving different needs for users depending on where they are. Fortunately, GPS-equipped smartphones can use a geodatabase such as Google Maps to determine precise location.

Categories:

Hockey god Wayne Gretzky said, "I skate to where the puck is going to be, not where it has been." For application development professionals, three megatrends show you where to skate to be more successful:

Megatrend 1: Get faster. The recession that started in December 2007 created a hunker-down mentality. The sentiment for IT became: "We need to do more with less." As we emerge from the recession, albeit in an unresounding way, the new sentiment is: "We need to get faster." The pace of business change continues to accelerate, and that in turn has intensified the need for application development professionals to deliver and change applications faster. The industrialization of application development has failed. Scrap it. You must get faster, and that means changing your process, changing your technology, and changing your organization. Software development is more akin to making a movie than to making widgets on an assembly line.

Seriously. I recently spoke with a client who swears that software quality improved once they got rid of the QA team. Instead of making QA responsible for quality, they put the responsibility squarely on the backs of the developers producing the software. This seems to go against conventional wisdom about quality software and developers: Don't trust developers. Or, borrowing from Ronald Reagan, trust but verify.

This client is no slouch, either. The applications provide real-time market data for financial markets, and the client does more than 40 software releases per year. If the market data produced by an application were unavailable or inaccurate, then the financial market it serves would crumble. Availability and accuracy of information are absolute. This app can't go down, and it can't be wrong.

Why Does This Work?

The client said that this works because the developers know that they have 100% responsibility for the application. If it doesn't work, the developers can't say that "QA didn't catch the problem." There is no QA team to blame. The buck stops with the application development team. They better get it right, or heads will roll.

As British author Samuel Johnson famously put it, "The prospect of being hanged focuses the mind wonderfully."