It's clear that our once-a-year, work-your-way-through-a-slide-set approach to computer security training doesn't work. Even with this training, people still write down their passwords, click on links in emails from untrusted sources, and download free software with unknown provenance. For example, last year, 10,000 New York State employees were sent a phishing email to test their ability to recognize suspicious email and links. Three-quarters of the recipients opened the email, and 17% clicked on the embedded link.

If there were any lingering doubts as to social media's potential to attack an organization's brand or reputation, they now have been laid to rest. The most recent incident involves an undercover video circulated by an animal rights group that shows alleged cruelty at a

In case you have forgotten your high school biology, convergent evolution occurs when different organisms from different genetic lineages acquire the same trait. Bats and birds both have wings, even though they do not share any ancestor with wings.

David Anderson describes Kanban as an evolutionary change method.1 In comparison to other agile methods, Kanban can be introduced with little changes. But what are the differences between different methods? And is there a way to handle changes more successfully?

I've been doing architecture for close to 20 years now and have built my practices based on what I've read, studied, and researched, and also from my experience of what works with clients.

[From the Editor: This week's Advisor is from William Ulrich's introduction to the November 2011 issue of Cutter IT Journal "Business Architecture in Practice: Lessons from the Trenches" (Vol. 24, No. 11).

For the last decade I have been asked, "What is the ROI for collaboration?" I have come to several conclusions about this: one, that it is the wrong question to ask (and is a trap in itself) and two, everyone wants collaboration, but no one seems willing to pay fo

One of my favorite sayings is from former US President Teddy Roosevelt, who once said that “Risk is like fire: If controlled it will help you; if uncontrolled it will rise up and destroy you.”

Mobility is now one of the top strategic priorities for organizations. In fact, supporting mobility is seen as so important that some organizations are offering employees the option of using their own personal devices.

Cloud computing discussions are fraught with apprehension about security, privacy, interoperability, reliability, and so on. While the advocates of cloud computing emphasize the importance of IT governance to address these issues,1 most of the practitioner literature is confined to surface-level analysis of the cloud computing concerns. Here I will focus on the nuances of some issues. In doing so, my first goal is to stimulate more thought about all issues that can mar cloud computing.

The Cutter IT Journal from August 2011 asks, "Devops: A Software Revolution in the Making?" (Vol. 24, No.

Last month I began an Advisor series that I am unofficially calling the "Scrum Ain't Enough" series (see "Agile

What should your "enterprise social media adoption roadmap" look like?

Consider this Advisor a very pragmatic recommendation to the software development manager/director/VP. I have a feeling that the opinion I express here might get me in hot water, but what would life be like without some risk?

I was recently asked by a client to evaluate a product in terms of scalability. The client had invested in a custom case management system that had 100 users and wanted to know whether the current architecture would support scaling to 3,000 users.

Security of information is a hot topic these days. That is probably because cyber crime has reached a level of popularity that far outstrips the drug trade in terms of ROI for everybody from old-fashioned Mafiosi types to any kid in the Ukraine with a computer. And given the fact that crime on the Internet is all about money, any CEO who does not take all of the steps necessary to secure their organization against cyber attacks is rolling the dice with their company's assets. At least that's what current doctrine would like you to believe.

First came the realization that the collective knowledge of an organization or, for that matter, the individual knowledge of its members, is not solely held in libraries of documents.

In the first installment of this Advisor series (Reflections on Innovation, Part I: An Idea, 29 September 2011), I suggested that you can conceive the idea of something -- its perfect,

Adopting agile as an operating methodology involves more than just operational change, it encompasses a mindset change.

Business process modeling lies at the core of all attempts to visualize and manage business processes.

Recently I had occasion to review software engineering position descriptions to try to understand what skills were sought after for entry-level software engineers. Much to my chagrin, I found that the top-level requirements, and for the most part the secondary requirements, made no mention of knowledge of how to develop secure software, how to avoid coding vulnerabilities, how to do threat modeling, and so on.

A recent experience with my ISP got me thinking a lot about the role social media can play in customer service and how companies looking for immediate payback may be missing the bigger picture when it comes to social media monitoring and analysis.

In the literary classic The Great Gatsby, Meyer Wolfsheim hints at some shady business "gonnegtions" (an intentional mispronunciation of "connections"), suggesting that there's money to be made if the protagonist is a fellow "businessman" (read: criminal). Over the past few weeks, we've seen the Occupy Wall Street movement

The "secret sauce" of agile productivity at the team level is that everyone does the most important thing at any point in time. Instead of following a rigid plan in which it takes months, and possibly years, to act on feedback, agile methods are geared toward immediacy of feedback and subsequent adaptation.

A few weeks back, I wrote an EA Advisor in which I suggested that IT architects and engineers ought to have differing roles: architects should deal with high-level design and engineers with the detail technology ("