Application Platform Strategies Blog

I've been thinking this all along...

Blogger: Joe Niski

Back in July at OSCON, I was thrilled to learn that I'm by no means in the minority in wincing and rolling my eyes every time I hear the phrase "Web 2.0." It made me feel a bit sorry for Tim O'Reilly (who handled it like a champ). To my jaded ear, catch-phrases such as "architecture of participation" and "social networking"  are almost as bad - and things like Second Life are even further down the ladder.

As cool as Second Life is in a demo or a 10-minute test-drive, I don't know many people who'd say they have adequate time for their first lives of family, friends, and in-person, real-time relationships and community. Curmudgeon that I am, I'm just as unconvinced about the value of most social-networking sites for anything but displaying one's personal foibles for all the 'Net to see. For example, I've gotten numerous generic LinkedIn requests from folks I haven't had contact with for years, and when I accept their invitation to link and send a personal message, I never hear anything back. Plus, LinkedIn seems to be a source of unsolicited email from recruiters. So, it was great to see Tim addressing Social Networking Invitation Etiquette very recently. When invited to join a new network with a similar purpose, I took a quick step backwards when they asked me to install software that would scan my Outlook address book to graph my professional networks (to their credit, they make it easy to opt out once you've gone through the mandatory registration required just to look around - but install software from an unknown site? to read my address book? why *shouldn't* I be highly suspicious?). When a former colleague who makes a sincere effort to keep in touch invited me to join him on FaceBook, I created an obfuscated identity, again just to be able to investigate the site's features, and found myself deeply unwilling to reveal enough information to possibly make it useful. I'd rather spend the time with him over lunch.

It's not that I'm such a privacy fanatic - I know that there are many ways of learning about people online, even if they don't spend time online. I just don't have the time - or the motivation to use my time - to get engaged in that medium. And beyond that, I have serious doubts whether there's real value for this in an enterprise context - tried & true threaded discussion tools, as well as those new-fangled wikis, do a great job for focused collaboration where email falls short. More importantly, can humanity's ever-diminishing attention span sustain the effort to keep the public Web 2.0 bubble from popping soon? Pop culture is notoriously fickle - how can you build a business upon anything but it's fickleness? And if you're not building a business on top of it, or not using it to help sell your consumer product, how can it be used to benefit your business? It's nice to know that I'm not the only one asking the latter question - the great post on TechCrunch titled "Will Human Laziness Burst The Web 2.0 Bubble?" says it much better than I can.

Yes, I sound like a cranky old Luddite - and this area is outside my team and responsibilities at Burton Group - but I'm trying to understand the phenomenon, to make sure I'm not missing something. My question is serious. What's the value of social networking tools inside the enterprise firewall?

Mobile Application Development

Blogger: Richard Monson-Haefel

Since January 2007 I've been spending most of my time researching and writing about application development on smart phones.  I've had the opportunity to research and write about Ajax development on mobile devices, Java ME, Adobe Flash Lite and most recently Microsoft .NET Compact Framework.  If you are a client you will have already received a notification, earlier this year, about an overview I wrote called "Rich Mobile Application Platforms for the Enterprise ". That document is just the tip of the iceberg. 

Next year we will be publishing all of my findings including an in-depth market landscape and four product reviews on mobile application development for the enterprise - I also plan to update the overview I wrote earlier. In total there will be six more documents that will be published in Q1/Q2 of 2008 on mobile application development frameworks and toolkits.   This will provide Burton Group's Application Platform Strategies service with a strong start on mobile application development for the enterprise.

During my research I've read an enormous amount of documentation and spoke to dozens of vendors, developers, and end-users. It's been a hoot and I learned a lot.  I wanted to call attention to a specific resource that I believe stands above the rest, a book on mobile application development called,  “Microsoft Mobile Development Handbook” (Microsoft Press 2007) by Andy Wigley, Daniel Moth, and Peter Foot.

In a nutshell the book is one of the best programming books I’ve read in a long time. In fact, I give it my highest recommendation. .NET Compact Framework is a nice piece of work and this book will help you appreciate all of its capabilities and how all the parts fit together. At about $70.00 a pop it’s not cheap and it can be difficult to find – it was sold out in every bookstore in
Minneapolis save one – but its well worth the price and effort. (You can get it at Amazon.com for about $45.00 at this time.) 

If you are thinking of developing mobile applications and are considering .NET Compact Framework, I recommend you buy a copy of this book.

More Recommended Reading on Internet Platforms

Blogger: Anne Thomas Manes

Following up on my last post on The Future of Internet Platforms, I also recommend that you read Joshua Allen's response. Joshua points out that APIs and platforms (especially proprietary ones) run counter to the essence of the Web, and that data is the true internet platform. In other words -- the Level 1 Internet platform that Marc Andreessen describes in the post that started this discussion is the highest level platform you could want. All you really want is RESTful access to the data on the Web.

Joshua has a valid point -- the proliferation of hundreds or thousands of proprietary APIs and SDKs will make Internet-based development a disaster site. But I'm still attracted to the benefits Andreessen describes in his Level 3 model -- an Internet-based environment that the average user can use to build sophisticated application systems. Not just a blog site. Not just my space or my face. But a sophisticated application. Without setting up my own web server or writing complex web applications.

Could that be possible without proprietary APIs or SDKs?

The Future of Internet Platforms

Blogger: Anne Thomas Manes

Recommended reading: Marc Andreessen recently posted a very thought-provoking entry in his blog on the emerging world of Internet Platforms. He describes three types of platforms (each a superset of the previous level):

Level 1:  Platforms that enable applications to interact with the supplied Internet-based application via APIs -- exemplified by Flickr, and by far the most common type of Internet Platform available today.

