First of all, I’ll define what I mean by cloud in 10 words: cloud is outsourcing some layer of services from you infrastructure. This thought comes after meeting a large healthcare organization that’s putting their “back office” operations in an MSP. This is having a significant impact on how they are viewing administration of IT. When you own operations and administration, you can easily blend the two. If you have an administrative issue that would be made easier by shifting something about the operations of your IT resources, you do it. But when operations is a black box, then you actually have to make your administration solve all your challenges. That is new for many.
This organization is putting most of the non-clinical systems in an MSP, or in the cloud if you prefer, and that means there are many IAM challenges. Where do accounts originate? Who controls the authoritative data about users? Because so many clinical and other applications require it, they are keeping much of the directory infrastructure in house. How do changes flow in both directions when there are automated process and human admins and operators on both sides? How can all the changes from both ends be tracked? How can the state, the changes and the policies be kept in line with regulatory requirements? It’s a daunting set of challenges.
Right now they have their hands full just making it all happen. And they have plenty of parties (each site, the central IT organization, various consulting organizations, all the vendors) that are all involved in the project as it’s ongoing. When I sat down with them and many of these parties, it was hard enough just playing catch up to see who was responsible for what. We were there to discuss many of the pains they are experiencing in the phase they are in now and where Quest can help. What I immediately started to envision were the pains of the next phase. I think Quest can help with those, too, but I’m hoping they were receptive to my suggestions about it all. My basic message was that they are going to have to arm their administrators with a new kind of toolset and those administrators were going to have to have a new, leveled up approach. They were going to have to think less like technologists and more like data architects. What will matter most going forward is having very sound and robust models for data, policies and processes. Otherwise they would fall back into old ways of thinking and likely find themselves without the ability to make those level of changes to the MSP hosted systems. Or, even worse, waste time fighting with the MSP to change operational details – a fight where they finance both sides of the battle and take both sides’ losses as well.
My degree is in philosophy; specifically I studied what would be called cognitive science or philosophy of mind. I still read papers and articles about the field occasionally as they come to my attention. Doing some pleasure reading this father’s day weekend I came across this passage in a paper called “Conceptual Problems in Memetics in a Multi-Level View of Evolution and Behaviour” which seemed to call out a problem that is worth considering for those contemplating the next generation of directories:
Consider the problems of ostension for a mother who points out and names the species of a bird that is singing in a tree to her infant child. How does the child know what precisely is being given a name: the name could refer to all trees containing birds, or all small, noisy objects, or of that particular bird, or of the underside of its belly? To avoid ambiguity, the child needs some low-level schemas, perhaps reflecting the nature of taxonomy and the economy of expression, which act as “attractors” for the acquisition of new higher-level schemas. These aspects might allow a child to surmise firstly that the mother is referring to the bird in itself, and not as part of its relation to this particular tree, or the fact that the bird happens to be singing. Secondly, these aspects should allow the child to realise[sic] that it is the “whole” object of the bird that is being referred to, rather than, say, only its underside. While the child has not yet developed a detailed knowledge of birds and their general relations to other very basic categories in the world, he or she is unlikely to expect the mother to be referring to detailed aspects of a bird.
We all know what someone means when they say “there is a need to track all the accounts and rights granted to those accounts that are associated with any specific person”. There are definitive ideas of an account, a person and a right – though a right is likely the one most likely to admit something inexact into the conversation. But these very concrete things are not first order objects in directories, they don’t have their own schema. Instead they are all persons or, worse, accounts, and the very obvious classes they fit into described in that simple to understand requirement are merely attributes assigned to them. That seems like something worth fixing. When the technical and real life descriptions diverge that much, it can never be good for your ability to get things done.
If you look at the language I’m using, my prejudice becomes clear. The concepts of object oriented programming seem to be very useful in this problem space. The idea of having a base class, like a person, and having classes that extend that to be an employee or similar flows very well. It also fits very well with reality. All these entities are people after all. And that base object becomes implemented through a schema for entries in a directory. If one organization relies heavily on contractors and another does not, it’s likely that contractors will have very different “schemas” defining them in each. If those two organization now want to share data about identity including the contractors, they may find themselves with a big job of mapping. If they had a shared basic schema that has been used by another more complex one as a parent in the more contractor reliant shop, there are well established ways for those interactions to take placed based on patterns from object oriented designs. And imagine how much better that could be using something similar to a common schema everyone used.
Doing things along these OO lines would also allow us to do more with less. Since the base classes are shared, changes to those would make their way through everything. And as new use cases arise, simple inheritance would allow for quick work making these new classes of schemas that map to the needs.