How do you build line-of-business applications in Silverlight and Windows Presentation Foundation (WPF) that can be maintained and extended over a period of years? How do you design and code to handle real-world complexity? Composite Application Guidance (a.k.a., "PRISM") from patterns & practices offers guidance, libraries and examples--in small, free-standing, digestible chunks--that you can use to tame the complexity.

In this episode of ARCast.tv, I sit down and chat with Ward Bell to learn how to compose complex UIs from simpler views, integrate loosely coupled components with "EventAggregator" and "Commands", develop independent modules that can be loaded dynamically, and share code between Silverlight and WPF clients.

About ten years ago, a really interesting exodus took place in the software development world. Architects and developers everywhere ran away, screaming in some cases, from building applications for the desktop to building pure web-bases solutions. Why? One simple reason: Web applications are way easier to deploy and maintain.

This stampede to the data center created some new problems, however:

• The browser, in many ways, is not the avenue to create rich user experiences
• Offline capabilities in "occasionally connected" applications went away completely
• Data and functionality is the desktop silo was simply relocated to a web silo

And thus it has been for the past decade.

The Return of the Client
Ray Ozzie talked a lot about software plus services in his keynote address at Microsoft MIX a couple of weeks ago. Ray's vision is a world where key application functionality is written and deployed as hosted services in the cloud that can be consumed by many different application end points running on a multitude of different platforms. This model of "many pieces loosely coupled" allows you access critical data and functionality whenever you need it, wherever you happen to be.

I've always been a big fan of the client application, and have spent the better part of my career writing these types of applications. This concept of software on the computer or device significantly leveraging hosted services has been a major component of my work lately. However, in talking to people about it, I get a fairly consistent comment back when discussing this:

I don't want to go back to building fat clients again. What a pain.

This got me thinking: Is this whole S+S thing moving us backward? Are we going to end up with the same deployment and maintenance problems we had before the web came along?

The "Thinner" Client
In a world of software and services, we need to think about the role of the client-side software differently than we did before. Without a doubt, local software will need to be smarter than your pure web applications ("thin" clients). Likewise, many of the features that we would normally need to build into a completely local piece of software ("fat" client) are going to be managed by services in the cloud.

As this kind of application isn't "fat" or "thin," I propose the concept of the thinner client -- fatter than a thin client, but thinner than a fat client.

The thinner client is a fully functional piece of software that can:

• Provide a compelling user experience because it can leverage the normally untapped processing powers of the client machine and fully take advantage of the strengths of the local OS software
• It can manage and organize data online or offline
• It provides users a piece of mind from a security perspective, sharing non-sensitive data online while locking-down sensitive data on the local machine
• Manage and automatically install software updates via services
• The innate extensibility of services facilitates multiple client "heads" for any particular application -- desktops, mobile devices, cell phones, game consoles, you name it

Thus, the thinner client manages only the work it needs to on the client machine, leaning on the hosted services for the rest of the required functionality.

Real World Thinner Clients at Work
The simplest example I can think of to illustrate this architecture is the subject of my last post: Twitter. At its core, Twitter is a hosted service that provides a communication hub, allowing people to post updates on what they're doing any time they like and people who are interested to receive those updates in near real time.

To start using Twitter, you create an account for yourself on the web site. From that point on, there is a multitude of different applications you can use to access the hosted service. As I write this, I have twhirl running on my machine pulling updates down for me. From my cell phone, I can either access a mobile friendly version of the Twitter web site or use TinyTwitter, a client application written for Windows Mobile on top of the .NET compact framework. And these are only a few examples. If you really want to get a feel for how many channels there are to distribute content from Twitter, just have a look at the Twitter Fan Wiki.

The core functionality of Twitter is exposed in its hosted services. This single architectural decision enables large scale extensibility of content delivery channels. These thinner clients offload the work of managing the stream of communications to hosted services and focus on delivering content in a way appropriate to a specific platform.

The Thinner Client In Practice
While Twitter certainly won't every be accused of being a business system, it certainly provides a solid example of how this architecture can grow and extend to meet many different user needs. Imagine this type of architecture flexibility in the line-of-business applications you're working on today.

