The New DevSecOps Positions

Finding good people especially in this market is hard. Historically low unemployment makes it difficult. Finding good IT talent, developers, engineers, architects, analysts, etc. is even more difficult. Getting the right person with a passion for their technology, an intrinsic motivation like making a difference, or collaborating with others on game changing technology, and someone who can communicate and cooperate with others from diverse backgrounds is difficult. These are all generally understood and the market tends to reward those with that rare set of skills and motivations.

Specialists are even more difficult to find. Developers with just the right mix of UI, experience with Ruby or Python or Go, and experience with your framework of choice. Security specialists with Threat Intel, SIEM, Threat Hunting, IAM, Forensics, Endpoints, and so much more are hard to find. Engineers with experience on just the right version of Linux, open source software, patching, networking, and more are equally difficult. These specialist with just the right certifications command a premium.

As technology has evolved new hybrid positions have come to exist. Consider the Cloud Engineer, or the Site Reliability Engineer, the Data Analyst, the Data Privacy Officer, all combinations of one or more specialties. As the need for these hybrids have increased and the number of people with the relevant experience dwindles, companies have been forced to promote and grow people with experience in one half of the equation while learning the other half. Most cloud engineers are former systems admins who were thrust into the world of AWS, Azure, Google Cloud, etc. and learned their position through on the job training with a mix of new certifications. So too the data analysts, taken from the ranks of business analysts and taught all about SQL, statistics, probability, as well as the new tools and technologies therein. These Data Analysts have to relate their newfound insights from data back into business terms.

The world of DevOps is no different. The DevOps engineer usually comes from a developer or engineering background and learns the other half of the trade. Developers learn the systems covering things like Continuous Integration or Continuous Deployment. Engineers learn about source control management systems, integrating software testing tools, and scripting. And as more and more of the Continuous Deployment landscape moves to containers and Infrastructure as Code, Engineers are finding they have to learn more about writing code.

Enter the DevSecOps Engineer. These positions are the new ‘unicorns’ of hiring. The DevSecOps engineer has a background in software development, application security and testing, as well as an engineering background for linking all three of these disciplines together. While DevSecOps has been around for a while it seems there are very few with titles reflecting the discipline. Hiring for senior positions yields quite a few resumes with a DevOps background. By and large, the majority of DevOps candidates are engineers who made some tentative moves into software development. So few have skills in languages like Ruby, Python, or Go. Moreover, gauging their skillsets by way of public code repositories or contributions to open source projects would seem a wise approach. Another consideration is hiring senior software developers with a basic understanding of systems administration or DevOps and teaching them application security.

The true DevSecOps professional will have to have a more well rounded resume. Modern concerns include securing Kubernetes which brings application security concerns back to system security concerns like securing the kernel, isolating processes and access, and protecting the whole with advanced networking controls. DevSecOps engineers will also have to address the need for sending telemetry to security operations systems from cloud based applications and platforms. Dynamic DNS, infrastructure as code, programmable certificate management, secrets management, encryption as a service, and log aggregation at scale for both systems, infrastructure, and applications are all in the purview of the modern DevSecOps leader.

New DevSecOps positions will include hybridizations of older hybrids. Security focused Site Reliability Engineers or SSRE’s will take on the role of supporting application development teams with the various technologies and disciplines of DevSecOps, things like Threat Modeling, leveraging security pipelines, and securely deploying your applications, on-premise or in the cloud. Agile software developers will become security software developers, building out the new software based DevSecOps tech stack. And of course there will be the need for the architects who can tie it all together, who have or support the vision of DevSecOps in the enterprise, can develop the needed reference architectures, work collaboratively with people in technical and managerial roles, and guide their team mates in maturing your program.

There are few if any certifications in this new DevSecOps realm. There is no governing body suggesting this person or that is a certified DevSecOps architect for instance,.Reliance on metrics like positions held, time on the job, or responsibilities are no longer sufficient. The new paradigm has to shift to a focus on accomplishments and demonstrated abilities. What did you build? What can you do? How well do you fit in our corporate culture? What are you passionate about doing going forward? These are the new focus for the modern DevSecOps hiring manager. What can you offer to entice these newest ‘unicorns’? A salary commensurate with their abilities, an environment of transparency and collaboration, the opportunity to make a difference, and an environment where they get to work with best of breed and cutting edge technologies. Expect to compete with the biggest and best companies around as this very limited pool of resources is highly sought after.

