An "Autopsy" on SOA

by dboynton 1/15/2009 2:44:00 PM
au⋅top⋅sy  [aw-top-see] noun
  1. inspection and dissection of a body after death, as for determination of the cause of death; postmortem examination.
  2. an analysis of something after it has been done or made.

Source: Unabridged (v1.1)

On Monday, January 5, 2009, Anne Thomas Manes, a well respected analyst at the Burton Group, wrote a post on her blog pronouncing SOA to be DOA. My colleague, Hanu Kommalapati, brought the post to my attention and I was getting ready to dig in my heals and put up a fight. Once I read Anne’s post, I found that not only was a fight unnecessary, but that I agreed with most of her points.

Seeing that SOA has been one of the most visible and widely talked about technology initiatives of the past decade, the fact that it has been pronounced “dead” would seem to require an autopsy to determine the cause of death and discover any foul play that might have been involved in its untimely demise.

Positive Identification
Sudden depature Before we begin, we need to make sure we know the identity of the corpse. For the context of this discussion, we’re talking about “SOA,” not “service-oriented architecture.” “Aren’t those the same thing?” you might ask. Again, for our purposes here, I’m going to make the following differentiation.

Service-oriented architecture is a technical philosophy combined with a practical approach to building distributed, loosely-coupled systems, focused on business capabilities that embody (no pun intended) the following four tenets:

  1. Boundaries are explicit
  2. Services are autonomous
  3. Services share schema and contract, not class
  4. Service compatibility is based on policy

In other words, service-oriented architecture represents the best practices for building services and the systems that consume them. Fortunately, service-oriented architecture is alive, well and thriving in new ways thanks to cloud computing and software + services, but more on that later.

SOA is the ubiquitous panacea presented and re-presented over the course of the last ten or so years, a business cure-all that has generated a lot of hype and attention, but few tangible, measureable results. At some point in the middle part of this decade, SOA extended far beyond simply building a solid service-oriented infrastructure. It began to involve things like governance councils, enterprise service busses (ESBs) and a myriad other things. It was a simple, eloquent concept made huge and untenable.

“SOA” is the body on the table, so let’s begin.

Cause of Death #1: Morbid Obesity
It’s not only becoming the primary cause of death for people in the United States, but it’s also the number one reason SOA projects in the enterprise fail. Over the years, the term SOA has gained a reputation as being a kind of magical elixir, capable of curing bleeding budgets and making IT organizations young and virile again. It has been pitched by good intentioned people to be the ultimate solution for solving system integration challenges and as a holy grail of enterprise reuse. Additionally, many of the top industry analysts and journalist were saying very much the same kinds of things. These factors created a lot of top-down interest in SOA within large corporations, which means that there was a lot of money being put behind trying to implement SOA.

How do I know this? Well, I was one such “good intentioned” person.

A few years back, prior to my joining Microsoft, a group of fellow architects and I set out with the intention of trying to make things better for the IT organization in our company. We started out with a simple, self-imposed charter:

  • Create a set of best practices for designing and developing services for software project teams
  • Develop a means of making deployed services visible to project teams
  • Evangelize service-oriented architecture to project teams, creating a common understanding of the principles and a specific context for our business

A simple, tactical approach, nes pas?

After awhile, management got wind of what we were working on and wanted to officially mandate the effort to ensure we were putting something together that would truly serve the entire organization. Once that happened, we found it impossible to keep our effort lean, tight and focused. The small group of five people that started the effort soon “blossomed” to eighteen people, with extended optional members, most in upper management, that would chime in when they felt it necessary.

Suddenly, we were trying to solve huge strategic problems with SOA. We were tasked with standardizing  processes across several departments and business units. We were talking to dozens of people about services that would standardize key business capabilities in their part of the company. We were developing taxonomies, dictionaries and registries to manage an eventual service environment. We were talking about governance standards and protocols and trying to answer questions like, “How do you get services approved for enterprise use?” and “How do you submit your service for deployment into the enterprise infrastructure?” and “What is your SLA for the service and who owns it?” and “If that group owns the service, who owns the SLA for the underlying data?” And while we were doing all of this, we were not doing one very important thing: Designing and developing services.

