Trifork Blog

JTeam Technology Matrix: The Stars

September 7th, 2009 by

In Alef’s previous blog entry about the JTeam Technology Matrix, he explained the basic idea of using a BCG-matrix to classify technologies. In this blog entry I’ll focus on the ‘Star’ section of our current matrix and highlight some of the technologies that are currently in there. Star technologies are the technologies that bring us added value in the projects that we do, but are also cool and innovative to use. Please keep in mind that the content of the matrix is under constant discussion and is subject to change. This overview should therefore be considered a snapshot of today’s matrix.

The Stars

Our current physical technology matrix lists the following technologies (in alphabetical order):

Amazon Web Services (AWS)

Amazon Web Services is a collection of web services offered over the internet by The most noteworthy services are:

  • Amazon S3 – Cost effective way to redundantly store large amounts of data
  • Amazon EC2 – Start / stop virtual private servers on demand via a webservice interface and pay only for the computing power you use

We think it makes sense to use S3 if it fits your needs, it is particularly well suited for backup solutions.

Traditional EC2 uses have been hosting temporary (non critical) infrastructure or performing computationally intensive tasks. For these use cases EC2 is very well suited. As of recently you can assign a server a static IP address and have the ability to persist data through server restarts. This makes EC2 a more attractive choice to consider for hosting a production site. The webservice interface that AWS provides allows you to build a true cloud infrastructure on top of EC2 (e.g. start up another server if the load reaches a certain threshold and stop that server again when the load goes down).

We at JTeam use S3 for our internal and customer backups. Furthermore we use EC2 to host some of our project infrastructure like ScrumWorks, TeamCity, Artifactory and the like. We also use EC2 to host UAT environments for our customers. So far we have not used it to host production environments on it.

Domain Driven Design (DDD)

DDD is not a technology or a methodology. It is a way of thinking and a set of design practices, techniques and principles aimed at accelerating software projects. DDD was pioneered by Eric Evans in his book Domain-Driven Design.

In our opinion DDD is a good way to professionalize the contact with our client / domain expert. It also allows us to shows the benefit of using DDD directly to the client. DDD really fits our way of working (e.g. Agile, close customer contact and fixed budget), because it provides an easy bridge between the customer requirements and the code. It allows the client to almost read the code as it is delivered. Because of this readability, it also is much better fitted to testing and documenting user stories.

Google Web Toolkit (GWT)

GWT is our preferred way to develop advanced RIAs (assuming certain prerequisites like no requirements related to SEO). We use it for developing backend / administrative interfaces in an intuitive manner. The main reason why we prefer to use GWT is that it allows us to build Swing like / fat client applications that run in any web browser. For users, this means no need to install software to run the application, while still getting an intuitive UI. Of course there are several ways to develop RIAs, but GWT has our preference because it allows us to write applications in our preferred language: Java. The added value of this is that we can reuse all of our tools and best practices (e.g. IDE, build environment and TDD).

We have been using GWT for some time now and even wrote a book about it. However, we feel GWT is still innovative and cool, as new features are added with every release and there is still a lot of innovation to do there. Therefore, it is definitely a star technology.


GWT is a great technology to develop advanced RIA. Anyone experienced with Swing (or GWT) knows that this programing model can act as a double edge sword – on one hand, it is simple and intuitive for Java developers for developing UIs, but on the other hand, when not following adequate design patterns and programming paradigms, even a relatively simple GWT application code base can quickly become messy and unmaintainable. The main goal of GWToolbox is to define best practices and design pattern that aid in developing clean and modular GWT applications. GWToolbox contains 3 main modules:

  • IoC: Using simple yet powerful dependency injection, one can maintain a clean code base even for the most complex applications. But DI is not enough – the framework promotes event driven development to the max by providing an infrastructure for application level events. This greatly simplifies the interaction between the different modules/component of the application.
  • SpringRpc: This module provide simple support classes to integrate a GWT application with the Spring Framework. Although there are several such integration libraries out there, this module tries to make full use of the latest features in Spring. It uses the component scanning mechanism to pick up services in the application context that should be exposed to the GWT client application. In addition, custom namespaces are defined which simplify development even more.
  • Widget: The widget module contains different kind of widgets that can be used to create advance RIAs. There are many widgets out there already, but they are either GPL licensed or not as advance as you typically need.


jQuery is just one of those libraries you can’t live without when creating a Web 2.0 website with plain old HTML and Javascript. It is a Javascript library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. Not only that, but it teaches you to write maintainable Javascript code. With a little effort you can do amazing visual things on your website, all the while keeping the code readable and concise. So next to pleasing your customer by creating cool things with jQuery, it actually provides lot of added value to you as a developer too. I can see jQuery play an important role in Web 2.0 development for the upcoming years, but it may have to give ground to the more RIA-oriented technologies like GWT and Flex.


