by Mike Morley and Barry Lawrence

Summary: With an increasingly diverse mix of hosted, product-based, and customsolutions found in the modern corporate environment, reliably ascertaining theidentity of employees across the enterprise can be difficult, and is often leftto manual processes.

Contents

Introduction
Scenario
Goals
Solution Approach
System Architecture
Active Directory/Exchange
Conclusion

Introduction

This article will discuss a system and approach that accomplishesidentity synchronization, developed by BST Global, a Microsoft Gold Partner,and deployed at Matrix Solutions. The discussion will focus on the first phaseof the project describing the architecture of the Employee IdentitySynchronization system, which synchronizes employee identity from Ceridian’shosted HR Payroll, BST Global’s Enterprise PSA, Microsoft’s Active Directory,and Exchange Server.

Each individual system contains domain-specific data regardingthe employee. These systems also use their own terminology to describe the data—terminologythat may not be applicable to the overall corporate understanding of thosedata, or relevant to other system domains. HR/Payroll systems, for example,typically contain extensive information that only HR requires in order to produce payroll and manage the employee, whereasPSA (Professional Service Automation) systems contain employee data that relateto projects, employee charge rates as applied to projects, time, and expensedata.

To synchronize effectively the relevant data across systems, aspecification that defines the employee data in terminology relevant to thecorporation, regardless of system domains, is required. To address thechallenge, Matrix Solutions Incorporated (Matrix) has adopted the use of a SOAengine called the BST Freedom Exchange (BSTFX), a services-based workflowengine that facilitates the corporate definition and synchronization offederated keys and employee identity across systems. The workflow engine hasthe ability to translate data from system domains to the corporate domain andhandles the process of populating the corporate definition from the individualsystems, managing changes in those data, and synchronizing the resulting databack into the subscribing systems.

Scenario

Matrix Solutions Inc. is a rapidly growing EnvironmentalEngineering consulting firm based in Calgary (Alberta, Canada) that primarilyserves the upstream oil and gas industry. The company’s rapid growth from 100to 250 employees in four years makes managing employee identity a challenge.

As with many modern medium-sized firms, Matrix makes use of a‘best of breed’ approach to primary business systems rather than attempting touse one monolithic ERP (Enterprise Resource Planning) system to manage corebusiness information. While this approach increases efficacy of each systemwithin a particular business domain, the fact that each system will have itsown native database and associated identity management framework exacerbatesthe issue of identity management.

Matrix uses a mix of commercial hosted onsite, commercial hostedoffsite and custom developed systems to run its business. Each has its owndatabase and domain-specific method for storing and describing business data.

Identity is at the heart of every system, as it defines the userexperience within each domain, and is the means through which security isgoverned. Security is dependent on proper knowledge of not only identity forauthentication but also for authority and access to the correct informationwithin the system in question. Keeping employee identity current in all coresystems is therefore critical to the smooth and secure operation of thebusiness.

Synchronization of identity between systems at Matrixtraditionally has been addressed by manual methods using full-time staffresponsible for each system. In some cases, batch-data reconciliations betweensystems were conducted by temporary staff to bring systems back into sync,resulting in identity disconnects between systems and data inconsistency. Onespecific example of this involved an employee who had returned from an extendedleave having two separate identity accounts created for them. Because of themanual methods that are used to synchronize identity, it was not until sometimelater that the error was detected, creating a great deal of extraneous work inreconciling and resynchronizing the systems that used the information.

Matrix operates in the dynamic, fast moving, and cost-competitiveconsulting business sector. The consulting business model is particularly sensitiveto overhead costs—each additional overhead resource required to support thebusiness has an impact on profitability. Keeping the number of administrativeresources at an optimal level to support the operation of the business whileensuring they are being used to maximum effect is crucial to the success of thecompany. Having administrators dedicated to keeping systems synchronized bydoing data-entry is not in the best interest of the organization or theresource.

Goals

Based on the business challenges, the following key objectiveswere established for a key IT initiative:

