Take advantage of organizational change to add talent

Take advantage of organizational change to add talent

As I’ve posted recently, if you are working in corporate IT, you know that frequent organizational changes are a given. No sooner does an IT department settle down and start functioning again after an organizational announcement and another change is being discussed. For managers, this is a time of great stress and great opportunity. Many times, as a manager, one is privy to the soon to be announced changes but can’t speak openly because all the details haven’t been fully finalized yet. HR job code changes are yet to be implemented, people need to re-aligned to new cost center structures and financial budgets need to be adjusted to reflect the pending new organization. Whether, as a manager, you are aligning to a new boss or gaining/losing responsibilities and/or people, now is the time to take advantage of the chaos and achieve a strong position to deliver in the new structure. This article offers some tips for corporate IT managers to exceed in the throws of organizational change.

Honor your responsibility as a manager at all times.

First and foremost, make sure you honor your responsibility as a manager within your organization. Sure, you may have some inside info that so and so is going to get canned or what’s her name is going to get layered, but always remember you are a manager entrusted with certain confidential information that you can’t share. Avoid the urge to gossip at all times. Focus on discussing the structure, goals and objectives of the pending announcement rather than the impact on specific individuals. The last thing you need nor want is to get a reputation for not being trustworthy.

Don’t relax, now is the time to strike.

Everything seems up in the air. Will you be gaining that new system to support? Will you be gaining or losing a percentage of your team headcount? What does your new boss expect? What has your current boss not shared yet that could completely change your strategy for the new org? The final throws of organizational changes can be exceedingly stressful times for the corporate IT manager. One urge is to just sit tight and wait for everything to settle down. This is absolutely not the time to be idle while your peers are gaining advantages.

Be open and transparent with what you know and more importantly, what you don’t know.

Times are certainly uncertain. Even if your boss confides in you an element of the change that seems a sure thing, always consider that your boss maybe misinformed or hoping that the change occurs rather than definitely knowing it will. Thus, make sure to always caveat your comments with “now, this could totally change, but right now, this is what I know” while you are pitching how the “A” player could be a good fit for your team. Describe the logic, as you know it, for the new structure, what the goals, objectives and priorities are, etc.

Be open about what you need to succeed with your new boss.

With all the change comes the ability to leverage that change to your advantage beyond grabbing a strong new team member. If you think that you could add more value if you had responsibility for an additional functional area, now is the time to make the pitch. If you think you could add more value if you could get a few more members on your team to dig deeper or provide more coverage, now is the time to sell that idea. Even if you get shot down, you still get points for looking to contribute more. Plus, your boss maybe looking for ideas on how to expand his or her coverage and wasn’t even aware of your idea.

As many know, organizational change is stressful. Trying employing the tips in this article to channel that stress energy to something productive for your team and your career.


EA can fit the horizontal IT puzzle pieces together
EA can fit the horizontal IT puzzle pieces together

Anyone who works in corporate IT knows that frequent organizational changes are a given. If you are sitting at your desk and an organizational change announcement communication hasn’t hit your inbox in more than six months you probably feel a certain discomfort that things are a little too stable. I don’t know from whom nor when I first heard this joke but there is an unfortunate truth to it: “If you don’t quite understand the logic behind the new organization structure, don’t spend much time thinking about it because a new organization announcement is right around the corner.” Thus, as I think about how corporate IT needs to constantly evolve to meet ever changing business needs, I thought I would share a few recent thoughts on the subject.

Pragmatic “Innovation”

I figured I would tackle this topic first even though a number of readers probably rolled their eyes at the very mention of this over used term “innovation” in present corporate IT vernacular. Yet, the reality is that if you are part of a corporate IT delivery process, an who isn’t (yes, corporate audit, you are included as well), if you aren’t constantly evaluating your tools and processes with a focus on continuous improvement you risk gross inefficiencies and potential outsourcing. But a specific challenge of the now popular cross-functional and business vertical aligned teams is the struggle to effectively innovate horizontally. Budgets, project life-cycles and quality gates are aligned to the business sponsor without much room for an enterprise opportunity intersection. Unless a new solution is “production ready” prior to the initial planning/design phase, it is exceedingly difficult to introduce cross-project solutions such as:

