Stuck in a Rut

Forbes has a series of interesting articles (part 1 here, part 2 here, and more to come) on the potential value of Enterprise Architecture(EA), written by Dan Woods, of their CIO Central group.

He begins the series by citing Lens Fehskens of the Open Group, who cites three levels of maturity that IT organizations can progress through:

Level 1: Getting technology to work at all
Level 2: Getting technology to do the right thing for the business
Level 3: Adapting technology to do the right thing efficiently

Fehskens argues that most companies are trapped at level 1, basically spending their time putting out fires. Woods argues that the “Raw Technology Persona” dominates at this level – where technology is implemented for its own sake, as opposed to for the benefit of the business. This topic, by itself, warrants extensive exploration, but I’ll leave that for another time.

More interesting is that the development of an architecture can provide the means for an IT organization to escape from level 1. This is because a properly defined architecture can provide a roadmap that describes both how IT is creating value for the organization and how new technologies and opportunities can, or can not continue on that path. If a technology doesn’t fit in the architecture (or presumably any system vs. a specific technology), the decision can be made to not pursue the technology. Of course, it is also imperative that everyone understand that EA is a process, and an expensive, difficult one, at that.

This last bit in the first article really caught my eye. The development of a proper strategy should be difficult and time consuming, and nobody should get locked into a non-changing strategy. The strategy, then, should primarily be about the strategy. Make the development of a long term, progressively elaborative strategy be the goal, and everything else is more likely to fall in line. I recently was speaking to a friend who indicated their company has agreed to a 5 year plan to harmonize 18 of their sites. I was amazed, because most companies don’t really work in 5 year horizons. Frequently they work in next quarter horizons. If they stick to their plan, I’ll be even more surprised.

The second article goes on to describe how the architecture leads you up the ladder, because you begin to understand what the business needs, and how technology supports that. Over time, as the architecture and organization mature, the vision becomes even more cohesive, where the interplay between technology and the business is viewed across portfolios and the entire company.

Woods also points out that there is a risk that, owing to the complexity of the methodologies (TOGAF occupies 750 pages), organizations can become absorbed in the process, and make the entire exercise about it instead of the desired result. Once again, the technologists can find themselves implementing a technology (or in this case a methodology) for its own sake.

Perhaps, then, the first step down this road is not convincing senior management to fund the process fully, nor to implement an architecture program. Perhaps the proper first step is for all of us technologists to agree that the success of the business is what is most important.

What Corporate IT Can Learn from Apple

There’s been an interesting couple of articles in the past week about Apple that hold some interesting lessons for those of us doing IT in a corporate setting. I’ll take the last first, a story in the Wall Street Journal about Apple’s successful retail stores.

I’m hardly an expert in retail sales, but one point in this story provides an important insight we can all use: “According to several employees and training manuals, sales associates are taught an unusual sales philosophy: not to sell, but rather to help customers solve problems. “Your job is to understand all of your customers’ needs—some of which they may not even realize they have,” one training manual says.” They go on to quote one employee who said, “You were never trying to close a sale. It was about finding solutions for a customer and finding their pain points.”

Frequently, even in corporate IT, there is a tendency to want to close a sale. I’ve got a tool we’re deploying, or a skill you can use. More frequently the sale is for a project – usually several. For anyone in the Business Analysis space, and I use this term somewhat broadly, a solid project portfolio is demonstrative of your value. Therefore, the point is always to have a good project list in your pocket that can be presented to senior management. This mindset runs all the way to the top. Frequently, the CIO demonstrates value to the CEO and board by having a robust portfolio of programs that IT is working on. What would happen if portfolio size was no longer much of a metric?

The challenge here is, of course, how do you measure IT effectiveness? For Apple, its straightforward – you look at the sales numbers per square foot. In a corporate IT environment, you would need to come up with both robust measurements of customer satisfaction, and then probably some good stories to share with management exemplifying this alternate approach. This is hard work, and a different way to approach IT management.

The other lessons come from an article at TechCrunch on the announcement of Apple’s iCloud offering. The focus on this article is the now famous Steve Jobs line, “it just works.” He proposes that users are generally not interested in how something works, nor are they particularly interested in having to learn a complex series of button clicks and selections, along with deciphering technical jargon, in order to make an application or system work. Some are, that is for sure, but most aren’t.

One of the fundamental challenges in many systems deployed in the life sciences industry, especially with the niche systems, is that they don’t “just work.” Interface design tends to be an afterthought, at best. Usually, the core users of the system get used to how to make it work, but many more casual users never do. I’ve seen with EDMS, with LIMS, with financial apps, with… just about everything.

If those of us responsible for implementing solutions made it a key point to ensure that the solution “just worked” at the end of the day, I wonder how much easier all of our lives would be.