In my discussions with consultants, integrators, and systems architects I have been noticing more interest recently around enterprise migrations of physical access control (PAC) platforms.
I asked them to help me understand the word ‘migration’, how it was being expressed with their clients, and what their lessons learned were from their engagements. I will share with you a sampling of their wisdom from my interviews.
- Enterprise Migrations (“to go from one to another”) can mean many things: Examples include:
• Any system or operational change to a new way of operating & managing the PAC’s infrastructure and technologies that impacts the whole enterprise both positively and negatively
• Moving from a centralized single server management platform to a distributed platform (sometimes referred to as ‘multi-server architecture’)
• Moving from one physical access management system to another
• Doing both (above) at the same time
• Moving from one version of a platform (software and/or hardware) to another
• Decommissioning a system to roll-back from a distributed to single server platform
• Moving from analog technology to IP technology
• Combining several ‘like’ databases into a master database with synchronization to local instances
- Change Management: Enterprise migrations are complex and involve change and new responsibilities across many stakeholders. For example: Organic growth and acquisitions can lead to independent facility or regional approaches that eventually must be rationalized. This impacts the ”owners” of these systems at a management and user level as well as their ”customer”.
- Cost and Risk Increase in direct proportion to the team’s competency (or lack of it) with migrating enterprise security systems. One consultant calls it “the tricks and traps knowledge gained by those who have done it and applied to similar situations.”
- Understand the Key Roles: Strategic planning, program and project management, lead architect (solution engineering management) and client partnerships are the key roles that must be involved in a successful migration.
- Organizational Risk and Value must be assessed across all interoperable groups to understand the baseline as well as the return on the investment. It creates the context to justify change. Example: A global consumer products and services company that goes through seasonal periods of activity that requires temporary workers. The on-boarding process must be highly efficient to ensure the security of the company by assessing, authenticating and then badging the temporary workers. Every minute in the on-boarding process takes away a minute in the customer service process. There is a direct value formula that can be applied that can help the organization understand the role of technology properly applied.
- Choose the Team Wisely: Students of change will tell you to identify all stakeholders, including the decision makers, influencers, culture keepers, and subject matter experts (SMEs). Your team will no doubt include external service providers (consultants, architects, and integrators) as well as current and future internal owners and users who must have ”skin in the game” for the migration to be successful.
- Report Findings, Strategic Options, and a Plan: At each phase of a migration there must be deliverables such as report findings, options, and contingency plans using the client’s language (Strategic, Financial, Operational) to successfully execute a migration. There are usually two pieces. One is a narrative. Remember that this is a story that is unfolding for the client that must be told at various levels of management. The other piece is the operations and technology plan that the staff (who all have different roles) must implement. A part of this plan is the detailed design document that details the integration effort. The deliverables have definitive project elements and timelines as well as the components of the migration assigned to the various stakeholders (communications and processes must be identified before the migration/implementation begins). The organization has to “prep” for this migration and help to drive it. In a big company there are multiple groups that have specific needs or problems that have to be resolved/addressed before the project starts. The report, the schedule and how they are going to do it involve all the moving parts and diligently managing them. It only takes one negative email from a corporate vice president or other communication issues to give the migration project a black eye. Too often, most security organizations believe the highest risk is in the technology, integration and technical performance of the migration. In reality, the highest risk of failure is communication. If the value is not properly understood; if the use patterns are not properly understood; if the culture is not properly understood; then the project can be derailed.
- Transparency: Jim Collins called this “the brutal facts”. It may be difficult to get people to talk about their personal and professional concerns over the migration as well as their current process or technology (tool) problems. But these must be collaboratively flushed out so that a baseline understanding can be achieved. Then a solution can be realized as well as its consequential benefits.
- Migration Knowledge and Integration Knowledge are closely aligned. This holds true in the evaluation and specification of systems as well as the migration of systems.
Throughout these discussions it became apparent that competency in a technology platform was only a small element of this migration process. Given the breadth and depth of any migration, the tipping point revolved around the team’s experience in leading and evangelizing change. Ironically, there are very few security technology architects and consultants who have robust experience in this area, especially in and around the key migration success elements detailed above.