Fifteen thousand empty calories a day, and suddenly our initiative was obese and hypertensive.

While this specific situation comes from my personal experience, I by no means think it’s unique. I’ve seen and heard this same story time and time again. Activities that would be absolutely ludicrous in a typical software development project become commonplace as soon as we start talking about SOA. The result is good intentioned people get mired down in politics and alternative agendas until the effort as a whole finally collapses under its own gargantuan weight.

Cause of Death #2: Cultural Shift Syndrome 
The SOA effort of which I was a part was similar to other failed efforts for another key reason: The focus tends to be on the technology, not on the people and culture of an organization.

In general, services are not complex or difficult to build, deploy and manage. However, implementing SOA in the enterprise requires a different way of thinking about enterprise software development. Developers, architects and project managers have to begin thinking about the development process in a more holistic way. They need to include existing services in their system design while looking inward to determine if there are new services their project can produce to benefit the organization.

In general, this is fundamentally different from how just about every enterprise IT shop in the world operates, where projects are funded by customers, either internal or external, and project managers work a project to that level of funding. Being responsible for using that customer’s money responsibly causes project managers to focus on the requirements of their project exclusively and incents them to minimize risk at all costs. Relying on services outside the team’s control introduces risk and could, therefore, be discouraged or even banned by project managers. This, in turn, encourages the creation of multiple siloed applications sprinkled throughout the company. Ultimately, this might work very well for individual customers, but makes a cohesive and cost efficient enterprise architecture impossible.

The bottom line is that technology is pretty simple to change, but changing people is extremely hard, especially when the funding model of an organization provides incentives against sharing and collaboration. Trying to approach the classic view of SOA in the enterprise presents the non-trivial challenge of trying to modify an organization’s culture and long-held opinions and policies about how it does it’s day-to-day business. If this fundamental change is a requirement for SOA success, then most initiatives would be over before they began.

Cause of Death #3: Bad Medicine
I remember once sitting in a conference room with my SOA team listening to a major software vendor (whose name I will not mention because I have shame, even though they didn’t) explain that they were there in the hopes of “selling us SOA.” After I finished my fit of laughing and asked for clarification, they stated that, by buying their suite of SOA software, we would have everything we needed to implement an SOA. This wasn’t unique to that vendor either. Many big name companies were actively engaging customers purporting that implementing a SOA was a matter of buying software licenses and/or hardware from them.

This, of course, is ridiculous, but was demonstrative of how crazy things had gotten in the SOA world. Certainly, third party software had a role to play in helping an organization build and manage a service-oriented infrastructure, but the idea that it was all that was needed was disingenuous at best, fraudulent at worst. The truly unfortunate part of this was that many companies looking to streamline their path to SOA goodness purchased these products and services only to find that, in the end, they still had most of the same problems they had at the outset, now they just had better visibility and reporting for them.

The end result was that companies often spent millions and took months (or even years) to evaluate, purchase and implement these SOA solutions. In today’s economic climate, it’s little wonder that many of these companies are drastically reducing their SOA initiatives or simply throwing them out, chalking it up to experience and moving on to other, more pressing things.

SOA: Dead, or In a Coma?
So, now that we have identified the leading causes of SOA’s demise, we need to ask the question, “Is SOA really dead or simply in a coma due to blunt force trauma to the head?”

Honestly, I have concerns about making the proclamation, “SOA is dead,” because what it stood for at its inception was not only good, but still very relevant today. Seeking to build a loosely-coupled enterprise service layer deriving from key business capabilities as part of a larger IT infrastructure is a good idea and at the heart of what SOA once stood for. By pronouncing SOA dead, I do not want to give people the impression that this vision and perhaps even services themselves are dead as well. The service-oriented approach to software development is not only still alive, but gaining momentum and expanding in the form of cloud computing.

