Role-based Authentication and the A-Z Profile Spec
January 25th, 2006
Member profile content - a-z
Our first quick reaction is that the a-z profile specification is a good, comprehensive list of the whole “landscape” of a member’s profile. In software development modeling terms, this list would be part of the domain or system boundary model.
In practical terms, that is the world of identity theft and cyber-harassment, we’d recommend that the a-z content of member profiles be wrapped with a role-based permission system where you could have two levels of control:
- First, LiA should have an overall policy about who gets to see what no matter what the member decides.
- And the second layer is a degree of latitude that each member would have to further tighten or perhaps loosen (within limits of LiA liability to protect its members) such role-based information access.
While this level of functionality may sound complex to incorporate into the LiA web platform, it is not as hard as it sounds. You start by selecting the right (hopefully Open Source) framework for content management and eCommerce that has flexible and extensible role-based authentication built into it. Many such platforms do have this feature. Setting up content creation, deletion, update, and view rights under such systems is a browser-based admin function, not a matter of programming.
Some Next Steps for A-Z
From a software development consulting standpoint — with you as the client and subject matter expert — our next questions/exercises would be to ask you:
- How would you logically cluster the a-z list from the point of view of its role-based viewers?
- What process-based linkage do you you see between items on the a-z list?
The first question gets as the next step of prototyping the user interface and information architecture of the to-be LiA web platform.
The second question begins to address the workflow aspects of how the a-z information relates to role-based use cases of “What is a typical day or task for someone performing X role?” For example, certain of the a-z information is known and member-person specific, so every new member would be know and need to provide this information at the first step of member account creation.
Other bits of the a-z specification are dynamic and can be generated from the member’s activity, such as the list of blogs the member is active on. The same with info about loan servicing activity, etc. In other words, some of the profile is explicitly created and maintained by the member, and some is gathered by examining the state of data in the overall system. This is the kind of information and understanding that is needed to begin building the to-be LiA web platform.
Building the Software Infrastructure for Globalization 3.0
Christina, this is just scratching the surface of what a business process-oriented software designer/developer would do with you in a working relationship to build the LiA web platform. In this sense, the software design and development process for an organization/business is very much like the process of psychological therapy. It is a rigorous and detailed process of self-reflection and values-surfacing that is uniquely valuable to the evolution of the business or organization.
The most interesting thing about the LiA/WE/I4C network is that it is an ideal and real example of what Sohodojo describes as an entrepreneurial community ecosystem. The web-based software platform required to create and sustain such an ecosystem is one of the most important and valuable things that needs to be done in order to unleash the alternative market-creating potential of what Tom Friedman calls Globalization 3.0, that is the Flat World of Empowered Individuals. The LiA/WE/I4C ecosystem is, in other words, a First Mover in Globalization 3.0.
–Sohodojo Jim and Timlynn–
Entry Filed under: Globalization 3.0 and the Small Is Good World, Life In Africa Group, Tech Talk
Role-based Authentication and the A-Z Profile Spec
January 25th, 2006
Member profile content - a-z
Our first quick reaction is that the a-z profile specification is a good, comprehensive list of the whole “landscape” of a member’s profile. In software development modeling terms, this list would be part of the domain or system boundary model.
In practical terms, that is the world of identity theft and cyber-harassment, we’d recommend that the a-z content of member profiles be wrapped with a role-based permission system where you could have two levels of control:
- First, LiA should have an overall policy about who gets to see what no matter what the member decides.
- And the second layer is a degree of latitude that each member would have to further tighten or perhaps loosen (within limits of LiA liability to protect its members) such role-based information access.
While this level of functionality may sound complex to incorporate into the LiA web platform, it is not as hard as it sounds. You start by selecting the right (hopefully Open Source) framework for content management and eCommerce that has flexible and extensible role-based authentication built into it. Many such platforms do have this feature. Setting up content creation, deletion, update, and view rights under such systems is a browser-based admin function, not a matter of programming.
Some Next Steps for A-Z
From a software development consulting standpoint — with you as the client and subject matter expert — our next questions/exercises would be to ask you:
- How would you logically cluster the a-z list from the point of view of its role-based viewers?
- What process-based linkage do you you see between items on the a-z list?
The first question gets as the next step of prototyping the user interface and information architecture of the to-be LiA web platform.
The second question begins to address the workflow aspects of how the a-z information relates to role-based use cases of “What is a typical day or task for someone performing X role?” For example, certain of the a-z information is known and member-person specific, so every new member would be know and need to provide this information at the first step of member account creation.
Other bits of the a-z specification are dynamic and can be generated from the member’s activity, such as the list of blogs the member is active on. The same with info about loan servicing activity, etc. In other words, some of the profile is explicitly created and maintained by the member, and some is gathered by examining the state of data in the overall system. This is the kind of information and understanding that is needed to begin building the to-be LiA web platform.
Building the Software Infrastructure for Globalization 3.0
Christina, this is just scratching the surface of what a business process-oriented software designer/developer would do with you in a working relationship to build the LiA web platform. In this sense, the software design and development process for an organization/business is very much like the process of psychological therapy. It is a rigorous and detailed process of self-reflection and values-surfacing that is uniquely valuable to the evolution of the business or organization.
The most interesting thing about the LiA/WE/I4C network is that it is an ideal and real example of what Sohodojo describes as an entrepreneurial community ecosystem. The web-based software platform required to create and sustain such an ecosystem is one of the most important and valuable things that needs to be done in order to unleash the alternative market-creating potential of what Tom Friedman calls Globalization 3.0, that is the Flat World of Empowered Individuals. The LiA/WE/I4C ecosystem is, in other words, a First Mover in Globalization 3.0.
–Sohodojo Jim and Timlynn–
Entry Filed under: Globalization 3.0 and the Small Is Good World, Life In Africa Group, Tech Talk
Trackback this post