·        Reduce the friction of information flow throughout the organization.

·        Maximize use of knowledge and administrative assets, wherever possible.

·        Replace repetitive manual business processes with automated processes.

·        Get the correct information to people when they need it, in the form inwhich they need it.

In addition, the following architectural guidelines wereestablished to govern the technical solution:

·        Create a set of standard definitions that describes core businessobjects in terminology Matrix understands (domain-specific language).

·        Create an extensible integration framework with the ability to capturecritical information from many sources and build a cohesive view of the currentstate of these Matrix Business Objects.

·        Use the Matrix Business Objects to keep subscribing business systemssynchronized and up to date using a rules-based workflow engine that can routeand handle exceptions.

·        Construct a standard set of services using the Matrix Business Objectdefinitions that can be reused for other business purposes.

Solution Approach

Matrix engaged with BST for consulting expertise and best practiceguidance on systems integration. The project team consisted of MikeMorley and Adrian Brudnicki from Matrix Solutions, and David Hebbler from BST,working over the course of a six-week Enablement Program that was establishedto provide Matrix with a hands-on, guided approach leveraging the BSTFXplatform:

·        Week 1: System design, architecture, and hands-on coaching with theFreedom Exchange integration platform offsite at BST

·        Week 2: Codevelopment and guided implementation onsite at Matrix toestablish baseline interfaces and system classes

·        Weeks 3–5: Independent programming by the Matrix development team toflesh out the working details of the solution

·        Week 6: Onsite solution review, QA testing, and deployment readiness

System Architecture

Rather than a single monolithic system to manage core businessdata, Matrix uses best-of-breed systems for each business domain. To limitscope, three key systems were selected for the first release:

·        Ceridian’s HR/Payroll Web system

·        BST Global’s Professional Services Automation (PSA) System

·        Active Directory/Exchange for network authentication and e-mail

These systems were chosen because they deal with the businessdata at the root of the entire corporation and have the largest reach in termsof impact to the user community. The Employee Identity Synchronization system’sarchitecture was designed to be extensible to allow for inclusion of otherexisting and future systems.

Ceridian

Ceridian’s HR/Payroll is a human resources and payroll managementsystem. It contains extensive amounts of information regarding the employeerequired by Human Resources to manage the employee’s life with theorganization. It is the primary system for managing employee identity, since anemployee must first be defined in the HR/Payroll system before they can existin any other corporate system. From an architectural perspective, it is the "mastersystem" for a number of the key Matrix Employee properties, such as theemployee’s ID, first/last name, company, team, address, and status assignments.

Ceridian also contains information regarding employee benefits,dependant information, health and welfare data, and so on. Much of the datastored in Ceridian regarding Employee identity goes beyond the reach of theother systems, and therefore, from the perspective of the overall Matrixorganization, is extraneous.

Because the system is hosted by Ceridian, and does not offer a Webservice API, extracting the data from the system requires traditional-stylefile-based integration.

The data extract from Ceridian contains highly sensitiveinformation such as employee names, addresses, and payroll data, so securitywas a critical architectural consideration.

Ceridian’s consulting services division constructed a CSV stylefile export of common properties derived from the data analysis exercise. Thedata file is encrypted and transmitted to a secure FTP server that is hosted atMatrix and specifically set up for the single purpose of receiving the extractfile.

BST Enterprise

BST Enterprise is a Professional Services Automation (PSA) systemthat provides financial and project management tools for firms based in theArchitecture and Engineering business. BST makes extensive use of employeeidentity information for tracking employee time and expenses, responsibilitiesand assignments on projects, and authorization to features within the BSTsystem.

BST Enterprise therefore derives core identity information fromCeridian, but contains a large volume of information about the employee from aproject perspective.

Ceridian views salary data from an annual context, and containsall sorts of information regarding reasons for a salary increase—whereas BSTneeds the salary information on an hourly basis in order to calculate and trackproject progress on a cost and budgetary basis. BST, therefore, is the owner ofthe properties associated with hourly project cost and charge rates. BST needsto know about salary increases in terms of the hourly cost rate, but does not needto know why these increases took place.

