We want to grant you unparalleled access to the torrent of new technology that we have been releasing since the first quarter of this year. We have spent 3 years completely rebuilding our technology stack from the ground up and we’re ready for the whole world to have a look.

Front and center is the Infinity, the Rich Internet Application (RIA) platform that powers two of our shipping products Blackbaud Enterprise CRM and Blackbaud Direct Marketing. We think it’s so cool we have posted a link on labs.blackbaud.com so anyone out there can take it for a test drive.

Expect to see a lot more on the labs. Oh, if you are a developer — stay tuned, we’re about to knock your socks off

Have fun!

Is that Linux? Yep.

So, as we exit one of the most intense R&D cycles in the 18 years I’ve been at Blackbaud, I took some time to reflect back on our initial goals for the platform and do a little internal report card of sorts around how I think we did. I won’t bore you with the details, or maybe I will in another post, but for now I’d like to look at one place where I give the team an A+.

You didn’t think I was going to blog about the “B” grade did you?

Goal: Embrace web standards to maximize interoperability

I know, it’s a mouthful, but I can’t figure out how to put it any more succinctly. Two years ago it was obvious to the team here that we needed to be web delivered and if we were going to be web delivered we should use as many standards-based technologies as possible.

Larry’s Linux App

This was important to us particularly in the area of how we exposed our API stack. We decided on using SOAP-based web services to support our API and extensibility models. Interestingly, we have also sprinkled in REST-based access to the services as well, but in general we are a SOAP shop. It wasn’t as if we were making some visionary choice. Our core applications are built on Microsoft SQL Server 2005 and ASP.NET 2.0 using Microsoft Visual Studio — we are a Microsoft shop — and Microsoft plays real nice with SOAP. Seriously, Microsoft did a great job with their development tools plumbing SOAP into the deepest levels of the platform, safely abstracting the developer away (well only if you want to be) from the gory details of the actual XML messages, wire format, WSDL etc. Our real visionary architectural decisions were made around how Infinity exposes all of it’s data and functionality via web services, with zero compromises.

“Let’s see just how platform agnostic the API is. Let’s build something on Linux”

That’s what I said to the team. So, as is always the case with the folks on my team, a developer jumped at the challenge. I have the luxury of having a brilliant team of developers here, so it was no surprise when two days later, Larry showed up at my door with a working application. The Apache/PHP based application provides basic search an record management capabilities by using the web services APIs exposed by our Infinity platform. It really was a proud moment, one that made all the rigor and discipline that has gone into building the Infinity platform *totally* worth it. I love when a plan comes together like that.

Two worlds, two totally different flavors of Kool-Aid, one application. It was borderline heresy in the Microsoft worshiping halls of Blackbaud — and it worked great.

Grandma to the rescue

Grandma’s LAMP

Initially, we were all so clueless about Linux it was comical. Picture three nerds poking and prodding at a computer with quizzical looks, not knowing where to start. It was a true “showing fire to the natives” type of moment. So, we did what anybody would do, and typed “Linux for my grandma” into Google. Bingo! Within minutes we had a Linux VM even the Blackbaud team could use! OK, so maybe I took some creative license on how it went down, but that’s pretty much what happened. Really.

Grandma’s LAMP was the perfect tool for the job — a pre-built VMWare image with the LAMP stack, samba, Firefox etc. All there and ready to use. The fact that Larry was then able to build a super-clean PHP wrapper that made it trivial to exercise our API from PHP and then build what he did in two days was proof enough for me that the mission was accomplished.

PHP Meets Infinity

2007 is going to be a fun year. If you see me at a conference some time please ask me to boot up ole Granny and show you what I am talking about here. We’ll include it in the Infinity SDK as well. Sure, this
was an exercise and proof of concept, but maybe someday Larry’s code will help somebody solve a thorny integration problem with our systems and some other application out there in the cloud.

Thanks Grandma!

But a huge part of facilitating processes involves communication among people and departments. I’m wondering what we can do to better allow users to communicate with each other through our products? And where would this type of functionality be most useful? We’ve already taken steps in this direction in specific areas - Major Giving cultivation, for example, where we’re looking to improve the ability of fundraisers and their managers to communicate progress and status on their prospects. But I think this is an area we can explore further and really take advantage of some of the newer tools available to us.

It seems like there are some key characteristics of situations where in-product collaboration would be most useful:

