Todd Biske: Outside the Box

All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.

Sometimes a simple message can be the most powerful. In a recent discussion on a SOA Consortium phone call, I made the comment that IT needs to shift its mentality from provider to advisor. I hope that most people read this and view it as completely obvious, but recognizing the fact and actually executing against it are two different stories.

Let’s look at two trends that I think are pretty hard to argue against in most corporate IT organizations. The first trend is to build less stuff. Building less means that we’re either reusing stuff we already have, or acquiring stuff from some other source and configuring (not customizing) it to meet our needs. This could be free stuff, COTS, SaaS, etc. The point is, there is no software development required.

The second trend can be summed up as buy fewer (none) servers. Virtualization, data center consolidation/elimination, and cloud computing all have ties back to this trend, but the end result is that no one wants to build new data centers unless data centers are your business.

So, if you accept these trends as real, this means that IT isn’t providing applications and IT isn’t providing infrastructure. Then what is IT providing? I would argue that rather than looking for something new to “provide,” IT needs to change its fundamental thinking from provider to advisor or be at risk of becoming irrelevant.

Am I simply stating the obvious? Well, to some extent, I hope so. What should also be obvious, however, is that this change in role at an organizational level won’t happen by accident. While an individual may be able to do this, redefining an entire organization around the concept is a different story. A provider typically needs to only understand their side of the equation, that is, what they’re providing. If you’re a software developer, you understand software development, and you sit back and wait for someone to give you a software development task. Often times, the provider may establish some set offerings, and it’s up to the consumer to decide if those offerings meet their needs or not. An advisor, on the other hand, must understand both sides of the problem: the needs of the consumer and the offerings of the provider.

To illustrate this, take an example from the world of financial services. A broker may simply be someone you call up and say, “Buy 100 shares of APPL at no more than $200.” They are a provider of stock transaction services. A financial advisor on the other hand, should be asking about what your needs are, and matching those against the various financial offerings they have at their disposal. If they don’t understand client needs or if they don’t understand the financial offerings, you’re at risk of getting something sub-optimal.

IT needs to shift from being the technology provider to the technology advisor. Will people outside of IT continue to hand-pick technology solutions without the right breadth of knowledge? Sure, just as people today go out and buy some stock without proper thought of whether that’s really the right investment for them or just what everyone else is doing. The value add that IT needs to offer is the same that financial consultants do. We provide significantly better depth of understanding of the technology domains, along with the right amount of understanding of the business domains of our companies to advise the organization on technology decisions. For the non-IT worker that loves technology, it should be seen as validation of their efforts (not a roadblock).

The final message on all of this, however, is that I believe architecture plays a critical role. To actually build an advisory organization, you must categorize both the technology and the business into manageable domains where people can build expertise. Where does this categorization come from? Architecture. Taking a project-first approach is backwards. Projects should not define the categories and the architecture, the categories and desired architecture should define the projects.

So, you can see that this simple concept really does represent a fundamental shift in the way of thinking that needs to occur, and it’s one that’s not going to happen overnight. If you’re a CIO, it’s time to get this message out and start defining the steps you need to take to move your organization from a provider to an advisor.

7 Responses to “IT Needs To Be More Advisory”