MidPoint has a lot of unique features. But what is perhaps even more interesting than the features is the approach to midPoint product management, planning, design and development. We tend to follow a couple of simple but very powerful principles:

Deployment and Maintenance Efficiency

The very most important principle of midPoint is: it has to be efficient to deploy and maintain. Our team has been working with identity management products for more than a decade. We have suffered. Therefore we know how an IDM system should work. And we know very well that it is the deployed and working system that matters. Not the ideas, not diagrams, not the latest and greatest Java fashion - it is only the result that matters. It has to be affordable to deploy. Not only by cost of licences (which is zero) but especially by the cost of effort to deploy it. This effort is huge for deployments of traditional IDM systems. But midPoint's goal is to make this effort reasonable.

We achieve efficiency by reuse and standardization. If some feature is frequently used in the IDM deployments then it needs to be a feature of the product. The deployer needs to flick couple of switches instead of writing thousands of lines of code. The difficult part is to realize which features are often used in IDM deployments. But we have been deploying IDM solutions for a decade and we know this quite well. We also listen to our customers and partners. In fact the feature set of last few releases was heavily inspired by the feedback from our partners.

What exactly the efficiency means in midPoint? It means this:

Our mantra is the Pareto principle: 20% effort, 80% effect. With midPoint you should have 80% of the solution very quickly. This usually means days or weeks, not months or years. The remaining 20% can also be achieved with midPoint. It may require a slightly more of sophistication, maybe some scripting or even a bit of programming, but it is definitely achievable and feasible. And actually even this extra 20% is much more efficient that was the case in traditional IDM systems. It has to be. This is the reason why we have created midPoint in the first place. We have created it for ourselves. For IDM engineers.

Separation of Concerns

Identity management is a complex field full of hard problems. It is perhaps even beyond the capacity of any sane person to understand it all in its entirety. But even though it cannot be efficiently tackled as a one huge lump it still can be efficiently handled. The separation of concerns principle can be used to divide big hard problems into smaller ones. This principle is used very frequently in midPoint. We try to design simple and efficient mechanisms that are good for one facet of the problem. Then we combine them together to solve complex problems. The mechanisms are relatively simple and therefore they are easy to master. Yet, when used together they can create very sophisticated configurations.

Few examples of the use of the separation of concerns principle are:

The individual partial mechanisms can then be combined into a very complex and powerful configurations. The somehow extreme examples are perhaps meta-roles and higher-order inducements. Please have a look at OrgSync Story Test description to get an idea how complex configuration can be created by using just a handful of mechanisms.


MidPoint has to be efficient to deploy and maintain. But it also has to be efficient to understand and develop. Therefore we are re-using a huge amount of concepts and mechanisms all over the midPoint. Reuse has many advantages. The mechanisms needs to be developed once, understood once, tested once - and the used at many places. This approach gives us huge effect while keeping the cost down at the same time.

Perhaps the best examples of reuse include:

Everything Changes

IDM solution is not a piece of software frozen in time and space. Quite the contrary. Everything changes in IDM deployments: data, requirements, processes, environment - even the software itself. The ability to handle this dynamic whirlwind is a critical feature of midPoint. Not just the software part of midPoint but the whole midPoint solution which also includes support services, partners, planning, and lot of cooperation. But more about that later.

When it comes to the software itself it has to handle changes in data. You might think that this is trivial topic - the computers do this all the time for decades. But it is lightyears from being a trivial problem. IDM solutions live in dynamic, volatile and heterogeneous environment. And during more than a decade of commercial identity provisioning system almost nobody got this right. What's the problem? It is both simple and complex: consistency.

The consistency is an achilles' heel of Identity Management. Identity management solutions integrate data from many sources and deliver them to even more targets. It is no exception for an IDM solution to have tens of data sources and thousands of targets. The hallmark of provisioning system is that they do not disable the native system administration tools. Given hundreds of entities it is almost sure that some data will get out of sync: the data will get inconsistent. IDM solution thinks that it is A, the remote system thinks that it is B. And this is where traditional IDM system fail miserably. Of course, this can be handled by brute-force methods such as reconciliation. But there are still major issues: It is painfully slow and inefficient. And even more importantly: somebody needs to decide whether it should be A or B in the end.

We have studied this problem in depth. We have fought with it while deploying traditional IDM solutions. We have explored it from the software architecture point of view. We have conducted academic research. And we think that we have a solution. Or rather a set of solutions:

Continuous change of data is really a major concern in IDM solutions. However the data and the environment are not the only changing things in the solution. Requirements and processes change quite often. Which means changes in data structures. MidPoint is based on the idea of the unified data model which in turn is based on Single Source of Truth principle. The data model of midPoint is defined as an abstract schema. Java class files are generated from this schema during the build. The same schema is also used by midPoint user interface to display the data. Therefore a simple change of the schema definition echoes through the entire system. Which means it is easier to integrate: parts of the user interface will adapt automatically without any change to the code. And the parts of the code which are not compatible with the changed schema will immediately be identified because the compilation breaks. It is very easy to fix bugs in this way. And that's what we do. Parts of the schema can also be customized after the build when midPoint is deployed. And again, user interface and other dynamic parts of the system will adapt automatically. Without any need for programming.

There is still one more source of change. A very important one: the software itself. MidPoint has a rapid release cycle with two releases per year. This approach used by many high-profile open source projects and it works incredibly well for them as it works for us. This means that midPoint software changes quite often. This is an excellent news on one hand. Partners and customers can get their features and improvements very quickly. MidPoint deployments are very efficient. But there is a risk on the other had. Keeping midPoint solution operational may require frequent upgrades. We are more than aware of this risk and therefore we spend considerable effort to make the upgrade process easy. The goal is to make it almost effortless with risks kept as low as practically possible. Upgradeability is an integral part of midPoint design and architecture from the very beginning. E.g. we pay a lot of attention to data format compatibility, compatibility of extensions and so on. That's one of the reason we are so meticulous about proper namespaces and URIs which are used a lot in midPoint. However, upgradeability is a hard problem. We have gone a long way and we believe that our ability to upgrade is several levels above average we are continually improving it.


The midPoint software is only a part of midPoint solution. It is undoubtedly a very important part, but it is only a part nevertheless. It would be nothing without the ability to deploy and operate it efficiently. And it is the people that deploy and operate midPoint, not the software. Therefore we pay a great attention to work with our partners and customers. Cooperation is a crucial part of our day-to-day work.

What does it mean, exactly?

See Also