Kicking off a series of posts on the top 5 Acropolis questions at TechEd 2007...

A question asked by a lot of people who are unsure what scenarios we're targeting with Acropolis, or whether they could use Acropolis to build the kinds of applications that they are interested in.

When we describe Acropolis, we say that "Acropolis is intended to make the development of modular, business focused applications easier". Yeah, yeah, yeah, but what does that mean?

Business Focused?

By business focused, we really mean line-of-business applications or the types of applications that you would typically find in a business setting, whether it is a small or medium sized business or in an enterprise. These include data entry, sales automation, customer care, inventory management, order management, reporting, KPI/dashboard style applications to name but a few. We've spoken at length to developers in healthcare, financial services, manufacturing, government agencies, etc, and they are all building applications along these lines.

These types of applications are typically required to be highly responsive and interactive, are data or user-interface intensive and are most often required to work offline. As such they are more suitable as client applications than web applications. Hitherto, it's been difficult for developers to easily build these kinds of applications on .NET, and this is something we wanted to remedy with Acropolis.

Of course, you could use Acropolis to build other types of applications, not just the types of applications listed above, but these are the kinds of applications that we considering our primary scenarios. On the other hand, not all applications will be suitable to be developed on top of Acropolis. If your application is extremely graphics or data intensive (like say a scientific data visualization application), then you probably won't find much in Acropolis that will help you.

Modular?

Acropolis adopts a modular approach to make it easier for developers to build their applications. This lets the developer divide their application into various functional pieces, that each encapsulates some specific pattern, strategy or piece of business or presentation logic. Acropolis then lets you recombine these pieces to make a fully functional application.

This modular approach improves the chances that if you write a component that encapsulates some specific piece of functionality, you'll be able to re-use it in more than one application. Then, you can build your next application more quickly, by re-using your existing components, leaving you to focus on your new application's specific requirements.

The modular approach also improves the chances that if (when!) you have to change your application, due to new requirements, additional functionality, new business process, new business opportunities, etc, you'll be able to do that more easily by adding or replacing modules.

Again, if your application is not modular, or cannot be decomposed into modules cleanly or easily, then Acropolis might not be suitable for you. But we believe that a lot of applications can be ‘largely' modularized - i.e. there may be some part of the application that can't be modularized, but there are large parts of it that can.

When we look at the kind of applications that line-of-business developers have been building on .NET, they of course vary widely as to their specific purpose, user interface, data handling, offline capability, etc. But when you dig into them, you'll find a small number of common patterns and themes that keep recurring time and time again. For example, there just aren't that many ways to implement a wizard-like interface that guides the user through a series of steps, or ways to integrate custom authentication, or centralized configuration settings, or offline support, or customization/personalization features into an application.

So by providing a system that lets us (Microsoft) or a third party encapsulate these common patterns into components that you can re-use, we hope to simplify and speed up your application development process. If your requirements are not covered by the ‘stock' components that we provide, and you can't find a suitable third party component, then you can of course write your own. We are hoping that due to the modular nature of Acropolis, this will be easy to do (notwithstanding how complex the thing that you are trying to do is) and that you'd only need to write it once and be able to re-use it in other applications that you build.

One analogy that I use that has proven useful in describing the ‘spirit' of Acropolis is SharePoint. SharePoint is a marvelous piece of software (for a web application J). When you think about it, SharePoint lets developers (or even non-developers) assemble an application (albeit a specific type of application) by composing it from pre-built components. Not only that, but end-users themselves can customize the application, almost to the point of constructing their own personalized version of it. Wouldn't it be nice if we could bring some of these benefits to the client application world? Of course, it's a different kettle of fish on the client, and things are a little more complicated in some ways. And of course the range of applications that we want to build is broader than those supported by SharePoint, but still, there must be something we can do, surely? We'll we intend to find out with Acropolis...

One caveat though - Unfortunately, you can't build the types of applications described above on the current release of Acropolis (we are only at CTP 1 status at the moment so be gentle with us) but we're hoping to ‘grow-up' pretty fast over the next 6 months or so. In subsequent releases, you should find support for more common patterns and strategies, and components that provide various implementations of them, will be included in Acropolis...