Checkpoints for Upstream Phases in the Unified ID Infrastructure Project

In our last discussion, we clarified the business goal behind the need for unified identity platforms—particularly focusing on their practical applications. This time, we'll organize the key considerations to keep in mind when implementing a unified ID system.

We sincerely hope those considering implementing a unified ID system will find this valuable reading.

Verify the timeline for your digital service deployment plan

As a fundamental principle, since the primary purpose of implementing a "unified ID infrastructure" is to enable multiple digital services to utilize it, it is necessary to systematically organize the deployment schedule for all upcoming services—both new offerings and those already in development.

For instance, if new services have already begun development, the ID management functionality should be implemented independently, with subsequent migration requirements being a key consideration for the unified ID infrastructure project. To minimize or eliminate the need for migration, it is necessary to plan the evolution of the unified infrastructure through phased implementation while determining the initial set of functionalities the unified ID infrastructure should provide.

<Key Points>

• Reviewing the web application deployment plan for the coming 2-3 years
• How should we approach the integration of existing web applications?
• What migration/new implementation strategies should be adopted?

Additionally, we must consider which technologies/services are most appropriate for maintaining both speed and continuous development. When prioritizing speed and considering functional updates, open-source software development often presents numerous obstacles, while utilizing SaaS solutions can significantly improve development speed and reduce maintenance overhead.

Assess whether any existing services need to be migrated

As briefly mentioned in the previous section, alongside scheduling considerations, if multiple existing services exist, users registered to those services will need to be migrated. We must clearly identify the implementation technologies for ID-related functions (user management, login authentication/authorization) for these existing services.

While detailed technical specifications will be defined during the requirements definition phase, initially conducting a preliminary assessment of migration requirements and their complexity can help verify whether the requested schedule is feasible.

<Key Points>

• Is user migration from existing services necessary?
• If required, identify the specific ID-related technologies used in those services.

Understand the service delivery model and contract structures

Service providers offer various service delivery formats. Broadly speaking, similar to terms like B2C and B2B, there are classifications such as consumer-oriented services and business-oriented services. Additionally, services may be provided to individuals through business partners (B2B2X model), or they might target partner companies exclusively.

Furthermore, there are classifications regarding whether service usage is by individual users or by organizations as a whole.

Whether to treat each user as a single entity depends on whether charging occurs at the individual level or at the organizational level (e.g., charging teams, departments, or companies for service access).

From a development perspective, these factors must be carefully considered in advance. If these details aren't properly organized, making changes to user/organizational design could result in significant modifications - making this a critical point to watch out for.

When offering multiple services, variations may exist such as Service A providing only Free and Paid options, while Service B offers three tiers like Basic, Standard and Premium, where available features differ by tier. Since this closely interacts with ID management, any predetermined specifications should be clearly documented in advance.

<Key Points>

• Clarify whether your services will be B2B (business-to-business) or B2C (business-to-consumer), and clearly define the target user profile.
• Conduct thorough research on each service's contract models and terms.

Clarify the responsibility boundaries for user attribute data

Since this becomes quite technical and will likely be finalized during the requirements definition phase, a more upstream consideration should be determining what user information the service needs to collect overall and where that data can be acquired.

For example, for standard user information, it may be preferable to gather and manage this through a portal service serving as the entry point for the entire service. If no such portal exists, an ID registration/login function could be designated as an ID service to handle data collection and management.

Without clearly defining the overall service architecture, you risk requiring users to provide redundant information, leading to degraded customer experience. Additionally, since data exchange between services will inevitably occur, service planning requires clearly establishing responsibility divisions regarding which services should collect which data.

There may also be possibilities for integrating these data and viewing them through a dashboard. Re-organizing your specific data utilization vision is crucial for identifying effective next-step applications. Furthermore, system integration with CRM and marketing automation platforms is likely to become necessary (since excessive expansion would quickly become unmanageable, this should be handled as a separate project focused on determining what data should be exchanged).

<Key Points>

• Based on the overall service concept, clearly define which services will collect which user attribute data
• Specify how these user data will be utilized and clearly identify the data to be transferred

Design the application onboarding process

The term "onboarding" is best understood by imagining how new employees or partner companies become authorized to use your services. For example, when issuing Microsoft accounts to partner companies to enable SharePoint service usage, the process typically involves completing some form of application, after which the administration department will issue the credentials within 1-2 weeks.

This highlights whether administrators will manually add users or if users themselves will register their IDs through the service—a key aspect to clarify.

If administrators will be adding users, you'll need to develop user interfaces for administrative management of services (which will almost always be necessary), while also determining the appropriate level of user experience and security requirements. For B2B services targeting IT-savvy companies, implementing multi-factor authentication methods like Google Authenticator can enhance security. However, for B2C services serving diverse user segments, offering various authentication methods—including social login, SMS verification, and passwordless authentication—may be necessary to accommodate users' familiar methods.

Developing an onboarding strategy will naturally reveal numerous additional considerations.

<Key Points>

• How will your service handle user registration?
• Clearly define your target users and establish the appropriate balance between user experience (UX) and security requirements.