• The specific context lends itself to questions, clarification, and a general discourse on the value, interpretation or significance of what is being shown. Obviously, part of this characteristic includes the need for multiple people to be interested in the context.
• There is some value in being able to capture this conversation in a centralized place and in close proximity to the subject of discussion.
• The relationship and proximity of the people involved encourages online communication. People who share a cube are less likely to use something like this than are people who are spread across departments and separated by some distance. Probably more value to larger organizations than in smaller ones.

Examples where in-app collaboration might be useful include:

• KPI dashboards and other reports - this type of data display can immediately provoke questions, clarification and discussion around its meaning and implications. Why is this trend happening? Can we expect to make this goal? What events may effect the future of this data? An ongoing discourse of this kind if very healthy for an organization, and could further enrich the usefulness of this type of display.
• Major giving cultivation - all of the intricacies involved in cultivating a prospect are often difficult to capture in a set of pre-defined fields. Ongoing conversations about the propensity and inclination of prospects could potentially be managed through in-product collaboration features.
• Event management - planning large events takes a huge amount of communication, and decisions are made quickly constantly throughout the lead-up to the event. Centralized management and documentation of the decision-making process could help ensure that decisions are communicated clearly and people don’t spend time repeating past discussions.

Relative to other more prescriptive features, in-product collaboration solves an “ill structured” business problem. In some ways, we may not know how (or if) users would employ it until it is in actual operation. How might this type of feature fit into your organization? Do you see opportunities for improving communication through in-product collaboration?

These were existing RE users, so our hope is that they were just reacting to a change in the pattern they’ve grown accustomed to. But “they’ll get used to it” always makes designers really uneasy. Will they? How can we be sure this was an issue of familiarity and not a fundamental design flaw?

We’ll continue to test this issue with both RE and non-RE users, but I think this highlights the reality of user feedback and decision making in the design process. User input is one of several tools designers have at their disposal to help make the tough decisions, including design patterns, design principles, usability heuristics and personal experience. All of these are invaluable resources for informing the design process, but rarely do they make design decisions crystal clear. They are all very open to interpretation. In the end, it is still up to individual decision makers to make the “right” call based on the information they have.

For this reason, the real power in user-centered design comes not from a few usability tests and design heuristics, but from the development of a culture that puts a priority on user experience and encourages an ongoing, iterative process of feedback and refinement. This process doesn’t end when a product is released - existing features should be constantly re-evaluated and every new customer treated as another opportunity to evaluate your design decisions. Through these ‘layers,’ the experience becomes more and more refined:

When your decision makers are making user-informed, skillful design decisions, the difference between these levels are minimized. The process is then allowed to focus primarily on adding efficiency and smoothing out rough edges while functionality is gradually expanded. And when changes are required, this isn’t seen as a failure, but as a natural part of the design process.

Paul Crowder (the dev) has been working on implementing platform-level support for KPIs (Key Performance Indicators) in our upcoming Infinity application platform. KPIs will be featured throughout future applications built on the platform (Galileo, RE8, Bullseye etc.) Apologies for all the code names, we’ll cover those in a future post.

What are KPIs?

KPIs are quantifiable measurements that reflect the health of the organization. By quickly scanning an organization’s KPIs one should be able to get a solid idea on how things are tracking against the defined business goals. Some examples might be:

• Response Rate for a direct mail segment
• Number of gifts per day
• Avg days to close a major gift
• Gifts This Month
• Cost Per Dollar Raised

Those are just a few samples, but each one represents a single value that could be calculated and compared vs. an established goal.

Infinity’s KPI Platform

Editing a KPI Definition

Infinity’s base platform support provides the following for KPIs:

• A framework and UI for establishing, securing, and managing KPIs.
• A way to express a goal for a KPI.
• The ability to define warning and alert zones for a KPI as it progresses toward or deviates from it’s goal.
• An automated process to calculate KPI values and cache those values for quick rendering at a later time.
• A mechanism to back-calculate KPI values to establish historical trends.
• RSS support for KPI values so they can be monitored without running the application and logging in.
• A personal dashboard that can be customized by an end user to display the most important and relevant KPIs as the user sees fit.
• The ability to view the dashboard outside the application from any web browser without having to log in and navigate the application (assuming the user is authenticated).
• A stock set of KPI calculations “in the box”.
• Advanced support for creating custom KPIs using an open, extensible XML specification. (you’ll be hearing a lot about “specs” in the Infinity platform as I discuss it in future posts…)

A KPI Dashboard in “Galileo”

An Infinity-powered application presents a user interface that allows organizations to define their KPIs and have the system constantly calculate them based on the data as it flows in. Typically, you would sit down with leaders in the organization, agree on your KPIs and goals and then setup the KPIs in the system using a very simple user interface. There is even support for back-dating them so you can have a look at quantifiable results from the past, which can be a useful benchmark from which to build on as you define your unique set of KPIs and goals. Then the fun starts.