Where will this talent come from? Should you look for people with more systems administration or software development in their background? My background as a software developer makes me lean towards the software developers. Good software developers have the right mindset. They understand programming languages in the context of the underlying systems they run on as well as networking. They understand the relevance of their software as it impacts the business bottom line. They have a basic understanding of security as it applies to systems, software, and the business. And most importantly, the best software developers have an insatiable curiosity. These are hackers in the very best meaning of the word.

As more of our modern security stack moves to virtualized or cloud based systems, the importance of DevSecOps will grow. I fully expect that eventually the worlds of application security and ‘traditional’ security will merge back into one. The future of that world belongs to these new DevSecOps positions.

Ode to a MacBook Pro (13" with retina display)

Trying to show my oldest son how to write sonnets, did one (in iambic pentameter) about the first thing that came to mind.

Ode to a MacBook Pro

Gleaming silver surrounding a white fruit

The Apple is the best friend for me

Its sleek design, form and function do suit

It’s backlit keyboard so easy to see

The retina display a work of art

4 million pixels a window for all

Its solid-state drive that touches my heart

Its noiseless performance; a siren call

So light like a feather, cold to the touch

Yet fast like a cheetah this cat can run

The press of a button that does so much

Homework and learning transformed into fun

Oh MacBook Pro I admit my desire

You make my geek heart glow with burning fire

Addicted to devices or indentured to work, is that the only two choices?

One of my favorite movies HEAT has a scene where Vincent Hanna (Robert Deniro) is trying to convince one of his long time associates, Michael Cheritto, to back out of a job and retire. The score isnt worth it considering the heat (the police) involved. Cheritto replies "Well ya know for me, the action is the juice." meaning the payoff for him isnt the reason he does the job, the adrenaline, the action, is the reason he's addicted to robbing people. I've thought alot about that line over the years and it rings true for me and my relationship with my job and my employer.

 The New York Times article "Silicon Valley Worries About Addiction To Devices" suggests we are addicted to the rapid reward we get from devices and the interaction much like people are addicted to the Internet, video games, sex, gambling, drugs, etc. I can see this point of view and there is some truth to it. How else could you explain the record profits of folks like Apple and others. Tech junkies get off on tech and I am certainly one of them. But thats not the whole point.

 The Atlantic countered the NY Times article with a cheeky but point on retort that we're not addicted to our devices as much as we are slaves to our employers and our jobs. There's a pale indictment of big business behind all of this BUT the real point is that we collectively feel like slaves to our jobs because it allows the for a 24/7 work schedule. Again, there are times when work interferes with life and there's always the pressure to keep up with the sycophantic few who try to impress with the post 11p emails. But again, thats not the whole point.

 This brings me back to my initial discussion of HEAT in that I am very much like Michael Cherrito. I dont go to work for the paycheck, I am not addicted to my devices because of some dopamine receptor or tyrannical employer. I go to work because I get off on the action and I always have (and hopefully always will). My vocation is my avocation. My job allows me to create. It delivers the creative tension between whats possible and impossible. Its the Spartan agoge and the Athenian forum all rolled into one. I work with super smart and motivated people. I believe we collectively share a passion/addiction for making a difference, for doing something awesome and worthy of my time on earth.

 And I believe a great many people in technology are just like me, they get off on the job for the same reasons I describe. We have strong families and love our children, we enjoy our hobbies and our time off. We have some semblance of work/life balance although my wife will occasionally disagree. I feel fortunate to work in times like this. I enjoy the current technology zeitgeist. Its empowered me rather than enslaved me.

The Story of 'O' products

Its come to my attention lately there's a LOT of confusion about what the litany of 'O' products ('O' being Oracle). Given Oracle's choice to name everything after itself you end up with a myriad of 'O' products in three and four letter acronyms. Coming from a background of Microsoft products where almost every year the product was renamed to something entirely different for no rhyme or reason (see MIIS to ILM to FIM), I am OK with Oracle renaming everything it buys to "Oracle" something. Still there's a lot of confusion about the products and what they do. Given the recent acquisition of Sun products and there subsequent renaming there's lots of speculation that the products overlap or worse, compete. Some examples, OAAM or Oracle Adaptive Access Manager, OAM or Oracle Access Manager, given the names one might think the products are competitors. Naturally in today's business environment where every penny counts as businesses guard their cash reserves you wouldn't want to put anything into production with an overlapping or competitive function. As such, I've been repeatedly asked about things like OIM, OID, OIA, and OAAM and whether they are serving the same function. This post is my attempt to provide some insight as to how those products interact, what purpose they serve, and our roadmap for implementing them.

A good visual is invaluable to show the relationship between the parts of the Oracle Identity Suite. Here's the interaction as presented by Oracle for their products and respective niches they fill:

We're currently implementing the foundation for good Access & Identity Management which is good role based access and role governance. This is served by Oracle Identity Analytics or OIA. OIA will allow us to move away from the very manual of process of managing roles today by spreadsheet and SQL Scripts. It will also allow us several key improvements; separating our AIM systems from any and all legacy databases, moving away from the tight coupling of roles (access) to job codes and cost codes, and finally associating access with job functions and responsibilities in the form of enterprise roles. Having a solid grasp on roles is fundamental to our efforts and will provide a multitude of benefits to us, our customers, and the business.

We're also implementing Oracle Internet Directory or OID which will allow us to govern access to Oracle databases. Oracle Internet Directory (OID) is an implementation of LDAP (lightweight directory access protocol) and allows end users to access Oracle databases with their network credentials. This allows us to tie back access to Active Directory as our single point of control for all access in the enterprise. OID will also allow us to manage authorizations in Oracle databases via membership in LDAP (OID) groups, groups governed and approved by the database owners. So Business Intelligence database access will have to be approved by the Business Intelligence team, CRM database access will be controlled by CRM team, etc. All of this access will be requested, approved, and authorized through a single site, the Computer Access Process or CAP.

The CAP itself will get a facelift this year and we're going to improve and extend our provisioning process (see Identity Administration) as we implement Oracle Identity Manager or OIM. OIM will allow us to move away from our Microsoft based workflow engine, which has served our purposes admirably but not without its challenges, and allow us to begin to use OIM's connectors for expanded provisioning to the eBusiness applications. OIM also promises tighter integration with the Oracle owned applications like PeopleSoft and the rest of our Oracle Identity Suite products like Oracle Adaptive Access Manager (OAAM) and Oracle Identity Federation (OIF), two technologies we're going to implement in the next 4-6 months as well. More on Oracle Adaptive Access Manager and Oracle Identity Federation in a future post.

So to RECAP:

OIA: Oracle Identity Analytics - role management, a foundational piece (database) for role based access and role governance.

OID: Oracle Internet Directory - a directory implementing LDAP which will allow us to authenticate Oracle database users via Active Directory and authorize them based on membership in groups (roles) governed in the near future by OIA (no dependency).

OIM: Oracle Identity Manager - a workflow and provisioning engine for extending and enhancing the administration of identities.

OIF: Oracle Identity Federation - a means for federation of our identities with partner organizations. Federation via standards, plain and simple.

OAAM: Oracle Adaptive Access Manager - strong authentication and knowledge based authorizations for websites. Coupled with its capabilities for real time fraud detection and prevention this tool will serve a variety of purposes.

The Future of Identity @myJob

Identity is changing. Our initial focus was on controlling and provisioning access to key systems for purposes of satisfying Sarbanes-Oxley audit points. Identity was the afterthought, access was king. Our name for a long time reflected that, the Access and Identity Management (AIM).

More and more we’ve been moving towards becoming the Identity Information brokers. It hasn’t been easy. Our customers have continued with their demands to get their applications added to our Computer Access web site (CAP). The business has demanded easier access for new hires which gave birth to the ‘On-boarding’ project. The folks in Compliance and I&T still have an audit point to satisfy with regards to privileges granted roles in each application, and likewise privileged access to systems and databases. Throughout all of this we’ve been in the process of upgrading out metadirectory server for nearly a year now.

But as we’ve been completing these projects, my attention has been drawn to what we’ll need in the next 12-24 months. Here’s some of my conclusions of where we are headed in the Identity Management:

1. Being the identity information brokers doesn't mean we have to build a monolithic database (and schema) to house every little last bit of information about our users. For one, we should only build out relevant information as it relates to identity or is consumed by another application or end user. Likewise, we’ll never agree on a naming convention, etc with all of our end users. Instead we should look to support all of the elements they need and provide a proper mapping to the same for application developers. We should focus on building out a structure that will allow for more generic, more meaningful, roles for our end users. The application development teams who consume this information will provide the mapping to their application roles. We should partner with those development teams to better report on the privileges our roles grant to end users across the application eco-system.

2. We need to embrace the concept of Identity as a Service (IdAAS). We should provide an identity service layer to allow applications and other services to readily get their identity information from us. What are the aspects of this Identity as a Service that are key?

• Highly available
• Highly reliable
• Highly standard
• Easily recognized
• Simple to use
• Usable (see Simple to use)
• Ubiquitous
• Critical to daily activity
• Taken for granted (see ubiquitous)

The best analogy I can give for this Identity Service Layer is one of the old phone system (prior to cells). Applications should be able to lookup key elements of identity for a user of their system with the ease of using a Yellow Pages or a phone book. The elements like name, address, and phone number should be VERY easy to get from it. Likewise, simply pick up the phone and you’ve got a very, very, stable, always on, service layer waiting for your input. Simply dial the number of the end users and your application could be talking to them in moments. This also speaks to the need for an elegant API.

3. The API we develop for accessing this identity service layer should be very simple. We should not force our application development partners to learn new standards, or complicated SOA schemes. My preference is for a simple REST-ful interface. Federation is where we will need standardize our communications with trusted partners.

4. Federation is a key to our success with vendor and student/faculty integrations. As as move to a service oriented world, integrations of our end users with various vendor applications and even access to our student and faculty portal will be critical. We’ll have to provision and de-provision users to and from their systems. Our initial approach is going to help to ease multiple logins to vendor systems internally. Our focus should be to allow staff to access vendor sites from home or other remote sites without having to remember their passwords. This will take some time to complete. The first step should be federating our identity repository information with existing vendors. From there we can begin to look at the student and faculty portals. I believe we should have an awareness of student and faculty identities in our internal identity repository. I don’t believe this requires that we provision and de-provision students and faculty (although I would certainly prefer we leverage a common identity framework) as that is the particular domain of the people vested with maintaining those applications.

5. Replication and copying data demands will grow to the point where it may become untenable. Metadirectory tools like MIIS and ILM are based on a Web 1.0 paradigm where it is relatively simple to determine who owned the data. There was HR data, Galaxy data, CT & OSIRIS data and so on. Today’s applications are sharing data, components, and identity information. Who owns the data is becoming less and less important and clear. As we grow our IdAAS and IDM Service Layer, we will be forced away from ILM as a hub for identity information and driven towards policy and user centric information sharing. This change is still roughly two years away but we need to consider the buy vs. build solutions now that will allow us to remain competitive and relevant.

6. Identity’s importance to the enterprise will continue to grow. Enterprise 2.0 and Web 2.0 will change our business models and our strategies will need to adapt. Identity is the FOUNDATION for all of this. Identity will grow to not only encompass systems and database access, but physical and user access to laptops and desktops. The Identity team will work more closely with the HR Team as it pertains to the identity lifecycle. But as our scope grows we will HAVE to staff up to meet the demand, simple decisions to purchase software in an attempt to minimize man hours spent developing custom applications will not suffice to meet the demand. The key will continue to be employing highly intelligent, highly effective people to extend, implement, and support our identity initiatives.

7. The computer access web site will continue to become less and less important. We should focus on breaking it up into viable, independent pieces to be consumed in other applications or modalities. The computer access web site will need to live on for the next 18-24 months or until we acquire an identity management suite. At the point where we implement any new identity management suite, we may be able to employ the gadgets or pieces of the old computer access web site that we develop. More focus should be given to building our Identity Service Layer (with consideration for an Identity BUS to be implemented as a part of a larger enterprise service bus) and the tools necessary to support it.

This is my vision for the next two years. I would love to hear from all of you and your thoughts on the future of Identity Management in the Enterprise for the next two years.

Agile Software Development contributes to flow experiences

I've been practicing agile software development since the early XP days. When the agile manifesto came out it seemed to echo many of the things that I found good about agile software development. For our shop we needed agile software development so we could eliminate waste in the form of unneeded features which contributed to code bloat. To eliminate this waste required the participation of our customers. Customers would meet with us daily in a variety of ways, email, face to face, or in instant messenger. They would see the progress we made on a particular feature and say "good enough" or propose corrections. All in all it was a very efficient process. Likewise, as a manager I met with the business weekly to ensure that what we were working on was aligned with their objectives. In an ideal world, their objectives would line up with the company's strategic plans. This was a perfect synergy of strategy, tactical objectives to achieve the strategic goals, and software development addressing the objectives in two week releases of new features. I often thought about the unexpected by product of this whole process; happy customers and more importantly happy staff. It seemed that no matter how daunting a task I gave my team, they just smiled and got down to work on it. Truly, this was a software development manager's dream. Little did I realize that the happiness was a byproduct of 'flow' and that flow was a direct result of agile software developments' other tenets, namely self-directed and self-organizing teams.

Consider the following principles as described on the Agile Manifesto website:

• The best architectures, requirements, and designs
  emerge from self-organizing teams.
  
• At regular intervals, the team reflects on how
  to become more effective, then tunes and adjusts
  its behavior accordingly.
  
• Build projects around motivated individuals.
  Give them the environment and support they need,
  and trust them to get the job done
  

As a software development manager I was encouraged to turn over command decisions to my team so that they could come up with the architectures, requirements, and designs. My job was to accurately relay the problem and manage any impediments to progress. Our team would get together monthly and review what worked and didn't work and adjust accordingly. My job changed from getting hands on with the code, to supporting my staff, hiring the best and brightest to join our team, and understanding the needs of the business as deeply as possible.

Our team evolved into a very dynamic, highly cohesive, unit that would work together, eat together, and celebrate victories together. From the first design principle, people well versed in architecture started to shine and teach others about better ways to develop software in accordance with design principles and patterns. We moved from good ASP.NET developers to really good object oriented developers. This transition helped us bridge the religious divides of Java and .NET as we quickly started to attend tech talks and pattern workshops with the Java guys (they called us the 'sharpies' (for C Sharp (C#)) and we called them the 'dullies'). How was all this openness, honesty, and good work ethic achieved? Was it the agile software development methodologies we were following? No, it was the fact that in spite of all the hard work, we were all very happy. We took IMPOSSIBLE requests and turned them around in weeks, not months. We were by all measure one of the most productive groups in all of IT at the time. So where did all of this happiness come from? In a word, FLOW.

So, what is 'FLOW'? Flow is a concept described by Mihaly Csikzentmihalyi. I could spend this entire post describing it. But I would refer you to two really good articles on the subject, Frank Heckmans' article on 'Designing organizations for flow experiences' in the Journal for Quality and Participation, and an excellent post by blogger Steve Pavlina on the 7 Rules for getting into flow. The simple description of flow is the experience of happiness, energy, and creativity when someone is perched between impossible goals and insipid, easily achieved goals. In that fine line of tension, energy manifests itself, creativity is forced into play to achieve the 'nearly' impossible, and people just feel in the 'zone', invincible, and most importantly, HAPPY. There's a growing body of research that supports this psychologically, sociologically, and even anthropologically. It seems the state of flow is a very human experience from our antiquity. Flow was something that developed in the early nomadic tribal groups, wherein members were all called upon to participate, lead, follow, and play different roles.

My agile software development teams seem happier than other non-agile teams. I believe it's because agile software development in whichever methodology you choose, fosters flow. Its practices contribute to and create opportunity for flow experiences. Agile software development does this by way of its aforementioned principles, self directed and self organizing teams. These mirror the research done by Emery on the design principle of work organization that leads to flow; self-managing, adaptive group structures. Like the many links one sees to the Fibonacci sequences in nature and the universe, self-organization has roots in autopoiesis, complexity theory, physics, and biology. It would seem that self-organization is the natural order of things and when human beings at work in any area follow it, they are happy.

Emery's research suggested six requirements for human productivity. I will translate these to aspects of agile software development and how managers should structure the organization around that team for maximum productivity and employee satisfaction.

1. Autonomy – Self organizing teams are self-directed. You may suggest problems for them to solve, challenge them on the accuracy or completeness of their solution, but you can't employ traditional top-down management with them. You have to give them support and guidance so that they get needed direction enough not to feel lost or bored, but not so much that they feel like they have no ability to influence their success in the organization.
   
2. Foster a learning environment – This is something Google does exceptionally well in theory, they encourage staff to learn new things as long as they are loosely related to the company's overall aims. Agile teams constantly challenge one another to do more, work smarter, and learn new ways of being more productive. This makes people happier as a result.
   
3. Variety – Cross functional teams are advocated in agile software development. Cross training and mentoring are hallmarks are these teams. This leads to variety which helps people stave off boredom. Beyond that, as managers we should constantly be exploring new technologies and encouraging our staff to do the same. It's not technology for technology's sake, it's applied when applicable and at the very least the lessons learned can be applied to the employee's current assignment.
   
4. Mutual support and respect – Loyalty to the team, mentoring, and a healthy respect for each other's various proficiencies are keys to success in software development. Teams who have mastered this are able to cover for one another in absences, pick up and help one another without direction from management, and can self-organize along respective strengths better. Again, the end result is a feeling of belonging, a feeling not of us against them, but rather a nearly familial pride in each other. Agile software teams achieve this by virtue of cross-training each other, mentoring each other, and working as a team on their goals.
   
5. Meaningfulness – This one is harder to quantify for some managers. The suggestion here is that people like to think that their work makes a difference, contributes to society, and helps their employer's bottom line. How does agile software development help to achieve this? By releasing software in regular, incremental intervals. Agile teams release software every 2-4 weeks on average. Projects which take 60 days or a little more are rare. Project lasting 90 days are almost unheard of among agile teams. This means that software developers see their efforts, their code, and their creation, go into use. They get regular, almost daily feedback from their customers about how well the software works. Agile developers make a difference in their customers' lives and as such they derive meaning from their work.
   
6. Upward mobility – Some software developers feel stifled in their positions. They feel like they are spinning their wheels. Their software never sees the light of day and they will never get promoted or receive recognition. Agile software developers on the other hand know they make a difference. They can feel themselves growing as they get mentored, as they pair program, as they evolve newer and more efficient ways of writing software. Just the fact that they are on an agile team or can add experience with agile software development methodologies to their resumes is a huge plus. This in combination with the ever growing list of achievements added to their resume makes them more marketable. The really wise software development manager will promote from within, recognizing his or her employees' growth thus extending their tenure at the company. Likewise, be sure to backfill these promotional vacancies with junior level new hires that show an aptitude for learning and a 'go-getter' mentality. Lastly, as a good software development manager, recognize that at the apex of your senior staff's development, they will leave you for larger, more lucrative projects with national or global companies. Rather than trying to woo them back with unreasonably high counter offers or worse, veiled threats of sabotage or retaliation, celebrate their success within your team. This will build your personal network of former developers (who can buy you sushi someday) and will send a signal to your existing staff that their jobs are not dead ends, that they too can expect a celebratory farewell lunch someday.
   

So what will happen if you follow my advice? Will you get rich? No. You will not be personally famous. But, if you do decide to adopt agile software development (agile with a small a) then you will most likely have happier, more productive employees. It will help people that work for you get into the 'flow' and that experience by all accounts is meaningful, memorable, and makes a difference in people's lives. And if you're lucky, you may just end up on a list of some of the best places to work in IT, over and over again.

Ubuntu in the office

So yes, I've been running Ubuntu (6.10 and now 7.04) in the office since October. I've definitely had my challenges but now I rarely need to cross over to Windows. The one thing that vexes me is a good substitute for Visio. I've got UML tools and Thinkature
but thats about it. So how do I get by with Ubuntu in a largely Windows corporate world? Here's how:

1. Buy in. My management is completely cool with my running Linux instead of Windows. I exist in open source goodness by the grace of their positional authorities. If you dont have buy in, you're asking for trouble, run Ubuntu as VMware or on a thumb drive.
2. Email. Well Outlook seemed to be an insurmountable challenge. I have Outlook Web Access which is pretty damn swell in Exchange 2003. But I've forced myself to know Evolution and I've been pleasantly surprised with how well it performs on Feisty Fawn. Its everything I need in an email client but it still has it quirks. It occasionally hangs, or crashes without saving my appts to my calendar, etc. But overall, no issues.
3. Development. Well this is afterall what I am supposed to do. I have been forced to use MonoDevelop in lieu of VS.NET 2005. I like MonoDevelop, but I am limited to doing just source code and very little complex stuff. I can check it in through KDESVN *I still say Tortoise is WAY better. And even though MonoDevelop is based on my all time favorite OSS IDE for .NET (SharpDevelop (I LOVE YOU BABY!)) its no where near as good as VS.NET 2005 or SharpDevelop yet. I also use Eclipe with a variety of plugins for Ruby, BPEL, UML, and many more. I really really like what they've done with Eclipse. Now if they could just get the refactoring thats built into NetBeans or a plug-in like ReSharper (the BEST Visual Studio plug in EVER) I would never leave. AND it runs SOOO much faster on my Ubuntu than Windows ever did for me.
4. Web. Oddly enough there are still times when I wish for IE back. I know its odd to say but for some Microsoft only solutions, its king. I was pleasantly surprise to see Sharepoint 2007 work well with FireFox 2.0. Nicely done Microsoft. And yes, I did install IE for Linux *v6 but sill dont like it as much as the real thing.

Conclusions? Ubuntu, OpenOffice, a SLEW of development tools....Ubuntu is great. Challenges? Enterprise buy in and integration challenges, no corp VPN, no corporate virus protection, no Outlook. If I have a problem with it, I own it. Other challenges, HARDWARE. Driver issues plague open source systems. Try to get full compatiblity with NVidia or worse yet ATI with Ubuntu. Got a Web CAM? Try to use it with GAIM or aMSN....its not that easy. Ubuntu is the best Linux yet for the desktop. For open source shops or non-Microsoft developers, this is a real consideration.

Lessig's Presentation

Aside from the brilliance of his presentation style, Lessig has an important message. His message was that an internet 9/11 is coming, which will result in an internet version of the Patriot act. This work is already under way with the Identity gang and Kim Cameron at Microsoft. The identity layer, an identity metasystem will enable traceability and regulability. Lessig's call for action was to have we as technologists involved in framing and shaping the discussion in order to preserve the generative, free, Internet we enjoy currently. He offered no clear way for us to get involved short of getting off the PC and getting into the political arena to help counter the perception of the Internet as a series of 'tubes'.

I also got to ask him about the CC license and the Microsoft Zune. His reply was that DRM much like the Patriot Act was a poorly crafted, poorly implemented technology. He suggested that the conversation with Microsoft and Apple (even Apple is guilty of catering to the DRM Nazi's) has been started and that its an important one for the digital rights world.

Gartner Identity Management Conference Summary

WOW. I am really proud. Apollo is ahead of the curve in SOOO many ways. Now mind you we're not at the apex of Gartner's Maturity Model which is Policy Based (and yes that is our new target) BUT...

We're at the Virtualized stage, our objectives now are increasing business efficiency to reduce costs in labor intensive or time intensive business activities.

A whopping 73% of Gartner customers DON'T do automated user provisioning. Likewise, all the products we looked at have CRUDE interfaces, ill defined interactions, and are still half baked. Even Oracle, the best identity and access management suite on the market today is only a rebranded amalgam of their most recent acquisitions. It introduces yet another workflow technology, it has gaps in what it can and can't do, namely business roles and role governance. For that it recommends we leverage someone like Bridgestream, which has yet another web interface for business users to use in requesting business roles (apparently only IT users use Oracle Identity Manager to request IT only roles) and yet another workflow engine for our support teams to learn. Add to that the spartan and un-intuitive interfaces on both products, and we look like rock stars.

We are in fact rock stars, what we've done and in the time that we've done it is nothing short of miraculous. We're in the top 27% of Gartner customers for user provisioning and I'm quite sure we're even higher considering the periodic audits we've been doing for a full year this month. At the user round table I attended Thursday, I was ahead of all but one customer and even then we had features and maturity that they were only now starting to consider.

So, considering all of this, where do we go next? Well there are still significant gaps in our offerings, and most certainly, opportunities for growth. Here's the short list of things we're missing or needing to improve upon:

UI: what we've got in the CAP UI is extensible, robust in comparison, far easier to user and more elegant than anything we saw at the conference. But being the rock stars we are we cant settle for success. Let's take it to the next level, let's simplify the UI and make it clean. We'll engage the HCI team in order to get this done. Think of the good Web 2.0 designs we've seen like Google, Skype, Delicious, and you'll have an idea of what it is that we want to do.

On-boarding: We need to simplify the on-boarding process for all new users. CAP can still be the place we go for on-boarding contractors. But when we hire staff or convert contractors to staff we HAVE to vastly simplify and streamline that process. Users shouldnt have to go from HR to CAP to put in access requests. Likewise, we should be able to identify people as existing identities when we provision them so we dont end up with duplicates. Every vendor has this, so should we.

Default access levels: When we on-board people we should automatically grant them a default level of access based on a role. This access would include network access, email, and some combination of roles based on their job code and cost code.

Email access: Its not fully automated provisioning until we include email. This is #1. Enough said.

Role Management: We need a means of adding or removing roles within CAP, the identity management environment, and downstream in the applications. This is a larger, multi-year goal but one we should pursue nonetheless. We should include some manor of reporting all the roles and role mappings in the system as well as who has these roles and who is in violation of the conflicting role policy. Role policy shouldnt be an Excel spreadsheet. That's just plain embarassing for a rock star.

Role simplification: We need to work on reducing role proliferation and streamline what we have to be more reflective of the true business roles. We should include some definition of what exists withing EMS.

LONG TERM GOALS:

RFP for IAM Suite: We should look at what we have versus what's available in the industry. We'll need to get some scope definition in place, then we'll engage Gartner to craft a proper RFP. Once we've got that we'll send it to the major players to see who responds. I'm anticipating we'll evaluate IAM Suites from Oracle, Sun, Microsoft, and IBM, with the outside possibility of BMC. We should narrow that down to 2 vendors within 3-4 months and then do POC's with both. Based on the results of the POC, we'll select a vendor and engage Purchasing for the contract. Here's the timeline for the RFP:

December - January: Scope Definition. We'll need to work on getting the list of applications we have as an enterprise, then list what it is we have in terms of IAM support for all of them. Once we've got that we'll draft the RFP with Gartner.

February - March: Draft the RFP with Gartner. Vet it with the business. I'm anticipating 2-3 days with Gartner on site potentially.

April - May: Send out RFP and await responses.

June - August: Vendor on site meetings, demo's, and selection. I'm anticipating we'll make #1 and #2 offers by the end of August.

September - October: POC one and two.

November - December: Work with Purchasing to sign contracts. Begin to plan phased roll out.

IMPORTANT NOTE: An important option we have open to us throughout the RFP process is to pass on all vendors before or after the POC(s). The relative immaturity of the market, the relatively high prices, and the relative maturity of Apollo's IAM infrastructure by June of 2007 could suggest we pass on all vendors for 2007-2008.

The rationale behind the drive to select a single vendor or at minimum 2 partial vendors is to reduce the manpower needed to build and deliver identity and access management as well as to move away from something thats completely customized and labor intensive to own and operate. Our development resources should be able to get to a point where they are focusing on integration and delivering services to our fellow application developers in accordance with the service based model. This is very high level, very rewarding work. And then finally, when we're ready to tackle transitioning to a policy based model, our developers will very likely use a single vendors tool(s) to assist our business end users in defining and implementing their business policies in terms of identity and access management policies.

Presenting at IAM2: Next year, I want to be on stage at Gartner in Los Angeles talking about the best company with the best IAM team on the planet. I want to wow our fellow Gartner clients. I want them to base a case study on us. I want us to have to wear shades on stage that day, not because the lights are too bright, but because our FUTURE is SO bright we've got to wear shades.

Start of a new blog life

Here's my blog which is tied into Gmail and GTalk. Only fitting as I explore the netherworld of Open Source technology and programming languages