Level 2: Platforms that enable applications to run within the supplied Internet-based application via a plug-in model -- exemplified by Facebook.

Level 3: Platforms that provide a hosting environment for Internet-based applications -- exemplified by Andreessen's company Ning, as well as Salesforce.com.

As Andreessen says, there are a lot of challenges associated with being a provider of a Level 3 Internet Platform, so there aren't very many players in this space yet. But a trend toward this type of platform will fundamentally change the shape of application development. As he says in his second closing thought:

A new platform typically enables a new set of applications that were not previously possible.

Everything but the code

Blogger: Joe Niski

The importance of infrastructure is a major theme for Burton Group - the loose definition of "infrastructure" as "everything but business logic" structures our thinking and research.

In my years as a developer and development manager, I came to regard most of the tools I used on a day-to-day basis as infrastructure, just as important as my chair, desk, PC, and telephone. "Everything but the code" became infrastructure. My IDE, the version control system, the build scripts, the bug-tracking system, all the tools involved with the magical evolution of ideas into software. Fortunately, some of my employers understood development tools this way: tools were licensed, installed when I showed up on the job, worked well together - and there was someone responsible for the infrastructure, and somebody I could go to for help and support (whether inside the company or via a support contract). I didn't need to worry about those things; they were part of the environment, and I could largely forget about them and focus on the software project(s) and/or people I was responsible for.

Unfortunately, many of the companies I worked for didn't quite get it: multiple version control systems (or none at all), bug-tracking via post-it notes, requirements management by half-remembered customer conversations - or I couldn't get the budget for reasonable tools and support for my team. Anyone who's worked in more than a few development shops has probably seen all the bad. Sadly, many developers I talk to haven't experienced much of the good.

When I arrived at Burton Group just a year ago, I thought SDLC infrastructure was important enough to write about. (I spent the last quarter expanding on this theme with a collection of Reference Architecture templates due for publication later this year.) Of course, I'm not the first or only person to look at development tools this way - Joel Spolsky touched on these issues years ago in "12 Steps to Better Code" and more recently in "The Development Abstraction Layer." A client I met at Catalyst in July recently started capturing her thoughts on this, coining the term "envirostructure."

The development trade and development tools continue to evolve rapidly - five years ago, few people would have considered a unit testing framework as essential as version control, but that's changed. Everyone agrees on the importance of requirements documentation, but there are so many ways of defining requirements that tools are all over the map. Here's my current list of must- or should-have infrastructure, more or less in order of decreasing importance:

• Some organized and standardized way of documenting, managing, and tracing requirements
• IDEs
• A software configuration management/version control system
• A defect-tracking system
• Unit testing frameworks
• Build automation tools
• Packaging and deployment tools (i.e., release management)
• Whole-system test automation
• Reporting on key development metrics
• Automated code analysis

What's on your list? What did I miss?

Silverlight 1.0 is now available

Blogger: Richard Monson-Haefel

Microsoft announced today that that Silverlight 1.0 is now available as a general release. When you download the Windows plug-in it supports Microsoft IE 6, FireFox 1.2/2.0 but not the Safari browser, which is still in beta on Windows.  The Mac (version 10.4.8) plug-in supports FireFox 1.2/2.0 and Safari. Note: Silverlight 1.1 will not be supported on PowerPC Macs.

While the plug-in is in full release, the tools for building Silverlight presentations are still beta. Silverlight 1.1 which will be released sometime in the future includes a lot more features. In the mean time you can still do some interesting things with Silverlight as is demonstrated in a Windows Media video by Microsoft. Microsoft has even promised to work with Novell to create a Linux plug-in called Moonlight - that was a surprise since it recognition of the Linux Mono project.   

Micosoft has a long road ahead of them if they want to be competitive with Ajax and Adobe Flash.  The Flash plug-in is ubiquitous (96% of people browsing the Internet have it). Ajax is supported accross 93% of browsers.  It's going to get even more interesting as Sun Microsystems brings JavaFX Script into production.

When Technology Matters in SOA

When Technology Matters in SOA

Blogger: Anne Thomas Manes

Nick Gall just alerted me to another fine post by Andrew McAfee -- this time on the importance of technology in SOA.

Andrew is expressing concern about the fact that many people frequently say, "it's not about the technology" (INATT).

Andrew suggests that INATT has two typical meanings:

INATTv1:"It's not about the technology alone"

INATTv2:"The details of this technology can be ignored for this discussion"

Andrew rightly cautions people against taking either of these two meanings to the extreme--particularly the second one, which can lead people to view all technologies as equivalent.

Now, I must confess that I am one of those people that regularly says INATT--especially in respect to SOA. But I don't think either of Andrew's meanings actually represent what I mean.

When I say INATT in respect to SOA, I'm trying to convey the idea that technology is secondary to design. More specifically, technology is an implementation decision. When initiating a project, the project team should first identify and analyze the project requirements, then select an appropriate technology that effectively supports those project requirements.

People always ask me things like, "Which ESB should I use?" or "Which is better: SOAP or REST?", and, invariably, the answer is, "It depends on your project requirements."

So I reiterate. SOA is not about technology. It is about design. You can implement a service-oriented system using any type of distributed computing technology: HTTP/REST, SOAP, CORBA, DCOM, RMI, Jini, Fax, Telex, or whatever. That's not to say that technology doesn't matter -- it does. The technology used to implement a project will profoundly impact the detailed design of the project and its capabilities. And I think this is Andrew's point. Technologies are different. New and better technologies are being invented all the time, as well as new and innovative ways to use the technologies. But technologies are tools. And as any carpenter or mechanic will tell you, it's always best to use the right tool for the job.