Services are also vital to perhaps one of the most important trends we’ve seen in technology in quite awhile: Software + Services. Again, one of the major misperceptions about SOA was that services in and of themselves would solve all of IT’s problems. The S+S approach to architecture provides a model that uses services to augment client applications running on potentially multiple platforms and using a plethora of technologies. This model has the potential to provide huge benefits to companies, leveraging a services layer to provide commonality of key business capabilities while fully utilizing the power and versatility to deliver those capabilities on clients throughout the enterprise.

Instead of pulling the sheet over SOA’s head and sending it to the morgue, I propose that we look at SOA like it has been in a deep coma, at the mercy of forces operating all around it, and recently woke up with amnesia and is starting anew, getting back to basics. As SOA leaves the hospital and starts to reintegrate with society, it should stay focused on its core principles:

  • Stay Tactical: It’s far too easy to start out trying to make a bowl of soup and end up attempting to boil the ocean. Focus on activities that deliver real solutions to development teams. The time to take a larger, more strategic view will be obvious when it arrives.
  • It’s About the Services, Stupid: Related to the first item, keep your focus on designing, building an deploying good services in your environment. As an organization, seek to find a way to catalog and expose the availability of different services to reduce functional redundancy and increase reuse and consistency.
  • Focus on Architecture: Building reliable and extensible system architectures is hard, and no silver bullet exists from any software vendor that will supplant the need to think hard about the services in your environment and the role they should an can play to software development in your enterprise. Always remember that good architecture is platform independent.
  • Evangelize…Gently: You will never have 100% success in getting people to think in terms of services. Become an advocate and help people understand the benefits of service-orientation without setting mandates or imposing policy. Success with tactical level services over time will eventually lead to policies that make sense and everyone can live with.

Ms. Mannes summarizes these suggestions nicely in her post:

But perhaps that’s the challenge: The acronym got in the way. People forgot what SOA stands for. They were too wrapped up in silly technology debates (e.g., “what’s the best ESB?” or “WS-* vs. REST”), and they missed the important stuff: architecture and services.

So I say: “The old SOA is dead; long live the new SOA!”

Currently rated 2.0 by 42 people

  • Currently 2.047619/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: ,

Architecture | SOA | Software Plus Services

Software Plus Services Recap and Resources

by dboynton 7/29/2008 12:13:00 PM

First, I'd like to thank everyone who came to my talk last night at the St. Louis .NET User Group meeting. I was nice to see so many people from the community come out and support this group. I hope that my presentation helped clarify what software plus services really means from and architectural and development standpoint, as well as providing you with some ideas on how you might apply some of these principles to your work as well.

As promised, I've uploaded my deck from last night.

There was also the matter of the Day In the Life... video that I showed, but could not get the sound system to work. So, since we spent some time last night talking about the Silverlight Streaming Service, I went ahead and uploaded the video to the service and embedded it below.


By all means, feel free to comment or send me an email if you'd like to talk more about S+S.


Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: ,

Architecture | RIA | Software Plus Services

Luminary David Chappell Touring the Central Region This Month

by dboynton 5/8/2008 12:44:00 AM

DavidChappell2 Industry thought-leader David Chappell will be visiting four cities in the central part of the country throughout the month of May to present Undestanding Software + Services: A Perspective. David's talk will provide a clear explanation of what an S+S approach to architecture really looks like, an overview of building software with hosted "services in the cloud," as well as the tools and guidance Microsoft is providing to help development teams be successful in developing S+S oriented solutions.

David will be speaking from 1:00 PM to 4:00 PM in the following cities on the following dates:

Location Date Registration Link
Southfield, Michigan May 13th [register]
Bloomington, Minnesota May 15th [register]
Downer's Grove, Illinois May 20th [register]
Houston, Texas May 22nd [register]

David is Principal of Chappell & Associates in San Francisco, California. David has been the keynote speaker for dozens of conferences and events in the U.S., Europe, Asia, Latin America, and Australia. His popular seminars have been attended by tens of thousands of developers, architects, and decision makers in forty countries. David’s books have been translated into ten languages and used regularly in courses at MIT, ETH Zurich, and many other universities. In his consulting practice, he has helped clients such as Hewlett-Packard, IBM, Microsoft, Stanford University, and Target Corporation adopt new technologies, market new products, train their sales staffs, and create business plans.