“Hey, project A for business unit X, project B for Y and project C for Z could all use a single Flim Flam capability. With 91% of the requirements overlapping, this is a no brainer. A single Flim Flam capability reduces overall IT delivery costs by 66% for these three projects.”

Well, try to get all these projects with their separate funding streams, separate resources, separate time-lines, separate sponsors, etc. together to talk about enterprise alignment and … I think you get the picture.

Note: I put the word “pragmatic” in front of innovation. I’m not trying to argue that every corporate IT organization must over achieve in delivering cutting edge, emerging technology. I am suggesting nothing exotic like enabling sales teams with Google glasses that facially recognize sales prospects and mine Facebook, Linked In and the corporate CRM systems and display relevant attributes about the prospect the sales person is currently looking at. Wait a minute … maybe I should put more thought into this concept. Where did I put that contact info for Y Combinator …

Cutting edge technology innovation is great, but I’m arguing that the need to pragmatically look across the portfolio of projects in the pipeline and identify opportunities to inject enterprise solutions to common needs is a level of innovation desperately needed by today’s corporate IT functions.

How does “Enterprise Architecture” play a role in this need?

This cross-portfolio view is where an “enterprise architecture” function would be able to look across efforts, identify these opportunities and outline the benefits of an enterprise solution rather than separate more costly overlapping investments. But having a functional role be able to identify these pragmatic innovation opportunities involves a degree of organizational maturity to support the funding of such teams. Yet funding the EA role isn’t enough. There needs to be PMO/PLC mechanisms and budget/project funding flexibility to further empower the architecture role to actually inject the innovation into the project delivery flow.

Thus we finally get to my main point: corporate IT organizations need to go beyond the business vertically aligned teams to incorporate some horizontal enterprise view in order to drive down overall costs and provide pragmatic innovative solutions. Corporate IT functions that don’t will find more and more business needs being solved by “the cloud” and corporate IT will find themselves viewed as an expensive “cost center” that needs to be constantly reducing expenditures and relegated to a “keep the lights on” level of staffing.

Look for some more articles on evolving corporate IT structures to address current business challenges soon.

, , , , , , , , , , , , ,

Statistics for 2012 With time zipping along, 2012 represented another year for MidwestITSurvival.com. I thought I would be consistent with prior years and share some statistics from 2012 in the same format as I’ve done in those prior years:

Per Google Analytics:

Unique Visitors: 4,117

Page Views: 6,820

View Traffic Sources:

I appreciated that 14.84% of visitors came directly to the site but that was less than the 23% of visitors that come directly here last year. Additionally, 29.63% came here from links on other sites which is very similar to last year (31%).

The top 3 articles in terms of number of unique visitors reading them are:

1. Hooked on Tablet Computing [605]
2. Managing Infrastructure Compared to Software Development Teams – Part 2 [532]
3. Organizational Structure and Enterprise Architecture [482] <- #1 for all of 2011

With only 14 articles compared to 33 in 2011, 2012 was a challenging year for me to get a number of solid articles published. I started out the year strong but quickly got overwhelmed with other professional demands. I was fortunate to receive multiple promotions in 2012 that layered on more responsibilities in my day job. The new roles came with a heavy strategic focus for my employer. These strategic roles made it challenging for me to translate work related experiences into engaging blog articles. The theme of the majority of my articles involves translating corporate work related experiences into educational posts. When the work activities involve conducting industry analysis and making recommendations for enterprise wide initiatives such as cloud computing, enhancing information security posture and buy versus build technology sourcing, I found it exceedingly challenging to come up with helpful blog content while maintaining a clear separation of my professional occupation and this blog. Additionally, I was asked to teach an information security course as an adjunct professor at a local college. I’ve taught similar courses prior, but the textbook was new and so much has changed in security in that last year that any prior collegiate material I had accumulated needed to be significantly re-worked and updated to reflect the current security landscape in order to teach an effective and relevant course.

For me, 2012 was the year of social media consumption much more that production.

Yes, overall, excuses, excuses … so my goal in 2013 is to increase my social media contribution activity including more active blog posting to improve my writing and be more engaging to the social audience.

, ,

