In October 2013 I wrote a blogpost for Innovation Factory about software architecture:

Recently we added a new feature to PIT. The feature enabled idea challenge coordinators to invite external experts to share their views in a single idea challenge. Building this feature proved to be quite an interesting challenge. It convinced us to switch from a connected design style to a more modular one.

Let’s start by viewing PIT, our idea management platform, as a model for a specific kind of territory. Every instance of PIT can be seen as a digital island, to be colonized and nationalized by different companies. What company wouldn’t like to have its own little innovation paradise off the technological shores of Amsterdam?

Like any territory, our platform has a customs office with predefined policies for logging in. Nobody can get in without registration and a means of identification. This is an area in which the new feature raised some concerns. I think our product owner said something like:

“We want to be able to invite external participants to a single challenge without giving them access to the rest of the platform.”

Please notice the use of we in this phrase. Then notice how simple this request sounds. This is why product owners are champions in raising frowns with software developers. They articulate very broad concerns in very clear and simple language. It’s up to the development team to identify and separate the underlying “real” concerns. This separation of concerns is one of the fine arts in our line of work. I’ll try painting a picture of what this means for our customs office.

Passport Control

To be able to invite externals to a single challenge, we need to implement a new foreign policy. Until now, so called “foreigners” could only be given access to the platform by granting them full citizenship. This is great if you are prepared to happily disclose your entire ideation process to people from outside your organization. If you would however like to keep a few challenges indoors, you might be thinking twice before inviting an “outsider” to your precious little innovation paradise.

We came to the conclusion that we needed to enable a foreign policy that could distinguish between “natives” and “foreigners”. Foreigners will need something more than just their passports. They’ll need different kinds of visas, granting them access to different possible parts of the platform. Once we introduce visas, we’ll also need checkpoints everywhere in our software to check if we want to allow someone access a certain area on the platform. It gets even more complex when someone does have access to a certain page, but we don’t want to allow this person to see all of its content. To tackle these problems, we came up with built-in access and view policies. Sounds nice, right? If only this were the real challenge…

Making the transition

It is easy to think of a model for solving a problem. It’s a little more challenging to fit it into an existing system. The visas and checkpoints seem like good solutions for foreigners, but what about the natives? If we add all these checkpoints, we also change the world in which they live. For this group of users, access has always been implied. If we still want natives to have implicit access to the entire platform, we will get a chain of checks and conditions that will look something like the following.

The above dependency chain contains a mix of two different access policies: a native and a foreign one. If you would like to add more complexity later on, it can quickly become a little obscure. If something would then break, it will be quite hard to track down the problem.

In the foreign access policy we see a clear separation of concerns. The first one is that we want our users to have an identity with certain properties (a user account). The second one is that we need to be able to determine different access levels for different users explicitly through visa’s.

In the native policy, we derive different roles and access levels from user accounts by looking at specific properties. Access to a certain area is always implicit.

Consistent design

We can see how the foreign policy is the more modular one. It might be a good idea to extend this modular solution to our native users. We’ll simply give them visas as well, allowing them access to all public areas. At the checkpoints, we now only have to check the visa.

Dependency chains like the one we encountered are the result of the connected design style we employed in the past. A connected design style let’s you blend different concerns. It enables you to develop your software rather quickly, since you can simply derive different sorts of behavior from one and the same entity. This definitely has a few advantages.

For the first few features, a connected design style is cheaper than a modular design style. In fact, using what might be referred to by software design snobs as ‘poor design’ could give you a competitive advantage in the early stages of your product’s development. The trick is to recognise when it’s time to switch styles. (See Matt Wynne’s Hexagonal Rails – Introduction)

Closing remarks

The explicit separation of identity and access proves to be quite beneficial. It is now easy to add new roles to the platform without having to change the underlying architecture. It was for example easy to apply the new conceptual design to the existing role of challenge coordinator, who has some privileges with regard to the challenge(s) he coordinates. The above case exemplifies the exciting process we are currently involved in, making the transition from a connected design style towards a more modular one. This way we can keep our software maintainable, while at the same time adding beautiful new features that will continue to make PIT the beautiful innovation paradise you’ve always wanted!