Imagine you're working for a manufacturing company. A sales person is at your biggest customer's office and they make the decision to place a large order with you and have a very aggressive timeline for delivery. The sales person has a mobile device on which he/she can enter the order information. The data is entered, but their wireless Internet connection is not available right then and there, so the mobile application persists the data locally. As the sales person leaves the customer site, the Internet connection becomes available and the application automatically pushes the data to a service hosted in your company's data center. This service sends the data into the sales system and then forwards it on to the ERP system which queues up the order for production line processing. Production floor personnel, viewing the order via a PC based application consuming the same set of services, can then see the priority of the order and act accordingly.

At the same time, sales managers at your company are getting notifications on their cell phones alerting them to this major deal. At this point, they can send feedback via the system back to the sales person on site, generate reports to get the information to upper management or notify key personnel in the manufacturing part of the company to raise visibility of the ongoing activity.

And there's a good chance that all of this has happened while the sales person is still in their car on their way back to the office.

Hosted services in this case provide a continuity of experience for users at all client endpoints. Client applications are consuming a consistent set of functions and data based on need, priority and the role of the end user. Centralization of service-level functionality provides one version of the truth, instilling confidence that everyone involved in the process if fulfilling the order is working with the correct information in to correct portion of the workflow.

With the ability to leverage computing cycles on the fringe, run effectively in an occasionally connected world and automatically update themselves when new updates and patches become available, thinner clients represent an extremely viable alternative to pure web applications. They leverage what is best about client-side applications with the agility of the of the web to provide an engaging and valuable experience to users.

"Thinner" is the new "fat."

My wife, Maria, manages the health care information for my family. God help me if I am ever in the position of having to tell an ER doctor about what antibiotics my children were on, when they had this or that bone broken, etc., without here there. This got me thinking about a better way to manage all of our important health-related information and was a perfect framework for a recent conversation I had with St. Louis entrepreneur, John Struckhoff.

John is the managing partner of a St. Louis startup called Health InfoSTAT. John and his team have produced a software solution to help manage you and your family's personal health care information, both online and off. In chatting with him about his product, it became apparent that he and his development team have not only designed a commercial grade S+S solution, but had the concept locked long before there was a buzz-phrase around it.

"Software"
John's product is called Solace, and it is a WinForm application built on .NET 2.0. The product is a very easy-to-use data entry application for your family's health care information. Everything from personal and medical emergency contact information to past surgeries to chronic conditions to a history of prescription medication you've been on. It's all there. Each member of your family receives a "profile" with their specific information stored in it. When you've completed entering all the information, the software generates a detailed report that you can print and bring to the doctor's office or hospital with you. And there it is, a comprehensive health history for you and your family. Wouldn't it be nice to not have to complete that long questionnaire every time you go to a new doctor and instead just hand them the report?

So, the first question I asked is, "Why build this as a client-side application instead of a web application?"

John explained that they looked at a 100% web-deployed solution at the beginning, but decided to build it as a "connected client" for a few keys reasons:

• Solid Security Management: While securing sensitive data on the web has come a long way, there are few things in a person's life more sensitive than their health history. Managing and persisting this data inside the client software reduces the number of times it needs to be transmitted across the wire and allows for a customized approach to cryptography and digital signature.
• Offline Capability: John describes his product as being "brain dead simple" to use. He is from the old school of software design that doesn't tolerate any application that requires the user to know anything about the Internet, networking or other technical concepts. In fact, he specifically mentioned that his father, who is in his eighties, is a key tester of the software -- if he can use it, anyone can use it. Solace manages its connection to the Internet and automatically alerts the user when they are trying to do something that requires a live connection. For the most part, Solace is designed to run mostly offline anyway, and when it does connect to services in the cloud, it does so on background threads, allowing the user to continue working on the desktop unhindered.
• Better User Experience: Beyond asynchronous background processes to improve performance, the user experience John was looking for in the software was very difficult to develop in standard web pages. Solace has seamless transitions between data entry screens and modal entry dialogs. While these things are doable with CSS and AJAX, it is a far more thorough and fluid experience on the client.
• Automated Updates: The initial drive to the web was based almost solely on being able to deploy updates quickly and invisibly to the user. To ensure that their client-side solution enjoyed this same benefit, Solace has the ability to perform automated updates. John and his team opted to build an update application so that they could control the software manifest, as well as push product, system and company information to the client.
• Document Management: Solace allows you to reference important health-related and legal documents, such as a living will, power of attorney, advanced directives, etc. Through the client side application, you can manage the location of the electronic versions of these document as well as referencing the location of the hard-copies. You can also view and manage access rights to these documents. Doing this on the web would require that the documents be uploaded and persisted on the web site, which may be superfluous to what the user actually wants.