Recently, I was pleasantly surprised to receive a copy of Mickey W. Mantle and Ron Lichty’s new book entitled “Managing the Unmanageable. Rules, Tools and Insights for Managing Software People and Teams” (Amazon link) from Pearson Education, Inc. publishing. I am always on the lookout for books that try to cover the challenges associated with managing technical teams. Since I first got my hands on Michael Lopp’s “Managing Humans” (Amazon link) many years ago, I’ve been a sponge for new concepts and tips from other technology team managers. Without hesitation, Mantle and Lichty’s book is absolutely one every tech team manager needs to get their hands on and read cover to cover.

Review Summary

Without a doubt the authors speak from experience and have logically constructed this book to reveal that experience to their readers. Chapter after chapter describe their accumulated wisdom when it comes to managing software developers. After only a few chapters in I found myself wishing I had access to this book at the beginning of my management career. I kept agreeing with the authors’ perspectives and chuckling at their humor page after page. I can wholeheartedly recommend this book to anyone interested in a critical look at the success factors associated with managing software developers and software development teams. My only criticism, and it is a weak one at that, is that I didn’t uncover any new striking management revelations. Thus, if you new to systems delivery management, you will absolutely learn valuable tips and techniques that took me years to accumulate. If you are a seasoned manager and have invested heavily into the learned depth of your management role, you will find the book a pleasantly refreshing read that will confirm you are balancing the competing priorities associated with software delivery team management.

Review at Length 

Both Litchy and Mantle have impressive career credentials. Touting managing teams at well known technology and software companies such as Pixar, Borderbund, Apple, Berkley Systems, Schwab.com and even the US Navy. The book has a somewhat bias towards technology companies rather than companies that use technology to deliver their products and services (my career and blog focus). This by no means suggests one working in a corporate IT shop won’t benefit from the majority of the great ideas in the book. Rather, the tips and concepts apply most directly to corporate IT team management challenges. This divergence manifests itself most in the development role categorizations in chapter 2. The descriptions of “systems” versus “applications” programmers are spot on, but with the ever growing “buy versus build” trend in corporate IT, that role distinction is getting more blended. The luxury of hiring both a “systems” and “applications” programmer on to your delivery team maybe an evaporating luxury and thus recruiting someone who can blend into either role as the situation demands becomes more of a necessity.

The book is structured in a logical flow that is easy to read and allows the authors to build upon the foundational elements of prior chapters as they introduce more complex topics in subsequent chapters. Below is a brief chapter outline to give potential readers a sense of the author’s flow and concepts addressed:

  • Chapter 1 – Light introduction to support the title of the book: why programmers seem unmanageable, or rather, why programmers are uniquely challenging to manage. Here, contrasting Michael Lopp’s more artistic explanation of the mental make-up and personality drives of “nerds”, Mantle and Lichty take a more straight forward, logic based explanation of the motivations and drives of the average programmer.
  • Chapter 2 – Understanding programmers, those “systems” versus “applications” programmer role preferences I mentioned above.
  • Chapter 3 – Finding and hiring great programmers covering the recruiting challenges with some very pragmatic tips and tricks that I had to learn in a trial and error fashion myself. In this chapter I really was nodding my head paragraph after paragraph about how much I completely agreed with the authors’ perspectives.
  • Chapter 4 – Getting new programmers started off right. Logical extension of once your have hired someone you really want on the team, what you need to do to get them acclimated and part of the team right away.
  • Chapter 5 – Effectively managing down or managing the team you have assembled
  • Chapter 6 – Managing up, out and yourself
  • Chapter 7 – Motivating programmers
  • Chapter 8 – Establishing a successful programming culture
  • Chapter 9 – Managing successful software delivery

In the middle of the book in darker colored pages is a collection of what the authors call “Rules of Thumb and Nuggets of Wisdom”. This section is filled with great quotes that speak to a variety of technical team management challenges. I rarely if ever go back and re-read a book to refresh my mind with the perspectives I originally appreciated from the book. I believe I will most certainly be flipping through this collection of quotes from time to time to remind myself of some of the great tips and tricks the authors have assembled.

