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.

It’s been about two months since we announced TIBCO Silver, and the overall response has been overwhelmingly positive. We are very pleased with the positive reaction and excitement that Silver has generated among our customers, partners, press and the analyst community. There have been quite a few articles by the press and blogs by various independent thinkers on Silver. Here is a quick synopsis of some of the analyst articles and blog posts.

On the analyst front - Gartner published its research note on TIBCO Silver (Aug 6, 2009) titled “TIBCO’s Silver Cloud-Computing Platform Shows Potential.” Authored by some of the leading Gartner analysts, the report gives us positive feedback overall on our positioning and calls out our cloud platform strategy as “genuine”(not just another AMI) and describes the offering as unique and ahead of the curve compared to the other cloud platforms. MWD published its first take on Silver titled “TIBCO gets on to the Cloud with Silver,” noting that TIBCO is the first vendor offering an enterprise class cloud platform. Several other analyst firms, including Forrester, have given us their thumbs up on Silver.

On the independent blog front - “ The next generation of cloud-development platforms” is a very interesting blog post by James Urquhart. His depiction of Silver’s three-element architecture is right on the mark, although I would like to point out that the only component that runs in our datacenter is the initial provisioning server. Once the account is provisioned, Silver and all its components run entirely on the customer’s virtual machine instances. Other interesting blog posts are “TIBCO Silver: RAD and governance for enterprise clouds” by Dennis Howlett , “TIBCO Silver – Amazon for dummies” by Maureen O’Gara, “TIBCO takes PaaS plus integration capabilities to global enterprises via their choice of clouds” by Dana Gardner. These blogs explain Silver quite well and are all good reads.

We also published a couple of articles highlighting the challenges that enterprise customer have in adopting cloud computing - Enterprise Ready Rapid Delivery Platform for the Cloud and Cloud Governance.

The Silver Beta Program is in full swing. Since the beta program was kick-started on July 20^th, more than 200 customers have registered. In my next blog post I will detail the interesting set of cloud use-case patterns that have come to the fore. Btw, if you haven’t done so already, please sign up for the TIBCO Silver Beta program.

Like many my first personal computer was a Commodore 64. I immediately wanted to *do* something with it – to create something new with it.

I remember poring over these archaic references guides, learning 6502 assembler and the special code pages that would enable sprites and colors and all the rest. The level of dedication and effort required to do anything on that tiny machine was huge. Building anything with it was a personal experience.

But my biggest shock came when I interacted with a “real” computer. It was an alien beast. All of my hard won, deep knowledge on the “play” computer were irrelevant. Beyond understanding the basic principles of programming and machine architecture – nothing else was transferable. I had to learn everything about this new computer from scratch. Even things that had no business being different – were different. It was another set of (even) larger reference manuals with another set of archaic knowledge.

The barrier to entry for each new system was huge. Don’t know the secret handshake you’re kinda screwed. Don’t have enough time to focus and get to know the nuanced aspects of the system – doubly screwed. Each system had its own set of good and bad bits. What you always dreamed of was a ‘super computer’ that would somehow take all of the best bits from a bunch of different systems and forget the rest. A computer that would be tailored just for your needs, skills and requirements.

Fast forward and we have the same problem today with architectures, tools and languages. Knowledge sharing and the advent of the internet has definitely reduced the barrier to entry but it hasn’t fundamentally changed the problem. Each tool or language or framework has its own little idiosyncrasies and details. But often one tool isn’t going to get the job done. But the pain associated with trying to stitch together different technologies into a single application can be a painful exercise. Then deploying that solution in a repeatable way is the next challenge.

The final challenge is really the killer. Once you have assembled this Frankenstein application trying to pick the best of different tools and languages – how do you evolve your application? How can you easily change one part out for a new technology or architecture?

What we set out to do with TIBCO Silver™ was to enable the creation of not just enterprise class cloud applications but to enable a developer and architect to essentially choose a set of tools and technologies that they are comfortable with. Essentially we wanted to allow a user to personalize the new “super computer.” Do you like ActiveRecord from Ruby on Rails but are also pretty solid with Spring? Then fine – use those technologies in Silver. We will take care of the communication, security, scale and deployment aspects of this AR/Spring solution. You get to focus on building the solution, not building out yet another custom framework.

With TIBCO Silver™ we are often talking about Months to Minutes. For me it is making my tools personal again.