Mike Wyatt's Weblog
Enterprise Single Sign On (ESSO) - the Holy Grail
Though my primary Identity Management experience is with directory services and provisioning solutions, for many, Single Sign On is the ultimate "killer app." The difference between a provisioning solution and ESSO for end users is crystal clear - with the exception of end user password reset, the end user community does not typically interact backend systems like a provisioning solution. Contrastingly, having to log into multiple systems, even with a common credential set is time consuming and error prone
Any corporate user that has to remember multiple credentials (typically user name and password) can appreciate the elegance of the vision of Single Sign On. Login in one time and have access to all of the systems and data needed. There are two primary approaches (and often confused with one another) to SSO:
- Web SSO
- Enterprise SSO
One of the issues with discussion SSO is the CONFUSION between these two types of applications. Web SSO enables single sign on for web based applications, usually utilizing an LDAP directory for Authentication. Integration with Web SSO, while not trivial due to the various web and application server platforms that must be supported, is significantly easier than enterprise SSO. Enterprise Single Sign On has been the ultimate goal for a number of companies for many years. The challenges to successfully implementing an all encompassing ESSO solution are numerous and include but are not limited to:
- significantly different authentication and entitlement mechanisms
- mutually exclusive password policies
- system administrators resistance to implementing a single authentication mechanism
- general platform integration challenges
Given the technical and political hurdles to implementing an all encompassing ESSO solution, many companies are starting with Web SSO and migrating legacy applications to Web 2.0 infrastructure. An alternative approach is to focus on Reduced Sign On where an ESSO solution is implemented for only those systems which most of the end user community utilizes on a regular basis.
The primary word of warning is to a) not confuse Web SSO with Enterprise SSO and to realize the significant undertaking a full blown ESSO solution would entail
Posted at 10:54AM Nov 30, 2006 by Michael Wyatt in Identity Management |
Benjamin Wyatt joins the Wyatt Family
Thursday Nov 11th at 1:19pm CST, Benjamin Michael Wyatt joined our clan. Weighing in at 9lbs 7oz, he is already a strapping lad. Mom and new son are both doing very well. Dad is enjoying the time with the family and readjusting to no sleep. Big brother Max is adjusting as good as any 2.5 year old could to sharing the spotlight with a baby brother.
Big thanks to all of my coworkers and industry friends that have asked about Ben's arrival. Oh, yes we DID realize that his initials are BMW.
Here is a picture of Ben:
Posted at 09:04PM Nov 22, 2006 by Michael Wyatt in Personal |
A Personal Project
We are expecting the arrival of my second son tomorrow about 12:30CT (scheduled). I'm taking a few days to get to know my new son and enjoy the family. I'll be blogging again within a few days.
Posted at 03:46PM Nov 15, 2006 by Michael Wyatt in Personal |
Lessons from leading an acquisition effort
I've had the privilege of leading an acquisition effort that started about 1 year ago. The acquisition was completed in on Oct 13th. Since that time I've been the business leader in charge of running the acquired entity in addition to my day job running Sun's Architecture and Enablement services team for the Software Practice.
One of the lessons that is continually reinforced is the need for clear, concise, and consistent communication to various internal and external stakeholders. Much of my time is spent educating and informing internal groups about the objectives of the acquisition and the status on the integration. When you live something like an acquisition effort for a period of months, things are are seemingly obvious to you are definitely not obvious to other stakeholders, many of which will see things through a very different lens than your own.
In order to ensure that the key members of the integration effort including members of the acquired entity leadership team as well as leaders from the acquiring company are all singing from the same song sheet. The amount of investment to initial craft the key messages pales in comparison to the effort to overcome miscommunications.
Posted at 11:42PM Nov 13, 2006 by Michael Wyatt in Business Leadership |
Great Expectations
One of the folks on my staff asked that I talk about Expectation Management or the lack thereof in Identity Management deployments. In my entry on the Cone of Uncertainty Uncertainty is typically highest at the beginning of the project. The early coversations during the sales cycle for the solution can have lasting effect - positive or negative - on the customer's expectation for the solution. When I worked at Tivoli, we used to have a saying, "Never confuse Selling with Installing." This is something that customers should keep in mind as well. We all realize that a "perfect fit" solution is as ellusive as the fabled Unicorn. As professionals, we need to present our solutions in the best possible light without creating a situation where the customer feels like they were sold a "bill of goods." Areas of risk of inappropriate expecation setting include:
- Level of Effort to complete the project
- Project Duration
- Customer resources / time commitment required for the project
- End user experience using the end solution
- Skill set of the person or team that will have to support the solution after the production
- Level of effort to create or "tailor" a resource adaptor or connector to connect to a managed system
- Level of effort to change default out of the box capabilities to customer specific use cases
- Price of the professional services to implement the solution
Posted at 12:42PM Nov 10, 2006 by Michael Wyatt in Identity Management |
Just say No to customization!!
One of the biggest issues with enterprise software implementation, including Identity Management, is the desire by the team architecting the solution to "tailor" the implementation to meet every conceivable use case. A new article entitled, "Resist the Urge to Modify draws a great analogy between drinking coffee strait or drinking coffee with cream and sugar. Check it out.
This article points out many of the long term costs of modifications that really are not truly needed.
Message - go for the 80% solution and invest in change management rather than non-standard custom configuration work. It will pay much higher dividens over the long haul.
Posted at 02:08PM Nov 08, 2006 by Michael Wyatt in Identity Management |
Burton Group Blog
Normally I delete bulk emails without a second glance but one tonight caugh my eye. Its an email from the Burton Group about their Identity Management and Security Blog
I'm a Burton Group fan. They have both good content (Sun is a subscriber) and balanced analysis. Their Catalyst confererences in the US and EMEA are also key Identity Management focused user & vendor conferences.
Posted at 11:10PM Nov 07, 2006 by Michael Wyatt in Identity Management |
Ten Unmyths of Project Estimation
I ran across an article that I like about Project Estimation myths, or as this the author Phillip Armour states, "unmyths ...are truths that, when we look closely at them are not, well, true." The article, Ten Unmyths of Project Estimation covers a variety of topics such as:
- Accurate Estimates
- Project End-Dates
- Estimate vs. Commitment to the Estimate
- Project Estimate is proportional to size of final project
- Historical Data is an accurate indicator of productivity
- More People will get the project done faster (my favorite)
- Defect Free software as an achievable end state
Posted at 10:18AM Nov 07, 2006 by Michael Wyatt in Identity Management |
Steve McConnell and the Art of Enterprise Project Management
One of my favorite authors on how to do Project Management right is Steve McConnell. Steve has written a variety of books on both software coding practices as well as project management.
Let's be honest - Identity Management implementations are more closely aligned with an application development project than installing an office productivity tool like OpenOffice. Yes, there is an enterprise software solution providing the foundation for the implementation; that said the specifics of the deployment are in various configuration files. In addition, Identity Management solutions, by definition touch other systems such as LDAP, RACF, RDBMS systems etc.
he approach you need to take with implementing an application development effort is analogous to the approach required for an implementation of Identity Management software. What are aspects of an Identity Management solution project?
- Requirements need to be defined / agreed upon
- The solution must be designed
- The solution must be architected
- The solution must be configured / built
- The solution must be validated and tested
- The solution must be promoted into production
- The solution must be managed after implementation
- The project must have change control
- The implementation team must use Source Configuration Management such as CVS
- The project needs a defined governance approach
- etc...
Posted at 10:32AM Nov 06, 2006 by Michael Wyatt in Identity Management |
Time and Materials Projects
The most common pricing structure for Identity Management projects, especially large enterprise deployments, is Time and Materials. With Time and Materials projects, there are several approaches, two of which are:
A customer contracts with a service provider for a resource at a specified rate for some duration. There are no specific deliverables associated with the engagement. At Sun we use an artifact called a Consulting Services Agreement or CSA. Usually for short duration general consulting engagements.
A Statement of Work(SOW) is created which includes specific deliverables and pricing for the resources that will perform the work. The SOW usually provides an hourly or daily rate for each resource that will work on the project. The scope of the work performed is typically described in the SOW. Though not included in many SOWs, #Items that are specifically out of scope should be clearly stated as well.
The biggest concern from a customer perspective is that though specific deliverables are listed in the SOW, when the money runs out, there is no obligation to finish the work, or the customer winds up paying for unbudgeted additional hours to complete the deliverables. One way to address this is to have performance criteria in the SOW that protects both the customer and the service provider regarding specific deliverables that must be met in order for the project to be considered complete. Another approach, which I think potentially better is to have a tiered rate structure that at the point the original SOW runs out of hours, future hours are paid but at a lower rate.
One of the biggest risks I've seen in T&M projects is lack of strong project management and project governance. At times the service provider assumes that their job is to work through the project and bill hours. The customer assumes that the deliverables outlined in the SOW are firmly committed. Only when the money is close to gone or gone do the two parties have a hard conversation. By this time, its too late. Even with T&M projects, it is critical that both the customer and the service provider adhere to change control and progress against the plan. Scope creep is often a problem especially if the service provider has resources working at the direction of the customer without a service provider provided project / program manager to buffer the technical resources. I have personally had superstar architects agree to work that is out of scope because they want to solve hard problems and want the customer to be happy with them. When asked to "just let the customer" provide the project management and oversight, I get very nervous. Checks and balances are needed.
Posted at 03:52PM Nov 03, 2006 by Michael Wyatt in Identity Management |