One thing that is worth noting is that it takes the authors a full eight chapters before they start covering the process and attributes of producing a quality product. Another reason I found the book an excellent reference is the in depth of focus on people rather than technology and process up front. If you’ve read some of the articles I’ve posted over the years, I rarely if ever talk about technology specific challenges. The challenges all revolve around people and the processes that drive people communicating rather than what .NET library or Java framework is the most effective to deliver a quality end product. Again, another reason I really enjoyed reading this book was this immediate identification with the authors’ and my priority on the people dynamics of IT solution delivery.

The book also makes mention of on-line tools such as recruiting checklists and work estimation guides. As of this review I didn’t directly access those additional on-line resources but will peruse them and update this review at some point.

, , , , ,

If you are looking for the most straight forward, pragmatic book covering the most prevalent Agile software development approach, then “Essential Scrum: A Practical Guide to the Most Popular Agile Process” by Kenneth S. Rubin (Amazon link) is it. From beginning to end, the book walks you through all of the concepts and techniques that makes Agile Scrum software development as effective as the industry has recognized. My only regret is that this book wasn’t available a hand full of years ago when I was fumbling my way through implementing Agile methodologies when I was leading development teams.

Disclaimer: I was privileged to assist the author, Kenny, with reviewing sections of the book prior publication. Kenny was gracious enough to mention my contribution in the Acknowledgements section of the book.

Kenny has structured the book to be a classic chapter by chapter read. Chapter 2 provides an excellent end-to-send Scrum primer with chapters 3 through 8 addressing the core concepts. Chapters 9 through 13 cover the roles of product owner, ScrumMaster, etc. Chapters 14 through 18 address planning including more complicated topics such as multi-level and portfolio planning. Chapters 19 through 22 cover the sprint in depth. Chapter 23 ends the book with the send off: “There is No End State” and re-iterates the lack of a one-size-fits-all mandate with Scrum. The chapter sequencing serves as both a comprehensive education on Scrum as well as an excellent concept reference when your team is struggling and a specific Scrum technique needs to be re-evaluated.

To all of those looking for a single text to provide the most breath and depth of coverage on the Agile Scrum methodology, I strongly recommend Kenny’s book. After only being published a few weeks, Jurgen Appelo listed it at 76 on his Top 100 Agile Books (Edition 2012).

 

, , , , , , , ,

As the final day of the Open Group – Washington DC conference comes to a close, in looking back over my notes, there was plenty of very useful knowledge and experience shared by the majority of the sessions I attended. Having stumbled upon many documents and publications from the Open Group over the years, I’m somewhat surprised that this is my first attendance at one of their quarterly conferences. Looking back, the conference itself wasn’t as flashy or as polished as major technology vendor conferences like CA World, Oracle’s Open World, etc. or those by analyst groups such as Forrester or Gartner, but the presentations were by folks actually doing the work they are talking about. Even consulting firms, clearly advertising their skills and service offerings, were focused on the pragmatic rather than pure sales. It was refreshing to not have that constant undertone of sales, sales, sales in every aspect of the conference. Another initial observation was the seniority of the attendees. As I try to recall, I was probably in the minority age/career seniority wise. Pretty much everyone was in suits, ties and sport coats with not a pair of jeans or shorts to be seen. The attendees were very much senior members of their organizations which seemed to set the tone for a less flashy, more pragmatic focused theme of the conference.

The conference agenda was general, broad topics in the first part of the day with more narrowly focused topics in the second half of the day. With people from over 30 countries, there definitely was an international feel with plenty of case studies and perspectives by companies that aren’t common names in the US. There also wasn’t a heavy concentration in any particular industry. Oil and gas exploration, manufacturing, medical, retail, airlines, universities, government especially department of defense, enterprise software and financial services companies were all presenting.

The keynote was by Joel Brenner, currently an attorney at Cooley LLP but has had roles in government prior including the office of inspector general for the NSA. He gave an energetic presentation around the growing cyber-war between nations and international corporations. I think he could have spoke for 2 or 3 hours and people would have still been glued to his speaking. He almost seemed like he had to keep constraining himself from going too deep into any one particular topic by visibly pausing to allow his energy and enthusiasm reside enough to move to his next topic. My favorite quote from him, which I tweeted the minute I heard it, was, related to security threats: The weakest link is not the silicon based unit on the desk but the carbon based unit in the chair.  Great choice for a keynote speaker given all the media buzz around breaches and security threats.

