Burton Group’s Catalyst Conference: Dipping your toes into the Cloud

One of the more interesting sessions that I attended today discussed cloud security and some of the key issues organizations face when moving data across open, untrusted networks. These issues include the limitations of available security models, clear definition of data ownership, lack of visibility into incident management and resolution, and the need for comprehensive auditing. I walked away with the belief that the current vendor models offer customers too little control over their own data and applications to be viable in their current form.

Despite these challenges, cloud computing offers a number of benefits that make the solution an attractive opportunity, including reduced application deployment times, increased storage, reduced administration, and a pay-as-you-go model that matches expenditures with usage levels. Based on the sessions I attended, I believe that there are four fundamental areas that need to be addressed by vendors to make the cloud an attractive solution:

1. Better define and implement Data/Application Security


2. Provide incident management either directly, or facilitated through a trusted 3rd party


3. Provide Audit and Compliance functionality


4. Define an exit strategy for customers so they can bring data and applications back in house easily without incurring undue risk (e.g., loss of data)

Burton Group Catalyst Conference: Roles-Based Access Control Highlights

Today was the first day of the Catalyst Conference general sessions and a number of the sessions that I attended were focused on Identity Management and in particular RBAC. At Big Sky we have always asserted that Identity Management begins with defining the core business processes behind on-boarding and off-boarding users (employees, contractors, etc.) It’s nice to hear from the Catalyst presenters that organizations that have experience in implementing RBAC have a similar point of view; successful implementations start with the process and not by mapping system privileges. Begin at the top and drill down to the details. A summary of the key areas that need to be understood when defining roles:

1. What does each person do in their position? (e.g., DILO study of work processes)
   
2. How do we optimize the processes for that position? (What are the value-added decisions and activities), and then
   
3. Understand what applications that person needs to be effective within that process. (Determine how to best accomplish tasks and share information)

The roles definition will naturally fall out of this exercise and allow the business need to drive the IT implementation. After all, the effectiveness of the roles you define depends on properly matching the right entitlements with the right user in the right position.

Key Takeaways from The Burton Group’s Catalyst Conference.

I managed to gain some good insights today from two Catalyst Conference presentations on cloud computing / virtualization. Both speakers, Chris Wolf from the Burton Group and Mark Templeton from Citrix, emphasized the need for organizations to make deliberate changes to their business processes to successfully implement virtualization on any level. For most large scale change efforts like virtualization, the problems (and failures) often come from the people and processes, not from the technology. After all, technology just does what it’s told. To ensure success, organizations must take a step back from the actual technology to determine what organizational processes are in place now and how those should change in the future vis-à-vis the planned solution. Based on the speakers’ experience, organizations that are most successful with virtualization projects have made a commitment to analyze and change organizational processes as a first critical step to foster solution adoption and to maximize the delivery of business value. The successful implementation of any technology is never an isolated event as it profoundly affects both people and processes. An organization must recognize and plan for this disruption.

Dangers of Scores in Decision Making -- From James Taylor

James Taylor, who we've referenced on this blog on several occasions, shared his thoughts today on the dangers of scores in decision making. He provides a great example: the Body Mass Index (BMI), which is fraught with issues but is nonetheless used inappropriately by companies and health officials alike.

I've seen the misuse of scores or other numbers in some of the organizations served by Big Sky. When a model is developed that produces a number or a score -- such as with Analytic Hierarchy Process, Statistics that measure strength of relationships, or even simple weighted averages -- there are many who focus too narrowly on the number without context, or fail to realize its limitations. For example, we will often help clients use quantitative methods to prioritize budgets, but the numbers that "pop out" are really nothing more than measures of preference; they are not truth. In many cases, they aren't useful measures outside of the model, and can't even be compared to previous analyses using the same method.

Scores must be balanced with other factors -- which James correctly points out can be codified in rules and often automated. For those decisions that can't be automated because they are inherently more political or are subject to other unpredictable factors, the limitations of "scores" should be carefully and frequently communicated to all stakeholders to avoid confusion or misuse.

