Ok, as you are reading this blog post I want you to understand something; I consider myself at best an average developer. I think the nicest thing anyone every told me about my programming was that ‘I did ok prototypes’.

So - with that admission out in the open - let’s talk about the approach to prototypes.

When we first conceived of tibbr (way back prior to the launch of TIBCO Silver^TM in June last year) we decided to follow a rapid prototype plan. Each prototype would focus on one area - essentially prove a single concept.

We broke the prototypes up into three distinct areas:

1.       Technology prototypes; looking at tools, languages and other things

2.       Architectural prototypes; how to scale etc

3.       Functional prototypes; focus on the actual user experience and functionality.

The early prototypes were of the ‘does this work’ variety. The later prototypes were ‘does this make sense’ variety. Essentially - technology/architecture then functional prototypes. This helped the teamfocus early on basic architecture questions and then later with a good baseline understanding of the technology landscape we could then focus on the real value which was prototyping the functionality.

Technology Prototypes: I always like the architecture/tech exploration phases of a project. At this stage of the project everything is possible. The first rapid prototype we did using Ruby components in Silver. We were really looking at development speed/ease against system performance tradeoffs.

What we found was that Ruby has a generally good profile.  It has a good set of libraries and gems (add-ons like ActiveRecord for example) and because we could make changes to tibbr prototype services on the fly we could cut the development time dramatically.

However it wasn’t all sunshine and roses. The first is that as the services got more ‘complex’ we needed to be very aggressive in refactoring in comparison to Java or C#. Raw processing performance of things like messages was also poorer in ruby versus java or C. But ultimately the compactness of the ruby syntax, the ability to develop the services on the fly and the richness of the ruby gems meant it was the primary component tool set.

Now this looks like a fair number of moving parts. The great thing about TIBCO Silver is that there is almost no penalty to mixing multiple different technologies in a single application. This really gives us the flexibility to choose the right technology for the right problem area.

We then moved from simple tech and tool selection to logical and physical architecture.

Personally I find this part of prototyping a lot of fun; it can also be a bit frustrating. You sometimes feel that you are not making a lot of forward progress or solving problems that are kinda silly. We ran into a whole bunch of JRuby Vs Ruby issues and the usual array of OSGi classpath loading issues that slowed forward momentum and I found to be a bit of a grind. Spending a full day trying to work out why something worked in Ruby and not in JRuby and having the solution be a tiny single line code change can be a little crappy.

Anyway - architecture prototypes.

Architecture Prototypes: The primary question we were answering in the architectural prototypes was ‘what is the best level or componentization and granularity for the tibbr services’

Now this is a pretty straightforward question right? People will generally follow top down or bottom up methodologies when talking about services and components. Personally I don’t actually find either methodology useful during the prototype architecture phase.

Don’t get me wrong. I am happy to work in either paradigm. But my goals at this point in the tibbr project were much more basic:

1.       How do I scale the system

2.       How does scaling the system impact the service/component granularity

3.       How do I operationalize the architecture

For example, I could build an architectural prototype that essentially takes ALL the deployed granular services as one big application bundle and then replicate this bundle on a large number of machines using some kind of HTTP load balancer for scale.

Or I could think about the types of services that I need (user management, subject management, message pipelines etc) and break up the deployment into groups that more accurately reflect system usage. I could hypothesize that a user logging into the system needs to scale more horizontally than any other function in the system. This would in turn lead me to scale components services a user login request.

You get the idea.

Now these two approaches (and the many that I haven’t discussed) have wildly different impacts on scalability and (somewhat more importantly) on the ability to administer the system effectively.

Designing a super scalable infrastructure is worth nothing if it is almost impossible to manage and administer in an easy fashion.

So you end up with these three forces that play a huge role in determining overall system and component architecture:

1.       Componentization - how easy is it for the system to be understood and to evolve over time

2.       Scalability - how can the components scale and how easy can the system flex up and down

3.       Usability - How easy is it to administrate the system at multiple levels.

We played around a lot here. There are so many novel approaches and technologies to throw around that you really start to see how the system can come together.

I have to give a nod to SCA here. Service Component Architecture is a standard that we have used for a couple of years in our cloud and SOA products. The ability to quickly and easily break apart components, assemble them in different ways gives you an incredible freedom of expression.