BST provides a .NET SDK (Software Development Kit) called the BSTFreedom Framework™ that enables developers to programmatically interact withinformation in BST Enterprise in real-time. The SDK uses a document-centricmodel to define its business objects, and has strict validation rules aboutwhat is required to create a valid BST Employee. Therefore, key fields from BSTare mapped into the Matrix Employee definition. In addition, to capturebaseline information required by BST but not stored elsewhere, a "default"baseline employee was established as a root mapping point.

Active Directory/Exchange

Active Directory is used at Matrix as the primary authenticationsystem, and Exchange Server is the e-mail system.

Because Matrix is very dynamic, employees will move about in theorganization frequently. It is important that an employee’s status with thecompany is kept up to date in Active Directory and Exchange.

Since an employee’s team as defined by Ceridian corresponds to anActive Directory security group, and e-mail groups inExchange, it was possible to create a set of rules that map the employee to thecorrect OU and E-Mail group automatically.

Datamart

The Datamart is a custom database that acts as the hub for all EmployeeIdentity Synchronization workflow and mapping, including:

·        Staging area for Ceridian import data (the Datamart is used as a façadeto represent Ceridian as a data source).

·        Mechanism through which the Enterprise Identity Synchronization systemtracks new Matrix Employee objects through a key table. The key table alsodefines which systems are subscribing to the synchronization.

·        Central repository to store overall state of a Matrix Business object asderived through querying all subscribing business systems.

·        Holding of any information that is specific toMatrix and is not handled by other systems. Examples of employee information thatis not provisioned by other systems are the Employee Chargeability and Hourstargets. These targets are key performance indicators (KPI) that allowemployees and business managers to track how employees are doing, with respectto goals that are set during performance reviews. These KPI are unique toMatrix, and, as a result, none of the commercial offerings has facilities formanaging them.

Matrix Business Object XML Definition

Systems typically will take on the characteristics of thebusiness domain that they are designed to serve. This has several architecturalimplications from the standpoint of identity management.

To leverage specialist knowledge associated with the businessdomain from a user experience perspective, systems will define identity objectsusing terminology associated with that domain. As a result, even identityinformation that is common across systems will be defined with differentterminology and often on a different basis than is required by systemsoperating in a different domain.

Each system contains a great deal of information that is specificto the domain in which it resides, and has no purpose outside that domain. Bygoing through each system in detail, we derived a definition of the union ofidentity that was outside each system domain. The resulting properties make upa business object that is called a "Matrix Employee." An XML-basedstandard was created to describe the Matrix Employee (see Figure 1).

Figure 1. Matrix employee business object XML

A map that defines the system owner of the properties (that is,the "master" property) and its name in the local system domain wereestablished (see Figure 2). To limit the scope, the first iteration of theEmployee Identity Synchronization system does not have a mechanism forreconciling differences between properties in different systems; therefore, a "mastersystem" is established for each property, which tells the mapping enginewhich system to use as the source for a given property when synchronizationtakes place. A more sophisticated handling/reconciling system is planned for alater release of the system.

Figure 2. Matrix employee property ownership map

Implementing Identity Synchronization

BST Freedom Exchange (BSTFX) is both an extensible serviceframework and a service host for implementing and managing enterprise servicesbased on SOA (service oriented architecture) best practices and principles(Figure 3).

Figure 3. BSTFX overview

BSTFX exposes a set of integration interfaces and APIs that givedevelopers the freedom to define and implement completely customized services,service contracts, and workflows using WCF (Microsoft Windows CommunicationFoundation) and WF (Windows Workflow Foundation).

The Employee Identity Synchronization system is implemented as aset of BSTFX services, which are hosted by the BSTFX Runtime. The Runtime isresponsible for registering and managing the services (Threading, MemoryManagement, Message Queuing, Activity Monitoring, and so on), while the ServiceConsole provides administrators with the ability to manage and monitorregistered services, including the ability to run and schedule jobs utilizingthe custom service interfaces, inputs, and settings established by thedeveloper (see Figure 4).