Thanks to James for a great post.

Role-Based Access Control – Introduction – PART I

Knowledge and innovation are key factors contributing to growth and prosperity in a service economy and require an information framework that organizes and makes information available when and where it is needed. The challenge facing organizations is not just in managing organizational knowledge, but in determining who should be given access to that knowledge. This Blog entry offers an overview of the latest set of tools known as Role-Based Access Control (RBAC) that provide a security model to manage access to sensitive organizational information.

Historically, organizations have granted access to their applications and data through a security system that is based on application-level administration to grant and deny access to resources. Administrators had to maintain a list of rights for users known as Access Control Lists, or ACLs, to manage system access. As the number of applications and users grew so too did the administrative burden of maintaining ACLs. Furthermore, the security risks to the organization increased because administrators had no effective tools to promptly remove users who should no longer have access to systems. These problems are eliminated in an RBAC security model, where user access is administered dynamically through Roles.

As organizations have opened up their networks to the Internet, securing their information resources has become much more complex. It is a difficult balance to strike between protecting customers, employees and shareholders from potential risks or losses and the need to achieve organizational goals efficiently and effectively. While many would argue that the security is a cost of doing business, the increased expense and effort required to implement effective security models becomes daunting as information is made widely accessible beyond organizational boundaries. This challenge can be mitigated, however, by Role-Based Access Control, which allows organizations to automate security decisions about who has access to what.

A Role has a set of permissions and by placing a user in a Role, that user is granted access to the systems or resources associated with the Role. Users are assigned to one or more Roles, and each Role is associated with a permission or set of permissions to IT resources. In this way, a Role establishes the relationship between the users and the systems that they are authorized to access and provides a much more efficient way to decide who has access to what resources. Organizations no longer have to work at the application or system level, instead they can use roles to assign the appropriate permissions en masse. As a user’s responsibilities change (i.e., they are promoted or move divisions) they are removed from their old roles and placed in new roles based on their job title.

Let’s walk through a quick example. Bob is hired by ABC, Inc. as a Financial Analyst I and gets assigned to the Base User Role, which grants access to the network, email, and the time & expense system. Bob also gets assigned to the Financial Analyst Role as is granted access to specific financial systems and reports required for his position. A couple of years down the road, Bob moves to Accounting and takes a position as Accountant II. As his position changes, he is automatically removed from the Financial Analyst role and assigned to the Accountant role, losing access to those systems he no longer requires to perform his job and gaining access to the accounting systems that he now needs. The end result is that security is implemented more efficiently and effectively and administrative holes (e.g., removing users from systems they no longer require) are eliminated. The question is “What do we need to get there?” which will be the subject of my next entry.

"Lean Won't Work Here" -- Post by Mark Graban of Lean Blog

This morning I ran across this excellent post by Mark Graban on Lean Blog that walks through a short history of how organizations have crafted various reasons for why Lean won't work for them. He starts with the automotive industry and ends with health care - but in each case, the industry leaders adopt lean and the laggards fall behind. Each justification for resistance begins with "we're different . . . . ".

Big Sky uses lean principles for many of our clients, but we too have found that there is significant resistance to overt Lean or Six Sigma projects. Many clients are turned off by what I would call "true believers" -- practitioners who are unwilling to let go of by-the-book implementations of lean or six sigma methodology. The practicioners' or consultants unwillingness to be flexible or adapt their approach to the unique client situation dooms adoption of lean in the organization and everyone suffers are a result.

The bottom line, however, is that I have yet to find a process in any organization that couldn't be improved using at least some of the Lean or Six Sigma toolkit. Every client and every organization really is different -- but that doesn't mean that Lean/Six won't work. It does mean that Lean and Six Sigma must be applied differently. The real finesse comes with educating the organization in a way that isn't threatening or dogmatic, but brings them along at just the right pace.

Thanks to Mark and Lean Blog for a great post that I will surely be sharing with many of my clients.