I am coordinating David's tour through this part of the country. If you have any questions about the event or have any problems registering, please drop me an email or leave me a comment below.

If you've never seen David Chappell speak, you won't want to miss this opportunity to see one of great luminaries in the industry talk about one of the most exciting topics in software architecture today.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , ,

Software Plus Services | Events | Architecture

Health InfoSTAT Case Study on Software Plus Services Now Available

by dboynton 3/21/2008 11:03:00 AM

logoSolace A few months ago, I wrote a post about a St. Louis start-up called Health InfoSTAT because they adopted a software plus services approach to developing their inaugural product offering, Solace. Basically, Solace is a personal health record management application that allows you to create and maintain profiles for you and members of your family. Downloading and using the client software is free and, for a fee of about $20 a year, you can publish your information securely to Health InfoSTAT's hosted services and make the information available to medical professionals whenever it is needed.

I thought their story was different because their business model evolved around their architectural model of software plus services. That is, they are creating several free client applications available for multiple platforms and devices, most of which are fully functional and stand-alone. Then, for an annual fee, customers can then subscribe to Health InfoSTAT's hosted services and significantly extend the functionality of the client software.

Anyway, Microsoft decided to do a case study on Health InfoSTAT and published it earlier this week. If you've been intrigued by the concept of software plus services but have struggled with the business value proposition, I highly suggest you give it a read.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: ,

Software Plus Services

Software Plus Services and the "Thinner" Client

by dboynton 3/15/2008 2:14:00 PM

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
Financial Analyst Meeting 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
TwhirlThe 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."

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: ,

Mashups | SOA | Software Plus Services

FedEx Joins Bill Gates on Stage at the ODC

by dboynton 3/7/2008 6:44:00 PM

For those who've followed my posts on this blog in the past, you know that I'm a strong proponent of the so-called "software+services" model of software architecture. In fact, I highlighted a start-up last year that has found a very creative way to build a business model around what is normally a pretty technical subject.

One of the reasons I feel so strongly about S+S is that, by moving functionality that really belongs on the client machine, the overall performance of the application can be enhanced as well as providing a better, more familiar software experience for the user. This can be especially true when a custom application is delivered via Microsoft Office. I mean, let's face it, most information workers spend the vast majority of their day in Outlook or Excel, right? What could facilitate a better user experience than letting these users access your custom line-of-business applications in these applications? It creates a seamless experience and can truly make people more efficient in their work.

On February 12th, two of my esteemed colleagues, Jon Box and John Mullinax, were in San Jose, California for the Office System Developers Conference where FedEx Corporate VP, David Zanca joined Bill Gates on stage to talk about their delivery of QuickShip as an add-in application to Microsoft Outlook. For the full story, John has a great write-up on his blog, including a video of Bill's keynote and an overview of the QuickShip solution.

I think this is a tremendous example of how far customizing Microsoft Office applications has come. Please understand, I've written my share of VBA macros over the years, and the scars have never really healed. But I can tell you definitively that the landscape has changed 180 degrees with Visual Studio 2008. The Visual Studio Tools for Office (VSTO) is completely integrated into the IDE and building rich applications in Outlook and/or Excel begins by just creating the project. That's it!

I'll be following-up in the coming weeks on more news from the S+S world and rest assured, Office Business Applications (OBA) will be a big part of it.

Congratulations, John and Jon.

Currently rated 1.5 by 36 people

  • Currently 1.472222/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , ,

Software Plus Services

Real Life Software + Services: Health InfoSTAT

by dboynton 3/7/2008 6:35:00 PM

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.

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.


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.

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

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: ,

Mashups | Software Plus Services

Powered by BlogEngine.NET
Theme by Mads Kristensen

About the author

Denny Boynton Denny Boynton
Microsoft Architect Evangelist by day, wannabe rock 'n roll star by night! Want more? Here's my bio.

E-mail me Send mail

    follow me on Twitter


    <<  August 2015  >>

    View posts in large calendar

    Recent comments



    The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

    © Copyright 2015, Denny Boynton

    Sign in