Of all the sessions, as it seems is true for me in any industry conference, hearing from peers in the industry sharing what does and doesn’t work for them is the most valuable. It is good to hear the consulting version and what consultants are doing for clients from a solutions perspective, but hearing peers share their trials and tribulations is most useful to me. I focused on the enterprise architecture track and the use of frameworks such as TOGAF as the cloud and security tracks didn’t look to have as much new material for me. I know that it is impossible to attend every session on every topic, but looking back, it would have been interesting to hear what peers are doing and experiencing in the cloud and security space given what I learned about enterprise architecture.

I’ve got a pile of useful notes on individual topics or specific slices of enterprise architecture. Instead of trying to organize those here in some meaningful way, I thought I would just share some of the major themes of:

Enterprise Architecture – Value/Metrics

One of the topics I was keen to hear was how other enterprise architecture groups track or measure the value they produce for their respective companies. Unfortunately, as is the case with most complex IT topics, there was no consistent silver bullet metric everyone was leveraging. It seemed everyone struggled with this same:

“Hey, the CIO knows we add value, our peer groups and departments in IT know we add value, but we can’t put a specific number or metric to say what it is directly.”

  • Some tracked fuzzy cost savings figures of re-use versus separate investments/solutions.
  • Some tracked solution adherence to standards.
  • Some tracked “problems” with “solutions” via “patterns” (if u need to do X, use this pattern to consistently do X).
  • Everyone stopped being “ivory tower” and focused on adding direct value to projects.
  • Everyone added some form of a charge-back model for project and solution focused deliverables and struggled with cultural adoption from being “free” in the past.
  • Everyone was trying to use a framework like TOGAF in some manner to structure their deliverables.

It seemed each group presenting was adding value, but being groups formed in somewhat the last 5 to 7 years, weren’t fully ingrained in all IT processes and cultures to have an easy time of enterprise governance.

Thus, it was refreshing to know I wasn’t alone in trying to discover a more straight forward way to clearly demonstrate value through metrics rather than pure perception.

All in all, a great conference for those, like me, looking for direct pragmatism in solving today’s IT problems without having to sift through the sales noise and distractions that can accompany other IT industry conferences. I highly recommend Open Group conferences for those who read this article and identified with some of the perspectives I tried to convey.

 

, , , , , , , ,

I know I am making a rather bold statement with the 2.0 title connotation, but as Jurgen Appelo has effectively captured the Management 3.0 construct compared to 2.0 and 1.0, I believe a similar level of radical role change is occurring for information security professionals and specifically the CISO role within organizations. I’m finding I’m not alone in this thinking. Robb Reck over at InfoReck writes about the new challenges for CISO’s and also makes tepid reference to the 2.0 moniker. Additionally, Gartner’s Tom Sholtz makes similar assertions of the need for information security professionals to evolve to “truly understand how security links to an enterprise’s business goals” in a recent Bank Info Security interview.

The last decade in a nutshell from an information security perspective

The prior decade with the explosion of the information exchange and commerce via the Internet solidified the CISO role and the formal information security department as a critical need for any medium to large size corporate IT shop. As companies birthed whole new business models to leverage the seemingly endless financial opportunities the Internet afforded, the few IT roles that involved haphazardly securing “stuff” quickly were organizationally structured into information security departments. These departments were aligned separately within IT reporting to the Chief information Officer or in even more risk adverse industries and organizations, reporting into the Chief Risk Officer or other such non-IT role. Additionally, legislation and regulatory guidances were being passed to help address the abuses of weak corporate controls as well as rapidly expanding new Internet money movement and associated new fraud patterns. The list is extensive, but SOX, GLBA (technically passed in 1999 and probably more noted for reducing regulatory restrictions on US banks than prescribing security), HIPAA (again, technically passed in 1996), PCI DSS and FFIEC guidances are the first that come to my mind as impacting my information security career. While commerce was still rapidly expanding, at the same time, beginning the narrowing of frameworks towards technology standardization and commonly appreciated security controls, along comes Enterprise 2.0, as characterized by Andrew McAfee and the advent of social media’s dynamic change in people’s personal and professional interactions.