Once the KPIs have been defined they can be featured wherever you like inside and (here’s the killer part) *outside* the system! Infinity support syndicating KPIs and alert mechanisms via auto-generated web pages, RSS feeds (which can be consumed directly by IE7 and feature rich support for sorting and filtering), and even via directly accessible AJAX-friendly web service end points! The key point here, is since we are building all this stuff using standard open technologies like XML and Web Services, there is simply an explosion of interoperability and reach scenarios. What “the Pauls” showed me today was a great example of leveraging that power. So, let’s talk about what they showed me…

Technology Converges on the Windows Vista Sidebar

Windows Vista has added a really nice feature for displaying graphical gadgets directly on what is referred to as the sidebar. Its a nice unobtrusive way to have important information featured on the the desktop. For example there is a little weather gadget that gives a graphical cue and some other info about the weather conditions at a given location. I guess you could say a Sun is a good KPI and a Rain Cloud a bad one. Interestingly the sidebar supports using standard Dynamic HTML and JavaScript to build custom gadgets. When the team was discussing scenarios we wanted to support for KPI reach, we all got excited about the possibilities here. Remember when I mentioned that Infinity exposes it’s KPI data as an AJAX-callable endpoint? Well, add one part Vista, a little JavaScript/AJAX to call Infinity, some Dynamic HTML to present the user interface and whammo, you have KPIs on the desktop. Sure, when we release this it will look prettier (the current rendering is placeholder art) but I think it’s pretty cool.

The true payoff of using open, standard technologies really is exciting. When I think of all the mash up scenarios we’ll be poised to support it puts a smile on my face. And if all this technology helps you improve the reach of information, whether it be to your boss, your board, or even your constituency I hope you’ll be smiling too.

• quantitative (lose 20 pounds!) or qualitative (eat healthier!)
• subjective (be a better person!) or objective (spend 10 hours a month helping out my favorite charity!)
• personal (appreciate the little things more!) or altruistic (make the world a better place!)

…but they are things that challenge us because they challenge our ability to overcome our limitations, our conditioning and our environment.

Of course, I’ve got my list of personal resolutions…..drop 20 pounds, finish the Cooper River Bridge Run in under 50 minutes, and complete a lengthy list of home improvement projects….just to name a few. However, I thought it would be an interesting exercise to try and come up with a New Year’s Resolution that has an impact on our Products team at Blackbaud and, by extension, the products we deliver. While surfing the web looking for some ideas, most of what I found centered on resolutions like “write more reusable code”, “comply with web standards” or “do more usability testing”; all worthwhile goals, but they didn’t capture my imagination or feel like what I was looking for.

Eventually, I came across an article discussing New Year’s Resolutions and “Deficit Thinking”. The article defines Deficit Thinking as “an ingrained habit of focusing on gaps and weaknesses instead of what’s working” and goes on to talk about the value in avoiding it and provides some strategies to help avoid it. The article itself may be a little too Stuart Smalley and doesn’t specifically apply the concept of Deficit Thinking to software development. However, the basic definition of the comment did strike a chord with me. Much of what we do in developing software necessarily involves Deficit Thinking;

• Product Managers and Business Analysts study gaps between what our products do and what our clients need them to do (or what our competitor’s products do!).
• Developers work to ensure that all of the product requirements are satisfied in the code they write and try and figure out why their code won’t compile or pass unit tests.
• Quality Assurance Engineers demonstrate the creativity of Van Gogh (for the QA people out there, that was a compliment, not a comment on your mental stability!) in devising test plans designed to identify gaps between what the product does and what the Business Analysts said it should do.
• Usability Engineers exhaustively test our products for ease of use and collect reams of data that point out where they are substandard.

It’s not a stretch to say that a software development team simply can not function without a culture deeply rooted in Deficit Thinking. That said, I think that providing truly compelling products and solutions to our clients requires an ability and willingness to balance this mindset with one that keenly recognizes how and where our product features provide value to our clients and seeks opportunities to build on that value or apply that value to new challenges. This type of “Opportunity Thinking” (for lack of a better term) provides a valuable complement to skills we all bring to the process of building products by focusing that process on maximizing the value we provide to our clients rather than towards satisfying a list of requirements.

So, there you have it, my New Year’s Resolution for Blackbaud products:

To balance “Deficit Thinking” with “Opportunity Thinking” by recognizing the value that our products provide and thinking of new ways to enhance that value and apply it to the challenges our clients face.