Figure 4. Settings in BSTFX console

The Enterprise Identity Synchronization process begins withCeridian, which produces a nightly export of employee identity data to theMatrix SFTP site. Data is picked up by a scheduled SQL Server SSIS (SQL ServerIntegration Services) package, which is responsible for taking the data fromthe SFTP server, decrypting onto that server, and then downloading the file toa secure, temporary staging location on the SQL server, where it is importedinto the Datamart (Figure 5). As an added security measure, the import processre-encrypts the salary information. E-mail alerts are sent out on success/failof the import process.

Figure 5. SSIS integration package diagram

Identity synchronization involves taking the Matrix Employee XMLobject and asking each of the subscribing systems to fill the properties theyown, validate them against the subscribing systems, and finally commit thefinal data back to each system. Doing this effectively builds a full picture ofthe current state of the Employee’s identity from all systems, and then commitsthe latest, composite version back to each subscribing system, thus bringingthe systems into sync (Figure 6).

Figure 6. Enterprise Identity Synchronization structure

Interfaces

To isolate the specific requirements of each subscribing systemfrom the overall synchronization pattern, the system is divided into twoprimary interfaces:

·        IMatrixDataSource—Describesthe requirements for a valid synchronization data source and provides the basicmethods for an object to fill its properties from the underlying data source,validate its properties against the Matrix Employee Business XML Object, andupdate any information that is mapped and synchronized from subscribing systemsback into the local system domain.

·        IMatrixService—Describes thestandard methods that must be implemented to define a valid Matrix Service thatcan be implemented to synchronize multiple data sources through workfloworchestration.

Workflow Services

The EmployeeQueue is exposed as a top-level workflow service thatis managed by the BSTFX scheduler. The EmployeeQueue workflow process isresponsible for iterating through the Ceridian employee identity list in theDatamart, determining which of the employees are new, generating a uniqueidentifier for each new employee, and registering the related employeeidentifiers from each of the other systems.

Once the new employee identities are registered into theDatamart, the EmployeeQueue process calls the EmployeeSync service for eachemployee, passing the unique identifier assigned to the employee’s identity tothe service.

Business Services

EmployeeSync loads the Matrix Employee Business Object XMLdefinition, and then calls the SelectById() method on the Employee service, which passes theXML to the DataSource layer for each of the systems that is registered in theEmployee Service.

Once the SelectById() workflow step is complete, the EmployeeSyncworkflow moves to the next step in the process and invokes the Update() methodof the Employee service using the Matrix Employee XML derived from theparticipating systems.

The Update() method first runs a Validation()pass on all the Matrix Employee XML against all registered systems, whichreturns a MatrixBSTFXValidation object. If the validation passes cleanly forthe employee identity record, the Update() method of the Employee Service calls thecorresponding Update() method on eachregistered data source, passing in the Matrix Employee XML definition (Figure7).

Figure 7. Employee Service Class diagram

Data services

Each data source provides a domain-specific implementation of Fill(), Validate(), and Update() methods of the IMatrixDatasource interface: (Figure 8)

Figure 8. DataSource classes

Figure 9. Synchronization interfaces

Figure 10. Synchronization pattern

·        ActiveDirectoryEmployee

·        CeridianEmployee

·        BSTEmployee

·        MatrixEmployee

The Fill() method maps the properties that are owned by thesubscribing system into the Matrix Business Object XML. For example, theActiveDirectoryEmployee data source will fill the E-Mail property, but will notfill the FirstName and LastName properties, which are owned by theCeridianEmployee data source.

Architecting the Enterprise Identify Synchronization system inthis manner ensures that details of the mapping, domain-specific languages andqueries are isolated from the top-level workflow and synchronization process.The top-level services and workflow services therefore only need to focus onthe implementing requirements associated with handling the Matrix BusinessObject XML Each DataSource uses the Employee ID native to its data domain fromthe Matrix Employee XML. A blank value for a given ID means that the employeedoes not exist in the system in question—in which case, default values arereturned.