The need for information security investment and a strong, controls based CISO leadership focus was perceived critical. The need to keep the “bad guys” out of the company’s networks and data assets was ever in everyones’ minds. Asking for ever increasing budgets to buy and implement the latest firewalls, gateways, anti-virus, identity management and web access control technologies were made using the business case of fear of bad stuff happening and the seemingly well established security perspective that strong security controls protected one from data breaches and data loss. If a new business or technical initiative didn’t have a well known security control framework associated, security professionals, leveraging their unique position in the organization’s decision making hierarchy simply crushed the initiative with “no, we can’t do that, it is too risky”. Many a new idea was squelched with “security won’t approve that” motivated by a notion it was impossible to secure or a convenient excuse to avoid shaking up the status quo.

In all fairness, the last decade did go a long way to improve corporate and customer security technology controls. Where companies may have had internal security decisions made by disparate individuals across the organization, both inside and outside of IT, the formation of central security policies and standards and the subsequent evolution of centralized, risk based security decisioning was a major step forward. But, now in hindsight, a great fallacy has been realized:

Ever increasing investment in stronger and stronger security controls does not guarantee the elimination of breaches nor data loss occurrences.

As the last decade came to a close, the bad guys, struggling to directly attack hardened company networks and devices switched to the now clearly easier target: the company employees and customers directly. Phishing, being the early indicator of this switch in tactics, was most prevalent in financial services scenarios where access to an account holder’s on-line access permitted the direct movement of funds out of those accounts and into the fraudsters’ accounts. And thus, what John Kindervag of Forrester has labeled the need for “zero-trust” is one of the many signals as to the end of the prior decade’s strong control based “hard outer shell, soft gooey center” approach to corporate security.

The new decade brings the insider threat and Advanced Persistent Threat

With the start of the this decade, the success of security departments in the prior decade of hardening the perimeter has forced the bad guys to look for easier targets and thus why try to get through all those firewalls and demilitarized network zones when gaining access to customer credentials and employee computing devices gets you legitimate access to the data and transactions they desire. In parallel, the constant barrage of media coverage on successful insider breaches of major household names across all industries further sensitizes even the least technically inclined that bad guys are every where stealing everything. The rise of hacker brands such as Anonymous and Lulzsec further cements this information security breach fear in a wide audience.

Now, one would think all of this security press would be a boon to the security industry. For security vendors it truly is practically free advertising for the need for their products, at least initially. Vendors clamor to the table to insist they have the latest whiz bang tool that will protect your company from these evil hackers out to cause havoc and steal your data. But, with all this vendor and media fodder, the CISO conversation quickly has become much more complicated. Here is one particularly extreme example conversation between a CISO and senior management that over embellishes the problem to outline my point:

Senior Exec: I’m hearing about all these breaches. We are protected, right?

CISO: Well, not exactly. The bad guys are using new ways to attack and with the recent economic downturn, the company hasn’t been investing in protection as much.

Senior Exec: But we’ve been spending millions of dollars on this security stuff? Well, what do you suggest we do about it?

CISO: We should upgrade our FlimFlam protection technology, create more security network zones with more encrypting of stuff as well as hire more people to manage the security tools we have as well as start monitoring activity logs for suspicious behavior …

Senior Exec: So you are telling me we have to spend even more money and get more people to protect us? If we do all that can you guarantee we won’t get breached?

CISO: Well, even if we do all that I can’t guarantee we still won’t get breached.

Senior Exec: So what are you telling me to do? How much to spend? What is the worse case if we spend nothing? What if we cut back our current spend 10% or 20%? What would a breach cost for us?

Again, a somewhat far fetched example, but hopefully today’s thematic security challenge is more clear:

How much security is enough when one can’t guarantee, with all the security technology and best practices in place, breaches are still very possible, even likely, and the cost of breaches is difficult to quantify?

This is a different security paradigm today compared to last decade. Security professionals are coming to grips with the realization that, being a bit cavalier here, they were purveyors of a false sense of security in the prior decade with a “strong controls = strong protection = security” mantra.