"Service"
The Solace client experience is impressive in and of itself, and much of that is enabled by the interaction with services in the cloud. For example, the automated updates for the client application compare local file versions with those in an online deployment repository on the server and pulls down only the files that are needed. This significantly enhances the experience for users on slower Internet connections. It also has the capability to pull reference information managed centrally and cache it on the local machine, ensuring that users can add data to their profiles even if an Internet connection isn't available.

They've also created a lot of intelligence around the Internet connection itself, and I think this is an essential characteristic of any S+S solution. The application displays the status of the machine's Internet connection at all time. The process of checking for the connection runs in a background thread, so the status can be updated every couple of seconds without negatively impacting performance on the local machine. Also, keeping the mandate of a "brain dead simple" user experience in mind, the client checks for access to its services before the user is required to do any work that would require the Internet connection to be present. This is a very nice feature in that the user is spared having to enter several pieces of data only to find that they can't complete the task due to the lack of connectivity.

As it turns out, the service component of Solace represents the primary revenue opportunity for Health InfoSTAT. You see, all of the features and functionality I've described thus far is free for anyone to use -- just download and install the software. However, for a very small annual fee ($20 per profile per year or so), you can publish your data to the Heath InfoSTAT servers and make your information available online via the company's web site.

The scenario John outlined goes something like this: Imagine yourself in the emergency room after being in an auto-accident. You're unconscious and the ER staff is beginning your treatment. How would they know that you have an allergy to certain anesthesia's? That you had your gallbladder removed when you were a child? That you're currently on an antibiotic regimen? Leveraging the Emergency Access portion of the Health InfoSTAT web site (which also accesses the company's services infrastructure), medical professionals could access this information and any other pertinent information, including access to important medical and legal documents you have chosen to publish.

So beyond keeping the client software up-to-date, the service cloud for Solace provides a means of accessing your information anywhere on-demand while keeping the management and security model based on the client where it can be best leveraged.

"The Perfect Storm": Flexible Architecture and Outstanding User Experience
The real relevance of the S+S model Solace embodies is that this flexible and responsive architecture ultimately leads to an outstanding user experience. The ability to interact with services in the cloud on background threads creates a truly seamless experience for the user, who, in most cases, won't know (or care!) when the software is pulling data from the service, but will enjoy the fact that something that wasn't available to them a couple of minutes ago is suddenly there in the client ready to be used.

The flexibility of this architecture, especially the ability to push software updates and information down to the individual client, allows the HIS team to be very agile in implementing new features and patches to fix issues. John mentioned a couple of examples where a bug fix was reported by a user, examined by his team, a patch implemented and tested and rolled to the update server in less than an hour. This is the kind of deployment agility normally reserved for web server-based applications.

The important thing to understand here is that the entire web experience is originated and managed on the desktop itself inside the Solace application. This really brings the whole process full circle. In this case, the heavy lifting of the system is located on the high-powered client machine, where CPU cycles and memory abound. The web is a premium service offering, allowing authorized individuals to securely access the information published from the client. All components of the architecture are positioned to take full advantage of the strengths of their respective platforms.

If this sounds compelling, I encourage you to go take a look at the software for yourself. Like I mentioned earlier, Solace is free to download and use on your local machine. The only caveat is that you can transfer the local profile data files to another machine; that is a feature reserved for folks who subscribe to the service. If you check it out, I'd like to hear your thoughts on how the application work. I was drawn to this software because of its architectural implications, but I like that John and his team are focused not only on helping people manage their health care data better, but Solace might even save a life someday.

