Hallmark Cards released a new web slice for Internet Explorer 8 to the IE Add-ons Gallery last week that will make it extremely simple to remember the birthdays, anniversaries and other raisons de célèbre in your life. This slick little slice integrates with your Facebook friends list and provides you with a list of the next ten special events coming up. From the web slice, you can write on your friend’s Facebook wall, send them a Hallmark E-Card or even order them a “print-on-demand” card that you can design and that Hallmark will print and mail for you.

From the technological perspective, web slices are not difficult to develop. They are built just like any other web application, but they are tagged in a web page by a specific set of HTML that tells IE8 that this content is “sliceable.”  In this case, the web slice is obviously integrated with the Facebook API, but another interesting feature is that the slice will also call out major holidays and integrate them into the list. This is provided by a secondary service, showing you how you can build really useful mash-up style applications leveraging multiple background services. Rather than dive into the details of how to develop add-ons for IE8, I’ll refer you instead to my colleague, Jon Box’s, blog. Jon has written several extremely useful posts over the past twelve months showing how to not only build web slices, but accelerators and visual search providers as well.

From a business and marketing standpoint, IE add-ons make all the sense in the world. I mean, the Hallmark web slice is a great example of providing not only a cool and useful application for customers, but it also lives in the link bar inside the browser, allowing their customers to check on their special events at any time, regardless of the web site they are currently on. It provides a very non-obtrusive way to provide your company’s specific products and services to customers while maintaining brand ubiquity in a piece of software in which users spend the good majority of their time each day: The web browser.

The best way to get the web slice is to visit the IE Add-ons Gallery. Since you need to connect the slice with Facebook, there is a two-step installation process, but it’s pretty easy and intuitive. I’ve been using it since it was released last week and I find myself checking it every day. See what you think.

The ongoing economy unraveling is the defining moment of our time. Many professional developers are fearful for their livelihood, as employers and customers cut and slash development plans, and as economic activity grinds to a halt.

But not everywhere.

In centers of technical excellence and innovation such as the Silicon Valley, the major players, from investors to industry leaders, are aligning themselves with the next boom in software, a field Juval Lowy calls the Energynet. Alternative energy covers a wide range, from new cars, to micro renewal sources energy producers, infrastructure upgrades to charge stations and distribution, new power and transformation grids, and integration of billing systems, let alone commercial building and homes modification. And the key for making all that work is software. We simply cannot make the physics or the chemistry substantially better, but we can profoundly integrate systems, iron out inefficiency, automate and vertically integrate energy trading, production and consumption; and the key to all of that is great software. This massive new software system is the Energynet, and the analogy to the Internet is a good one - instead of packets and request the Energynet transfers watts and usage data, connecting anything and everything in the energy market. In this unique session, Juval Lowy presents the case for the next boom in software, shares personal observation and perspectives, and points out the skills and expertise required of developers that want to not only survive but thrive on the next boom in software.

Be sure to check out this compelling interview conducted by my colleague Bob Familiar.

The first time I saw Ron Jacobs talk about service-oriented architecture was at Microsoft TechEd 2004. He did a talk with John Devados and it was the first time I can remember someone talking about services in a way that made sense to me as a developer as well as an architect. It seemed that every time I went to see a talk on SOA, I was looking at a lot diagrams of clouds with lines connecting them to other clouds. Any questions about the practical application of services was met with the answer, “Well, it depends.” Ron was the first person I ever saw who offered real, prescriptive guidance on how to design and implement properly factored services, and it had a big impact on how I’ve approached SOA ever since.

Beyond being an in-demand conference speaker, Ron is also the creator of ARCast.tv, the show that I and several other architects at Microsoft got the chance to co-host just a little over a year ago when Ron moved-on to become a technical evangelist for the Windows Communication Foundation and Workflow Foundation product teams. Heck, I even had the opportunity to do an interview with Ron back in 2006 at the Microsoft National Architecture Forum in Vale, CO.

In our newest episode of ARCast.tv, Ron gets to sit in the interviewee seat and talk about some of the key differences and benefits of SOAP-based and RESTful services, and how Windows Communication Foundation supports the implementation of both types of services.

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: Dictionary.com 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
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!”

For those of you who didn't get the memo, Ron Jacobs is no longer hosting the very popular Channel 9 show, ARCast. After spending a couple of years traveling the world talking to hundreds of practicing architects, Ron decided he needed a change and is now a Technical Evangelist in Redmond working with the WCF and WF teams.

Because of the popularity of ARCast worldwide, I and a small team of fellow architects from across the country have been working over the past several months to bring into being what we're calling, "ARCast 2.0." Instead of having one regular host on the show, any architect evangelist in the world that has a story to tell and is willing to sit down and record it can be the host of an ARCast episode.

We published the first official episode of ARCast 2.0 last week. My colleague and good friend Bob Familiar sat down with Simon Guest, Senior Director of the Platform Architecture Team at Microsoft, and had a great conversation about what his team does and what types of content and activities his team will have for the community in the future. If you haven't had a chance to watch the interview yet, you can watch it here.

And this week it's my turn.

A few weeks ago at TechEd Developer 2008, I had an opportunity to sit down in the TechEd Online "fishbowl" and have a conversation with Juval Lowy about his ideas concerning interface-based design in software. Any conversation that starts with, "Object-orientation has completely failed us," is going to be a good one.

You can watch the full ARCast video here:

ARCast.tv - Juval Lowy on Interface Based Design

If you never want to miss an episode of ARCast, then be sure to subscribe to the show's feed here. Please let me know what you think of the interview.

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

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?