If this weren’t enough, the continued Internet and Enterprise 2.0 evolution collides with the continued sophistication of consumer mobile devices. I even fell victim, although later than most of the technical gadget minded. The overtly intuitive touch-based, instant response user experience of the current mobile phone and tablet becomes a sharp contrast to the overly locked down, slow and seemingly cumbersome “legacy” experience with the corporate issued computing device. Even the once beloved device by corporate users and security professionals alike, the RIMM Backberry, quickly falls out of favor due to the conflict between a great end user consumer-focused experience compared to a locked down corporate experience. Security departments are now increasingly faced with:

Senior Exec: I want to get my company email on my iPhone without giving up all the personal things I already do on it.

The security roadblocks of “no, it isn’t secure” collide head on with “I want it now and they, they and them to are already doing it. You said we can be breached at any time no matter what controls are in place so why not?” The later being the most difficult to navigate given the reality of the current insider threat landscape. Plus, all the healthy discussion around why corporate laptops and Blackberries were locked down in the first place is eclipsing 10 or more years ago.

Even mobile device manufacturers are quick to respond by incrementally adding corporate security control options to their original consumer devices. Realizing the entirely “new” market for their products: companies with IT budgets, device manufactures are adding features to enable the open personal use while creating technical control barriers to corporate access and data within the same device. Thus, while RIMM’s Blackberry products are trying to make the evolution from corporate focus towards consumer focus, Google, Apple and others are trying to evolve from consumer to corporate. Both trying to achieve the best of both worlds leaving security professionals to try to stay abreast of all the dynamic changes.

The media has even labeled this whole spectrum of corporate mobile computing BYOD or “Bring Your Own Device”. With the IT punditry touting to security professionals: “it is not a case of if but when. BYOD is coming. Better get used to it.” Thus again, in this decade, saying “no, it is too risky or not secure” gets drowned out by senior execs wanting the more modern user experience backed by accountants saying: “if our employees can use their own devices to do work, we don’t have to buy each one of them a $3k+ company owned and managed device.” Any CIO would like to see the upside of reducing the IT budget by delivering an enhanced employee computing experience. How many times goes a CIO get to deliver something better for truly less cost? Yes, the cost/benefit economics of managing employee owned devices over corporate owned devices hasn’t fully be universally accepted. But, there is quite a bit of evidence to indicate it could very well be a windfall to get employees to bring their own computing capabilities to work.

So how does a CISO make the transition to 2.0?

Deep business integration

As primarily done in the last decade, focusing all energy on integration with IT technicians and integrating technical controls in order to secure business products, operations and services isn’t enough. At the same time, abandoning effective security process integration over technology initiatives will most certainly lead to control and ultimately security posture atrophy. A new balance needs to be struck between early business initiative engagement to offer security awareness to help integrate security into those engagements as they are gestated while maintaining a level of presence with technology delivery and change processes to ensure control strength doesn’t reduce.

Of course, this transition to business versus IT balance brings a host of yet to be fully answered questions:

Is the business ready for security professionals to be partners at the table against the prior perception of “security just says no to everything”?

Can security professionals be seen as credible through engaging business acumen?

Can security professionals accurately convey risk based decision trade-offs in easy to digest business language?

In closing, what keeps me drawn to the security profession is the constant changing landscape. I’m looking forward validating answers to these questions.

Do you agree or have I missed a major prospective here?

, , , , , , , , , , , , , , , , ,

For those who are regular followers of my corporate IT ramblings and have noticed a dearth of articles recently, let me offer a blatant excuse: I’ve been honored to receive multiple promotions at my current employer. Those promotions have involved building a new team as well as amalgamating additional functional areas and teams. Thus, I’ve been forced to redirect the time I’ve allocated to article posting to establishing these new teams. Secondly, I’ve been mulling over the topic of the current information security challenges facing corporate IT for some time and have struggled to try and capture my perspective to help contribute to the on going cross-industry conversation. I’m still not sure I’ve outlined my thoughts as effectively as I would like but I felt I better get something published in order to get feedback before too much more time passes. Thus, coming next week is my initial attempt to capture this radical change in demand placed on those holding the corporate title of CISO – Chief Information Security Officer.

 

, , , , , ,

If anyone is interested in hearing more about the newly forming Cleveland Chapter of the Cloud Security Alliance, drop me a note. I’ll be attending the first meeting mid next week and will have many more details after that first meeting.