Note: This is a repost of a piece I published last October that received a lot of attention. The only updates I've made are to make it temporally correct.

I was talking with one of my colleagues yesterday about Popfly. He'd heard of it and had a general idea of what it was all about, but was looking for more. I had been going on for awhile (as I am prone to doing from time to time) about how cool Popfly was and how it gives non-technologists an opportunity to use their creativity in building interesting composite applications.

The he asked me, "What do you think the relevance of Popfly is outside of the 'Wow, this is cool' market?"

I hadn't really thought about that. I mean, creating a mashup with Virtual Earth and Flickr to let people see where you took your photo and then actually look at them is fun, but what untapped value might be there for businesses?

SOA As It Is Today

I've spent the last several years of my career espousing the merits and benefits of the service-oriented approach to system architecture. While the idea itself isn't all that new, the technology we have at our fingertips these days is the component that was missing with prior attempts at making SOA practical.

The concept of implementing SOA in the real world has always been centered around identifying key business processes and capabilities and designing services to address them, while, of course, following the tenets of SOA, i.e. platform agnosticism, standards-based implementation, etc. Once these services are deployed, an organization's architecture group plans for how to extend these services, as well as how to leverage composite services which compose multiple fine-grained services. For the most part, developers were responsible for building the business applications that consume the service infrastructure. So, in the end equation, the IT organization controlled the design and development of the SOA and the line-of-business applications that consumed it. This can lead to obvious tension between the user base and IT, as well as stretching the valuable resources of the IT group very thin. Users tend to be unhappy with IT's performance, and IT's morale tends to be low, as they are always being asked to do more with less on shorter time frames.

Enter Popfly...To the Enterprise!

Popfly is a tool that allows users to visually design composite applications using so-called "services in the cloud." Each gadget in the Popfly tools frame represents a service out in the world somewhere that can be easily clicked and dragged onto the design pallet, configured and "mashed" with other services to produce one application. This application might enjoy long-term use, or it could be fulfilling an ad hoc need. Either way, the application is built quickly and done so without writing any code.

Now let's make a "mashup" of our own: Combine Popfly with a well constructed SOA inside the enterprise. What might that look like?

Imagine giving your business customers the ability to view a tool box of service "gadgets" that they simply drag into a design space where they can mash data together and build their own line-of-business applications on their own.

This would be a tremendous step toward empowering users to more fully leverage IT assets within their companies. The benefits would include:

• Happier Users: I have to believe that, in most organizations, IT and the rest of the business don't skip merrily through a field of flowers together, holding hands and signing happy songs. In most cases, the business has huge requirements on short time frames and limited resources, and IT has to try to make it work. While this approach won't necessarily resolve this tension (I'm sure it can ever be truly resolved), letting users take a "self-serve" approach to addressing some of their own software needs, should go a long way to taking some of the pressure off already stretched IT teams.
• Happier Architects: The hunt for the ideal value proposition for SOA would be achieved. When SOA becomes the foundation of most of the line-of-business applications in your company, the value and ROI become far easier to measure and realize.
• Happier Developers: This might be a bit contentious. I mean, it could be argued that this whole thing could cost developers their jobs by reducing their relevancy in the company. I would argue, however, that this would take a lot of the menial development projects off of their plates and let them focus on the big, meaty, interesting projects. You see, this idea isn't a silver bullet solution. Using a Popfly-like application to mash some services together will take care of the "I need it now and I need it once" kind of requests IT gets from their users. In any sizable organization that significantly leverages technology to run their business, there will always be a place for more advanced applications and systems. And, thus, there will always be a place for developers, but developers focusing on the more challenging projects.

I should point out that in no way, shape or form has anyone from Microsoft suggested to me that this is even on the radar screen. I think it would be interesting to take the "cool" and "fun" technology that is Popfly and make it something that could provide real value to business in their everyday work.

What do you think?