Mockito is innovative because it represents the state-of-the-art in Java mocking frameworks. It has taken the best practices and the best ideas pioneered by previous mocking frameworks, and applied these in the best way possible. It allows unit tests to be both more expressive and easier to read. In comparison, EasyMock – another currently popular mocking framework – tends to produce more over-specification, resulting in more brittle tests. Finally Mockito’s idiom is both simple and consistent, making mocking easier to learn for TDD newbies.

As a result, Mockito adds value to our business by helping us make our code more robust and easier to maintain and evolve. In the coming years we expect Mockito to become mainstream, and succeed EasyMock as the de-facto standard Java mocking solution.

Rob van Maris’ blog post titled Easier mocking with Mockito describes how to use Mockito and how it compares to EasyMock.


Agile software development is a combination of technical, social and organizational aspects. It requires a matching set of engineering and project management practices. This is where Scrum fits in.
Scrum is a lightweight framework for project management that promotes the Agile Principles. It complements our engineering practices and promotes the same core values (organizational learning, quality, personal development, fun). We have applied Scrum in various projects and like the way it contributes to success factors like transparency, customer involvement, focus, productivity, motivation and self-improvement. On the other hand, Scrum has introduced new challenges regarding how we sell projects and services, how we manage projects and how we manage resources.
There is currenlty a lot of hype surrounding Scrum, and many seem to regard it as a silver bullet. Someday the hype will be over, but by then Agile software development will have become (almost) mainstream.


Solr is definitely one of the biggest stars (if not *the* biggest). Solr is a Lucene based search server which makes enterprise search available as a service. Not only does it bring together all Lucene/search best practices in one box, but it also extends on Lucene’s basic search functionality with powerful features like faceted classification, statistics, and a powerful and extensible query language. Due to an open and extensible architecture, it is very easy to extend Solr with even more functionality (for example, there’s already an extension which integrates document clustering functionality to search results). Ok, so it’s a powerful search server, but why is it a star? Simply because search is growing big… very big. In the last 2-3 years we’ve witnessed it first hand from our clients. Perhaps it’s the Web 2.0 era, or maybe its the proliferation of information that has grown too big to handle, but more and more companies realize that their products cannot do without a good powerful search functionality. We can honestly say that in the last 2 years more than 85% of the projects we did had some form of search integration requirement, most of which grew with time with features and functionality. Today, Solr (and search in general) sells itself. Solr already started to gain good reputation and if 2 years ago we had to explain companies what Solr is and what it can do for them, today customer already know that Solr is what they want and come to us for our Solr expertise.


Wicket is a Java framework for web applications. A big difference compared to many other web frameworks is that it does not require a special language (e.g. JSP), just Java and HTML. Furthermore, Wicket is component oriented. Each component is responsible for only a small piece of a web page. Components are reusable which allows you draw from an extensive collection of existing components. These components come from Wicket itself, but also from the open source community. Of course it is possible to build your own collection. This way of working leads, even for very complicated screens, to highly maintainable applications.

Almost every sentence in the paragraph above indicates why Wicket is cool, innovative and productive. Wicket is actively supported and developed and is therefore an excellent choice into the future.

What is next?

I hope this blog entry gives you some insight into the technologies / methodologies that we at JTeam feel are interesting both from an innovation perspective as well as from an added value perspective. As mentioned before, maintaining this matrix is an ongoing effort, therefore this list is subject to change.
In the future you can expect updates as well as blog posts about the other parts of the technology matrix (which will lead to a lot more controversy ;-)).

3 Responses

  1. September 7, 2009 at 14:31 by Itay Maman

    I often felt that GWT is not a good UI solution. It seems that object-oriented languages are quite verbose with respect to UI code and that hierarchical (XML) languages are better in this aspect. From this perspective, GWT maximizes the *disadvantages*. I’d be interested to hear your thoughts about GWT.

  2. September 8, 2009 at 13:22 by Uri Boness


    I totally understand and appreciate your opinion on the subject. From my experience this is very much a subjective issue. We’re talking about two completely different programming styles – some people feel more comfortable with a markup language while others (perhaps those who’re more Java and Swing oriented). Personally, I find the “Swing-like” style easier to grasp and develop and the fact that all code (presentation and logic) is written in one language makes it easier *for me* to work with and maintain. Another aspect to consider is that type of application you’re actually developing. I think it is very important to choose the right technology for the right problem. If you ask me, I wouldn’t go ahead and for example develop a public website with GWT simple because I don’t believe it’s the right technology (there are more issues than development style here to consider – SEO for example). In JTeam we see GWT as a perfect technology for developing back office and management consoles applications, in which the richness of the UI is much more evident and plays a stronger role. That all being said, the good news is that the next GWT release (2.0) will come with support for template binding – that is, you’ll be able to define your UI in a markup language and bind it to the GWT java code.

  3. September 22, 2009 at 00:47 by

    […] JTeam Technology Matrix: The Stars « JTeam Blog / JTeam … […]