Setting up MongoDB for bi-temporal data

See this tutorial: http://www.projectbarbel.org/docs/mongotutorial

Manage bitempotal data with BarbelHisto

The last 15 years I've worked on projects for insurance businesses, implementing a variety of policy management systems. The topic that has always been a major requirement was to store the policies and their changes in a way that is traceable for audits and customer claims. Implementing bullet-proof bitemporal data storage has always taken a reasonable amount of time (and nerves). Every time we've implemented a new policy management system we have been on the lookout for a reusable component for bitemporal data. The few options we found did not really satisfy our needs, or had too many technical constraints. For that reason I've decided to implement my own open source library that I'd like to share with you guys: BarbelHisto. With this lightweight library I want to address that bitemporal data storage requirement, without any bothersome constraints. Just managing bitemporal data, that's it. No technology backpack.

Modern State Pattern using Enums and Functional Interfaces

It’s offen the case that the behaviour of an object should change depending on the objects state. Consider a ShoppingBasket object. You can add articles to your basket as long the order isn’t submitted. But once it’s submitted you typically don’t want to be able to change that order anymore. So, there are two states in such a shopping basket object: READONLY and UPDATEABLE .

Passing multiple arguments into stream filter predicates

When I am working with java streams I am intensively using filters to find objects. I offen have the situation where I'd like to pass two arguments to the fiter function. Unfortunately the standard API does only accept a Predicate but not BiPredicate.

To solve this limitation I define all my predicates as methods in a class, say Predicates. That predicate class takes a constant parameter.

5' on IT-Architecture: the modern software architect

Before I start writing about this let me adjust something right at the beginning:

Yes of course, there is the role of a "software architect" in any non-trivial software development project. Even in times of agile projects, dynamic markets and vague terms like "emergence". The simple reason for that is that emergence and democracy in teams only work within constraints. Though, it's not always clever to assign somebody the role explicitly. In an ideal world one developer in that team evolves into the architecture role.

When I started working as an IT professional at a *big* american software & IT consulting company I spent around five years with programming. After that time I got my first architecture job on a big project at a german automotive manufacturer. My main responsibility was to design the solution, advice developers, project managers and clients in doing things and to organize the development process. I wrote many documents, but I didn't code anymore. The result was that I lost expertise in my core business: programming. So after a while my assessments and gut instinct got worse, which results in worse decisions. As a sideeffect of generic (vague) talking it got harder to gain acceptance by the developers, project managers or clients. When I realized all that I decided to do more development again. Today, I am doing architecture for 10 years. I am developing code in the IDE of my choice at least 20-30% of my time.

5' on IT-Architecture: root concepts explained by the pioneers of software architecture

The last couple of weeks I am working on a new software architecture course specifically for the insurance and financial sector. During the preparations I was reading many of the most cited articles on software architecture. The concepts described in these articles are so fundamental (and still up-to-date) that every architect really should know about them. I have enjoyed reading such "old" stuff. I first read most of the cited articles during my studies at university in the mid 90s. It is surprising to realize that, the longer you're in this business, the more you agree to the ideas explained - in articles that were written 40 years ago! I've decided to qoute the original text passages - may be I thought it would be overbearing to explain it in my own words ;-) I hope you enjoy reading these text passages from the pioneers of software architecture.

5' on IT-Architecture: four laws of robust software systems

Murphy's Law ("If anything can go wrong, it will") was born at Edwards Air Force Base in 1949 at North Base. It was named after Capt. Edward A. Murphy, an engineer working on Air Force Project MX981, (a project) designed to see how much sudden deceleration a person can stand in a crash. One day, after finding that a transducer was wired wrong, he cursed the technician responsible and said, "If there is any way to do it wrong, he'll find it."