System.Identity & the Repository in action at PDC

  • Article

For any number of reasons I’m just now catching up on my PDC videos. Among the many that interest me as an Architect working in a very large IT shop, are a great presentation by Kim Cameron and Gert Drapers on System.Identity titled “The ‘M’-Based System.Identity Model for Accessing Directory Services”. As an IT Architect watching System.Identity closely, I found this presentation noteworthy for three primary reasons:

  1. Kim hit a number of important topics relating to the capabilities of the System.Identity model, not the least of which were Polyarchy and Multitenancy.
  2. Gert demonstrated how programming against System.Identity might look based on the System.Identity Dec 2009 CTP API.
  3. The demonstrated System.Identity CTP code is running on top of the SQL Server Modeling Services Repository.

 

Polyarchy & Multitenancy

Hierarchical structures and representations abound within the business world. From organizational structures to classification taxonomies, Architects that work in Big IT are constantly dealing with new, changing, or outmoded hierarchical structures in their IT software systems and databases. Traditional solutions in this space concentrate on the definition of the hierarchies themselves, with a natural tendency to produce stovepipe systems. Examples of this abound in IT, including:

  • “Reports-To” hierarchies in HR systems
  • Profit Center hierarchies in accounting systems
  • Billing Hierarchies in billing systems

A common, but thorny, scenario with these types of systems is the case where an item in one hierarchy participates in another hierarchy. The need for an item crossing stovepipes typically results in multiple copies of the item – one for each hierarchy – and the data synchronization/quality issues that inevitably follow.

System.Identity provides an elegant solution to this problem by elevating the relationships between items in a hierarchy to first-class objects in the model. In System.Identity hierarchical structures are inferred from the collections of these relationships, thereby allowing a single item to participate in any number of hierarchical structures simultaneously – no data fuss or muss!

As a career IT guy, I can personally attest to the ever-increasing diversity, and complexity, of business relationships that can stretch existing IT systems and databases to the breaking point. Now, instead of designing my own solutions using Silverston or Arlow & Neustadt as a guide I can leverage Microsoft’s strategic investment in System.Identity – awesome!

 

System.Identity’s invaluable polyarchy capabilities are only enhanced through support for multitenancy. Multitenancy is a hallmark feature of enterprise-class business platforms such as CRM and ERP due to the almost universal fact that different parts of the enterprise will need to use the same business platform differently from everyone else.

System.Identity not only supports a single item simultaneously participating in multiple hierarchies within an organization, System.Identity also support a single item participating in multiple hierarchies across organizations. In the era of global supply chains and outsourcing this capability is an absolute requirement to enable the business. Again, as an Architect I no longer have to concern myself with the proper design of a multitenant polyarchy solution, I can leverage System.Identity and (hopefully) standardize its usage across my IT shop and with my enterprise’s trading partners.

 

System.Identity Dec 2009 CTP API

It was good to see a demonstrable API operating against System.Identity. I especially liked how Gert demonstrated extending System.Identity to easily incorporate new object types, while maintaining the core power of the System.Identity model. The architectural approach of using the logical schema as an abstraction of the underlying store is obviously spot-on. I was also very happy to see that the API Gert demonstrated had a very similar feel to my experimentation with a fluent interface for System.Identity.

However, as an IT Architect I still have a number of questions regarding how System.Identity is going to work in heterogeneous environments. Personally, I would like to see a vision like:

  • Next gen AD lives and breathes System.Identity
  • Next gen AD integrates seamlessly with SQL Server Modeling Services
  • SQL Server Modeling Services provides the abstraction/integration mechanisms for disparate sources of System.Identity data in the heterogeneous IT environment, thereby combining the data for easy access in the Repository 

If Microsoft can deliver on the above vision, I think it’s a no brainer for Big IT to jump on the technology.

 

SQL Server Modeling Services Repository

As I mentioned above, many databases have been created from the guidance provided by various authors including Silverston, Arlow & Neustadt, Fowler, and Hay. As I can personally attest (as I’ve designed my own Table-per Class database that implemented the Party Model), this is a “Good Thing”. The usage of these design patterns has only helped increase the overall quality of systems that I’ve built or extended.

Using design patterns in the construction of databases confers a number of documented benefits (and consequences) and is pure goodness. However, I can speak from personal experience that databases built using these techniques often do not address a number of orthogonal (and I would argue architectural) concerns.

As an example, take the following hypothetical scenario:

  • Dave and Rob are both Architects designing replacement systems for existing legacy apps for two different enterprises. Oddly enough, both Dave and Rob each have a need for a Party Model implementation. However, Dave is a big Arlow & Neustadt fan, while Rob is Silverston devotee. Dave and Rob both design their model stores using SQL Server, where the design is guided by the use of design patterns.

Consider the scenario above in the context of the orthogonal (i.e., architectural) concerns of Security and Localization. Assuming that Dave and Rob incorporated Security and Localization in their respective designs (and they might not have), one or more of the following are highly likely to be true:

  • Dave’s implementation for Security and/or Localization is different from Rob’s
  • One, or more, of the implementations is incorrect
  • One, or more, of the implementations is suboptimal (doesn’t perform, doesn’t scale, hard to maintain, etc)

This is where the SQL Server Modeling Services Repository comes in. The Repository provides a number of patterns and services that address a number of architectural concerns. Using the above scenario, both Dave and Rob choose their respective design patterns and create models in ‘M’. Next, leveraging the SQL Server Modeling Services tool chain, Dave and Rob are able to create data stores for their models that not only possess the benefits they need (derived from the design patterns), but also receive robust implementations of architectural concerns like Security, Localization, and Versioning. Oh, and did mention that Dave and Rob get exactly the same implementations? Excellent!

Right now is a very cool time to be a modeling junkie working with Microsoft technologies. The strategies Microsoft has in place with System.Identity and SQL Server Modeling Services are worth the effort to follow for any IT Architect. I’m personally stoked to explore the possibilities.