How IT is not aligned with business

One of the hot topics on IT related web sites lately is aligning business and technology goals.  While I think there are plenty of things business people can do to get more out of their technology (and that could be an entire discussion on its own), I’d like to focus on what technologists can do bring more business focus to their jobs in this post.

Most technologists I’ve spoken to believe quite strongly that they understand business and have what it takes to design business applications, yet most of them fail in doing so.  Here are some examples:

What’s the best way to develop a mobile application?  Web, native application hand-written for each environment (Android, iPhone, Blackberry, etc.), or a third-party solution that creates custom apps for each environment?

That was a question I had overheard at a user-group meeting describing the strengths and weaknesses of different third-party solutions.  Why does this developer think he’s business-focused?  Implicit in his question about what is the best way to get information to users of mobile devices; he is thinking about the balance between time-to-market (and therefore development costs) and creating a smooth, understandable interface for his users.  Where he needs to improve is that he fails to understand that the appropriate technology used will depend on the circumstances.  When time and budget is the primary issue, going with the easier-to-produce web site built for mobile apps is likely solution.  When impressing your customers or creating the most intuitive interface is needed, creating native mobile apps for each platform used is probably the way to go.  In all other cases, you have to determine the best approach that best balances the needs of your users with your budget.

Which is better, ASP.NET WebForms or ASP.NET MVC?

This was a real discussion I had with two very good technologists.  One argued that WebForms was the better technology because it had all sorts of inclusions increasing developer productivity.  The other suggested that MVC was the better technology because it resulted in cleaner HTML, and therefore you could write highly-interactive websites with it more easily.  Implicit in each argument was the business need: the WebForms guy was thinking about cost per feature, the MVC guy was thinking about creating websites with the “wow” factor with the lowest possible cost.  Here again neither technologist thought that the appropriate technology for a situation would change on the situation.

Do you have any SharePoint needs?  Do you need help with reporting?

One time I was on a sales call and the salesman asked these questions, pretty much in these words.  From a sales standpoint for a consulting organization, these questions make sense because they’re easy for us to fill.  Do you have any SharePoint needs?  If so, great!  I have a SharePoint developer right here ready for you….  Unfortunately for sales people, business problems usually aren’t so straightforward that you can just drop a piece of technology into the business and reasonably expect problems to be solved.  Instead, we as technologists should be looking at the underlying business problems first.  For example, instead of asking “Do you need help with reporting?”, ask “Do you feel that the information you are getting is sufficient for your decision making?”  Then you can start a conversation about what the problem actually is.  Is the business having problems interpreting information they already have?  Is the business having problems storing and digesting the information that they are getting?  Is the business having problems gathering the information they need in the first place?  All of these problems can be solved with technology, but reporting will not always be the solution.

To start solving this problem, we as technologists should start with the following:

• Understand the business problem first before trying to create a solution.  As in the example above, insufficient knowledge cannot always be solved with reporting.
• Explicitly state and agree on acceptable risk (downtime, security, errors) and associated costs.  Most developers I know have their own risk tolerance, but rarely actively think about it, much less communicate it effectively.
• Remember that your job is to solve a business problem, not implement a specific technology.  Just because a particular solution is easier to implement or cooler to create, doesn’t mean that it is appropriate for the circumstances.

Obviously following these three steps will be insufficient to bridge the gap between business and IT, but if we all could do it, it would at least be a start.  Keep watching the blog, as I’m planning a post about what training might be appropriate for technologists.