In practice, most programmers are not used to supporting multiple processors, so the software they write can only take advantage of a single core. This means all that extra processing power sits idle. Fortunately, the Spring team, along with the rest of the Java community, has come up with a very elegant approach to supporting multiple processors.

Today for my R&D project, I changed our background score calculation process so that it can take advantage of more than one processor core. It only took a couple hours from the time I started reading the documentation to the time I had my code working. I couldn’t believe how easy it was! I will definitely keep an eye out for other places in our software that could take better advantage of multiple processing cores.

For the technical folks out there, here are the resources I used to get me up to speed so quickly. I used Spring’s @Async annotation, Java 5’s java.util.concurrent.Future class and Spring’s org.springframework.scheduling.annotation.AsyncResult.

• Spring Documentation
• How to determine the number of available processor cores. I setup a thread pool size equal to the number of processing cores, so that way each core is used and no core is overloaded.
• Spring Blog Post: Task Scheduling Simplifications in Spring 3. One of the comments explains how to create @Async methods with the use of the Future class. Basically, if you need to return something from any async method call, just set it up like this:

  @Async
  Future<?> getMyResultAsynchronously() {
  	Object result = // set the result to whatever you want returned
  	return new AsyncResult(result);
  }
  

• Future class documentation
• AsyncResult class documentation

What’s so different about Web service coding, however, as opposed to typical web application programming, is the way that you can make sure your code is working as expected.

When building a typical web application, you can write your code, deploy it, and view it through your web browser. When building any sort of SOA functionality though, all communication is done through code…not quite as “visual” (unless you’re also writing a bunch of extra logging code), and arguably a bit more difficult to debug.

I wanted a quick way to test out the Web services that Scoreboard was providing…similar to the way that you might use a SQL console to test out your queries before you throw them into your application.

Of course there are plenty of development tools out there that will explore a WSDL, tell you which endpoints are available, and help you to build clients and POJO’s to use those services…but I wanted something simpler.

I already knew exactly what my endpoints were, and what the SOAP messages should look like, it was just a matter of ensuring that they were working as expected. I wanted to send a simple SOAP message, and see what the response looked like before I started writing client code that would consume those services.

Perhaps I just didn’t look hard enough, but I couldn’t find any tools out there that were a simple “form” that I could throw a SOAP header, body, and URL into, and send them off for a response.

Thus, I built my own. It’s a pretty simple Java Swing application that runs completely independent of both Scoreboard and Connect. I’m looking forward to it relieving many headaches related to analyzing JDOM elements through my Eclipse debugger!

A sample SOAP request, retrieving data from Scoreboard

The source code, as well as an executable JAR file can be downloaded here.

• Text
• Pictures
• Scorecard Nodes with configuration options for what they display
• Speedometers
• Gauges
• Charts
• Graphs
• Gannt Charts
• and all of that on top of a background image if needed.

WOBs are a wonderful, fluid, configurable AND exportable set of objects that offer our customers a major method for creating powerful information displays that can be bound in Briefing Books, set as the login page, exported to MS Office apps as well as embedded instantly into emails sent from the app!

With WOBs, “Dashboards” are much, much more than the word implies!

Pie Chart, Guage and Line Graph WOBs

Dashboard WOBs on an iPad

An example of text, scorecard node and chart WOBs

Stunning Dashboard by Scott O'Reilly

Actual Spider Strategies WOB Dashboard

But what do I REALLY love? Every month I prepare a presentation on the previous month’s performance. I have it in a “Briefing Book” that doesn’t change except for the date. So make it once, use it always! That’s a lot easier than updating slides! BUT what I really love is that every month, after updating the dates, I send our performance management briefing book to Microsoft PowerPoint and then EMAIL the whole presentation to our executive team for read ahead before our meeting. Sometimes, they just go through the slides and email back “looks good to me, let’s not meet!”

Here’s an example slide (it is real data).

I LOVE Scoreboard!!!

I’ve been thinking a lot lately about Apple’s new iPad and its lack of support for Flash graphics.  This is clearly a strategic move by Apple away from a closed technology that is fully owned by one company.  Feel free to see the irony there.

Regardless of how you feel about Apple, however, they do have a solid track record of making early, bold choices that the rest of industry follows.  Remember floppy disks?  I think Flash will continue to be supported on traditional computers for quite a while, but its heyday is behind us.  HTML 5 and native cross-platform vector graphics are the future.

Which brings me to the point of this post.

When we started writing our dashboards functionality over a year ago we had some tough choices to make.  We had an aggressive vision of creating dashboards with freeform layout, allowing users to easily move and resize objects on a blank canvas.  Think PowerPoint, as opposed to shuffling uniformly sized content boxes.  If we could pull it off we’d be lightyears ahead of our competitors.

The easy road would have been to use Flash to power our dashboards.  It was a mature, widely used technology, but something didn’t feel right.  Flash required a browser plugin, and regardless of how ubiquitous it was, it didn’t fit with the philosophy of the open web.

Instead we decided to code our dashboards in 100% HTML, CSS, and JavaScript.  It wasn’t the easiest development path, or the quickest, but we felt it was the “right” thing to do.

It’s now a year later, and our customers love the new software.  Our dashboards are everything we hoped they’d be, and our architectural decision to forgo Flash was a distant memory.

Until today.

While our flash-based competitors are scrambling to explain why devices like the iPad aren’t important, we leave that choice to our customers and just ship software that works everywhere.

To be fair, there’s no way we could have known the iPad was coming.  We didn’t have a crystal ball or some sort of extraordinary insight that others didn’t.  What we did have, though, is a development philosophy that favors open standards and cutting-edge research and development.

I couldn’t be more happy with where our software is today.

Here is an example of a quad chart, which is a popular chart in the US Army.

You can even upload maps to view real-time geographic performance data!

Here’s an example with a Polar chart. You can really squeeze a ton of data into a presentation that is easy to understand at a glance!

But the fact is, it didn’t work for us. As a small business, we could measure both our strategic and tactical success by looking at about 10 KPIs. You don’t need an enterprise class performance management application to do that.

But then in August, we introduced Spider Connect™ and Scoreboard® with absolutely incredible WOBs™ (web Windowed Objects) and everything changed.

All of a sudden we could create a scorecard reflection of our monthly P&L quickly and easily, export the P&L to Excel, read it and map the data fields in the spreadsheet and import the data into Scoreboard®.

THEN, in Scoreboard® we could create absolutely incredible Dashboards for visual analysis of the data. We could put those Dashboards into Briefing Books and export them to slide presentations that we could share via email and discuss at management meetings.

Overnight, our software became a genuinely critical part of assessing our performance and actioning improvement.

Wow does that make an incredible difference in the way I see our market. We are still a very small business and we still have clients who are the largest Fortune 100 companies in the world as well as the US Army which is the largest organization in the world. But if WE find our software indispensable, ANY organization needs Scoreboard® and Spider Connect™!

We not only imported our P&L but we could easily create new KPIs from the P&L data that give us critical insight into our goal attainment. For instance, we want to see our licensing and hosting revenue increase by at least 2.5% month to month, but ideally 5% month to month so that we achieve a 70% increase over 12 months.

Here’s what that looks like in Scoreboard!