, , , , ,

Entrenched Vendor = It is hard to compete with "free"

Entrenched Vendor = It is hard to compete with "free"

I was having a conversation with someone that was utterly frustrated with the vendor selection process for a new technology product in a large corporate IT shop. The product was to address an IT specific need rather than a business unit need. In this individual’s mind, the choice was clear: Vendor X’s product. She couldn’t fathom why the choice wasn’t obvious to all the other stakeholders participating in the solution process. From her mi-optic viewpoint, Vendor X’s product meets her perception of the need and thus why all the gesticulation around alternative products in the mix?

Sure, the textbook approach to technology vendor selection seems pretty straight forward. Most would agree to start by documenting the business case (the need) and requirements (the what). Next, conduct an RFI/RFP to narrow down the vendor landscape to a few products (the how). Finally, conduct some proof of concept implementations with clear success criteria involving all stakeholders, score the results, finalize the business case and a clear and obvious winner will emerge and be embraced by the organization. Rarely, if ever, does the selection process proceed this scientifically in any moderate to large corporate IT shop. I did my best to explain to this individual the illogical nuances or hurdles that derail the most straight forward and seemingly logical technology selection process.

Hurdle #1 = Entrenched Vendor

One of the first challenges of considering any new technology is:

Does a vendor you are already using have a solution?

This may seem obvious to anyone reading this article but you might be surprised at how many large corporate IT organizations don’t have a transparent way across all teams to know what already exists. This challenge exists both in implemented products as well as owned or licensed but not yet deployed products. One of the most confusing can be the “enterprise license agreement”. Also called an ELA, an ELA represents some pre-agreed upon pricing structure where a whole buffet of vendor products are able to be used for “free” or with heavy discounts. If a new capability is needed and an ELA exists with a vendor, you might be able to start using that new capability immediately.

Sounds simple, right? Just make a master list of everything the company owns or has a license to use. So, why is this considered “hurdle #1”?

Well, if you need a new capability and an existing vendor has it, for a reasonable price (or “free” via ELA) and all stakeholders agree it fits the need, fits the technology support structure, etc., congratulations, smooth sailing.

But what is exceedingly more challenging and thus worthy of the “hurdle” reference is when an existing vendor has a product for the need but various stakeholders don’t agree it is the right fit.

I have observed the later easily ten fold more than the former.

Compared to other reasons stakeholders might not agree on fit (which will be addressed in subsequent articles), the universal feature gap is the least challenging. The need has been described and (hopefully) documented in a non-emotional context to a degree that makes it obvious the existing vendor’s product isn’t a good fit. “Hey, we need the product to do X and ABC’s Vendor product we own but haven’t deployed doesn’t do X”.

Vendors that are considered to be “strategic” or “strong technology partners” tend to have an effective means of access to top IT executives. If they hear of a need/product overlap and don’t feel they got fair consideration, all it takes is the vendor to tap into that access to create a whole mess for those tactically trying to find the best solution.

IT Executive: “Hey, I know we are looking for a product to solve X. Our partner ABC Vendor says they have it and we can easily use it. I agreed to a proof-of-concept starting next week.”

Now everyone has to participate in this executive “suggested” POC rather than reached out prior to the vendor or the executive in order to head off this undesired body of work with an already known lack-o-fit outcome.

Additionally, make sure you get a good handle on the history of exiting vendors you might be prepared to rule out. Does your company use any of the vendor’s components in your products? This is most prevalent in the manufacturing sector where the buyer and supplier lines can cross. Does the vendor do other business with your company such as hold a line of credit or use any of the company’s leasing services? Both come into play heavily in the financial services space. Is one executive related to a vendors executive? I once was aware of a relationship between a member of the board of directors of the company I worked who owned a small commercial electrical company and thus you always saw people with that logo on their shirts pulling cables in the data center.

Tip: When considering new technology that has some product overlap with an existing vendor, don’t be quick to rule out that vendor without ensuring there is truly an obvious feature to need gap as well as engaging the vendor and individuals with whom the vendor has access to be aware of any non-traditional relationships.

Next Hurdle … look for additional articles in this series for more hurdles and some tips to over come those hurdles.

, , , , , , , ,