For example, I had original prototyped a number of the tibbr components as separate composites. Each composite would essentially encapsulate some functionality only exposing a public interface to the rest of the world. As the number of composites and components started to grow I was easily able to create ’super’ composites which would suck in the lower level composites and expose higher levels of granularity. I could also go the other way and refine existing composites until I felt I had the right levels. All of this was achievable without having to change the underlying code itself.

The final series of prototypes - which in this case we ran in parallel - were the functional prototypes that encapsulated the application functionality AND the user experience.

Functional Prototypes: The approach here was a bit different. In tech and architecture prototypes we are exploring possible solution set. What I mean by that is that you almost start with a blank sheet of paper and then step by step fill it up with different technology/architecture decision branches.

For functional prototypes we took a completely different approach. For this stage we started by asking ourselves a simple question:

“If I was to write a press release on TIBBR - what would it say?”

Then a follow on question:

“What would the sales or marketing presentation look like?”

Now I know what you are thinking - what does a press release or a presentation have to do with a functional prototype? Well for me it is pretty simple; if I cannot distill the essence of my product into something as simple as a press release I probably don’t know what I am actually building. The same is true for presentations.

From this baseline we then began a series of discussions (arguments), designs (napkin) and user interfaces (colored pens). Each mini prototype looked at different areas of the user experience and functionality. As we got deeper into the process we had no problem going back and changing an earlier prototype.

These prototypes were ‘vignettes’ they essentially took a vertical slice of functionality and with stubbed out services or dummy data and trialed it. Did it suck? Did it work as a user would expect it to work?

For the user perspective our User Experience team was a massive help. They would help us understand human factor and usability issues that we might not have thought were big issues. Even things like color and color palettes for the application itself were prototyped.

Ok, so this looks like a whole lot of work and not much gain in terms of designing, building and releasing a product right?

Yes and no. We made a conscious decision that as we moved from prototype to design/execution that we would not re-use earlier prototypes. So we did lose out there.

However what we gained was something more valuable:

1.       We had a great technology landscape of proven technologies being used for the right problem

2.       We had a very real sense of scale and manageability

3.       We had a much deeper appreciation and understanding of the application itself.

All of this helped us to get into the next phase with a high degree of confidence. The team also had developed a great horizontal and vertical understanding of the functionality so even if one person was working on the server based components and another on the user experience they each had a shared understanding.

Stayed tuned for the next edition of this blog where we will explore the actual solution from a high level tech perspective.

After months of hectic activity, we finally launched tibbr™ yesterday. tibbr is a social networking tool for the enterprise that couples the usability aspects of social micro-blogging sites with a unique subject-based addressing approach to deliver relevant information in real time to business users.

I am excited about tibbr for a couple of reasons – first, this represents a natural extension to what we do today in the enterprise, getting applications to talk to each other; we now make relevant events available to business users in real time to help them make the right decisions; second – this showcases an end-to-end composite application that has been built and delivered on the TIBCO Silver™ platform.  Based on the initial response, it does seem like the press and analyst communities are quite excited about tibbr as well.  “TIBCO takes after twitter” and “TIBCO’s tibbr aims to be enterprise twitter” are interesting reads. tibbr is generating quite a few tweets in the Tweetesphere as well. I expect more in-depth coverage in the next few weeks.

In my blog post a few weeks back I did allude to this – getting the right information to the right person at the right time.  The subject-based addressing mechanism allows users to subscribe to relevant information irrespective of whether it is a person or an enterprise application that is generating this event.  In the enterprise it is not just about people, but rather contextual information and expertise about relevant subjects. A subject can represent a user, an application, or a process relevant to a particular business user in an organization.  tibbr filters out all the static and unwanted information clutter by keeping the focus on subjects.  Want to know if the purchase order relevant to your project was approved or if the component has gone through the appropriate QA cycle or if the legal contract been signed on the deal?  Simply subscribe to that subject feed.

Excited yet? Need to know more about some of the internals of tibbr? Make sure to register to test drive tibbr. Also make sure visit the Silver blogs next week. Matt Quinn (SVP, Products and Technology at TIBCO) who conceptualized and leads the design and development effort on tibbr will provide a “behind the scenes” narrative on how we actually went about conceptualizing, building tibbr and scaling tibbr via the TIBCO Silver elastic platform.