A few years ago I was asked by one of our customers to help them make better use of their integration layer. Ever since then me and my team have been working on a framework in support of that. This is the fourth in a series of blogs on the development of our framework, and discusses the features it provides. The one that was announced last time, about building blocks, is momentarily postponed.

So far I’ve discussed the goals & challenges surrounding the development activities, but I’d like to focus more on the framework itself now, and what it brings to those that are using it.

As soon as a new party (be it service consumer or service provider) connects to our framework, it can profit directly from the wealth of functionality we deliver out-of-the-box. These ‘generic features’ are exactly what one would expect from a (logical) ESB, and are partly based on the Expanded Enterprise Service Bus Pattern.

 Read more

Part 7: Best practices

In the previous blog posts in this series we discussed the role of technical leads (and in particular of Technical Product Owners [TPO]) in an agile software development process. Since then we have had several questions. The main question was: “I am in a classic architecture team. The development teams go agile. How can I get more involved with the teams?”. In this post I would like to focus on some best practices: how can you, as a TPO get more involved and facilitate the teams to deliver better quality? Read more

A few years ago I was asked by one of our customers to help them make better use of their integration layer. Ever since then me and my team have been working on a framework in support of that. This is the third in a series of blogs on the development of our framework, and discusses the challenges we had to meet.

In the previous blog of this series I mentioned the goals we had to reach. Succeeding in doing so of course meant we had to overcome a lot of challenges. In order to keep this blog from reaching the size of one of the books of the ‘Lords of the Rings’ trilogy, I’ll keep it limited to the five below, which together form a pretty good picture of what we had to deal with.

 Read more

Part 6: The Senior Operations Engineer

Architectural activities tend to focus on the initiation and design phase of a project. In the previous post, we already pointed out the importance of architectural thinking during the development of software. In classic organizations, there is relatively little attention for the operations department. The architecture of infrastructure is essential for the success of software.

The only valuable software is software in production. This means that for software to be valuable, you should focus on getting it in production as quickly as possible. Many agile practices help in speeding up the development part. But if you limit yourself to these agile practices, you may still hit a wall when you want to deploy your software on the live systems.
 Read more

In the previous post I’ve explained in short what OpenShift is about and how you can use it. In this post I’ll go a bit further in how to use the OpenShift origin framework in a private pass environment. I’ll do this by creating an application based on the “Do it yourself” cartridge.  Read more

In this post I’ll try to explain why everyone should start using OpenShift.

1. What it is?
The paas platform OpenShift is a free and opensource platform from RedHat. With free, meaning actually that you get 3 gears for free. On those nodes (see it as virtual servers), you can do almost everything you want. From running a JBoss Application server, up till a php application or do something with MongoDB.
The fact that it is open source makes it even more nice. You can simply download the paas platform and install it in your own small datacenter, taking advantage of all the features the online platform gives you. Simply clicking on the image below will bring you to the download page to install it in your own datacenter.

 Read more

Part 5: The Senior Software Engineer

In Scrum it is best practice to have in each sprint all the team members needed to implement the user stories in that particular sprint. Most members will be either developer or tester. Some of them will play a more pronounced part in delivering a potential shippable product. A reason for this is that they take part in the process from sprint one. The effect is that these team members grow seniority over other team members because they have more in depth knowledge of the system under development. They will be consulted more than others by the Product Owner and the Scrummaster. In our process from “Concept to Cash” we call them Senior Software Engineers (SSE). How is a SSE related to the Technical Product Owner (TPO)? Read more

Design a large scale NoSQL/DataGrid application similar to Twitter with Nati Shalom (Founder and Chief Technology Officer at GigaSpaces).  Read more

Architecture refers to a very broad concept that creates a lot of confusion in the IT world. Why is it that such a common term is so vague? In this article we will give you an explanation for it.  Read more

A few years ago I was asked by one of our customers to help them make better use of their integration layer. Ever since then me and my team have been working on a framework in support of that. This is the second in a series of blogs on the development of our framework, and discusses the goals we had to reach.

In the previous blog of this series I mentioned the business needs that we had to address:

• Efficiency in business processes
• Consistency in data representation
• Flexibility and time-to-market accelerated by the IT department.

Based on these the goals described below were set.

 Read more