If a system has knowledge regarding an employee’s identity, theDataSource layer maps the properties it owns from the local system domain intothe Matrix Employee XML definition. This process builds the overall view of theemployee’s identity from all systems registered in the Employee Service.

A successful pass through this process results in thesynchronization of the Employee’s identity to all subscribing systems.

Conclusion

The Enterprise Identity Synchronization architecture provides Matrixwith an automated framework for keeping identity up to date across multiplebusiness systems and domains.

Defining an XML-based Matrix Business Object for data used by thesynchronization architecture means that the services themselves become independentof the data they transport. This service/message pattern is the basis forcreating a full Matrix Services Oriented Architecture. The use of a MatrixBusiness Object ensures that properties used across all systems are put intoterminology that makes sense to Matrix Business, and is separate from specificsystem domains.

Because the BSTFX engine itself leverages Windows CommunicationFoundation, the actual service endpoints are separate from the communicationsprotocol they use—so that it is possible to take advantage of having multipleentry points to each of the services (Figure 11). Separating the architectureinto workflow and pure service layers that follow common patterns and contractsgives additional flexibility of being able to either call the workflow layerfrom an external client, or call the service layer directly.

Figure 11. Future systems

The enablement approach has also proven to be a powerful andeffective blend of methodology, software architecture, and best-practiceimplementation, providing enormous business value and key benefits to Matrix,including:

·        The system was constructed from architecture toinitial deployment in six weeks.

·        Leveraging BST’s expertise, while doing the actual productiondevelopment onsite at Matrix, ensured that the system would directly meetMatrix requirements.

·        Because the engagement covered the entire software cycle fromrequirements through development, Matrix resources were able to participate inarchitectural decisions and more importantly build a full understanding of thesystem.

·        The base classes and contracts created for theEnterprise Identity Synchronization are generic enough to allow for extensionof the framework not only to other systems, but to other classes of data, suchas projects, clients, and vendors.

·        All materials, including source code, architectural drawings, and system-designdocuments, were turned over to Matrix—thus, giving Matrix full access to allassets that are derived from the engagement and the ability to extend thesystem.

The flexibility of the architecture is already being leveraged byseveral new Office InfoPath systems that query the Employee service layer anduse the XML definition to extract identity data for lookup lists in the forms.

About the authors

Mike Morley is the Systems Architect atMatrix Solutions, a rapidly growing Environmental and Engineering Consultingfirm based in Calgary, Alberta Canada. His responsibilities include designingand implementing corporate systems architecture, setting direction and visionfor Matrix IT and IM based on Matrix business goals and system design,development, and deployment in support of and extending the business. Mikeholds a Bachelor of Applied Sciences in Geological Engineering from theUniversity of Waterloo. Mike has a diverse background in software developmentand design including developing three-dimensional blast design anddrawing management applications for the mining industry, enterprise softwaredevelopment at Pandell Technology Corporation, and spatial/scientific softwareincluding 3D mine modeling systems at Golder Associates. Visit Mike’s blog at http://www.menome.com/.

Barry Lawrence is the Director of SystemsIntegration Management for BST Global and is responsible for driving the visionand development of the BST integration platform. Barry’s areas of expertiseinclude Software Architecture, Quality Assurance, Project Management, andSoftware Development Methodology. Barry has over 15 of years of professionalexperience developing and leading technical teams in the implementation ofenterprise-scale software systems, including seven years as an applicationdevelopment consultant for Software Architects (Sogeti, a subsidiary ofCapgemini). Barry holds a Bachelor of Science in Marine Biology from theUniversity of Tampa, and has certifications as a Microsoft Certified SolutionDeveloper (MCSD) and Microsoft Certified Trainer (MCT).

This article was published in the Architecture Journal, a printand online publication produced by Microsoft. For more articles from this publication,please visit the ArchitectureJournal Web site.